アジャイル アジャイル開発のメリット・デメリット?

 2010/11/10

http://jp.meritdemerit.com/topic/712より。 なんか誤解が多いなぁと思ったりもするので、個別に突っ込みを入れてみる。 ○はYESと答えた人の数。×はNOと答えた人の数ね。

メリット

1.基本概念が強固なシステムに対し、ある程度までの枝葉を補足するのに有効
○ 14 × 0

なんじゃこりゃ?基本概念が強固=優先度の高いフィーチャーが決まっている、ということを意図しているならまぁ良い。 枝葉ってなんだろう?枝葉だったらそもそも作らなくても良いんじゃないかな。

2.ビジネスドリブン
○ 4 × 0

これはOK

3.価値が少ないドキュメント作成を極限まで省く方向性
○ 3 × 0

まぁ良いんだけど、ドキュメントより動作するソフトウェアを優先するという考えで、必要ならドキュメント作るからな。 ちなみに体裁にはこだわる必要がない(綺麗にデコレーションするコストに対してリターンは少ないだろ)のでwikiで良いよ。 んで顧客が求めてきたらCSSで装飾してPDFで出力するなり。

4.修正が必要な箇所を局所化し、仕様変更に強い
○ 1 × 0

それは実装の問題だ。例えばScrumだけではこれは担保できない。XPのユニットテスト+継続的インテグレーションが備わっていれば変化に対応しやすくなる。

5.開発コストが削減できる
○ 10 × 2

結果として削減できることは多いんだけど、それがメリットかと聞かれたら僕は違う答えをする。 「ビジネスのニーズに応えやすくなったので、投資対効果が良くなる」 「一括リリースでなく優先度の高いものからリリースするので、早期にマネタイズしやすくなる」 「失敗に早めに気づける(=リスクマネジメント)ので、プロジェクトを中止した際の痛手が少なくなる」

6.開発期間の早い段階から動くソフトウェアを目で見て確認できる
○ 10 × 5	

これに×つけるってどういうことなんだろう?スプリントやイテレーション単位で出荷可能な製品作らないんですかね?

7.流行モノではなく、近い将来標準となる
○ 6 × 3

まぁ変化を好まない層も沢山いるので近い将来か、と言われると微妙な気もする。 ただ僕はもうウォーターフォールでは開発できない。

8.PDCAサイクルを短く回せる
○ 3 × 2

Retrospectiveしませんか?そうですか。プロセス改善しない巻物規約アジャイルとかはやめよう

9.早い、安い、旨い
○ 3 × 3

吉野家行け

10.要望を的確に把握し満足度の高いシステムを開発できる
○ 6 × 10	

なんか受託開発っぽい話だな。ビジネス要件は通常プロダクトオーナーが出してくるので、顧客がもやもやしている要件を開発チームが勝手に推測する話でもないと思うんだけどね。必要ならプロダクトオーナーのサポートをしよう。

11.要求の変更を許容するようなアーキテクチャ
○ 2 × 6

というかYAGNIの原則で、中小規模の案件だったら前払いしすぎないようにはする必要がある。 一方で大規模開発の場合は、簡単にアーキテクチャは変えられないので、開発の序盤でアーキテクチャについては前払いする必要がある。

12.Eclipseのような大規模プロジェクトでも使われている
○ 1 × 4	

Eclipseはどうだか知らないけど、少なくともIBMのRational製品群やMicrosoftのVisual Studioはアジャイルで開発されている。

13.初期段階から携わった少数のメンバーかつ小さめのスコープ゚のシステム開発がしやすい。
○ 0 × 0	

この条件が満たされればどの案件だって楽だけどな。アジャイルかウォーターフォールかに関係なく自動化されているテストが用意されていて継続的にビルドできるんだったら途中での人の追加はそんなに問題にならないだろ。

デメリット

1.大規模なシステムには向かない
○ 27 × 1

こう言ってるのは日本だけ。海外では大規模事例も沢山あるし、Visual Studioなんかは3700人規模の大規模開発。 @KenTamagawaさんのアジャイル開発の本質とスケールアップを読むべし

2.オフショア開発に適さない
○ 6 × 0

オフショア側をどうやって扱うか次第。チームの1つとして組み込み、同じDoneの定義やプラクティスを適用できるのであればOK。 一方で全部丸投げしてオフショアでやらせるというのは無理。

3.見積もった工数が膨らんだ場合の負担に関しての調整が困難
○ 12 × 2	

一括請負契約するからそうなるんだよ。 スプリント単位で契約するとか準委任で契約するとか考えよう。 顧客もアジャイルという単語は知るようになってきたけど、それは状況によっては、仕様は自由に変えたいけど、払う金は最初に決めた分だけにして、それでも望んでいる機能が全部出来上がるから、という誤解をしていることもある。 納期と金額を固定したかったらスコープを可変にするしかない。以上。

4.1人1人がなるべくたくさんの役割を担うことが求められる
○ 8 × 1

クロスファンクショナルチームね。何が嫌なんだろ? 幅広く勉強するのが嫌なのかな?だったらこの業界から足洗うと良いね

5.習熟した技術者によってのみ(真の意味で)成し遂げられる
○ 6 × 2	

未経験のチームが自分たちだけでやるのはなかなか大変であることは同意。最初はコーチなり経験者を入れた方が良い。 ただ、習熟した技術者だけでチームを構成するか?と聞かれたらそうじゃないよね。チームで人を育てれば良いし、ペアプロやレビューの繰り返し、コーチングで段々チーム力が上がってくる。

6.適切な規律が求められる
○ 5 × 4

あんまり規律を求められた記憶がない。でもウォーターフォールは規律がなくても大丈夫なんですかね?

7.必要なドキュメントさえもを作られない場合がある
○ 5 × 10

これはアジャイルを誤解しているチームがよくやるパターン。動作するソフトウェアを重視といっているだけなので、必要なドキュメントは作る。これ知らないで何やろうってのかね。

8.わかりにくく、人によって都合の良い解釈がされやすい
○ 1 × 2

単に勉強不足なんじゃ?

9.アジャイルの容易さに溺れ転換期に本末転倒に陥りやすい。(柱に影響や柱より太い枝の追加など)
○ 3 × 8

アジャイルって容易ですか。すごいですねぇ。僕に教えてください。

 2010/11/10

サイト内検索


著作

寄稿

Latest post: