使えるアジャイル開発の本 - SCRUM BOOT CAMP THE BOOK とプロセス -

ソフトウェア開発プロセスの定義は色々ありますが、モデルとして考えるなら

　　「選択的なタスクの集合」

だと思っています。特定のやり方を強制するのではなく、状況に応じて対応できないといけないと思っているからです。

これまでのアジャイル開発の本は仕組みや考え方のの解説が多く、多様性があまり無い物が多かったと思います。 SCRUM BOOT CAMP THE BOOKはスクラムで不足している内容を補っているだけではなく、多様性を与える事で使えるアジャイル開発の本であると思います。

守破離の危険性

CMMブームの際に議論になったのはレベル３(定義されたれレベル)の壁です。CMMで考える良いプロセスは、定量的で管理され（レベル４）、常に最適化される（レベル５）プロセスです。

しかし実際は、段階モデルに従ってレベルを達成していくと、レベル３でとどまる事が多いと議論されていました。これはレベルの達成に時間がかかって疲弊してしまうだけではなく、「ルールだから守れ」というトップダウン的な強制が思考停止を招くからだと思います。

アジャイル開発に置いても同じ事が起こりうると思います。それぞれのチームがルールだからと何も考えずに実践していれば、改善の考え方や仕組みが組み込まれていても、いずれおざなりになるからです。

ワークショップの危険性

ワークショップは特定の技術を体感して身につけるには効果的です。しかし、体験した印象があまりにも強く、講師が複数の選択肢を示していても記憶に残るのは唯一の経験でしょう。

これは開発の現場でも良く起きる事です。一度、プロジェクトで成功すると前提条件が変わっても同じ方法をとり続けて失敗するというパターンがあります。このような状況を避けるには、書籍や他の開発者との交流などで、より多くの判断可能な知識を得ておく事が重要です。

どのように考えてリリーススプリントの実施を決めるかなど、この本の様に示されていれば、現在のチームの状況を見定めた上で実施方法を判断する事ができるでしょう。

業務の開発では失敗できない

UltimateAgileStories iteration２のアジャイル放談で細谷さんが語られた様に、トラブルが発生した場合、ウォーターフォールは対策方法がわかっていてそれなりに鎮火できますが、アジャイル開発はその解決方法がこなれておらず、とんでもない事になると思います。

[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組みで書いた様に、私も過去にアジャイル開発で失敗していてうまくリカバリーできませんでした。この時は研究開発だったので失敗も経験のうちと考えられましたが、お客様の業務をになうシステムなら、大きな失敗はゆるされません。

プロジェクトを成功させるには、プロジェクトのゴールを明確にするだけでなく、リスクを明確にして対策を講じておかなければいけません。そのためには、プロジェクトがイメージでき、いざという時のために複数の手駒を用意しておかなければいけません。

設計時に複数のアーキテクチャを健闘した上で判断した方がより良いソフトウェアが実現できる様に、プロセスプログラミングにおいても、複数の方法を健闘した上で実践する方がうまくいくのです。

お客様の業務開発を考えたとき、ようやく使えるアジャイル開発の本が登場したと思いました。