この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。

第8回目のテーマは、「スクラムイベントの実践方法」です。

この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える!半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。

スプリントプランニングを実践する

スプリントプランニングは、スプリントの最初に行うため、起点となるMTGです。スプリントプランニングはその名の通り、スプリントの計画を立てるイベントです。スプリント計画とも呼ばれたりします。

このMTGの目的は、プロダクトバックログからスプリントバックログを選択し、決定することです。スプリントバックログには、スプリントゴールが含まれます。スプリントバックログとスプリントゴールが決定すれば、このスプリントにどういう価値があるか?なにができるのか?が明確になります。

スプリントプランニングの手順を解説します。

スプリントプランニングの成果物は、スプリントゴールとスプリントバックログなので、この2つが満たされるのであれば、どんな方法でも良いと思います。ただ、多くの人がやっている方法は、何かと参考になるので、まずは世の中のやりかたから学んでみましょう。

  • スプリントゴールを決める
  • スプリントバックログを選ぶ。POは選んだスプリントバックログの説明を行い、開発者と質疑応答する
  • 明確になったスプリントバックログの見積もりを行い、スコープ(やる量)を決める
  • 必要であればスプリントバックログをタスクに分割する

スクラムガイドにはイベントに書ける時間が目安として書かれています。1週間スプリントだと2時間。2週間スプリントだと4時間。1ヶ月スプリントだと8時間ぐらいが目安になります。しかし、周囲を見てみると、1週間スプリントで30分ぐらい。2週間スプリントで1時間ぐらいが多いです(1ヶ月スプリントはあまり見かけない)。

この時間については、やりかたによってかわってきます。たとえば、スプリント中にちょっとずつ準備を進める場合は、短い期間でできるとおもいます。MTG内ですべてを決定するなら、それ相応の時間をかける必要があります。

デイリースクラムを実践する

デイリースクラムは、スクラムチームのための15分のイベントです。15分と限定するように、短い期間で情報を共有していきます。デイリースクラムは、毎日、同じ場所、同じ時間に開催するコミュニケーションの場でもあります。スクラムチームが集うMTGなので、積極的なコミュニケーションをとっていきましょう。スクラムマスターであれば、コミュニケーションをチームに促していきます。

開発者は、スプリントゴールの進捗を中心に1日分の作業計画を立てます。これをスプリントの最後まで繰り返します。スクラムにおける計画は、スプリント開始時の計画づくりで1回します。朝礼で再計画を行うことで、スプリントが1週間5営業日だとすると5回、合計6回計画づくりができます。このように小刻みに適応していくことで変化に強い開発を実現します。

もちろん、計画の調整が必要になった場合は、次のデイリースクラムまで相談を待つのではなく、デイリースクラム外でも積極的に調整していくべきです。

デイリースクラムでは、計画づくりだけでなく、問題や課題があれば解決策を議論し、迅速な意思決定を促進します。スクラムマスターにとって、デイリースクラムにおいて、「問題ありません」からが勝負になります。本当に問題ないのか、不安はないのか、チームに問いかけながら、発言を促していきます。

デイリースクラムの一般的な手順を解説します。チームのひとりひとりが、3つの質問に答えていくのが一般的です。

  • 昨日やったことは何か?
  • 今日やることは何か?
  • 課題や不安がないか?

昨日やったことから昨日立てた計画の確認を行います。うまくいったのか、うまくいかなかったのか、うまく行かなかった場合はどうするのか?を個人だけでなくチームで考えます。今日やることは、今日の計画づくりです。朝礼で自分の計画をうまく話せないのであれば、きちんと準備して朝礼に来るように促していきます。

課題や不安の解決に時間がかかりそうであれば、別で時間をとって議論します。あくまで短い時間で朝礼を終わらせるのが重要です。

スプリントレビューを実践する

スプリントレビューの目的は、スプリントの成果を検査し、今後の適応を決定することです。デモMTGや成果発表会と呼ばれたりもします。スプリントレビューの大切な目的は、よいフィードバックを得ることです。

レビューを確実に行うために、主要なステークホルダーが集まる必要があります。見て欲しい人がいない状況でレビューをしてもこのイベントの効果が薄れてしまいます。

レビューをする時間は決まっていても、スプリントレビュー時にまとめてみせるのではなく、できたものをどんどん見せていってもいいでしょう。もしそれですむのであれば、スプリントレビューで確認をやめて、デモを見ながら次のアイデア出しに時間を使うのも手です。

スクラムガイドには目安の時間が書かれています。1週間スプリントで1時間、2週間スプリントで2時間、1ヶ月スプリントで4時間になります。筆者の周囲では、1週間スプリントで30分、2週間スプリントで1時間ぐらいが多いです。

スプリントレビューの手順を解説します。

成果の発表方法は、スクラムチームによって異なりますが、一般的には、開発者が開発したものをプレゼンテーションします。そして、開発者とレビュアーで質疑応答を行い、レビューOKかどうかを判断します。

プレゼンテーションがメインですが、質疑応答セッションも大切です。レビュアーによるFフィードバックを元に、新しいアイデアを考えたり、次の計画に盛り込んでいくことが重要です。

生まれたフィードバックは、対応するならバックログに追加します。やらないならやらないと意思決定します。いつ対応するかはスプリントプランニング等で決めていきます。

スプリントレトロスペクティブを実践する

スプリントレトロスペクティブは、レトロと略される場合もありますが、それだけだと意味がよくわからなくなりますし、レトロスペクティブという言葉自体があまり馴染みのない英単語なので、筆者はわかりやすい「ふりかえり」という言葉を使うようにしています。

スプリントレビューは、成果物の改善のための検査でした。ふりかえりは、プロセスやツール、開発全体の改善のための検査と言えます。

ふりかえりででてきた問題の対策や改善方法は、スプリントレビューと同じくバックログに追加できます。

目安の時間は、1週間スプリントで1時間、2週間スプリントで1.5時間、1ヶ月スプリントで3時間とスクラムガイドにあります。筆者の周辺だと、1週間スプリントで30分、2週間スプリントで1時間ぐらいが多いです。

ふりかえりにはいろんな手法があるのでここでは一例としてKPTを紹介します。

ふりかえりの方法のひとつ「KPT」

まず、KPTをはじめるまえに、はなしやすいようにKPTボードを作ります。このスライドの右図のように、Keep(よかったこと)、Problem(いまいちなこと)、Try(チャレンジ)と区分けして、チームでふせんをはりながらすすめます。

ボードは、ホワイトボードを使ってもいいですし、オンラインのお絵かきツールを使ってもいいと思います。使いやすく、やりやすい方法を選んでください。筆者の場合、リアルタイムで話すときはホワイトボードを使い、オンラインだとMiroFigJamというサービスを使うケースが多いです。

時間を区切ってまずKeepを集め共有します。次にProblemを集めます。たくさんでてきたときは、優先順位を決めて優先順位が高いものから話します。ふりかえりの時間は限られているので、限られた時間内で最大の成果が生まれるように考えます。

問題の確認をして、対策を考えられたならTryに貼り付けます。誰がいつまでにやるかを決めて、ふりかえりを終わります。アクションは忘れないようにバックログに追加してもいいと思います。

次のふりかえりでは、前にきめたTryの確認から始めます。そしてまたKeep、Problem、Try、Tryの確認、またKeepに・・・というサイクルをまわして改善を進めていきます。

スクラムの成果物

スクラムイベントを通して成果物を出していく必要があります。スクラムの成果物は、プロダクトバックログ、スプリントバックログ、インクリメントの3つです。

ひとつめの成果物は、POの説明でも出てきたプロダクトバックログです。プロダクトレベルのやることリストです。プロダクトバックログは、どんどん磨きこんでよいものに仕上げていく必要があります。この磨き込みをリファインメントと呼び、バックログリファインメントというイベントを追加で行うチームも多いです。

スプリントバックログは、スプリントプランニングで作られます。スプリントバックログは、成果物であるインクリメントを届けるための、具体的な計画と言えます。長期的なプロダクトバックログと、短期的なスプリントバックログは、解像度が異なります。

プロダクトバックログにプロダクトゴールがあるように、スプリントバックログにはスプリントゴールがあります。

最後の成果物はインクリメントです。インクリメントは、プロダクトゴールに向けた具体的な階段になります。インクリメントはスプリントレビューで検査されます。インクリメントは完成の定義を満たさなければなりません。

連載一覧

第1回:アジャイル開発の過去、現在、未来を知ろう!
第2回:声に出して読みたいアジャイルマニフェスト
第3回:従来型開発とアジャイル開発の違い その1
第4回:従来型開発とアジャイル開発の違い その2
第5回:アジャイル開発のよくある誤解を解いていこう!
第6回:世界中で大人気の秘密に迫る!スクラムを使ったソフトウェア開発
第7回:わかるようでわかりにくいスクラムチームの責任
第8回:スクラムイベントの実践方法
第9回:エクストリーム・プログラミングとその価値
第10回:エクストリーム・プログラミングの原則と基礎プラクティス
第11回:エクストリーム・プログラミングの応用プラクティス
第12回:リーンソフトウェア開発
第13回:ソフトウェア開発における「かんばん」
第14回:さまざまな方法論 − リーンスタートアップ・DevOps

SHARE

  • facebook
  • twitter

SQRIPTER

藤原 大(ふじはら だい)

スーパーアジャイルコーチ、株式会社せかい 代表取締役

記事一覧

スーパーアジャイルコーチ、エンジニアリングマネージャ、『リーン開発の現場』の翻訳者のひとり。創造的、継続的、持続的なソフトウェア開発の実現に向けて奮闘中。週末に娘と息子とお昼寝しながら世界のビーチや離島を旅する夢を見る。

RANKINGアクセスランキング
#TAGS人気のタグ
  • 新規登録/ログイン
  • 株式会社AGEST
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST