これいつまでにできますか？と考えるとき、1日1個ずつPull Requestを出してマージしていけるとして、何個のPull Requestを出せば完成するか？と考えることが多い。
進め方の前提
- Pull Requestでの変更は、ひとことで言い表せる単位の粒度にしたい
- ❌ 〇〇を✗✗にして、△△は□□に、一方☆☆は＊＊にする
- ⭕ 〇〇を✗✗にする
- レビューが通る前に次々と実装していくと手戻りが大きくなる可能性があるので、並行して手を付けずに、1個ずつ順番にやりたい
- 大きいPull Requestを作ってしまうと理解が困難になり、レビュー漏れの恐れもあるので、無理なく見れる範囲にしたい
リソースの前提
- 実装する時間と、レビューから返ってきたときに返事したり、必要ならコードを修正する時間は確保したい
- 丸一日すきまなくミーティングだとソフトウェア開発する時間がなくなるため
- レビュワーは固定で1人にお願いしたい
- 長きにわたって開発する場合は、レビュー依頼が毎回別のメンバーに当たっても理解不能なため
1日1個Pull Requestを出していくのが理想のペース
上のような前提に立つと、1日1個Pull Requestを作ってレビューに出していき、それらのレビューを毎日通してマージしていく、というのが、普通に暮らしている場合に無理なく出せる最速のペースになる。
すみやかにレビューを通してもらうためには、タスクのタイトルを1個ずつ眺めて、もし、このタイトルのPull Requestが来たとして、レビューできそうかな？とイメージして、分けられそうだったら分解していくとよい。
そのうえで、見逃しがあってやることが増えたり、思ってたより難しい箇所に遭遇したり、夏休みを取ったり、納会があったりすると、ずるずつ伸びていくけど、基本は1日1Pull Requestずつ出していくので、残り10タスクあればだいたい10日で終わり、という計画になる。
開発中の機能をマージしていく方法については以前書いていた。
blog.sushi.money
不明点は先に明らかにする
最初の段階でやることのリストを作って、あとは上から順にやっていくだけにできるとよい。
全部のタスクの粒度が揃っていたら、1日1個ずつ進んでいけるので、カレンダー上に1個ずつタスクを並べていくだけでスケジュールを立てられる。
実現方法が不明瞭な箇所が残っていると、このような計画を立てられないので、最初によく知らない部分を調べていったり、ちょっと変更してみて思ったとおりに変化するか様子を見てみたり、詳しくないAPIを触る場合は、最初に仮の実装で呼び出してみて、動きを確認したり、ということをしていき、何をどうしたらいいか明らかにしていくとよい。
そういう調査系のタスクも「〇〇の呼び出し方を調べて感触を得る」みたいなタスクにして、カレンダーに並べておくと良い。
その調査タスクが終わった時点で、新たな事実がわかったら、都度やることリストに加えていって、残り何個の作業があって、どの順でやればいいんだっけ、という手順は明らかにしておく。
そこのリストの保持ができなくなると、残りなにをやれば終わりなのかわからなくなり、いつどのくらいのことをどれくらいの急ぎ度でやればいいかもわからなくなってしまう。
人は皆生きているのではなくて生かされている
本当に大急ぎな場合は、Pull Requestの粒度を小さくすることをあきらめて、毎日進められる限界まで進めてレビューに出したりとか、2並列で実装し続けられるようにして、2並列でレビューを投げ続けることもできるけど、そのような無茶をすると、レビュワーの負担が増えていき、レビュワーは他の仕事がなにもできなくなることでしょう。
この仕事は進んでるけど他の仕事がぜんぜん進んでないじゃん、ということになると、チームとしてはどちらがうれしいか？という議論になっていく。
