ブログ

みなさんこんにちは。@ryuzeeです。

答えはHで、上のどれでも無いです。 プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではありません。 アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならないのです。

以下いくつかよくある例や思ったことの補足をしておきます。

• RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、というわけではない。ツールは道具であり、価値の実現に寄与して初めて価値があるといえる
• したがって、自分たちにとって価値の実現に寄与できる！と思う機能は現場ごとにも違うだろうし、ツールの全ての機能を使う必要性はない
• ツールの機能は一般的に「最高にうまくいっているチームはこうしてるよ！」というモデルをベースにして開発されるので、チームの成熟度が低いうちにツール化に走ると、かえって混乱に陥る可能性もある。もちろんツールをうまく使いこなせると生産性はあがる
• TDDやCIやペアプロはウォーターフォールにだって適用できるし、やっている現場は多々ある。アジャイルにおけるプラクティスがウォーターフォールにおいて排他なわけではない
• 一気に完璧なチームができ上がるわけではなく、チームのアジリティの向上はプロジェクトを通じて改善のループを回して、反映していけるかどうかである
• 現状がうまくいっていても、もっとうまくいくかもしれない。改善をやめた時点で、思考停止→組織の力が衰退していく
• そういう意味でも、アジャイルな開発プロセスを、書面で標準化して守らせよう、というアプローチを全面的に採用しない方が良いだろう。マイクロソフトにおけるVisual Studioの開発は多数のチームから構成される大規模分散開発だが、最低限のルールと品質チェック項目（クオリティーゲート）以外については、各スクラムチームの裁量が多い