Reports機能による遅延プロセスの特定方法
ZenHubを利用する目的の一つとして、Reports機能の充実性によるプロセスの分析のしやすさがあります。
さまざまな分析方法がありますが、チームの遅延プロセスの特定という観点で以下2つを紹介します。
- Cumulative Flow Diagrams
- Labels in Velocity tracking
Cumulative Flow Diagrams
Cumulative Flow Diagramsとは、パイプラインの各レーンが時間とともにどのように変化しているかを見ることができます。
プロセスのボトルネック特定
ひとつの効果としてはZenHubのパイプラインの中において、どのプロセスがリードタイムがかかっているか、ボトルネックになっているかを可視化できます。
私のチームの例を出します。上で紹介した、カスタマイズしたパイプラインにおけるCumulative Flow Diagramsを例に見ていきましょう。
概ね良さそうな感じはしますが1点気になる点があります。
それは、「Doing」「Review/QA」の部分です。用語の意味ですが、Doingは進行中のアイテム（スプリントバックログアイテム）でReview/QAはレビュー中といった形です。
- Doing = 4
- Review/QA = 6
となっており、Review/QA、つまりレビュー中のものが溜まっていることがわかります。
実際には、Doingのアイテムの開発自体は終わっている状態で、チームメンバーのレビュー時間が遅延していることでClosedせずにレーン上に残ってしまうと、スプリントの終わりにバーンダウンせずにベロシティーに反映されません。
つまり、このチームがベロシティーが安定しないという問題を抱えているならばここを見れば、単に開発力が追いついていないのではなく、Review/QAのパイプラインで溜まっているだけだということがわかります。
これを解消するには、皆でレビューする時間を決めたりそもそもパイプラインを見直すことも良いでしょう。
また、チーム内でDoingのWIP制限を設けている場合、つまりどのくらいマルチタスクで作業していいかについても、Doingの部分の数値がどのくらいになっているかでオーバーしているのかどうかが可視化できます。
Labels in Velocity tracking
Velocity trackingにおけるLabelsのフィルター機能における分析方法について記載していきます。
LabelsとはIssueに対して種別をつけることができる機能です。デフォルトで用意されているLabelsは以下です。
そもそも、なぜLabelsをつけるのでしょうか？ 意味としては2つあると思っています。
- 開発者側から見た作業の明確化。Issueの立ち位置を可視化する
- 開発プロセスの分析におけるチーム傾向とプロセスボトルネック特定
1の作業の可視化は、イメージしやすい通り、IssueのAuthors及びAssigneesにとって、そのIssueがどのような種別で、どのような意味を持っているのかを示します。
一番大事だと感じるのは2つ目の「開発プロセスの分析におけるチーム傾向とプロセスボトルネック特定」です。
簡単な分析手法としては、そのスプリント内で消化したIssueの中で、どのLabelsに紐付いたIssueが、どのくらいの割合を締めているかが直感的に見ることができます。
下図の例でいけば、Sprint12のベロシティーは「18」で、その中で「bug」のLabelsが紐付いたIssueがほとんどを締めているなど、Labelsの追跡を追加することでチームの傾向を特定できます。
ベロシティートラッキング（出典：Track team Velocity sprint-over-sprint）
Labelsの追跡を追加することで、チームの傾向を特定して例えば、スプリントごとに「bug」「enhantment」にどのくらい時間を割いたかわかります。
例えばチームとして、プロジェクトの最中にもかかわらず新規開発（enhantment）が全然見積もりどおりに進まないということがわかった際に、ベロシティートラッキングから「bug」や「ops」（運用・定常業務）のLabelsの割合が多いことが可視化されれば改善の第一歩目が踏み込めます。
まずは、このようなReports機能を使ってプロセスの可視化を第一優先で進め、ボトルネックを特定してから改善を言う流れが良いと思います。
まとめ
今回は「ZenHub×GitHub」を軸としたアジャイルプロセスの作り方と題して、アジャイルとの親和性やアジャイルプロセスを作っていくにあたってのZenHubの基本機能や開発プロセスを説明させていただきました。特にプロジェクトで、GitHubを利用している方にはZenHubはおすすめです。ぜひ、ZenHubを使ってのプロセス設計をしてみてください！
参考資料
- What is ZenHub？
- アジャイルソフトウェア開発宣言
- Create GitHub Milestones across a multi-repo Board : Help Center
- Using Epics in ZenHub for projects and user stories : Help Center
- Plan long-term projects with Release reports
- Creating Burndown charts in ZenHub using GitHub Milestones : Help Center
- Using Velocity charts in ZenHub : Help Center
- How the ZenHub team uses kanban boards in GitHub – For beginners
- Introducing Cumulative Flow Diagrams in ZenHub!
- Track team Velocity sprint-over-sprint
