理解したい事
ウォーターフォールとの違い
メリットとしては論理的であることがあげられるが、デメリットとして変化に弱いことがあげられる。
後半に提案される素晴らしいアイディアはウォーターフォールでは危険なものとして扱われる。
また逐次的な工程は仕事を受け渡す人たちの対立関係を助長してしまう。
アジャイル開発とスクラム
“商品開発における学び、イノベーション、変化等、より実践に基づいた方法にすれば、より良い結果をもたらす” という信念によって生まれた。
事前に仕様を書く多くの時間を費やすことよりも、すぐに出荷できる動く製品を重視する。つまり、顧客にとって本当に価値があるのかを常に考える。（設計書を書いても顧客は喜ばない）。
スクラムによってアジャイルな状態になる。
スクラム概要
企画や製品開発もしくはアプリケーション開発を繰り返しながら漸増するフレームワーク。
各スプリントの初めに、PBIから項目を選ぶ。チームはスプリント終了までに選択したすべての項目を完了させることを公約。選んだ項目は変更しない。デイリースクラムで進捗を確認し、残りの仕事を終わらせるのに必要な次の作業を調整。スプリント終了時にチームは利害関係者と共に構築した製品を実際に用いてスプリントを検査する（スプリントレビュー）。参加者は次のスプリントで具現化できるフィードバックを得る。スプリト終了時に本当に価値のある製品が実現されることを強調する。
スクラムの大きなテーマは、「検査と適応」
スクラムの役割
- PO
- 製品特性を特定することによって投資収益率（ROI）を最大化することに責任がある
- PBIを継続的に見直し、次のスプリントのためにどの項目が上位にあるべきかを決めて洗練する
- 自らスプリント毎に優先順位をつけ、結果を検査するなど、チームと積極的かつ頻繁に交流する
- SM
- 製品開発チームがビジネス価値を実現するのために、スクラムの学習と適応を支援
- 工程を促進したり、チームの自己組織化と自己管理化を支援する
- PMとは根本から違う。スクラムチームは自己組織化できているためPMは必要ない
- “子守” としての役割（分担、現状報告、その他のマイクロマネージメント形式等）をやめ、チームの “奉仕者” と “リーダー” の役割（指導、コーチング、障害除去支援、問題解決支援、有意義な情報提供、チームメンバーの開発技術指導等）を担う
- 単に問題解決策を決め、それをチームに指示するのではなく、問答形式でチームが問題解決を見いだすのを支援する
- スクラムチーム
- アプリケーションやウェブサイト等、プロダクトオーナーが示唆する製品を造る
- 職能上の枠を超えて、各スプリントで出荷可能な製品を納品するために必要な全ての専門技能を持つ
- “自己組織（自己管理）” し、とても高い自律性と製品に対して責任がある
- 何をすべきであり、そのすべきことを達成する最適な方法を決める
- チームは、７人 ± ２人。ソフトウェア開発の場合、チームは、分析、開発、テスト、インターフェース設計、データベース設計、アーキテクチャ、書類作成等の能力を持った人で構成される
- 機能的な管理者
- スクラムの役割が変化する間、とても貴重な役割
- スクラムの規律と精神を尊重することによって、チームを支援
- チームとプロダクトオーナーの障害を取り除くことを支援
- 専門技術と経験を活かせるようにする
スクラムの開始
スクラムの第一歩はPOが製品の構想を明確に伝えること。最終的には、プロダクトバックログと呼ばれる、洗練された特性（項目）の優先順位リストに発展する。
PB
PBは製品のロードマップである。様々な項目、主に新しい顧客要求を含んでいるが仕事の改善目標、探求や調査の仕事は含まれない。最新の出荷を対象としたPBIの部分集合は、リリースバックログと言われる。POには、各項目のビジネス価値を見積る責任がある。POには投資収益率（ROI）を最大化するためもしくは副次的にいくつかの主なリスクを軽減するためにPBIの優先順位付けをする。
スプリント計画
各スプリント開始時に、スプリントの計画を行います。これは２部構成で、最初はスプリント計画第１部（スプリントプランニング・パート１）。
スプリントプランニング・パート１
第１部は、プロダクトオーナーの要求を理解することに焦点を合わせる。
プロダクトオーナーとチーム（スクラムマスターが会議を促進）が、プロダクトバックログの優先順位の高い項目、プロダクトオーナーが、このスプリントで着手したい項目を確認する。プロダクトバックログの優先順位の高い項目の目的や状況を議論する。また、プロダクトオーナーの考えをチームで共有します。プロダクトオーナーとチームは、全項目の （前もって定めた）“完了の定義” を満たす必要がある。
スプリントプランニング・パート２
POがいてくれると嬉しいが基本不参加（連絡は取れる状態にしておく）
バックログ項目を実現するための詳細なタスクを決めることに焦点を合わせる。
チームは、スプリント期間で実現出来ると公約できる量のプロダクトバックログ項目をPOではなくチームが選択する。
チームは、たまに優先度の低い項目を開発することがある。これは、チームとプロダクトオーナーが優先度の高い項目の開発と合わせて、優先度の低い項目を簡単に開発できると気付いた時に生じる。
チームは、各メンバーがスプリントに費やすことができる時間を見積もるところから、スプリント計画第２部は始まる。チームの許容量を決めると、チームが次のスプリントでいくつのプロダクトバックログ項目を達成することができるか分かる。設計議論を行い、全体設計を理解すれば、チームはプロダクトバックログ項目をタスクに分解する。全員で個別のタスクに分解したものをスプリントバックログと呼ばれるドキュメントに記録する。
チームは見積もった許容量を使い切るまで、同様にプロダクトバックログ項目を順次、明確化していく。
スクラムの柱の１つは、チームが公約すると次のスプリントまでは追加や変更できない。それは、プロダクトオーナーがスプリントの途中で、チームに新しい項目を開発して欲しいと思っても、次のスプリントまで変更することはできないことを意味する。
スクラムの規律に従うことで、プロダクトオーナーは２つのことを学ぶ。
１つは、チームが現実的で明確に設定し、完了するという公約を信用すること。
もう１つは、プロダクトオーナーは、次のスプリント開始までにプロダクトバックログを変更しなければならないことを学ぶ。
デイリースクラム
定刻にチーム全員が参加して行う（１５分以下の）短い打合せ。管理者への状況報告ではないことに注意する。チームが自己組織化するために、お互いの情報共有や調整するための打合せである。
各メンバーが３つのことを他のメンバーに説明します。
(1) 前のデイリースクラムから何を完了したのか
(2) 次のデイリースクラムまでに何を完了させようと考えているのか
(3) 現在、止まっていることや障害になっていることは何か
スクラムマスターは、チームメンバーが自立的に問題解決を支援する責任がある。デイリースクラムでは、議論は行わない。すぐに議論が必要ならば、デイリースクラムの後にフォローアップ会議を行う。フォローアップ会議は、デイリースクラムで聞いたことをチームに適応するための会議。
スプリントバックログとスプリントバーンダウンチャートの更新
スクラムチームは自己管理するために、状況を把握しなけばならない。
毎日、チームメンバーは、スプリントバックログの現在着手しているタスクを完了するために必要な残時間の見積りを更新しなければならない。この更新の後に、メンバーの誰かがチームの残時間を合計してスプリントバー
ンダウンチャートに描画する。このグラフは、チームがタスクを終わらせるまで、全タスクの（計測された）残時間の新しい見積りを示す。グラフの傾きが、スプリント最終日に “ゼロになる” ような軌道を描くことが理想的。
もし、バーンダウンの曲線がスプリントの終盤で完成に向かっていない場合は、チームは調整が必要。
プロダクトバックログの見直し
各スプリントの５ー１０％を使って、チームによるプロダクトバックログを洗練（もしくは、手入れ）することは、スクラムの貴重な原則の１つ。これは、詳細な要求分析、大きい項目の細分化、新しい項目の見積り、既存の項目の最見積りを含んでいる。この改善活動は、現スプリントの項目は選ばない。１、２スプリント後のために行う。
この習慣に従うと、プロダクトオーナーとスクラムチームは明確で、詳細分析され、丁寧に見積られているPBIがある状態でスプリントの計画を始めるので比較的簡単になる。
スプリントの終了
スクラムの原則の１つは、スプリント期間を決して延長しない。チームがどのくらい達成することが出来るかを学びことで、見積りと長期のリリース計画を支援する。また、チームが仕事のリズムを得ることを支援する。
スプリントレビュー
ここでは、チームとプロダクトオーナーがスプリントを見直します。しばしば、“デモ” と誤った認識をされますが、“デモ” では本当の目的を得ることは出来ない。スプリントレビューは、製品の検査をし、適応を学ぶ。
プロダクトオーナーが製品とチームについて学ぶ機会になる。また、チームはプロダクトオーナーと市場を学ぶ機会になる。従って、レビューの最も重要な要素は、チームとプロダクトオーナーで徹底的に話し合い、状況把握やアドバイス等を得ることである。レビューが会話よりデモに集中するのは良くない。
役立つスクラムの原則は、製品もしくは納品に関する “完了の定義” を明確にする。これは、スクラムマスターの責任である。スクラムマスターは、チームがデモする、もしくは、“完了の定義” に従って完了していない項目に関して議論しないように支援する。“完了” されていない項目はプロダクトバックログに戻され、プロダクトオーナーによって再度、優先順位付けされる。この方法は、仕事の品質に透明性がある。
スプリントレトロスペクティブ（ふりかえり）
スプリントレビューは製品の点検と適応に焦点をあてる。ふりかえりはスプリントの工程（プロセス）の点検と適応に焦点をあてる。
スクラムマスターはチームでレトロスペクティブ（ふりかえり）をするように促し、チームの交流を容易にする。
リリースバックログとバーンダウンチャートの更新
この時点では、いくつかの項目が、完了や追加、新らたに見積られたり、リリースから外されたりしている。
プロダクトオーナーは、リリースバックログ（プロダクトバックログ）に変更を確実に反映することに責任がある。
加えて、スクラムはリリース日への進捗を示しているバーンダウンチャートがある。これは、スプリントバーンダウンチャートに似ているが、細かなタスクではなく、高いレベルの項目（要求）を描画している。
次スプリントの開始
。チームは通常、ある午後のレトロスペクティブ（ふりかえり）から、次の朝（もしくは、月曜の朝）にスプリント計画を行う。アジャイル開発の原則の１つに、“持続可能なペース”がある。妥当な水準の業務時間内でチームはこのサイクルをいつまでも続けることができる。
リリーススプリント
スクラムの完成とは、スプリント終了時に出荷可能な製品を納品できること。
多くの組織は、脆弱な開発手法、ツール、基盤、一定水準が完成できない、もしくは、その他の酌量すべき事情（コンピュータが壊れた等）がある。こうした場合は、いくつかの作業が残るので、完成品の統合テスト等、残った作業を行う “リリーススプリント” が必要になってくる。
リリーススプリントが必要ということは、いくつかの改善点があるサイン。理想は、それがない状態です。必要とする場合、プロダクトオーナーが製品の納品準備が整ったと判断するまで、スプリントが続く。これは、納品準備のためのリリーススプリントになる。
「どのようにしたら反復モデルで長期のリリース計画ができるか」という問い。
これには2つのケースがある。1. 新製品の初期リリース。2. 既存製品の次回以降のリリース。
新製品、既存製品のどちらにスクラムを導入する場合でも、最初のスプリント後に初期のプロダクトバックログを見直す必要がある。そうすることによって、プロダクトオーナーとチームは適切なプロダクトバックログを作ることができる。
プロダクトバックログが固まっている既存製品の場合、次リリースのための特別もしくは詳細なリリース計画は必要ない。なぜなら、プロダクトオーナーとチームは全スプリントで、（各スプリントの５ー１０％）プロダクトバックログの見直しを行いながら、継続して将来（リリース）の準備をするから。
あらかじめ、全てのことを把握することはできない。焦点は、（例えば、スケジュールの範囲等の）計画を作り洗練する時に、リリースの広い方向性を加え、明確なトレードオフを決めることが出来ること。
これを最終的な目的地へ導くロードマップを考える。旅の正確な（最終的な）道の決定は、旅の途中で決まるかもしれない。
まとめ
スクラムには長期プロジェクトの序盤、中盤、終盤はない。それに、従来のプロジェクト管理者も存在しない。
むしろ、安定したプロダクトオーナーと寿命の長い自己組織化されたチームが、製品もしくは、アプリケーションが償還されるまで、固定したスプリントを “終わりのなく” 繰り返しながら恊働するだけである。
スクラムは習慣を明確にするだけではなく、より重要なことは、透明性を提供するフレームワークということ。これは、“検査と適応” ができる仕組みである。スクラムの機能障害と障害となっている物事を明らかにする働きは、プロダクトオーナーとチームの有効性に影響を与え、それらに取り組ませることができる。小さな改善の試みと短期間での問題解決方法を探求する枠組みを苦痛なほど明確化して提供する。
スクラムのよくある過ち。
- スクラムを変えること
- 例えば、チームは公約したことを達成できないトラブルがあった時、スプリント期間を延長するかもしれない
- スクラムの本当の利点を徐々に弱らせる
- スクラムが明確に要求しないから、実行を妨げたり禁止しようと思い込むこと
- 例えば、スクラムはプロダクトオーナーの長期的な製品戦略を必要としない
- また、技術者も複雑な技術的な問題への経験豊富な技術者から助言を求めることを必要としない
- スクラムは正しい決断を関係者に任せる
- 管理者がチームにスクラムを強制すること
- スクラムは、チームに自由と管理するツールを提供し、上司から命令されても成功しない
- より良い方法は、チームで同僚や管理者にスクラムを学ぶことから始め、総合的に教育をうけた専門家の訓練を経て、一定期間、忠実に実践するとチームが決断し、その期間の終わりに、チームはその経験の重要性を評価し、継続するかどうかを決める
確認したい内容
- ３つの役割に加え、製品を成功させる貢献者には機能的な管理者（技術管理者等）もいますってSMとは別？開発チームの中でいるみたいな感じ？か書かれていることはSMの責務な気がする
- A.
- 「様々な項目、主に新しい顧客要求を含んでいるが仕事の改善目標、探求や調査の仕事は含まれない」とあるが、システムの改善の優先順位付けはどうするのか？このタスクが発生した場合ベロシティが図れなくなるのではないか
- A.
- 「また、技術者も複雑な技術的な問題への経験豊富な技術者から助言を求めることを必要としません。スクラム
は正しい決断を関係者に任せます」とあるが、これは助言を求めなくてもスクラムチームが一丸となって解決するはずだからという意味？- A.