開発リズム

←日々のリズム burndown←TRICHORD

このチームでの開発のリズムをこんな感じでまわします。また、残要件見積り・必要な作業時間把握・リリース機能把握には「タスクかんばん」と「バーンダウンチャート」を使います。(ポイント=常時結合&機能単位の短期リリース。おまけ:毎朝の再見積)

7/7  機種ごとのソフトウェア開発要件に合わせようとして、まちまちに計画していたイテレーション期間を 2週間に固定することにした。

ある開発要件の開発開始→納品のタイミングとチームメンバ増減のタイミングは、開発要件が複数平行して存在するので一致しない。 であるので、開発要件毎に要員計画をたてるのは無意味。

複数の開発要件に対応するためには、リソース(要員x時間)を固定し、そのタイムボックスに入るように要件を調整することで稼動を平準化する。これがコストや品質に良い影響を与えてくれるはず。顧客にとっても良いはずだ。

**開発工程のフェーズによって人を抜き差しする(コーディングになったら人入れて...テストになったら人抜いて...とかね。)のはもうやめよう。それを必要とするプロジェクト計画にしてしまうのはマネジメントの失敗に違いない。**