アジャイルかWFかの議論はやめよう。大切なのはWin-Winの実現
ソフトウェア開発はお客さまあってのもの。これだけ社会の変化が激しければ、仕様が変わっても仕方がない。直接変化がなくても、短期間の商品化を実現するために並行開発を推し進めるなら、予想外のこともあって当然だろう。
中間であれ、最終であれ、リリース後に変更を受け入れれば、複数リリースになる。また、リリース前であっても、最初のリリーススケジュールの変更なしに機能追加をするなら、一度にすべてをリリースできなくなるので、これも複数リリースになる。
このように、変更を受け入れるとリリースが複数になり、結果的にアジャイルの定義としてよく言われる繰り返し開発になる。
アジャイルの定義には、このほかにも要求が変化した際にリリース時期をずらさずに、スコープを変更すると言われることがある。これも、アジャイルだけの話ではない。
開発の予算があらかじめ決められていることは、よくあることである。大きな会社なら普通のことと言っても良いだろう(予備費を取っておいたり、別の予算を回すということはあるだろうが、それは別予算のプロジェクトを実施すると考えても良いだろう)。
予算が限定されていれば、2つの方法しかない、外注先に無理を言うか、優先度の低い機能を減らしてスコープを変更することだ。
このように考えると、仕様変更を受け入れるとアジャイルの要素が生まれる。もっと言うなら、仕様変更の発生時のプロセスを形式化、軽量化して、変化を前提にしたものがアジャイル開発ということになる。
このように、アジャイルと従来型の開発に切れ目はない。あらかじめどれだけ見込んでおくかということと、繰り返しの期間の長短だけである(それも、アジャイルと呼んでも良い境界を示せといわれると難しい)。
大切なのは、お互いにWin-Winの関係でいられるように、顧客満足度を高める計画が立てられるかどうかだと思う。
« [#TiDD] プラクティスにあだたぬチケット駆動開発 | トップページ | [#TiDD] RedmineとTracの入力項目「バージョン」 »
「私のアジャイル」カテゴリの記事
- 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)
「ソフトウェア」カテゴリの記事
- 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)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
コメント
この記事へのコメントは終了しました。
« [#TiDD] プラクティスにあだたぬチケット駆動開発 | トップページ | [#TiDD] RedmineとTracの入力項目「バージョン」 »
最終的な顧客満足度が大事であることについては激しく同意なんですが、WFにおいて、プロジェクト後半になってから仕様変更を受け入れつつ複数回リリースするのと、アジャイルにおいて、プロジェクトの早期から理想的にはイテレーションごとにリリースしていくのとでは本質が違う(Market Valueの実現タイミングが違う)と思うのですが、どうなんでしょう?
投稿: Ryuzee | 2010年9月19日 (日) 11時50分
ココログの通知が遅かったので、気付くのが遅れました。すみません。
従来の開発でもここまでできるという内容を別記事に書きました。もちろんアジャイルがふさわしいプロジェクトもありますが、そうでない場合もあると思います。
投稿: さかば(管理人) | 2010年9月21日 (火) 23時41分