アジャイルの定義 #agileto2010
アジャイルとかウォータフォールの議論をしていて、混乱する理由の一つが「言葉の定義」だと思っています。そんなことからアジャイルの定義を探していたのですが、Agile Tour Osaka 2010の牛尾さんの講演で明快に定義されていました。
方法論者がみんなで集まって共有できたのがアジャイル開発宣言で、それぐらいしか合意できなかった。これを実現すればなんでもアジャイルというものです。
なるほどと思って読み直すと、これまで私がアジャイルのつもりで行っていた開発だけでなく、お客さんがウォータフォールでと言っていた仕事の何割かは、まさにアジャイルでした。本来リリースは1回での依頼でしたが、無理な要望にこたえるためにリリース回数を分けさせていただきましたし、実行環境やアーキテクチャが不安なので、ものづくりを優先することもしばしばだからです(苦労してます)。
さて気になったのは、12の原則の一つ
「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
というものです。「ビジネス側」という表現が微妙ですが、これからすると世の中のアジャイルプロジェクトと言われているものの何割かはアジャイルでなくなるのではないでしょうか?
結局、アジャイルは4つの価値にある「あたり前のマインド」で、ウォータフォールがロイス氏の論文などの議論(名古屋アジャイル勉強会)にあるように、単純なままでは「問題のあるとされているモデル」だからいつも議論がおかしくなるのでしょうね。
そうそう、牛尾さんの講演でもっとも印象的だった言葉は「ファイアーウォール」です。リーダはプロジェクトを混乱させない重要な責任を担っていると言うことだ再認識しました。
« [#TiDD] チケット駆動開発の議論 | トップページ | 「ウォータフォールモデル」を超えた「エクストリームウォータフォール」 #agileto2010 »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
この記事へのコメントは終了しました。
« [#TiDD] チケット駆動開発の議論 | トップページ | 「ウォータフォールモデル」を超えた「エクストリームウォータフォール」 #agileto2010 »
コメント