generated at
プル型スケジューリング
なぜスケジュールを立てるか? → その通りになってほしいから
詳細に基づいて納期予算にコミットメントするのではなく、詳細化する能力に基づいてコミットメントする
詳細からスケジュールを立てる (プッシュ型スケジューリング) のではなく、スケジュールから詳細を設計していく
詳細を決めておくよりも、起こしたいときに起こしたいことを起こせるものについては、そのようにするとよい
バッファを持たせるよりもコストが小さくなる
大きなシステムも、依存の小さなシステムに分解するとよい
チーム同士も依存度を下げると効果的
フィーチャーチームを作り、顧客のフィーチャーの開始から終了までを手がけることがおすすめ
数か月から数年分の仕事が溜まっているようなキューには価値がない
顧客と開発組織の間のバッファとなり、話し合いを妨げてしまう
キューは要求の変動を吸収するために使うべし
キャパシティに応じて要求を制限せよ
スケジューリングタイムボックスの課題 (スコープボックスの課題ではない)
大規模で重要な要求やイニシアチブ (組織全体で目標を設定して取り組むもの。 「○○運動」 とかリーンの導入など) についてはポートフォリオ管理を行う企業が多い
役に立つ新しいやり方
種類によって開発作業を分類 (戦略的ビジネスイニシアチブや、ビジネスフィーチャーのアップグレード、インフラのアップグレードやその他 (保守等) など) に分ける
種類ごとに費やせるサイクル時間 (タイムボックス) を決める
種類タイムボックス年間あたりの回数
戦略的ビジネスイニシアチブ6 ヶ月2 回
ビジネスフィーチャーのアップグレード2 ヶ月12 回
インフラのアップグレード12 ヶ月1 回
その他 (保守等)継続キャパシティの 20 %
作業は機能横断的な常設チームに割り当てるのをおすすめ
スコープを目的とすべきではない : スコープは、顧客が望む成果を実現するための情報を得たうえで継続的に判断するもの

参考文献