たまたまかもですが 1on1 で二人連続でこんな話になったので。需要があるかもと思い、自分が普段考えていることをメモしてみます。
前提
バックログの大きさ・小さくする考え方
バックログを作るとき（or 週初めのプランニングのとき）は、スプリントをまたがずに完了できる大きさにします。例えば一週間区切りだとすると、「みんなが一緒に取り組んだときに一週間を超えない大きさ」にするということです。
また、「今週やること」をリストアップするときは、当たり前ですが今週終わる量に抑えます。「このバックログの 30% くらいまで進めよう」みたいなことはなしです。
この二つの考え方を踏まえると、こんな感じの思考になります：
- やりたいことリストのうち、上から順に選んでいこう
- 一番最初のチケットは3日くらいで終わるか、じゃあいけるな
- 次のチケットは1日で終わるな、これもいけそう（合計4日）
- 3つ目のチケットは3日くらいかかるか…。 これ入れると溢れちゃうから考え直そう。
- 3つ目のチケット、実は開発内容がいくつか混ざってるな。
- 「検索条件を増やす」ってのを、条件ごとに小さいバックログに分割しちゃおう。
- お、そしたら小さくなったチケットが1日で終わるくらいになった、じゃあこれをやろう
- 元々「検索条件を増やす」だったもののうち、残りは来週だな。また週末に考えよう。
太字がめっちゃ重要です。これをすることで、「今週終わらせること」の信頼性を上げることができるのです。
タスクの大きさ・小さくする考え方
バックログには、いくつかのタスクを登録することができます。これについてはこんな原則で考えてみましょう：
- タスクはどんなに大きくても１日以内に終わるようにする
- 僕は普段は「午前中に終わるくらい」で考えます。三時間とか。
- 三時間思いっきり開発をして、それでも完了できないものは、多分自分にとって複雑すぎるので。
- どんなに大きくても、タスクごとにプルリクエストを作る（複数のタスクをまとめて進めない）
- 着手しないタスクには担当者をアサインしない
太字がめっちゃ大事です。自分がアサインされてたら、まとめて進めたくなっちゃうのが人間の性なので。
タスクやバックログをどう分割するか
『アジャイルな見積りと計画づくり』がとてもわかりやすいです。時間がなかったら 12章だけで OK です。
特に「曳光弾をとりあえず撃つ」のが重要です。詳しくは本を読んでほしいのですが、日本語だとこの記事がそこそこまとまってました：
まとめると、こんな感じです：
- バックログは「これ単体でリリースしても効果が検証できるような、意味のあるまとまり」にする（そしてなるべく小さくする）。
- タスクは曳光弾のような開発から始めて、ちょっとずつ骨組みに肉付けを行なっていく。
参考図書たち
- アジャイルな見積りと計画づくり
- スクラム実践者が知るべき97のこと
- アジャイルサムライ−達人開発者への道−
- 達人プログラマー(第2版): 熟達に向けたあなたの旅
- This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント
更新履歴
- 2025/02/14 - 表現がわかりづらい部分を整えました。
