そもそもアジャイルって何だろう?

 2010/07/22
このエントリーをはてなブックマークに追加

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

Q:あなたは以下のどの理由でアジャイルではないのでしょうか?以下から1つ以上選んでください。

  • a デイリースタンドアップミーティングしていない
  • b ペアプログラミングをしていない
  • c TDDをしていない
  • d 象徴となるような人を雇用していない
  • e スクラムマスターがいない
  • f イテレーション計画ミーティングをしていない
  • g インデックスカードを使っていない

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

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

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