Sean Osawaさん
  • コラボレーター
  • アトラシアン株式会社
  • Sean Osawa

アトラシアンにおけるアジャイル開発② 〜スプリント計画の方法〜

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

この連載では、アジャイル開発の3つの作法として「ふりかえり」「スプリント計画」「スプリントレビュー」を取り上げ、それぞれどのように取り組んでいるのか、3回に分けてご説明いたします。第2回の今回では、「スプリント計画」について考察します。

※【第1回】ふりかえりの方法 はこちらです

アトラシアンでは、「スプリント計画」というアジャイル作法を非常に頼りにしています。スプリント計画は、予期せぬ展開を最小限にとどめ、全体的なコード品質を向上するものです。私たちが経験から見出した、最も役立つスプリント計画の4原則を順に説明していきます。

Step1: 会議前にプロジェクトのロードマップを確認する

スプリント計画のための会議を行う前に、まずはプロジェクトのロードマップに目を通しておくことをお勧めします。ロードマップが最新のものになっていて、チームメンバー全員が目にすることができる状態にあるか確認しましょう。

ロードマップは、「エピック」と「バージョン」というアジャイルで重要なふたつの概念により設定されます。エピックとバージョンは、アジャイルプログラムの計画を根底から支えるもので、長い期間にわたって作業のデリバリーを追跡するのに役立ちます。アトラシアンの場合は、JIRAを管理システムとして使って管理をしています。

Step2: スプリント会議の前に行うべき、「バックログ・グルーミング」

スプリント計画を構成するタスクは、主に2点です。それは「バックログ・グルーミング (手入れ)」と、次回スプリントで完了すべき作業の決定です。

▶バックログ・グルーミングとは何か?

バックログ・グルーミングは、バックログの健全性を確認するものです。

健全なバックログとは:

  • 各作業項目に優先順位がつけられ、最重要作業が一番上に表示されている
  • 開発チームが作業を開始できる状態までしっかりと形成されたユーザーストーリーが含まれている
  • 各作業項目に対する最新見積もりが含まれている

アトラシアンにおけるバックログ・グルーミングは、本番のスプリント会議の前に、プロダクトオーナーとスクラムマスターを中心とした別会議で行う方が良いことを見出しました。開発チームメンバーについては、この先行会議への参加は任意としています。

実際には、チームはスプリント計画の数日前に短時間のバックログ・グルーミング会議を行います。約30分で、続く2回のスプリントで取り組む可能性が高い課題を優先順位付けします。すると、作業項目に含まれている情報が不十分であったり、プロダクトオーナーからより詳細な情報を得る必要がある、ということが判明することがあります。

これが、バックログ・グルーミングを先行する利点です。本番会議までにこのギャップを埋めることができ、実際のスプリント計画の際に時間を無駄にせずに済みます。先行バックログ・グルーミングを行うことで、スプリント計画時に様々な選択肢を検討したり、次回スプリントへの留保事項を検討する時間を長く取ることが可能となります。

▶Tips:チームアクティビティ

チームによっては、工数の見積もりに苦労することがあります。その際に役立つのが「ストーリーポイント」です。ホワイトボードを用いて、ストーリーごとに妥当なストーリーポイントの値 (0.5、1、2、3、5、8、13、20、40、100)をチームメンバーが選んでいきます。

そうすると、多くのストーリーでは1つの数値に票が集まります。チームで妥当な見積もりを引き出すために、有効なアクティビティです。ストーリーポイントの値に関して異論がある場合は、その理由を議題に話し合いを始めてください。

Step3: スプリント計画会議・本番 優れた計画がスプリントの手戻りを防ぐ

スプリント計画会議の焦点は、スプリント目標の設定と合意です。その中でも目標は、そのスプリントで完了可能だとチームが考える作業量になります。プロダクトオーナー、スクラムマスター、開発チームメンバーの全員が参加する必要があります。

アトラシアンでは、スプリント1週間当たり、最低1時間を会議に割当てることを推奨しています。例えば、2週間のスプリントを取り扱う場合、スプリント計画会議に最低2時間を割当てるということです。スプリント計画の会議日程は週の初めに設定するのが理想的です。そうすれば、週末近くに実施するより、開発中にチームのコンテキストとフローが中断される可能性が低くなります。

▶Tips:経験から学んだこと

スプリントのふりかえりとスプリント計画の会議を同時に行わないでください。ふりかえりを十分に消化する時間的余裕をチームに与え、スプリント計画会議に効率よく貢献できるようにします。2つの会議の間にランチタイムをはさむのもいいかもしれません。

会議開始時に、スクラムマスターはチームのふりかえりで取り上げられたすべての関連アクション事項を提示します。次に、プロダクトオーナーが製品や市場の最新情報を伝えて全員の足並みを揃え、より幅広いコンテキストを得られるようにします。

それらの報告終了後、実際の計画に関する話を始めるのはプロダクトオーナーの責務です。始めるにあたって、プロダクトオーナーはチームの平均ベロシティ (1 回のスプリントで完了した平均的な作業量)を使い、対象スプリントで取り組むべきストーリー一式をまとめます。これを「スプリント予測」と言い、カスタマーへ届ける価値を最大化するようにします。プロダクトオーナーは次の3要因も考慮してください。

  • 祝日、個人休暇、チーム全体のイベント
  • バックログでのストーリーの優先順位付け (最上位の項目を勧めることが理想的)
  • 一連の作業により、製品は最終目標に近づくか

チームがまだ新しく、利用できる妥当なベロシティがない場合、プロダクトオーナーはスプリント予測を提示すべきではありません。代わりに、チーム全員でそれを行います。各メンバーに参加してもらうことが重要です。まず始めに、チームはスプリント予測に関する最善の判断を出し、試行錯誤しながら、2、3回のスプリントを行います。チームのベロシティを確立できたら、その基準を使用してスプリント予測を導き出します。

そして、プロダクトオーナーがスプリント予測を提示したら、チームはそれに同意 (または調整)し、次のスプリントのアクションプランに同意します。

プロのアドバイス: チームは、各スプリントにおいて技術的負債を返済できるか検討すべきです。チームのバックログにあるバグをリストアップし、技術的負債について確認しましょう。

スプリント計画における次のステップは、ストーリーを順番に確認することと、各ストーリーを完了するために必要な作業内容の説明です。チームが計画を進める際、課題管理システムの各チケット内に要点を記録するよう誰かをアサインしてください。そうすれば後からその意思決定と根拠の両方を簡単に確認することができます。チームが検討すべき質問は次のようなものです。

  • ストーリーを定義した後に、それは変わってないか? チームが考慮すべき新しいコンテキスト情報はあるか?
  • ストーリーの見積もりは現在も妥当か? チームメンバー全員がその見積もりに賛成しているか? 異論がある場合、スクラムマスターはチームに再度見積もりを行わせること。
  • ストーリーを完了するのにどのようなタスクが必要か? サブタスクを活用して、並行して作業を行えるようにし、フローを最適化する。作業を分類中に独立したストーリーを見つけたら、別のストーリーを作成しそれに関するタスクを分類する。
  • ストーリーのテストから推測される事は何か? どうすればテストを自動化できるか?  (手動テストスクリプトは基本的に技術的負債であることに注意)
  • 専門的スキルセットが必要とされているか? 他のチームメンバーを邪魔せずに、その専門家の時間を有効利用するにはどうしたらよいか?
  • ストーリーがプロダクトアーキテクチャにどのような影響を与えるか? デザインやコード検証のためにチームに引き入れる必要がある特定人物はいるか?
  • 各ストーリー間に依存関係はあるか? その依存関係を考慮しても、対象スプリントですべての作業を完了できるか?

この細かいエクササイズを急いで終わらせたいと思うかもしれません。しかし、優れた計画を立てれば、スプリント開始後に多くの見返りがあります。ここでのポイントは、作業をどのように完了させていくのかチームメンバー全員が理解することです。そうすることで、計画実行時にチームに当事者意識が芽生えます。

step4: スプリントを開始する!

会議がここまで進むと、チームはスプリント予測に満足しているはずです。スプリント終了時にチームが達成しようとしていることについて、計画会議の終わりに全員に口頭での同意を得るのも良いかもしれません。また、最初に取りかかれるタスクを、各チームメンバーに最低 ひとつは割り当てましょう。作業が重複しないようにしてください。

スプリントごとにチームのエンゲージメントや士気が上がり下がりするのは自然なことです。そのような変動はスプリント計画中に現れますが、その時点でそれを深く掘り下げようとしないでください。代わりに、チームのふりかえりを使い、士気に関わるあらゆる課題を理解してください。チーム文化と開発懸念に対して迅速に対応するチームは満足度が高く、生産性が高く、より優れたコードを生み出します。

【前回記事】アトラシアンにおける「ふりかえり」の方法

【次回記事】第3回は、 アトラシアンにおける「スプリントレビュー」の方法です。 (※12月9日(水) 配信予定)

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet