スクラムガイド2017での変更点の紹介
みなさんこんにちは。@ryuzeeです。
2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。
なお、スクラムガイド自体はこちらからダウンロード可能です。日本語訳はさまざまな書籍の翻訳で有名な角征典さんです。以下の紹介に際して、スクラムガイド日本語版の記述を引用しています。
実践に際して、大きな影響はあまりないと思いますが、とくに以下の2点が注目だと思います。
●デイリースクラムで3つの質問を使うかどうかはチーム次第となった。大事なのはスプリントゴールが完成しそうかどうかを毎日検査して適応すること
●レトロスペクティブ︵ふりかえり︶で出た項目を、次のスプリントのスプリントバックログに含めること
以下、詳細です。
![](/contents/blog/images/7116/th_update0.png)
●スクラムの用途について ●スクラムマスターの役割の定義を洗練させた ●デイリースクラムはスプリントゴールの達成に向けた検査と適応の用途であること明確化 ●タイムボックスとは最大の長さであることを明記した ●タイムボックス化とは、行動や活動に関して厳密な時間枠を置く行為を指す ●スプリントバックログは、スプリントレトロスペクティブでのフィードバックを含める![](/contents/blog/images/7116/th_update1.png)
スクラムは世界中で以下の用途で使われてきている。 ●有望な市場・技術・プロダクトの研究および特定 ●プロダクトや追加機能の開発 ●プロダクトや追加機能のリリース(1日に何度もリリースされる) ●プロダクトが使用するクラウド(オンライン、セキュア、オンデマンド)やその他運用環境の開発と保守 ●プロダクトの保守や刷新![](/contents/blog/images/7116/th_update2.png)
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。そのためにスクラムマスターーは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する。 できる限り組織文化やスクラムマスターの組織的・政治的なスキルを踏まえて、これを忍耐強く行う。![](/contents/blog/images/7116/th_update3.png)
デイリースクラムはスプリントゴールの達成に向けた検査と適応のためにある。開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。![](/contents/blog/images/7116/th_update4.png)
﹁最大﹂という言葉を追加して、イベントを時間どおりに行なう必要があるのかという疑問を解消し、許容される最大の時間であることを明確にした。タイムボックス化とは、行動や活動に関して厳密な時間枠を置く行為を指す![](/contents/blog/images/7116/th_update5.png)
スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。![](/contents/blog/images/7116/th_misconception1.png)
私たちは役にたつプロダクトを作る。ソフトウェアはその例に過ぎない。どれだけ頻繁にチームがリリースするか、プロダクトがどのようにサポートされるのか、顧客がどれくらい新しい機能を受け入れられるかにも差がある。たとえば、自動運転の車では、たくさんの機能を頻繁にリリースするよりも、安全であることが求められる。プロダクト開発では以下のような観点がプロダクトバックログに含まれる。 ●開発 ●バグ修正や技術的負債の削減 ●運用環境の開発 ●運用環境の準備 ●マーケティング ●サポートの準備、トレーニングやレディネスの確認 ●ヘルプやサポート用のファイルの準備とテスト ●パイロットマーケットへの早期リリース ●その他価値を実現するのに必要なものすべて。たとえばパートナーシップなど![](/contents/blog/images/7116/th_misconception2.png)
●プロダクトオーナーが選択し、スクラムチームにとって可能なのであれば、いつでもリリースしてよい ●負債より価値が上回っていることを確認する ●必要なのは、スプリントの最後に完成したインクリメントがあること、実際にそれをリリースするかどうかに関係なく、利用可能なものであることである ●継続的デリバリーのプラクティスはスクラムと併用が可能![](/contents/blog/images/7116/th_misconception3.png)
●開発チームは、最初の数スプリントのうちにプロダクトが実現可能で価値を生み出すことを証明しなければいけない ●そうするためには、運用環境やサービスレベルアグリーメントを満たすような初期アーキテクチャが必要になる ●スクラムチームが権限をもっていて、組織が協力的であれば、結果的に、なんらの危機に遭遇することなく組織的な変化が実現される ●スクラムプロジェクトでは、先に進める前に、新しい能力を実際に使ってテストしておく必要があることが多い ●リスクを早期に最小化する それでは!
更新内容
![](/contents/blog/images/7116/th_update0.png)
●スクラムの用途について ●スクラムマスターの役割の定義を洗練させた ●デイリースクラムはスプリントゴールの達成に向けた検査と適応の用途であること明確化 ●タイムボックスとは最大の長さであることを明記した ●タイムボックス化とは、行動や活動に関して厳密な時間枠を置く行為を指す ●スプリントバックログは、スプリントレトロスペクティブでのフィードバックを含める
▶スクラムの用途
![](/contents/blog/images/7116/th_update1.png)
スクラムは世界中で以下の用途で使われてきている。 ●有望な市場・技術・プロダクトの研究および特定 ●プロダクトや追加機能の開発 ●プロダクトや追加機能のリリース(1日に何度もリリースされる) ●プロダクトが使用するクラウド(オンライン、セキュア、オンデマンド)やその他運用環境の開発と保守 ●プロダクトの保守や刷新
▶スクラムマスターの役割
![](/contents/blog/images/7116/th_update2.png)
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。そのためにスクラムマスターーは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する。 できる限り組織文化やスクラムマスターの組織的・政治的なスキルを踏まえて、これを忍耐強く行う。
▶デイリースクラム
![](/contents/blog/images/7116/th_update3.png)
デイリースクラムはスプリントゴールの達成に向けた検査と適応のためにある。開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。
▶タイムボックスは最大の長さのことである
![](/contents/blog/images/7116/th_update4.png)
﹁最大﹂という言葉を追加して、イベントを時間どおりに行なう必要があるのかという疑問を解消し、許容される最大の時間であることを明確にした。タイムボックス化とは、行動や活動に関して厳密な時間枠を置く行為を指す
▶チームの働き方の継続的改善
![](/contents/blog/images/7116/th_update5.png)
スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも1つは含めておく。
よくある誤解について
▶スクラムはソフトウェアにしか関係がないのか?
![](/contents/blog/images/7116/th_misconception1.png)
私たちは役にたつプロダクトを作る。ソフトウェアはその例に過ぎない。どれだけ頻繁にチームがリリースするか、プロダクトがどのようにサポートされるのか、顧客がどれくらい新しい機能を受け入れられるかにも差がある。たとえば、自動運転の車では、たくさんの機能を頻繁にリリースするよりも、安全であることが求められる。プロダクト開発では以下のような観点がプロダクトバックログに含まれる。 ●開発 ●バグ修正や技術的負債の削減 ●運用環境の開発 ●運用環境の準備 ●マーケティング ●サポートの準備、トレーニングやレディネスの確認 ●ヘルプやサポート用のファイルの準備とテスト ●パイロットマーケットへの早期リリース ●その他価値を実現するのに必要なものすべて。たとえばパートナーシップなど
▶スプリントが終わる前にリリースしてもよいか?
![](/contents/blog/images/7116/th_misconception2.png)
●プロダクトオーナーが選択し、スクラムチームにとって可能なのであれば、いつでもリリースしてよい ●負債より価値が上回っていることを確認する ●必要なのは、スプリントの最後に完成したインクリメントがあること、実際にそれをリリースするかどうかに関係なく、利用可能なものであることである ●継続的デリバリーのプラクティスはスクラムと併用が可能
▶DevOpsについてはどうなの?
![](/contents/blog/images/7116/th_misconception3.png)
●開発チームは、最初の数スプリントのうちにプロダクトが実現可能で価値を生み出すことを証明しなければいけない ●そうするためには、運用環境やサービスレベルアグリーメントを満たすような初期アーキテクチャが必要になる ●スクラムチームが権限をもっていて、組織が協力的であれば、結果的に、なんらの危機に遭遇することなく組織的な変化が実現される ●スクラムプロジェクトでは、先に進める前に、新しい能力を実際に使ってテストしておく必要があることが多い ●リスクを早期に最小化する それでは!
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
- 著者/訳者:西村 直人、 永瀬 美穂、 吉羽 龍太郎
- 出版社:翔泳社
- 発売日:2020-05-20
- 単行本(ソフトカバー):288ページ
- ISBN-13:9784798163680
- ASIN:4798163686