アトラシアンにおける スプリントレビュー の方法

アトラシアンのオフィスでは、金曜日の午後遅い時間になると拍手喝采の音があちこちから聞こえてくることがよくあります。私たちは一生懸命に働き、それを楽しみ、そして スプリントレビュー の形で成功をほめたたえるのです。

スプリントレビューはふりかえりとは違います。スプリントレビューは、設計者、開発者、プロダクトオーナーからなるチーム全体が懸命に行った作業をデモンストレーションするものです。アトラシアンではスプリントレビューをいつもカジュアルな雰囲気で行うようにしています。チームメンバーはひとつの机の周囲に集まり、簡単なデモをしたりそのイテレーションにおいて行われた作業の説明をしたりします。またその時間は、質問をしたり、新たなフィーチャーの試行をしたり、フィードバックをしたりする時間でもあるのです。成功体験を共有することはアジャイルチームを作るうえで大切な要因になっています。

ここで、スプリントレビューの説明をする前に、「完了」をチームとして定義することがこのアジャイル作法にとって重要であることを理解しましょう。

ステップ 1: 「完了」の定義

JIRA を常用している私にとっては、タスクを 「進行中」から「完了」に移すことほどうれしいことはありません。アジャイルカードがそのように動くことは、チームとして成し遂げるべき作業が終わったことを意味します。まさに「完了」なのです！

ゴールラインに到達し作業を完了させるためには、優れた計画、「完了」の明確な定義、そして集中して実行することが必要です。これらの要因の多くはスプリント計画の期間に発生しますが、スプリントレビューおよびスプリントそのものを成功させるためには、単なる計画以上のものが必要になります。「完了」の定義に加えて、作業のデリバリー方法に関して明確な文化を作ることが必要なのです。

デリバリーに関する文化

作業効率の高いチームは、すべての作業項目において明確なプロセスと開発文化を持っています。以下の質問項目は、プロセスを評価する上で、またそのプロセスがチームに最適なのかを確認するために役立ちます：

• 実装に先立って、プロダクトオーナー、デザイナー、エンジニアリングチームがストーリーを明確に定義しているか？
• 全員がエンジニアリングにおけるチームの価値観と文化を理解しそれを実行しているか？
• 持続的なアジャイル開発を促すために、コードレビュー、自動化テスト、そして継続的インテグレーションの定義と要件を明確にしているか？
• チームがあるストーリーを完了した後で多数のバグが表面化していないか？　つまり、「完了」が本当の意味での「完了」になっているか？

品質および完了に関連したチーム文化は、個々のユーザーストーリー、エンジニアリング作業項目、そしてバグなどの上位にあるべきものです。この文化は、チームがソフトウェアにどのように取り組み、どのようにデリバリーするかを反映しています。

個々の作業項目における「完了」の定義

「完了」を明確に定義することにより、チームは個々の作業項目における最終目標に集中できます。プロダクトオーナーがチームのバックログに作業を追加する時、受け入れ基準を定義することがそのプロセスの重要な要素となります。ユーザーストーリーにとっての完了とはどういう意味でしょうか？ アトラシアンの JIRA チームでは、ユーザーストーリーとともに受け入れ基準とテスティングノートを JIRA 内で管理しています。これにより、チームメンバー全員が個々の課題の成功基準を明確に把握することができます。ここで、受け入れ基準、テスティングノート、とは何を意味するのでしょうか？

• 受け入れ基準 : ストーリーが満足のいくように実装されたことを確認するためにプロダクトオーナーが用いる測定基準。
• テスティングノート : 開発エンジニアがより良いフィーチャーコードを書き、自動化テストを行うことが可能となるように、品質アシスタンスチームが発行する、短く重要項目に絞ったガイダンス。

成功するためには実装における課題を明確に定義することが必要です。JIRA では、インラインでフィールドを簡単に追加することができます。管理者の場合は、課題に表示されている 'admin' ボタンをクリックするだけです。

ステップ 2: チームをほめたたえる

アトラシアンにおいては、「チームとして楽しむ」ことが重要な価値を持ちます。スプリントレビューは、そのイテレーションにおけるチームと個々人全員の成果をほめたたえる重要な機会です。私たちは通常それを金曜日の午後、週末を前にして仕事を終える前に開催します。スプリントレビューはふりかえりの同義語ではなく、イテレーションの終了後でかつふりかえりの前に開催しなければなりません。外部からの参加も常に可能ですが、通常はこのミーティングにはプロダクトオーナー、開発チーム全員、そしてスクラムマスターが出席します。各々のイテレーションごとのこのミーティングにかける時間を 30 分から 1 時間とすることをベストプラクティスとして推奨しています。

私たちは、チームの健全性とモラルを維持するものとしてスプリントレビューを重要視しています。スプリントレビューはチームをつくる上で極めて大切です。レビューは反論することではなく、試験をすることでもなく、メンバーがそれぞれの作業内容のデモを行い、質問に答え、そしてフィードバックを得るためにチーム全体が関わる協同作業的なイベントなのです。

スプリントレビューがチーム全体に渡るポジティブな活動にならない場合、以下のような事象の兆候である可能性があります：

• チームが過大な作業量を抱えていて、イテレーションの期間中に完了することができていない
• 既存の技術的問題点をチームが解決できていない
• 新たなバグがコードベースに持ち込まれないことを確認した上でのフィーチャー開発ができていない
• チームの開発プラクティスをよりよいものにできたはずなのに、それが実行されていない
• イテレーション中にプロダクトオーナーが優先順位を変更しようとしていて、スコープクリープ (スコープの肥大化) のために開発チームが動けなくなっている

注：どのようなチームもイテレーションがうまくいかないことがあります。その場合はチームのふりかえりにおいてそのイテレーションが変化してしまった原因を理解する時間をとり、次のスプリントにおいてそれらに対処できるような計画を立てましょう。

ステップ 3: 地理的要因にも気を配る

開発チームが分散している企業では、アジャイル作法を地理的に拡張する際に特有の課題があります。スプリントレビューもその例外ではありません。JIRA チームにおいては、シドニー、グダニスク、サイゴン、サンフランシスコなど世界各地にメンバーがいます。そのようにチームは分散していますが、スプリントレビューはチーム文化の重要要素になっています。チームメンバーは簡単な動画を作り、Confluence のページで共有することにより、チーム全員が見ることができます。

この簡単な動画により、時差があるにもかかわらず、すべてのメンバーが開発進行状況に関する最新の情報を得ることができます。開発者によるフィーチャーのデモを直接見ることができるので、チームは二つの点において強化されます :

• 製品の理解 : チーム全体において、フィーチャーの意図、理論的裏づけ、そして実装を知る機会が得られます。これにより各々のメンバーの製品全体についての理解が深まります。
• チームビルディング : 動画はチーム全体に渡るメンバー間の交流を生み出します。製品の持つ様々な要素の担当者を知ることができます。このようなプラクティスによって作られる架け橋は、地理的条件にかかわらず、私たちのチームをより緊密で強く結びついた集団にします。

最後のアドバイス

スプリントレビューの経験がないチームの場合、スプリントレビューをふりかえりに取り込んでしまいたいという誘惑にかられがちです。しかしスプリントレビューは、スプリントのふりかえりとは独立した作法です。労働により得られた果実を味わう時間をとりましょう。成果をおおらかにほめましょう。効果的に行われたスプリントレビューはチームのモラルとモチベーションを高めます。ほめるというこのような考え方は、私たち JIRA チームにとって非常に大切なものになっていて、まさにそれが理由で私たちは「さあ、ほめたたえましょう」をビジョンステートメントに組み入れているのです。