大規模プロジェクトでagileやった結果がこのざまだよ - World Digger
知り合いのIT会社のすんげー偉い人の話を聞いたのでmemo 問題になったら消します。 【状況】 ・某大企業でのとある大規模プロジェクトをagileでやった。開発人数は50〜80人。 ・クリティカルでないシステムだったため、SI側/会社側もagileでやることをOKした。 →クリティカルなシステム（例えば携帯電話会社の料金システムのような、カットオーバー日をずらせないシステム）をagileでやるのは、先が読めないからいかんとのこと。 【問題発生】 /結局SI側もクライアント側もあまりagileを理解してなかった系 ・今までウォーターフォール開発の進捗管理になれていた役員（意志決定者）が、プロジェクト開始後しばらくしても収束することのない将来予測に(((( ；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ！→怖いからやめた。 ・必要とされるスキルに対して、個人のスキルが足りないケースが多かった。 →今
Agile失敗パターン三部作 - masayang's diary
Allan Kelly氏の「Agile失敗三部作」を適当に日本語訳してみた。 Agileで失敗する時 続・Agileでうまくいかないとき まだあった・Agileでうまくいかないとき 読めばわかってもらえると思うけど、「Agileだからうまくいかない」というわけではない。 未知の技術を採用したり、未知の領域のアプリを開発したりするような場合には、プロジェクトはそれなりの(把握できない)リスクを抱える事になる。だとしても、プロジェクト終盤で問題が発覚することが多いウォーターフォール型開発よりは、比較的早い段階で問題を把握できるAgileの方が有利ではある。ただしそれも、「問題が起きている」ということを把握できる実力がAgileチームにあれば、の話である。 二番目と三番目は、それぞれAgile計画管理、そしてAgile開発手法に特化した話だが、ぎゅっと圧縮すれば「経験がなければ問題が起きている事
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
