yewton/revisions.md

## revisions.md

      
    Raw
  

              revisions.md
            
          
    スクラムガイド 2010 年版と 2011 年版の変更点


開発チームはスプリント計画会議で計画した作業の完了を確約することはない。
開発チームは完成させられるであろうと思う作業の予測は行うが、
スプリント中に判明することが増えるにつれてその予測は変化していく。
進捗の観測にバーンダウンチャートを使うことをスクラムでは強制はしない。
スクラムに求められるのは以下の通り。

スプリントの残作業の合計を毎日確認出来ること
スプリントを通じて作業が滞りなく進捗していること


リリース計画を建てることはスクラムを使う上で価値のあることではあるものの、
スクラムそのものに必要はものではない。
スプリントバックログはそのスプリント中に取り組むものをプロダクトバックログのアイテムから選択したもので、
加えてそれらを達成するための計画も含まれる。
"スプリントバックログアイテム" というコンセプトは、良い計画を建てるために有用なテクニックではあるものの、
必須ではなくなった。
自律的な開発チームは常に計画を基に行動する。
プロダクトバックログには "順序がある" のであって "優先順位がある" のではない。
プロダクトオーナーは状況に応じてその価値を適切に調整する裁量を持つ。
プロダクトバックロググルーミングが追加された。
必須ではない取り組みやテクニックの多くを削除した。
インクリメントに取り組む人々で構成されるチームが開発チームである。
チームの個々人は、その人が何を行うかによらず開発者と呼ぶ。
鶏と豚のくだりを削除した。
undone work のくだりを削除した。

(参考) 角征典さんによる翻訳抜粋

2011 年から 2013 年にかけてのスクラムガイドの変更点


「作成物の透明性」の節を追加した。スクラムは透明性に依存している。
作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。
透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。
作成物が不完全に透明化されていれば、こうした決定には不備があり、価値が低減し、
リスクが高まる可能性がある。
スプリントプランニングが 1 つのイベントになった。
そのなかで「スプリントで何ができるか？」と
「選択した作業をどのように成し遂げるのか？」の 2 つのトピックを扱う。
開発チームがスプリントで届けるプロダクトバックログアイテムを予想したあとに、
スクラムチームでスプリントゴールを設定する。
スプリントゴールは、開発チームの作業に一貫性を持たせるものである。
それは、共通のゴールがないバラバラのチームでは成し遂げられなかった作業である。
このスプリントゴールを正式に追加した。
プロダクトバックログは、グルーミングではなくリファインメントする。
リファインメントされたプロダクトバックログアイテムは透明化され、
スプリントプランニングのインプットとして十分に理解可能であり、適切な粒度となっている。
このように透明化されたプロダクトバックログアイテムのことを「準備完了（Ready）」であるという。
スクラムで規定されたイベントは規則性を作り出し、
スクラムで定義されていないミーティングの必要性を最小化する。
すべてのイベントはタイムボックス化されていて、時間に上限がある。
スプリント（他のイベントのコンテナ）は期間が固定化され、増減することはできない。
スプリント以外のイベントについては、目的が達成されたときに終了することもある。
プロセスでムダなことをせずに、必要な分だけ時間を使うためだ。
プランニングイベントとしてのデイリースクラムの重要性を強調した。
ステータス確認のイベントになっているのをよく見かける。
開発チームは、自己組織化チームとしてスプリントゴールを達成し、
スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
このイベントのインプットは、スプリントゴールに向かってチームがどのように活動しているかであり、
アウトプットは、スプリントゴールを達成するためにチームの作業を最適化する新しいあるいは改訂した計画である。
したがって、個人ではなくチームを強調するために、3 つの質問を再構成した。

開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
開発チームがスプリントゴールを達成するために、私が今日やることは何か？
私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？


価値の概念をスプリントレビューで使うために強化した。
スプリントレビューでは、スプリントの成果について、スクラムチームと関係者が一緒に議論する。
スプリントの成果とスプリントで変更したプロダクトバックログを参考にして、
参加者全員は価値を最適化するために次に何ができるかを一緒に考える。

2013 年から 2016 年にかけてのスクラムガイドの変更点


「スクラムの価値基準」のセクションを追加。
スクラムチームが、
確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の価値基準を取り入れ、
それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり、
あらゆる人に対する信頼が築かれる。
スクラムチームのメンバーは、スクラムのイベント・役割・作成物に触れて、仕事を進めるなかで、
これらの価値基準を学習・探索する。
スクラムを活用するには、これらの 5 つの価値基準を上手に実践しなければいけない。
個人はスクラムチームのゴールの達成を確約しなければいけない。
スクラムチームのメンバーは、正しいことをする勇気を持ち、
困難な問題に取り組まなければいけない。
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない。
スクラムチームとステークホルダーは、仕事や課題と、
その遂行の様子を公開することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。


スクラムガイド 2016 年版と 2017 年版の変更点


「スクラムの用途」のセクションを追加した。
当初、スクラムはプロダクトの開発と管理のために開発された。
1990 年代初頭から使用され、今では以下のように世界中で広く利用されている。

有望な市場・技術・プロダクトの研究および特定
プロダクトや追加機能の開発
プロダクトや追加機能のリリース（1 日に何度もリリースされる）
プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守
プロダクトの保守や刷新
スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、
自動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、
個人や社会が日常的に使用するあらゆるものに使用されている。

技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、
スクラムがその対応に有効であることは日々証明されている。
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。
今では、プロダクト、サービス、所属する組織の管理に広く利用されている
スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。
こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、
数千人の成果やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。
チームは協力や情報交換をしながら、
洗練された開発アーキテクチャやターゲットとするリリース環境を整えていく。
スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、
それは上記のような複雑な作業を意味している。


「スクラムマスター」のセクションの表現を変更し、役割を明確化した。
スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。
そのためにスクラムマスターは、
スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する。
スクラムマスターは、スクラムチームのサーバントリーダーである
（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。
スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことを
スクラムチームの外部の人たちに理解してもらう。
スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。


「スクラムマスターはプロダクトオーナーを支援する」のセクションに以下を追加した。
スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるようにする。


「デイリースクラム」のセクションの最初の段落を以下のように変更した。
デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。
スプリントでは、毎日デイリースクラムを開催する。
開発チームは、次の 24 時間の作業を計画する。
前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、
チームのコラボレーションやパフォーマンスを最適化するのである。
デイリースクラムは毎日、同じ時間・場所で開催し、複雑にならないようにする。


「デイリースクラム」のセクションを変更して、デイリースクラムのゴールを明確化した。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、
他のやり方で行なっても構わない。
質問を使うチームもあれば、議論ベースで進めるチームもある。
たとえば、以下のような例を使用するといいだろう。

開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
開発チームがスプリントゴールを達成するために、私が今日やることは何か？
私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？


タイムボックスについて明確化した。
「最大」という言葉を追加して、イベントを時間どおりに行なう必要があるのかという疑問を解消し、
許容される最大の時間であることを明確にした。


「スプリントバックログ」のセクションに以下を追加した。
継続的改善を確実なものとするために、
前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく。


「インクリメント」のセクションが明確になるように以下を追加した。
インクリメントは、完成していて、検査可能なものであり、
スプリントの終了時の経験主義を支援するものである。
インクリメントは、ビジョンやゴールに向かうステップである。


参考リンク


Scrum Guide Revisions | Scrum Guides
角征典さんによる2016年版の翻訳
角征典さんによる2017年版の翻訳