ソフトウェア開発プロジェクトでは、どんな開発方式をとっていたとしてもスケジュール等に遅れが発生することはある(それが人の御業である限り)。そんな時にはプロジェクトを立て直す(リカバリーする)ためのプランを立てて実行することになるが、これをリカバリープランと呼んでいる。リカバリープランを自分で立てることもあるし、人のリカバリープランを見ることもあるけれども、おさえておくべきポイントがあると思う。 科学的に取り組む。精神論で立ち向かわない。 単純にブラックであること以上に、精神論で状況に立ち向かうことは関係者に多大な迷惑をもたらす。サイコリバカリーはよくない。 利害関係者と状況を共有することができない。 「今やってます」という回答を繰り返す、いわゆる蕎麦屋の出前状況になってしまう。 何らかのタスクの終了を待っている人が見通しを立てられない。 利害関係者からの協力がやりにくい。 もし少しでも状況

わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile

ソフトウェア開発におけるアジャイル手法の適用が話題になっている。生産性が格段に向上した事例や、従来手法に比べて成功確率が上がったというレポートも出ている。では、あなたの（わたしの）プロジェクトにも導入すべき？　その判断はちょっと待ったほうがいい。 アジャイル手法とウォーターフォール型開発の比較とバランスについて論じた書籍『アジャイルと規律』では、アジャイル手法と既存手法の比較資料について下記のように評している。 人は失敗より成功を報告する傾向にある。 先駆的プロジェクトは、新しい手法をいち早く取り入れる、かなり有能な人によって実施されている。 先駆的プロジェクトにはホーソン効果が働いており、注目を浴びている間は非常に素晴らしい成果を上げることができる。 これらのプロジェクトは過去の特に効率が悪かったプロジェクトと比較されている。 アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバ

ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ