アジャイルの勝ちパターンが知りたい

「ウォータフォールは何のメリットも無い」というエントリが熱いですね。 今夜は風が弱くて我が家も熱いわ〜

simplearchitect.hatenablog.com

自分も可能なら世界がアジャイルになってくれと思っているので、おっ！と思って読んでみました。

が、やはりモヤモヤしたままでした。 んー。

アジャイル系の記事って、「世界はみんなアジャイルってる」「ウォータフォールは正確な見積もり前提だから無理ゲー」「日本は遅れてる」みたいな内容が多いんだけど、具体的にアジャイルが日本で浸透しない理由と解決策を解説した記事が少ないですよね。 なんでだろう。 （すみません、知らないだけかも。いい記事があったら教えて下さい）

アジャイルを導入したい、という話を社内ですると上層部からは以下のような質問が出る。

• ドキュメント書かなくて本当に大丈夫なの？
• 大規模プロジェクトの場合、見積もりどうするの？
• 短いサイクルでリリースで品質大丈夫なの？

特にSIの場合、お客さんと契約する際の金額・開発期間、納品物等に影響するので、マネージャ陣は特に心配してくる。

それに対して、アジャイル系な回答は概ね以下の感じ （私の周りでの経験なので、一般論ではないかも。すみません）

• 書かないわけじゃないです。必要なものは書きます。
• 長期では見積もらないです。ただ早いサイクルでリリースしていくので、早期に触ってもらえます。
• テスト自動化します。（あるいは簡単な確認でリリースします）

ふ、不安すぎるっ

ドキュメントの「必要なもの」ってなんじゃい。主観なの？ソース読めってことなの？（読むけど）

SIがドキュメント多すぎで、そのくせメンテされなくて無駄なコストのデメリットはすごくわかる。

にしても、何を書いて何を書かないかの指針も無いとか、それでは上層部の説得が出来ないですよ。(´・ω・｀) ただドキュメントを書かないプロジェクトにしか見えなくなるやん。

アジャイル界では、まだ体系化されてないということなのかな？ 「書く、書かない」の判断基準とか、ウォータフォール時のドキュメントを「必ず書く、必要に応じて書く、時々書く、書かない」に分類して示してみるとか、何か必要なんじゃないのかな。

見積もりにしても、「結局開発は早くなりますから」とか言われるんだけど、いつ開発終了するか事前には分からないらしい。 事前に見積もるのは無理ゲーなのはわかるけど、お客様に何て説明して仕事を頂けばよいのか。

まずはやってみてください。とか言われても、失敗する気しか起きない。 上司やお客様に、どうやって進めていって、いつ終わるのか説明できる気がしない。

そもそもSIに当てはめるのがダメということなら、そういう話でも良い。 ただ、実践前に感じるおっさんどもの不安を解消できる説明が欲しいだけなんです。

アジャイルの勝利の方程式が知りたいというか。

ウォータフォールって、なんだかんだで中規模クラスなら成功体験を持ってる人って普通にいるんですよね。 で、それらが体系化されて日本の書店には、新人SE向け書籍としてまだまだ沢山売られている。

そんな人達にアジャイル良いですよって言うんだから、勝ちパターンを想像できる程度の説得力は欲しい・・・。 お願いします。世のアジャイル先輩たち。

アジャイルの成功パターンをどんどん発信してください。 ウォータフォール時代にこうやってた箇所は、いまはこうやって進めてる。お客さんに話してる。とか、対比して教えてほしいです。

あぁ。 我が社も早くアジャイルの波に乗りたいわー。

せめて自分だけでも（セコい）

アジャイルサムライ−達人開発者への道−