プルリクエストはコンパクトに

自分がこれまで携わって来たプロジェクトの多くでは、githubを利用してプルリクエストドリブンで開発フェーズを回しています。

この際、1つ1つのプルリクエストがなるべくコンパクトなものとなるように心がけています。数時間~長くても1日でプルリクエストが出せるような規模に開発タスクを細分化しています。短いものなら30分程度で完了するものもあります。

これは以下にあげるようなメリットを狙ってのことです。

進捗をリアルタイムに把握できる

最近では、開発フェーズの進捗把握にプルリクエストがどのくらいマージされているかどうかを用いています。開発計画上の予定と実績を比較することで機械的に進捗を把握しています。

この際、もし開発着手からプルリクエストのマージまでに要する時間が1週間であれば進捗把握の粒度も1週間になってしまいますが、マージまでに要する時間が1日であれば進捗把握の粒度も1日となります。

プルリクエストのマージという明確なものをトリガーに進捗を管理することで、個別に進捗をヒアリングするといった無駄な作業もなくなりますし、なるべくデイリーに進捗を把握することで進捗遅延に対するフォローをすぐに行うことができます。

ただ、実際にはプルリクエストごとに難易度が違ってくると思います。
そこであらかじめ、難易度A~難易度Eといったように難易度を付与しておいたり、想定される開発工数を決めておいたりします。
それを重みに予実を把握するようにしています。

手戻りを減らせる

開発フェーズでありがちなこととして、数日かけて開発したものをいざレビューしてみると求めていたものとは違うものになっており数日間の作業がほとんど無駄になってしまった、というものがあります。

これは非常に勿体ないので、1つ1つのプルリクエストをコンパクトにすることで、レビューで問題を見つけても手戻りがなるべく少なくなるようにしています。

開発着手前に設計者から説明を行なったり開発中も必要に応じてフォローしたりという対策もとっていますが、そもそも大きな手戻りが発生しない仕組みにしておくと安心です。

ただし1つ重要なこととして、プルリクエストが上がってきたらすぐにレビューを開始するというものがあります。プルリクエストがレビューされないまま放置された場合、開発者は問題点の指摘を受けられないまま次の開発に着手してしまい、結局手戻りが大きくなるリスクがあります。
そのため、レビューは最優先で行うようにしています。

成果を細かく反映していける

プルリクエストをコンパクトにしておき逐次masterブランチに反映することで、開発の成果をなるべく早く全体で共有できるようになります。

複数人で並行開発していると、「この機能を完成させるにはあの人が作成している機能で用意されるあのメソッドが必要だけど中々出来上がらないな、スタブでも作ろうかな、それともこれは後回しにしようかな」みたいなことになることもあります。
このようなことになりにくいよう、1つのプルリクエストで機能全体を完成させようとせずに機能を分割して小さなプルリクエストを複数出すようにし、成果を早く共有できるようにしています。

レビューが容易

大きなプルリクエストはとにかくレビューが大変です。最初にプルリクエストの内容を理解するのに時間がかかります。レビューでやりとりする回数も多くなりがちで、その度に大量の差分を相手にすることになるので正直つらいです。

プルリクエストがコンパクトなら、内容を理解するのに時間はかかりません。レビューのやりとりもそうは多くならないでしょう。
いろいろな仕事を掛け持ちしていると、会議と会議の合間などのすき間時間を利用して短時間でレビューすることができるのはとてもありがたいです。

プロジェクトにもよりますが、設計を理解しておりレビューを実施できるメンバーが不足しこれがボトルネックになることも多いので、なるべくレビューのし易いプルリクエストを出すように心がけています。
合わせて、設計の理解度が深まったメンバーは順次レビューも受け持ってもらうなどして徐々に改善するようにしています。

タスクがdoneする喜びを

中々レビューを通らずにいつまでも完了しない。モチベーションが下がる、ストレスを感じてしまう。といったことが起こらないように、
1つ1つのプルリクエストを小さくすることで少しづつでも自分の仕事が具体的な成果となっていくようにしています。

プロジェクトに新規参画したメンバーが、中々成果が出ずに焦ったり居づらくなったりして短期間で離脱されてしまうことがあります。このような事がなるべく起こらないよう、(プルリクエストに限らず)仕事が早期に成果となることをいつも考えています。

モチベーションの低下やストレスなどにより、チームを離脱してしまう優秀なメンバーを何人も見てきました。チームにとっては最大の損失ですし、離脱するにしても出来れば前向きな理由で離脱していただきたいと思っています。
手探り状態ではありますが、なるべくこのようなことにならない土壌を作っていきたいと常々考えています。

コメント

タイトルとURLをコピーしました