イベント #

ちょうど富士通の公開ページにスクラムのプロセスを解説している図があったため、これを使って説明していこうとおもいます。

スプリント #

スクラムでは1週間から最長1ヶ月までの固定の期間に区切って繰り返し開発を行います。この固定の期間のことをスプリント(イテレーションということもある)といいます。開発チームは区切られた機関の中で、計画、設計、開発、テストなどプロダクトバックログの項目を完成させるのに必要な作業すべてを行います。

このように固定の期間に区切って開発を繰り返すことによって、開発チームにリズムがうまれ集中できるようになり、全体のゴールに対する進捗が把握しやすくなったり、リスクに対応しやすくなったりします。

スプリントプランニング #

スプリントが始まって、一番最初にやるのがスプリントプランニングです。イテレーションプランニングと呼ぶこともあります。

まずプロダクトオーナーと開発チーム全員が集まって今スプリントでやることを決める会議になります。この会議体でやることはザックリ3つです。

プロダクトバックログの内容確認
バックログの作業項目の見積もり
スプリントの目標の決定

前準備 #

スプリントプランニングの前に事前準備としてプロダクトオーナーは、プロダクトバックログから次のスプリントでやりたい項目を取り出し、その作業内容を明らかにして、作業単位に分割しておきます。分割単位は1タスクが数時間から1日以内で終わるようにしておきます。

この作業をプロダクトバックログリファインメントと呼び、単にリファインメントと呼ばれることもあります。

プランニングミーティング #

スプリントプランニングミーティングが始まったら、まずプロダクトオーナーがリファインメントされたバックログの内容を読み上げ、開発メンバーと内容を共有します。

開発メンバーと作業内容を共有できたところで、各々のタスクについてデベロッパーがその場で作業量を見積もっていきます。見積もりにはよくプランニングポーカーといった方法が取られます。

その場で全員同時に開発者がそのタスクにかかる作業量見積もりを出し合うイメージです。じゃんけんゲームのようなものを想像すると良いと思います。全員同時に見積もり出すというのが大事なポイントで、こうすることで有識者もそうでない人も同時に見積もりを出すことになります。

こうした会議では有識者の意見に周りの人が引っ張られるということが往々にしてよくあるのですが、全員が等しく意見を出し合えるようにするというのが大事です。

もし開発者間で見積もった作業量に差異があるようであれば、その場で議論して合意をしていきます。議論をするというのが大事なポイントで、議論の中で実装上の思わぬ課題やリスクが見つかることがあります。逆に実は容易に実装できるといった気づきが得られるかもしれません。このときも、有識者よりも先に周りの人が意見を言えるようにするなど、適切なファシリテーションで全員の意見を汲み取れるよう配慮することが大事になります。

作業項目の見積もりが終わったら、チームのベロシティと照らし合わせて、このスプリントの中でどこまで実装するかを決めます。これをスプリントゴールと呼びます。

デイリースクラム #

デイリースクラムはスプリント中、毎日、プロダクトオーナーと開発メンバーが行う短時間（10分から15分程度）のミーティングです。スプリントバックログの残作業を確認し、このまま進めてスプリントゴールが達成できるかどうかを確認します。よく毎朝、朝会として行われる事が多いですが、スクラムとしてはいつやるかは決まってません。ただし、毎日同じ時間にやることが大事です。

デイリースクラムの進め方に特に決まりはないですが、よくある内容としては、以下の内容を全員で確認するものです。

昨日やった作業内容の確認
今日やる予定の作業内容の確認
なにか気になること

この3点目の「なにか気になること」が特に大事です。スプリントゴールを達成する上で障害になりそうなことがあれば、ここで共有することになります。ただし、デイリースクラムは問題解決の場ではないので、この場では課題の共有にとどめ、もし別途、問題解決のために作業項目が必要ならスプリントバックログに追加するなどして対応します。

スプリントレビュー #

スプリントレビューはスプリントの成果をレビューする場です。開発チームが作成したプロダクトをプロダクトオーナーが実際に触って、スプリントバックログにて完成した内容、完成しかなった内容を明らかにします。

スプリントレビューの最大の目的はフィードバックを得ることです。そのためスプリントレビューはステークホルダーにも参加してもらい、プロダクトに関するフィードバックを得ます。また、合わせてプロダクトの状況や、ビジネス状況についてステークホルダーと認識を合わせ、必要に応じてプロダクトバックログに反映するという場になります。

スプリントレトロスペクティブ #

スプリントが終わったら、スプリントの終わりにスプリントレトロスペクティブという振り返りの場を設けます。

スプリントレトロスペクティブではそのスプリントのプロダクト開発において、どんな問題があったかや、もっと成果を出すためにできることがないかを開発チームメンバ全員で話し合います。

ここで大事なのはここで挙げられる問題や課題で個人を責めてはいけないということです。これはアジャイル開発12の原則に書いたとおりです。たとえ誰かがバグを作り込んだとしても、特定の個人を非難するようなことはしてはならず、バグを作り込んだプロセスをどうしたらいいかをメンバー全員で議論します。

今スプリントの反省点だけでなく、良かったことも議論しましょう。 良かったことのなかには続けるといい習慣があることがあります。

スプリント中の反省点や良かったこと、開発プロセスの無駄について今後どうしたらいいかをチーム全員で議論し、その結果をアクションアイテムとしてまとめます。

その内容を次のスプリントバックログに反映し、チームをより良くしていきます。

アジャイルの重要なキーワードとして、自己組織化したチームというものがあります。これはアジャイル開発チームが目指す目標像そのものなのですが、その自己組織化したチーム形成するためのプロセスがこのスプリントレトロスペクティブです。筆者はスクラムのイベントの中で最も大事なプロセスだと考えています。

ここまでで、スクラムのロール、成果物、イベントについて説明してきました。どういった流れで開発を進めていくかの大まかなイメージはついたのではないかと思います。では最後にスクラムのまとめます。

まとめ