アジャイルができない理由は「イノベーションのジレンマ」か?

ウォーターフォールとアジャイルを比較する話は、違いを説明する都合で、実際によく話をすることがあるのですが、実際にウォーターフォールと比較すべきなのはアジャイルではないと思っています。書籍 More Effective Agileには「アジャイルと比較すべきはシーケンシャル開発である」と記載されていますが、そういったいわゆるウォーターフォール的な開発だとみんなが認識しているものと比較すべきなのは、「スケールされたアジャイル」だと私は思います。

いわゆるウォーターフォールをソフトウェア開発で採用するのは、PMBOK で必要なプロセスとドキュメントがしっかりと定義されていて、エンタープライズ開発で採用しやすいからです。これがなければどのように進捗や品質を管理すればよいのか?わからなくなってしまいます。

そこでもしウォーターフォールから切り替えるとするならば、切り替える先としては、「アジャイルを採用した小規模な開発」ではなく、「大規模な開発も扱えるアジャイル」が求められます。しかし、一般的なアジャイルのフレームワーク「スクラム(Scrum)」では、最大10名までのチームで扱える範囲の開発しか対応できそうにありません。これがフィットする規模の開発であれば、例えば社内システムの開発で小規模から始めるというのであれば、イメージしやすく「アジャイル(Scrum)でやってみましょう」と言いやすいでしょう。しかし、ソフトウェア開発を請け負う会社にとっては、多くの場合は規模が小さすぎます。もっと大きな規模のエンタープライズ開発に耐えられる方法が必要です。そこでついつい、Scrumを自分たちにフィットするように変えてしまう Scrum But になってしまいます。しかし、Scrum But は成功しません。その結果「アジャイルはダメだ」という主張になったり、完全にウォーターフォールのまま用語だけ変えた「なんちゃってアジャイル」が流行ったりするのだと思います。

Read More

完成の定義(完了の定義、DoD、Definition Of Done)から改善してみる

アジャイルコーチとして、あるいはスクラムマスタとして、スクラムチームの改善に取り組まなければならないとき、私がいつも最初に確認するのは「完成の定義(完了の定義、DoD、Definition Of Done)」です。

「スクラムがうまくいっていない」と表現されるとき、多くの場合、期待されるより開発のスピードが遅いということや、品質に問題があるということが起きています。そしてそれは、完成の定義が適切に記載されていない、あるいはそもそも完成の定義がない、ということが原因だったりします。

Read More

スクラムマスタ不在だとデイリースクラムをしない

これはよくあるケースだと思います。

毎日デイリースクラムもうまくやれているし、だんだんチームがアジャイル(Scrum)に慣れてきたかな・・・というタイミングで、スクラムマスタやリードディベロッパーがお休みで不在だったりすると、デイリースクラムがスキップされる。いつものデイリースクラムの時間に集まった人も、誰も発言をしないで、自然に「今日はしなくていいよね」と解散になる・・・なんということでしょう?!チームはアジャイルに慣れてきたのではなかったのか?!

これは、チームが Scrum のイベントを定義の通りに行えるようになってきたとしても、それはメンバーが全員スクラムを理解しているわけではない、というのが重要なポイントかと思います。

Read More

アジャイルは文化に踏み込む・そうじゃないと勝てない!

会社のトレーニング資料で話をするときにも、Scrum.org 公式のスクラムガイドを使って社外の人に話をするときにも、初めてスクラムを勉強する人のために概要を説明するときに、必ず伝えるようにしていることがあります。それは「アジャイルは文化に踏み込む、そうじゃないと勝てない!」というお話です。

Scrum.org スクラムガイド(日本語ダウンロードできます)

従来のウォーターフォール(PMBOK)では、プロセスやドキュメントに注目していて、組織の文化は問われませんでした。

しかし、アジャイル(スクラムガイド)には、スクラムの5つの価値基準として「確約(Commitment)、集中(Focus)、公開(Openness)、尊敬(Respect)、勇気(Courage)」があげられています。スクラムが成功するかどうか?は、チームのメンバーがこの価値基準を実践できるかどうか?にかかっていると明記されています。

Read More

代わりにコードレビューをやってくれますか?

私はコードレビューについて、少し反対派です。

というのも、コードレビューができる人って限られていて、大抵の場合負荷がその人に集中してしまうからです。ボトルネックとなって責められるか?バグの責任を一身に背負わされるか?そんなの誰だってやりたくない。本当に重要なところならともかく、何でもかんでもレビューしていたら、身がもちません。むしろコードレビューなんてしなくていいルール・仕組みにしておいても、どうせ本当にヤバいところはダブルチェックでレビューしあうでしょ?そういうところのために余力を残しておきたい。あるいは、そういう相談ができる相手がいない人は、結局レビューはしてもらえないのだから、本気で全力でやるしかない。だから、コードレビューを(ソース管理の制約やリリース判断として)ルールに組み込むのは反対。程度問題なんですが、いいバランスでやれるイメージがなかなかもてない・・・

Read More

リクエストをいただいたのでNuGetパッケージを更新・公開しました

今日、WPF Localization についてこちらのブログで紹介されていると教えてもらいました。そして使いたいので更新してほしいとのリクエストも。

そこでは、次の3点が指摘されていました。

  • 対応するクラス、プロパティが少ない
  • ライセンスが不明瞭
  • GitHub に上がっていない

早速、対応して新しいバージョンをリリースしました。

対応するクラスとプロパティに制限をなくし、Content、Text、ToolTip以外にも Titleなどのテキストプロパティや、FontFamily、FontSizeなどのオブジェクトや数値のプロパティをサポートしました。もし動かないプロパティがあれば GitHub の issues で教えてください。対応します。

GitHub はまだ場所を作っただけで、ファイルは上げていませんが。これまで個人の Azure DevOps ( 旧 Visual Studio Team Services ) で管理していたので、いったんそのまま開発してますが、次のアップデート時には移したいと思います。

アジャイル&DevOps ならこの本を読んで

先日、DevOps・アジャイルでよさそうな書籍を紹介してほしいと頼まれたので、ピックアップしてみました。

変革の軌跡【世界で戦える会社に変わる”アジャイル・DevOps”導入の原則】
分かりやすくアジャイル・DevOps導入の考え方が解説されています。実際に組織に導入するときに最初に読むのにお勧め。個人的にはメトリクスの話がわかりやすくお気に入り。

Effective DevOps ―4本柱による持続可能な組織文化の育て方
しっかりとDevOpsについて解説されている、おそらく現在一番スタンダードな教科書だと思います。

進化的アーキテクチャ ―絶え間ない変化を支える
実際にアジャイルでどうやってマイクロサービスを使ってくのか?について、より詳しい解説を読みたい場合に。

業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
現場の開発者向け、少しシニアナメンバーに(アジャイルやDevOpsをいきなり導入するのは難しくても)少しずつDevOpsのツール・方法を導入してみては?という実践的な視点で。

SCRUM BOOT CAMP THE BOOK
定番のスクラム解説の本、マンガ・ストーリーで解説されているので、まだアジャイルトレーニングを受けたことがない人が全体イメージを理解するのにお勧めです。

The Scrum Guide™
スクラムガイドは、簡潔に書かれているのでこれだけで勉強するには不向きですが、アップデートがないか?確認したり、全体をおさらいしたりするのに最適です。日本語版は https://www.scrumguides.org/download.html からPDFをダウンロードできます。

ブログに草を生やせるか?

ブログにGitHubの芝生( contributions graph )みたいな表示を載せたいと調べてみると、

今のところ、JavaScriptのライブラリで描画できそうなのが

Calendar Heat Map

あとは表示したい日付と数値をjsonで返してくれるサービスがあれば良さそう。GitHubの芝生をそのまま生やしたいわけじゃないので、これはできそう。最初はブログの投稿数を、と思いつつ、でも、SlidrshareやAzure DevOpsへのコミット数も、と欲を出すと終わらなくなりそう。Flowなどでできるかしら?

「良いとこどり」でなく本気でどれで開発するか?選んでください

アジャイルがうまくいかなくなる魔法の言葉があると思います。「いい所を組み合わせれば」この言葉が出てくると、私は、あぁこのプロジェクトはアジャイル崩れになって、失敗するだろうな、と思います。

良いとこどり、ができると思って皆、悪いところどりをして、結果としてウォーターフォールでもアジャイルでもない、ただのグダグダ、素人が初めて開発やってみました、みたいな失敗プロジェクトになってしまうのです。

Read More

連載 Good-bye CodedUITest(1) – Visual Studio でUI自動テストをどうすればいいか?

課題

これまで Visual Studio 標準の「UI自動テスト」機能であった 「コード化されたUIテスト」CodedUITest は、ついにVisual Studio 2019 での提供が最後になってしまった。これに変わるUIテストの自動化を考え、将来的に移行する準備を整えなければならない。

背景

Visual Studio 2017の「コード化されたUIテスト」の説明には次のような記載が追加されました。

clip_image001

Note
Coded UI Test for automated UI-driven functional testing is deprecated. Visual Studio 2019 is the last version where Coded UI Test will be available. We recommend using Selenium for testing web apps and Appium with WinAppDriver for testing desktop and UWP apps.

コード化されたUIテストは非推奨になりました。Visual Studio 2019で提供されるのが最後のバージョンです。Webアプリのテストには Selenium を、デスクトップとUWPアプリのテストには Appium と WinAppDriverを併せて使用することをお勧めします。

さようなら「コード化されたUIテスト」

私は一応、テスト自動化を含むTFS/Azure DevOps系の Microsoft MVP として、コード化されたUIテストを使用する方法を推奨してきましたが、残念ながらここまでということになりそうです。UIテストには、ここで推奨されているSeleniumやAppiumの他、沢山のフレームワークや商品がリリースされていて、それぞれ自分たちがやりたいことにマッチしているのを使うのが一番と思うのですが。Visual Studio標準のUIテストの機能として提供されている以上、まずはこれをお勧めし、不足を感じたら別のものを検討するのが良いのではという話をしてきました。しかしそれも Visual Studio 2019 までとなりそうです。

正直ショックが大きい反面、やっぱりそうかという感じもしていて。私自身、今後どのように人に薦めようかなというのを整理したいので、このブログを連載記事として書いてみようと思っています。第1回目は、「コード化されたUIテスト」Coded UI Test ってどんなものだったか?これからUIテストを作成したいのだけど、Visual Studio 2019 でこれを使用しても良いのか?ということが判断できるような内容を書ければと思います。

Read More