これは JIRA ワークフローの使い方に関するブログ 2 部シリーズの第 2 部です。第 1 部の記事である、最高のワークフローを作成する方法、を読まれていない場合、まずそこから読み始めることをおすすめします。すでに読まれている場合、考えられるすべての質問に対する回答を本稿中に見出すことができるでしょう。この記事では、組織において、より効果的にワークフローを用いる方法を確立するのに役立つ実践的な内容を主にとりあげているからです。
私たちが仕事で毎日用いる物の多くは、ワークフロー内で説明できるライフサイクルを持っています。記事第 1 部の図書館の例に戻って考えると、書物は、そのサービス・ライフの終りに達するまで、チェック・インとチェック・アウトを繰り返し、その後回収されます。ソフトウェア製品のバグは、ログされ、レビューされ、修正され、検証され、その後クローズされます。次に自分で検討しなければならない質問は、我々はワークフローからどのようなデータを取り出したいのか? ということです。次に、ワークフローの 4 つの主要な要素を検討してみましょう。
- ステータス—-どこに
- 担当者—-誰が
- 解決状況—-何故
- トランジション—-いかに
ステータス
ワークフローの各ステータスは、課題のライフサイクルにおける異なるフェーズまたはプロセスを表現します。 JIRA Agile の場合、各課題のライフサイクルに渡って仕事の流れを示すボードを作成するのは容易です。次に、実際に使われているボードを見てみましょう。
仕事の各フェーズ、および各フェーズに含まれる課題の個数が見てとれます。 フローを最大化したいチームにおいては、コード・レビューのようなものに対して進捗中の総量に制限を簡単に設定できます。課題のバックログがレビュー待ちとして積み重なりすぎないようにできます。上述の例では、レビュー待ちの課題が多すぎて、JIRA Agile がコード・レビューのカラムをハイライト表示しています。アジャイル・ボードを用いるメリットの 1 つは、ワークフローがコア体験の一部となることです。 1つのカラムに複数のステータスが存在しうることに注意してください。例えば、想定されるボード利用者がチーム外部の利害関係者だった場合、進捗中とコード・レビュー が同一のカラムに存在することができます。彼らには、両方のステータスが「進捗中」を意味します。
一連のリリースにおいて作業がどこまで進んでいるのかをハイレベルで把握したい場合にはどうでしょうか? 2 次元フィルター統計ガジェットが私の頼りになるソリューションです。X 軸にステータスを取り、修正バージョンを Y 軸に取って、合計を選択します。それにより表示されるものは、見やすいプロジェクトのマトリックスになります。任意の数字の上でクリックすれば、その課題が表示されます。
設定
実際のガジェット画面
担当者
メンバーが協同で仕事をする時に、より効率的にそれをできるようにするものがワークフローです。もしあなたが JIRA でプロフィール写真を使っていないとしたら、私は写真を使うことを強くお勧めします! チームでの貢献を表示することはとても重要です。関連記事の全ポイントを列挙したくはありませんが、これは一読の価値があります。 2 次元フィルター統計ガジェットにおいて、担当者フィールドを用いるように設定すると、チーム全体の仕事の分配が見やすくなります。チームのメンバーの誰かが致命的な課題をたくさん抱えすぎないようにするために、担当者と優先順位を同時に見ることは有効だと私は思っています。
解決状況
すべてのワークフローには「転換点」つまりワークフローのクライマックスがあります。 図書館の例に戻って、書物が回収されるとき、それは明らかに完了にされようとしています。ソフトウェア・エンジニアリングのワークフローでは、開発者が変更をチェック・インすると、その変更の元となる課題はライフサイクルにおける検証フェーズに入ります。課題が解決状況を有するという理由だけでは、それが完了であるという意味にはなりません。 繰り返させてください。解決状況を有する課題は、クローズされた課題とは違います。 図書館の例では、書物は、それが使い古されたからという理由により、回収されることもあります。替わりの本を待っている間のステータスとして、 オーダー・ペンディング (発注入荷待ち) と呼ばれるステータスを追加してもよいでしょう。
ブルーにハイライト表示されたトランジションにより、代替品が必要という解決状況がセットされます。 新しい本が受領されると、図書館は、新しい本のための新しい課題を作成します。ソフトウェア・チームの場合は、いったん開発者が変更をチェック・インすると、その課題の解決状況は修正済みと設定されます。その課題は誰かほかの人がレビューするべき検証状態へ遷移します。課題はまだオープンですが、それは「解決された」のです。いったん課題の解決状況が検証されると、 その後それはクローズされます。
解決状況を追跡するためにも 2 次元フィルター統計ガジェットが用いられます。しばしばエンジニアは変更をチェック・インすることを「私の仕事は終わった」と考えるでしょう。「解決済みだが未クローズ」の仕事を追跡するのにこのガジェットは有効です。進捗中の仕事の全体的なイメージを皆が持つことができます。
トランジション
前の記事で述べたように、トランジションは、マジックが起こる場所です。もし仕事が組織に流れ込む仕組みを理解したいならば、JIRA のクエリー言語、JQL を用いて課題を詳しく見てみるといいでしょう。 JQL は仕事が組織を通って流れる様子を詳しく見るのに役立つでしょう。検証を通過できなかった修正の数は、ソフトウェア・チームにとって重要な尺度となります。先月の検証に不合格の課題がいくつあったのかを見たいと仮定しましょう。
|
1
2 |
project = TIS AND STATUS changed FROM “Quality Review” TO “In Progress”
after –4w
|
組織においていくつのバグが修正なしに解決されるでしょうか? 不当な、または再現できない、という解決状況を有する課題のすべてを見るために JQL が用いられます。報告されたけれど修正されなかったバグは、関与した全員にとっての損失です。
|
1
2 |
project = TIS AND STATUS changed TO Resolved after –4w AND
resolution NOT IN (Fixed)
|
報告者 (reporter) と作成 (create) フィールドを用いることによって、作成 トランジションを問い合わせることもできます。JQL の関数 membersof() により人のグループの扱いが容易になります。product-engineering と呼ばれる JIRA で定義されたグループを持っているなら、コア・プロダクト・チームの外部でいくつのバグが報告されたか見ることができます。
|
1
2 |
project = TIS AND reporter NOT IN membersof(product–engineering)
AND created > –4w
|
状態間のトランジションを解析することは、どのようにすればワークフローを改善できるのかを理解する最良の方法です。特定の状態において渋滞していることに気づいている場合、その状態に遷移しようとしている課題、その状態から他へ遷移しようとしている課題の数と理由を見てみるといいでしょう。 いくつかの質問があります。
- その状態に遷移していくる全ての課題がきちんと定義されていることが言えるのか?
- この状態の課題のうちいくつの課題が前の状態に戻されるのか?
- どのくらい長く課題はその状態に留まるか? それはチームが予想した通りなのか?
- 何故、課題はこの状態に戻されるのか?
トランジションの追跡に JQL を用いることにより、ワークフローを改善してチームの仕事を最適化するための具体例が得られます。
視覚的ワークフロー追跡
ワークフローが最適化されているかどうか、どうやったら分かるでしょうか? JIRA Agile は、時間に沿って各状態の課題の数をマッピングする累積フロー・ダイアグラムを提供しています。ちょっと見てみましょう。
一般に、 我々は、各状態への遷移、およびその状態から外への遷移の一貫した流れを見たいと思います。1 つの状態がオーバーロードになっているとき、それは通常、ワークフロー下流にある別の状態が課題を求めていることを意味します。この不平等は、ワークフローの非効率性を助長します。4 月 15 日に始まるこの図を見てみましょう。 ブルーに表示された進捗中の仕事と、紫に表示された QA を待っている課題が見えます。4 月 15 日と 4 月 21 日の間に、QA を待つ課題の数が積み重なっています。このチームは課題の検証に十分な時間を使っていない、あるいは誰かが休暇中、あるいは仕事が予測より時間を取っている、のかもしれません。規則的に累積フローダイアグラムをレビューすることは、チームの各分野が互いに協調してうまく働いていることを確認するのに役立ちます。
ワークフローを活用しよう
改善するための最良の方法は測定することです。ワークフローの最大の単一のメリットは、 人々が協調して働いているかどうかを定量化して追跡できる点にあります。JIRA であれば、協同作業をしたいという願望を犠牲にする必要はありません。アジャイルのすべての事柄と同様です。今いる場所を基点として用いましょう。主な測定項目を定義しましょう。 結果を追跡しましょう。そして、必要な変更を行い、チームの振り返りを行いましょう。
また、ワークフローに関する下記のプレゼンテーションをご覧になり、ぜひチームで共有してください！
アトラシアンにおけるアジャイル開発のたくさんのヒントもご覧ください。
*本ブログは Atlassian Blogs の翻訳です。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2013 年 10 月 21 日 "Using Workflow Awesome"