はじめに
前回の内容は、業務の種類を問わず、Jira Softwareを使う際に参考になる情報でしたが、今回はJira Softwareが盛んに利用されることの理由の一つともなった、スクラム開発を行う際のJira Softwareの使用方法について紹介していきたいと思います。
スクラムボードでプロジェクトを管理する
第1回の記事で紹介した、Jira Software Cloudの次世代プロジェクトの機能の一つであるスクラムボードを使ったプロジェクト管理方法について紹介します。
次世代プロジェクトを作成する
プロジェクトの一覧画面の右上にある「プロジェクトを作成」から、「次世代プロジェクトをお試しください」をクリックします。デフォルトの設定では、すべてのユーザーが「次世代プロジェクト」を作成できます。これにより、開発チームのリーダーはJira Software管理者に依頼する必要なく自分のプロジェクトを作成できるようになっています。
次世代プロジェクトは誰でも作成することができる
次世代プロジェクトを選択すると、複数のプロジェクトテンプレートのオプションが表示されます。今回は「スクラム」を選択しましょう。
ここで、スクラム以外のテンプレートの違いを簡単に説明します。
カンバン
- Trelloのようなカンバン形式でプロジェクトを管理することができます
- スクラムとの違いは、スプリントによるプロジェクト管理機能がありません
- オペレーション系の管理に向いています
- 後からスクラムに変更することも可能です
インシデント管理（Jira Opsを導入し連携している場合にのみ表示）
- インシデント発生時の重要なタイムラインが管理できます
- Slack、StatusPageやOpsgenieなど各種ツールとの連携によって、開発者たちはJira Opsに必要な情報をアップデートするだけで、ステークホルダーとの密なコミュニケーションができるように設計されています
- この機能については、第4回の記事で取り上げる予定です
注
2019年4月より、Jira OpsはOpsgenieに統合され、インシデント管理のツールとしてAtlassianのプロダクトにラインアップされています。
さて、スクラムを選択してプロジェクトを作成すると、以下のように3つの機能が有効化されています。
- ロードマップ
- バックログ
- ボード
バックログに課題を登録し、開発プロジェクトの目的を共有しよう
では、バックログに課題を作成していきましょう。
「＋課題を作成」をクリックします。まずは課題を作成していきましょう。課題の題名には「ユニットテスト」といった単語ではなく、このチケットが完了するとどうなるのか、見た人が分かるように書くと良いです。「ユニットテスト」の例では、「XXXのユニットテストをする」もしくは「XXXのユニットテストを書く」など動詞で終わると、より分かりやすい状態になると思います。
開発プロジェクトの場合、ユーザーに価値を提供できる最小単位が望ましいです。「ユーザーストーリー」の記法で書くと、会話のきっかけになり、開発者たちは課題の背景を知ることで、より良い実装のための糸口を見つけることができます。
スプリントプランニングを行って、計画を行う
チームでストーリーポイントの手法を使って見積もりを行いましょう。直近に予定されている3つほどのスプリントの見積もりが常に行えているのが望ましいです（※ストーリーポイントやスクラムについて理解を深めるには、『SCRUM BOOT CAMP THE BOOK』などがお勧めです）。
チームで見積もりを行うことによって、事前に開発チーム内の認識を合わせることができます。こうすることで、後から認識のズレに気づくことが減り、手戻りを防げます。チームでの見積もりを行った後、スプリント（デフォルトでは2週間）で実施するスコープを決定して、スプリントを開始します。
スプリント開始時には、終了日時とスプリントゴールを設定することができます。
スクラムのプランニングでは、スプリントごとのマイルストーンを正しく設定することで、プロジェクトが正しく進捗しているかどうかを検査します。
スプリントバックログの進捗をカンバンで管理する
スプリントを開始した後に「ボード」をクリックすると、そのスプリントのスコープに設定したユーザーストーリーが表示されたカンバンができます。
デフォルトでは、「作業前」「進行中」「完了」の列（レーン）があります。
ステータス（列）を追加して、チームのプロセスを定義しよう
デフォルトで用意されている3つの列で十分な場合もありますが、各開発チームのワークフローに応じて、ステータス（列）を追加しましょう。筆者が必ず入れる列は「レビュー」のステータスです。プロダクトオーナーの確認や、開発チーム内のコードレビューなどに利用しています。
それ以外にも開発チームで必要なステータスがあれば追加しましょう。次世代プロジェクトでは、このステータスを追加するために、Jira Software管理者への依頼は不要です。チームのプロセスはチームで定義することができます。
ステータスを追加するときは、ステータスごとの「完了の条件」をチームで事前に決めておきましょう。例えば「進行中」から「レビュー」へ移動するときには、以下のような決まりごとをチームとして作ると良いです。
（例）レビューへ移る時の完了の条件
- リポジトリにプッシュして、自動テストをパスしている
- ローカルでの静的解析ツールからの指摘をクリアしている
- 必要なテストデータを自身で作って、テストを実施している
などです。こうすることでステータスを移す時に、チーム内の品質のバラツキが減り、手戻りも少なくなります。
自動化のルールを作成して、カンバンの管理をラクにする
Jira Software Cloudの次世代プロジェクトでは、自動化のルールを作成することができるようになりました。この設定もJira Software管理者に依頼することなく、チームが行えるようになっています。
現時点（2019年3月）では、「課題を誰かに割り当てる」と「フィールドの更新を自動的」のルールが用意されています。設定は、左上の「その他アイコン（…）」から「ルールの管理」を選択することで作成できます。
課題の割り当てを自動的にしてみよう
例えば課題を「進行中」に移動させる時に、カードを操作している人（現在のユーザー）に自動的に割り当てることができます。この設定は、チームリーダーがすべてのタスクを割り当てるのではなく、自分で取りに行く（サインアップする）ことをワーキング・アグリーメントにしているチームにとってうれしい機能です。
または、割り込みなどでタスクが中断するときは、Jiraのステータスを「進行中」から「作業前（手付かず状態）」に戻します。カンバンでタスクを管理し、状況を見える化するためには、ステータスを正しく動かすことが重要です。
ステータスを動かす時に、同時に担当者をクリアすることで、今誰もそのタスクを担当していないことを分かりやすくします。
課題のフィールド更新のルールでは、開発チームのメトリクスを取得するために、開発着手になったら、「Start Date」のようなフィールドを自動で更新させて、実際に開発に必要だった時間の記録などを分かりやすく設定します。
チームのプロセスを自動化できるか一度考えてみよう
チームの中で自動化できるプロセスがあるか一度検討することで、より合理的にカンバンを運用できるようになります。
ルールの機能は、最近利用可能になった機能で、これからも機能追加を予定しているようです。Atlassianのロードマップは、こちらで公開されています。
「ロードマップ」を使って、プロジェクトを見える化する
ロードマップ機能は、次世代プロジェクトの目玉機能の一つです。このロードマップを常にメンテナンスすることで、開発プロジェクトの状況をステークホルダーに対して、見える化することできます。これで報告のための資料をわざわざ作る必要がなくなります。
「エピック」という課題タイプを使って、課題を作成するとロードマップに表示させることができます。
エピックには、子タスクとして複数の課題を紐づけることができます。これらの子タスクがすべて完了すると、このエピックが終了したとみなすことができます。
また、ロードマップは上から優先度が高いように並んでいる状態が望ましいです。優先度はドラッグ＆ドロップで並び替えできます。
エピックに紐づくタスクの見積もりを行った上で、紫のラインを調整しリリース日を決定しましょう。
「レポート」を使って、開発チームの進捗を把握する
レポート機能は、デフォルトでは有効になっていないので設定しておきましょう。「プロジェクト設定」→「機能」と遷移して、「レポート」を有効にできます。
2019年1月現在、2つのレポートが利用できます（※ベロシティレポートは、複数のスプリントを完了すると利用できるようになります）。
バーンアップチャート
バーンアップチャートでは、スプリントでスコープ設定したタスクの総量と、その進捗が分かるようになっています。
赤いラインは作業スコープを、灰色のラインは理想線を表しており、スプリント内のユーザーストーリーが完了すると、緑のラインで表示されます。灰色のラインと同じように緑のラインが伸びれば、スプリント内での理想的な進捗だと判断することができます。緑のラインが、赤色に達すればスプリントゴールを達成したことになります。
このレポートを活用し、定期的にスプリントの進捗を確認することで、スプリントゴールが達成できそうか常に確認しましょう。スプリントが終わる直前で達成できないことに気づくと無理な調整が必要になりますが、なるべく早く検知することで、ステークホルダーとの余裕を持った調整が可能になります。
ベロシティはチームの実行能力を計測することになる
ベロシティとは、開発チームが実際にタスクを完了できた実績値です。実績値をもとに計測するからこそ、唯一信頼できる指標となります。ベロシティチャートでは最大7スプリント分のタスク消化量が表示され、ベロシティを確認できます。
ベロシティとは、単位時間（1スプリント）あたりに消化できるタスク量であり、最新の4スプリント程度の平均値がその開発チームの実力です。
このスクリーンショットの開発チームの平均ベロシティは、13ポイントだと分かります。
大きな機能開発もストーリーポイントベースでの見積もりが完了していれば、ベロシティで割り算することで、その機能開発に必要な期間が見積もれるようになります。 例えば、新しい機能開発に必要なユーザーストーリーの合計値が24ポイントだとする場合、これらのすべてのユーザーストーリーを開発するには、2スプリントがあれば開発できそうということが分かります。
100mを12秒でしか走れない人が、次の週にいきなり6秒で走れるようにはなりませんよね？ それと同じで、開発チームが、「今週はこれぐらいの実績でした。遅れを取り戻すため、来週から倍の量のタスクを消化します！」という計画は無理です。
実績値をもとに見積もりをすることで、将来に対する見込みを立てることができます。
最後に
Jira Softwareを活用すると、アジャイルによるプロジェクト管理も可能になります。Jira Software Cloudの次世代プロジェクトでは、チームに必要な設定はすべてチームでできます。自立的にチームのプロセスを変更するアジャイルチームにとって、とても相性が良いツールと言えます。
また、Jira Software Cloudは機能無制限で7日間のトライアルをすることができるので、まずは触れて新しいUXを体験してみてはいかがでしょうか。
次回の記事では、インシデント管理のための「Opsgenie」について紹介します。インシデント発生時の重要なタイムラインが管理でき、開発者はOpsgenieに情報を更新することで、ステークホルダーに対してシームレスに情報伝達することができ、再発防止の検討など、振り返りにも利用可能です。
どうぞ、お楽しみに。
