開発コラボレーションのヒント from Atlassian Blogs(76) アトラシアンにおける「スプリントレビュー」の方法

本稿はアジャイルの作法に関するシリーズ第 3 弾です。アトラシアンにおけるスプリント計画とスプリントのふりかえりもご覧ください。

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

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

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

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

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

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

デリバリーに関するカルチャー

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

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

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

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

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

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

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

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

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

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

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

注：

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

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

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

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

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

アドバイスの最後に

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