Proin Tincidunt

Cras Eros Elit


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

                                       

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

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

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

Read More

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

                                       

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

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

Read More