ソースコードから理解する技術-UnderSourceCode

手を動かす(プログラムを組む)ことで技術を理解するブログ

アジャイルな見積りと計画づくり(4)

「アジャイルな見積りと計画づくり」を少しずつ読んでいます。

また少し読み進めたところで、気になったところをメモっておきます。

◆「チームが成功する秘訣はチームメンバー全員が同意したコミットメントだという」(※1)

その通りだと思う。だだし現状ではリーダーが決めたスケジュールや機能を
黙々と実装するのが多いのではないでしょうか?

◆「見積もりはあくまでも『見積もり』であって保障ではない。(中略)
現実には、多くのチームで一番うまくいくのは、計画した作業が一日4〜6時間になっているときだ。」(※2)

◆「保守とコミットメント」(※3)
この節では、見積もりに通常の保守作業(本番環境の構築や問い合わせへの対応)を含めることを説いています。
常駐していると、確かにありがちです。。。

イテレーションの長さについて
イテレーションの終了時にユーザーからのフィードバックや計画の見直しをします。
なのでイテレーションの回数は少ないのは問題です。
本書では「プロジェクトの期間中にこうしたチャンスを少なくとも4、5回は用意すること」(※4)を推奨しており、
プロジェクトの期間に合わせて、イテレーションの長さを変えるとしています。

15章で著者はイテレーションの期間として2週間を奨めていますが、
確かに1ヶ月では長すぎるし、1週間では短すぎるでしょう。

この15章で、イテレーションの期間に2週間と1ヶ月を採用した2つのプロジェクトの成功例が載せられており、
参考になります。

◆一日の作業時間を見積もる
一日にプロジェクトに割ける時間は、4〜6時間。効率的なトヨタでさえ、80%。。。

確かに隣に座っているリーダーには5分おきに電話が掛かってきているような(笑)

◆スケジュールバッファについて
飛行機に乗るために空港へ行くときには時間に余裕を持たせる例(※6)や、
車の車間距離を開けること(※7)を例として挙げ、
スケジュールにバッファを持たせることを説いています。


※1 「アジャイルな見積りと計画づくり」 P174
※2 「アジャイルな見積りと計画づくり」 P175
※3 「アジャイルな見積りと計画づくり」 P176
※4 「アジャイルな見積りと計画づくり」 P182
※5 「アジャイルな見積りと計画づくり」 P196
※6 「アジャイルな見積りと計画づくり」 P203
※7 「アジャイルな見積りと計画づくり」 P213