まえがき

Essential Scrum
- 基礎に，coreとなる価値，原則，practiceの小さなまとまりがある( → 集まってframeworkになる )
- どのようなapproachを組み合わせるべきかわかるまでは，Scrum frameworkを忠実に守った方が良い

Ch01 Introduction

What's Scrum
- Scrum: 革新的なProduct, Serviceを開発するためのapproach
- Agile approach
  - product backlog
  - iteration
  - 機能横断型チーム
Scrumの起源
- all-at-once product development(団結型product開発): scalable チーム based approach
- - Object Oriented developmentの概念・経験にもとづくprocess control
- - iterative and incremental development
- - softwareのprocessと生産性に関する研究
- - 複雑で適応力のあるsystem
- Scrumの革新的な価値と原則は，softwareとは異なる種類のproduct開発や，さまざまな仕事のflowを生み出すためにも使える
Why Scrum
- 事前の設計を創発的な設計とjust_in_timeで組み合わせられるapproach
- より機能横断的
ゲノミカ社の顛末
Scrumは役に立つか
- 頻繁なrelease
- 組織的な機能不全や無駄を晒す
- iterationのたびに動作・統合・テスト・business的に価値のあるfeatureのdeliveryに注力
- Cynefin framework
  - 複雑な領域
    - 創発的
    - 検査と適応
    - Scrum〇
    - 探索(調査)・理解(検査)・反応(適応)
  - 込み入った領域
    - 専門家が適切なpracticeを適用する領域
    - Scrumでも対応できるが，最善ではないかもしれない
    - 日々のsoftwareの保守作業など
    - Six Sigmaのような戦術的・定量的approachの多くは特にうまくいく
      - 単純な領域にも〇
  - 単純な領域
    - 正統的なbest practiceの領域．既知のsolution．
    - 適切に定義され，反復可能な手順が組み合わせられたprocessを用いたほうが，Scrumより上手くいく
  - chaosな領域
    - 状況と行動に対して誰かが責任を負う
    - Scrumは×
  - 無秩序
    - 状況を構成要素に分解して，それぞれをそのほかの4つの領域に当てはめる必要がある
  - 割り込み駆動の作業
    - Scrumは×
    - カンバンが〇
      - 推奨
        
        作業がsystemをどのように流れているか可視化
        
        各手順で仕掛け中の作業(WIP)を制限．こなせる以上の作業はしない．
        
        system内の作業の流れを計測，最適化して，継続的に改善
      - softwareの保守とsupportに〇
      - systemごとにScrumとカンバンの使い分けもよい
まとめ
- Scrumは複雑なproduct開発という営みの変化を受け入れられる
  - 組織のpotentialを妨げている機能不全や無駄を可視化

Part 1 Core Concept

Ch02 Scrum framework

Scrum frameworkの概要
practiceに焦点を合わせ，役割，activity，作成物について見る
概要
- Scrum: 作業をまとめあげ，管理するためのframework
  - value，principle，practiceに基づき，組織に合ったengineering practiceや，Scrumのpracticeを実践するための具体的なapproachの追加ができる
  - → originalのScrumができあがる
  - 建物の土台や壁のようなもの．備品や機能の付加だけが可能．
  - 人間中心主義
    - 正直，開放性，勇気，尊敬，集中，信頼，権限付与，協力といった価値に基づく
  - practice: role, activity, 作成物, それらに関連するruleで構成
Scrumの役割
- 1つ以上のScrum_teamから構成
- product_owner
  - productのleadershipの権限
  - どのfeatureや機能をどの順番で構築するか判断する責任
  - チームの目標に明確なvisionを持ち，関係者全員に伝える
  - 開発や保守を含めたsolution全体を成功させる責務
  - 最も価値の高い作業が行われるようにする義務
  - Scrum_masterや開発チームと協力．質問にすぐ答えられるようその場にいる必要．
- Scrum_master
  - Scrumのvalue, principle, practiceを関係者全員が理解し，受け入れられるよう手助けする
  - as a coach, processについてleadershipを持ち，チームがoriginal Scrum approachを育てられるようにする
  - 組織変革のmanagementを支援
  - as a facilitator
  - impediment(ゴルフでのコース上の小石など)を取り除くときにleadershipを発揮
  - not a manager, but a leader
- development_team
  - productをdesign, develop, testする責任
  - product_ownerが設定した目標を達成するための最善の方法を決定
  - 5人～9人
Scrumのactivityと作成物
- flow
  - vision → groomingでfeatureに分解 → product backlog
  - sprint planningの結果: forecast/ commitment
  - sprint backlog
  - sprintの実施 with daily_Scrum
    - daily_Scrum: 作業の流れの管理のため，検査と同期を行う適応型planning activity
  - → product increment
  - sprint review: productをstakeholderとScrum_teamが検査
  - sprint_retrospective: processをScrum_teamが検査
- product backlog
  - product_ownerが，stakeholderと協力して収集，定義し，正しい順序にする
    - 順序: value, cost, knowledge, riskから
  - grooming
  - prioritized/orderedはどちらでもよい
  - 各itemの大きさ・コストを認識
    - 相対基準
- sprint
  - timeboxing
- product planning
  - product_ownerと開発チームがsprint goalを合意
  - 持続可能なpace
  - sprint backlog: 第2のbacklog．product backlog itemごとに細かいtaskに分解したもの．
  - just_in_timeのplanning
  - 期間: 2週間～1か月．sprint planningは4時間～8時間
  - simple cycle: product backlog itemを1つ選び，itemをtaskに分解し，選んだitemがsprintに収まるかjudge
    - taskは1時間単位で見積もる
- sprintの実施
  - 完成: 高品質な機能を達成するのに必要な作業をすべて終えたという強い自信があること
  - チーム memberがtask levelの作業を定義．自己組織化して実施．
- daily_Scrum
  - sprint期間中の毎日・同じ時間に，15分以内のtimeboxで実施
  - a.c.a. daily standup
  - 検査と適応のactivity
  - Scrum_masterがfacilitatorとして，各memberがほかのmemberに3つの質問
    - 前回のdaily_Scrumのあと，自分が何をしたか
    - 次回のdaily_Scrumまでの間，どんな作業をするか
    - 進捗を妨げる障壁・impedimentは何か
  - → 全員が今の状況の全体像を理解
  - sprintで作業をすばやく柔軟に実施するうえで欠かせない
  - sprint backlog itemの状況を開発チーム member間で共有するためのもの
  - 同期および検査と適応の毎日のplanning activity
- 完成
  - sprint の成果: 出荷判断可能なproduct increment
  - 完成の定義: 品質・出荷判断可能であることへの，自信の度合い
  - 出荷判断可能: sprintで構築したものに対する自信の度合い
    - 終わらせるべき重要な作業で，完了していないものがないということ
- sprint review
  - 構築中のproductの検査と適応
  - 参加者同士が会話
  - 開発activity全体へのreview
  - 今起きていることを可視化，次の開発をガイド，ビジネス上最も適切なsolutionが確実に作り出されるようにするための機会を得る
  - チーム内外で情報が双方向に流れるようになる
- sprint_retrospective
  - processの検査と適応
    - Scrumと関連する技術的なpracticeについて議論
    - 継続的なprocess改善
      - 現実的な数のprocess改善actionを特定し，実施をcommit
        
        次のsprintで取り組む
まとめ
- Scrum frameworkの役割，activity，作成物のすべてに焦点を当てて，Scrumのcoreとなるpracticeを見た

Ch03 Agile principle

Agile principleをtraditional 計画駆動のproduct developmentのprincipleと比較
- Scrumとの違いの理解の下準備
概要
- a.c.a. 順次的なprocess
- 計画駆動の開発
  - 基礎となる信念が，product開発に伴うUncertaintyと見合わない
変動性とUncertainty
- 役立つ変動性を受け入れよ
  - product developmentは製造業とは全く異なる
    - 製造業: 要件を固定し，よく理解された工程に従うことで，(定義された振れ幅の中で)常に同じ完成品を作り出す
    - product development: ほかにないproductをただひとつだけ作り出す
      - 1つだけのproduct: 料理のrecipeに似ている
- iterativeでincrementalなdevelopmentを採用せよ
  - iterative: 計画された手戻り戦略
    - 構築しているものを改善するために，いくつもの道を辿る
      - 優れたsolutionに辿り着く
    - 最大の欠点: Uncertaintyがあるため，どれだけの改善があるか事前に判断・計画することが難しい
  - incremental: 全部作る前に少し作ってみる
    - productを小さい部品に分割し，その一部を構築して，実際の環境でどのように動くか学習し，その学習に基づいて適応し，続きを構築する
    - developmentを調整し，やってきたことを変更するうえでの重要な情報を獲得する
    - 最大の欠点: 部品ごとに構築すると，全体像を失ってしまうriskがある
  - 併用することで，個別に使う場合の欠点を埋められる
  - Scrumではsprintと呼ばれるtimeboxingされたiterationで適応を繰り返すことで，iterative and incrementalという考え方を実現する
    - Water Scrumは×
    - featureに対して作業をし，統合・テストを経ることで，全体的な視点でproductを見られる
    - sprintの結果についてfeedbackを受け取ることで，適応ができるようになる
      - iterative developmentと継続的な改善に対するcommitmentの一部として，将来のsprintでやり直しを計画できる
      - → どの程度の改善が必要か事前に正確に知ることができないという課題を克服
    - 適切で経済的にも意味のある回数のiterationを行いつつ，productをincremental development
- 検査，適応，透明性(経験的なprocess control)を通じて変動性を活用せよ
  - 計画駆動とScrumの違い
    - processが定義される度合い
    - 成果のばらつき
    - 使われるfeedbackのtiming, 量
  - Scrumの核心が，検査，適応，透明性
    - 構築するものだけでなく，構築する方法も検査と適応を行う
      - このために透明性が必要
        
        透明性: productを作り出すための重要な情報はすべて，productの構築にかかわる人が入手できること
        
        communicationの基礎: 透明性により，観察・理解が可能になる
        
        → 信頼関係
- あらゆる形のUncertaintyを同時に削減せよ
  - 目的(what)のUncertainty: 最終的なproductのfeatureを取り巻くUncertainty
  - 手段(how)のUncertainty: product developmentに用いられるprocessやtechnologyを取り巻くUncertainty
  - 顧客(who)のUncertainty
  - iterative and incremental developmentにより容易に同時の削減ができる
    - 検査と適応，透明性を定常的に行うことで実現
    - 未知の未知を学習できる
予見と適応
- 予見への願望と適応の必要性との間のバランスをとる
- 選択肢を広げておく
  - 最終責任時点(LRM)
    - 拙速な判断は×
    - 判断しないcostが判断するcostを上回るときに決定する
    - 判断に関する理解が深まれば，判断のcostが下がっていく
- 事前に正しく行うことは不可能だと認める
  - 重要な知識がない状態では，精度の低い要件を大量に作ってしまう
    - 目的のUncertaintyが見えなくなる
    - 無駄になる
  - Scrumでは，ある程度は事前に要件を集め，計画を立てるが，必要な分だけ
    - 詳細は，構築中のproductの学習に合わせて埋めていく
- 適応型で探索型のapproachを好む
  - 適応: 何らかのactivityで知識を得ること
    - prototypeの構築，概念実証(POC)，勉強，実験
    - 調査によって情報を買う
    - tool, technologyが，調査のcostを大きく下げる
- 経済的に妥当なやり方で変化を受け入れる
  - 予見のし過ぎは逆効果
    - 自己成就的な予言pattern
  - Scrumでは変更cost曲線をできるだけ平たんにする
    - processにおける作業の量と流れを管理し，時間の影響を変更costに与えないようにする
      - 多くの作業の成果物(詳細な要件，設計，testcaseなど)をjust_in_timeで作り出す
- 予見的な事前の作業と適応型のjust_in_timeの作業とのbalanceを取る
  - 経済的に妥当なやり方で，素早いfeedbackに基づく適応の量を最大化し，事前の予見を最小化する
    - かつ，complianceや法規制，企業の目的から外れない
  - 革新的なproductを素早く開発するためには，適応すべきことに対して，chaosにならない程度の予見が必要
    - chaos → 作業が非効率
検証による学び
- 想定を確認したり反証したりする知識を得たとき
- 重要な想定をまず検証する
  - 想定: 推測や信念．検証による学びがまだのもの
    - 開発に重大なrisk
    - Scrumでは最小化かつ残る期間を短くする
      - iterative and incremental developmentをlow cost researchと組み合わせる
- 複数の学習loopを並行して活用
  - Scrumにおける継続的な学習
    - feedback loop
    - 予め定義された複数の学習loop
      - daily_Scrum, sprint review
      - pair programming(秒単位のfeedback), test driven development(分単位のfeedback)
- 素早いfeedbackのためのworkflowをまとめる
  - Scrumでは作業の直後にfeedback
    - 経済的恩恵が大きい
    - 学習loopをすばやく閉じる
    - riskを小さくできる
仕掛け中の作業(WIP)
- 作業は経済的に妥当なサイズにまとめよ
  - 計画駆動: all-before-any型approach
    - batch サイズ: 100%
    - 規模の経済をproduct developmentに当てはめたもの
  - Scrum: batch サイズを小さくする
    - 規模の経済の当てはめは重大な経済的損失を呼ぶ
    - 恩恵
      - cycle time削減
      - flowの変動性の低減
      - feedbackの推進
      - riskの低減
      - overheadの低減
      - 士気と危機意識の向上
      - cost, scheduleの肥大の抑止
    - 1個流しにこだわることはない
      - 作業の流れ，全体の経済性も重要
- 在庫を認識し，適切な流れで管理
  - 在庫: WIP
  - 大量の在庫があるときの変更は，重大な無駄につながる
    - → just_in_timeで在庫管理を健全に行う
  - 要件が多すぎると，要件の変更時に在庫の無駄が生じる
  - 要件が十分にないと，作業をすばやく流せない
  - → ちょうどよい在庫と多すぎる在庫との間で適切なbalanceを見出すことが目的となる
  - 在庫は要件だけではない．ほかのものも管理要
- 作業者の手待ちではなく，作業の手待ちに注目
  - 作業の手待ち: 実施したいのに何らかの原因でできない作業
  - 作業者の手待ち: capacityに余裕があり，もっと作業ができる人
  - 走者ではなくバトンを見よ
  - queue理論のgraph
    - 作業の手待ち（遅延した作業）は，いったん高稼働率になると，指数関数的に積みあがる
  - → 作業の流れの中でbottleneckを見つけ削減する，という経済的に意味のあるactivityに注力する
- delay_costに考慮
  - delay_cost: 作業の遅延やmilestoneの達成の遅延に関連した，経済的cost
    - どの種類の無駄が経済的に損失を与えるか算出できる
  - 例
進捗
- 自分たちがdeliveryし，検証したものによって測る
- realtimeの情報に適応してreplan
  - plan: 物事がどう進むか事前に予見しただけのもの
  - 経済的に重要な情報の流れに適応
    - 開発期間中に継続的に行う
- 動作する資産を検証することで進捗を測る
  - 動作する資産を検証 → 重要な想定の検証 → 次のstepへのfeedback
  - 顧客にとって価値のある作業をどれだけ終わらせたかがimportant
- valueを主眼に置いたdeliveryに集中
  - 中間成果物は顧客が認識できる価値をもたらさない．目的のための手段に過ぎない．
  - それ自体が重要なfeedbackを生み出したり，重要な知識を得るために役立つことに意味がある
作業効率
- 素早く進む，しかし，あわてない
  - 機敏 & 状況に適応 & speed
  - 機敏 & 持続可能なpace & 品質
- 品質を作りこむ
  - 機能横断型のScrum_teamに責任
  - 継続的に作りこんで，sprintごとに確認
  - valueのincrement: 強い自信をもって完成され，productに組み込んだり出荷しようと思えばできるようになっている
- 必要最低限の儀式
  - 不要な形式主義の儀式 ←→ Scrumは価値中心的
    - processのためのprocess
  - documentを書くcase
    - productの一部
    - 重要な議論や意思決定，合意を記録して，何があったのか将来分かるようにするという目的
    - 新しいmemberが追い付くうえで役に立つ，価値の高い方法
    - 規約上の要件
まとめ
- 核心的なAgile principle
  - Scrumの方法を導く基本的な信念
  - 計画駆動との違い

Ch04 sprint

sprint: 1週間～最大1か月までのcycleの繰り返し
timeboxing
- 短く固定された期間に，一度設定した目標をなるべく変えず，チームで合意した完成の定義を達成した出荷判断可能なproduct incrementを生み出す
概要
- sprint: Scrum frameworkの枠組み
  - goal, memberは変えない
  - 特性は，あらゆるチームのあらゆるsprintに当てはまる(一部例外がある)
timeboxing
- 時間管理のtechnique．
- 仕事の能率を高め，scope managementを支援
- sprint goalに向けて選択した作業を完了するために，持続可能なpaceで働く
- merit
  - WIPの上限設定
  - 優先順位づけを強制
    - 重要な少量の仕事が優先される
    - 集中力を研ぎ澄ます？？
  - 進捗状況の可視化
    - sprintの最終日という締め切りまでに重要な作業が完了し，検証されているかどうかという観点で進捗を可視化できる
  - 不必要な完璧主義を避ける
    - 期限がある
  - 締めくくりの促進
    - 切迫感
  - 予測可能性を改善
    - 予測の範囲がはっきりする
短期間
- 計画の立てやすさ
- すばやいfeedback
- 投資収益率の改善
- 損失の限定化
  - 失敗しても，短い期間を失うだけで済む
- 熱狂を取り戻す
  - 待ち時間が少なくなる
  - 目に見える進捗，終わりがある
- 頻繁なcheckpoint
  - 動作するfeatureを実際に見て，誰もが意思決定できる
immutable sprint term
- 例外
  - feedback speed up
  - 休暇，会計年度末
  - release span
- 一定のrhythmのmerit
  - 予測可能，計画が立てやすい
  - 安定した健康的な鼓動
    - 高速で柔軟なbusiness valueのflowを実現するため
  - zoneに入りやすくなる，roleを果たせるようになる，波に乗りやすくなる
  - 平凡だが必要不可欠なactivityが習慣化される
  - 短いrhythmで，仕事への集中力を一定に保てる
  - 調整のためのoverheadが大きく減少
- 簡潔なplanning
  - velocityへの信頼度up
    - sprint単位で平準化
  - releaseまでのsprintの回数がわかる
immutable goal
- sprint goal: sprintを要約したもの．取り組むbusiness上の目的とvalue．
  - 明確で1つの事柄に焦点を当てる
  - 複数のgoalとなることもある
  - development_teamが洗練・合意し，sprintで完成できるproduct backlog itemを特定する
    - sprint goalをさらに精緻化
- 相互commitment
  - チーム
    - sprintの最終日までにsprint goalを達成することをcommit
  - product_owner
    - sprint期間中はsprint goalを変えないことをcommit
  - sprint importanceを表現
    - business needsを変化に適応させることと，チームが短期間でvalueを生み出す能力を集中的に効果的に発揮させることのbalanceをとる
    - sprint goal → チームは明確に定義されたvalueに集中
- 変更と明確化
  - 変更は×，明確化は〇
- 変更の影響
  - あらゆる点でloss大きい
- 実利的であるべし
  - 経営状況や障害など実利的に問題があれば，ruleより実利を優先する
  - 変更の必要性を，経済的な観点でproduct_ownerがチームと議論できれば，やる気と信頼は高まる
- sprintの中止
  - 経済的な事情
  - 奥の手
完成の定義
- 出荷判断可能な
  - ≠ 出荷しなければならない
  - sprintで構築したものが完成しているという自信
    - 出荷するために必要な仕事（重要度の高いテストや統合など）が確実に完了している
- 概念的には仕事のcheck listのようなもの
  - 変動要因
    - 成果物の性質
    - 成果物に使われている技術要素
    - 成果物を構築した組織
    - 現在の可能性に影響しうるimpediment
- sprint期間より長くなりうるテスト
  - 自動化に取り組む
- 完成の定義は時間とともに改善
- 完成の定義と受入条件
  - 受入条件: product_ownerが規定した満足条件
    - 受け入れテストで確認
  - product backlog itemは，個別の受入条件とsprint levelの完成の定義の両方を達成して，完成したとみなされる
- 完成と完全に完成
まとめ
- Scrum frameworkにおけるsprintの果たす重要な役割
  - sprint: ほかのactivityや作成物を配置するEssential Scrumの枠組み
    - 短い，timeboxing，期間は固定
    - sprint goalで定義
      - 経済的な妥当な理由以外は変更不可
    - 出荷判断可能なproduct incrementを生み出す
      - 全員で合意した完成の定義を満たす

Ch05 要件とuser_story

要件の扱いが伝統的なprojectとどう違うか
user_story: business valueを表現する共通形式
概要
- Scrumでは，要件の詳細はprojectを通じて継続的に対話しながら調整
- 要件はjust_in_time．チームが開発を始める必要なときに，必要な分だけ
  - business goalを達成するために操作できる重要な自由変数
- Product Backlog Item(product_backlog_item): 要件の置き場所．それぞれが何らかのbusiness valueを表す
  - 会話の中で，より詳細なproduct_backlog_itemに分解し，最終的にsprintに入る大きさまで小さく・詳細化される
    - 設計・構築・テストができる
  - Product Backlogはproduct_backlog_itemの集合のsnapshot
  - product_backlog_itemの標準形式はない
    - user_storyやusecaseなど
対話する
- 要件: 構築しようとしているproductに欠かせない事柄についての共通理解を促進するcommunication手段
- 音声によるcommunicationは，帯域が広く，feedbackもすばやく，安くて簡単に共通理解が得られる
- 双方向communicationが問題解決のためのideaの発見を促す
- Product Backlogは生きているdocument
改良し続ける
- 段階的洗練戦略
what's user_story
- 様々な種類のproduct_backlog_item(特にfeature)に期待されるbusiness valueを表現する便利な形式
  - business側と技術側ともに理解しやすくなっている
  - 単純な構造，会話のために優れたplaceholder
  - 段階的改良もしやすい
- Agile development principleとneedsを効率的に結びつける軽量approach
- 要件の詳細化として，重要・役立つ情報の記録のために使う
- Card
  - userの分類（役割），目的，求める理由（利益）を具体的に書く
  - 要件の意図や本質を捉えた数行の文章にする
    - 関係者をより詳細な議論に導く
- 対話(Conversation)
  - Conversationは，要件の詳細を適切な時期に具体化・共有するためのstart point
    - user_storyはConversationのための約束事
  - user_storyが，書くことに向けていた注意を対話に向ける
  - 豊かな情報のやり取りと協調をもたらす
    - 正確な要件を誰にも理解できる表現にする
  - 文書と相互補完的
- 確認(Confirmation)
  - 満足条件，受入条件
    - 期待される振る舞いを示す
  - 受入テスト
    - 実例による仕様，ATDD(受入テスト駆動開発)
  - 具体例を精緻化し，user_storyを作成・改善するprocessを駆動できる．user_storyに自動化された受入テストも用意できる
詳細化のlevel
- user_story: Scrum のvalueを生み出すflowに顧客やuserのvalueを持ち込むのに最適
  - 大きさの問題
  - → 複数の抽象化level
    - epic: 数か月の期間，複数回のrelease
      - 期待されていることの概要，概要levelの全体像をもたらす
    - feature: 数週間の期間，1 sprintには入らない
  - epic, featureなどuser_storyの最小限の形式をstoryと呼ぶ
  - 関係するuser_storyをまとめたもの: theme
  - task: user_storyより具体的．構築するものについてのhow(not what)を決める
うまく書けたuser_storyとINVEST
- INVEST: user_storyが書き手の意図に合うかどうかを評価するために有用なprinciple
- Independent
  - 依存性を最小化
- Negotiable
  - user_storyは内容と理由を書く
    - 規制や制約がなければ，方法がNegotiableとなるようにする → Innovation
- Valuable
  - 顧客と利用者双方にとって → product_ownerから見てすべてのstoryはValuableが要
  - technical storyはProduct Backlogに入れない．business storyの関連タスクとする
- Estimatable
  - storyの規模，労力，costが目安
- Small
  - 近いうちに取り掛かりたいstoryは小さくする必要がある
    - sprintで扱うため
- Testable
  - 確認 → 5.4
  - 必須ではないし不可能なこともある
非機能要件
- system levelの制約
- できる限り多く完成の定義に含める
  - → すばやいfeedback
学習のためのstory
- prototype, POC, 実験, 学習, spike
- 探索的activity
- cost, valueの算出・比較
- fail first戦略もある
storyの収集
- userは作家というより批評家
- userにチーム memberとして関与してもらう
- user_story記述workshop
  - 目的: business valueについて協調的にbrain storming，想定するproduct/serviceのためのuser_storyの類型を作る
  - 初回はuser role analysis
    - personaというprototype的人物描写も作成する
  - 進め方は上手くいくやり方でいい
- story mapping
  - user中心指向の観点からuser_storyを作成
  - 抽象的なuser actionを，詳細taskによって組み立てられるworkflowに分解する
    - epic/theme/sprint可能なstory
  - userにとってのvalueから優先順位づけ
  - storyの分解とuset中心設計の考え方の結びつけ
    - user目線での行為の流れを示す
    - 顧客の価値という大きな観点からの，個々のstoryの関連性が分かる
  - workflow: contextとなり，関係するstoryに注目できる
  - user_story記述workshopに，優先順位を補完する
まとめ
- Scrumでの要件の扱いを見た

Ch06 product_backlog

概要
- product_backlog: productに求められる機能を，優先順位をつけてリスト化したもの
  - 何を作るか，どの順番で作るかについての認識が一か所にまとまり，共有できる
  - Scrum frameworkの肝
product_backlog_item
- だいたいはfeatureや機能項目を表し，userや顧客の目に見える価値をもたらす
- user_story形式で書かれることが多いが，書式は不定
good product_backlogの特徴
- Detailed appropriately(適切な詳細度)
  - 取り掛かる時期に合った詳細度．近いほど細かい．
  - 適切なtiming
- Emergent(創発的)
  - 時間とともに姿を変える
  - 対応可能になっている
- Estimated
  - story_point, 理想日を使う
  - 近いものは小さめで正確な見積もり
  - 遠いものは見積もりはしなかったり，Tシャツのサイズ程度の見積もりになることもある
- Prioritized
  - 遠いものは細かい優先順位不要．全体のlevelでの優先順位程度でいい
grooming
- DEEPなproduct_backlogのために，product_backlogの中身を整理
- product_backlog_itemの作成と改良（詳細の追加）/product_backlog_itemの見積もり/product_backlog_itemの優先順位づけの総称
- product_ownerが主導する全員での共同作業
  - 開発チームは，各sprintの作業時間の最大1割程度までgrooming用に時間を確保
- timing
  - 最初はrelease planningのときに，stakeholderとともに
  - 週に1度かsprintに1度程度で，development_teamとともにgrooming workshop
    - daily_Scrumのあとにincremental groomingを行うこともある
      - 全員でやる必要はない
  - sprint reviewの際にも行う
  - きちんとprocessに組み込みさえすれば，timingは重要ではない
- business valueを柔軟かつ高速にdelivery
準備完了の定義
- grooming: Backlogの最初のitemを準備完了にする
- 作業のchecklist
  - product_backlog_itemについて必要なことのリスト
- 厳しく設定すると，sprint goalの達成可能性が大きく上がる
flow management
- product_backlog: 不確実性がある状態でも高速かつ柔軟にvalueを提供する流れを実現できる
  - 重要な情報は絶え間なく少しずつやってくる
  - → 作業を整理して管理し，頻繁にやってくる情報をすばやく効率的に処理しながら対応する必要
- release flow management
  - release planningに備えたgrooming
  - 必須/できれば含める/含めないの3 エリアに分ける
- sprint flow management
  - groomingにより，feature群をsprintに流し込める
    - product_backlogの先頭のitemは，明確に定義されていてテスト可能な状態
  - product_backlogを要件のpipelineと考えてgroomingが〇
    - pipelineからsprintに流し込まれた要件を，設計・開発・テスト
    - product_backlogを上がっていく間にgroomingで要件が見直されていき，準備完了な状態になる
      - development_teamが理解できるほど詳細で，1回のsprintで完了できる規模になる
    - 必要十分なだけのproduct_backlog_itemを在庫として抱え，一定のflowを作ることがimportant
      - sprint 2回から3回分程度のstoryを準備完了状態で抱えておくとうまくいく
どんなproduct_backlogをいくつ用意するか
- 基本原則: Productごとにproduct_backlogを1つ用意
  - 注意が必要なcaseある
- Productとはなにか
  - さまざまな捉え方
  - goal: component_teamの数をできるだけ減らす
  - → packagedで，デリバリー可能であり，利用者に価値をもたらすものに合わせて，product_backlogを並べる
- 大規模product -階層化backlog
  - できるだけ1つのproduct_backlogがよいが，現実的に不可能なこともある
  - → 階層化backlog
  - feature area単位のBacklog Itemは．対応するproduct_backlogのitemよりも，サイズが小さい
  - release train → Ch12
    - portfolio_backlog, program backlog, チーム backlogの3 level
- 複数のチーム -単一のproduct_backlog
  - Productごとに1つのBacklog → Productにかかわるすべてのチームがproduct_backlogを共有するため
    - Product全体で見たときの経済的最適化可能
  - 各チームがproduct_backlogのどのItemに対応できるのか知っておく必要
    - → 共有Backlogに対するチームごとのviewを用意する
  - チームの交換可能性に価値がある
- 単一のチーム -複数のProduct
  - チームは複数のProjectの担当は極力避ける
  - 少なくとも，同時に複数のProductにかかわらないようにする
  - どうしても同時に複数のProductの作業をするときは，各product_backlog_itemを1つのproduct_backlogにまとめる
まとめ
- product_backlogが果たす，不確実性のもとで高速かつ柔軟に価値を提供する流れを実現するための役割

Ch07 見積もりとVelocity

概要
- まず作ろうとしているもののサイズを見積もる
- さらに，その作業におけるVelocityを計測
  - 各sprintで完成したItemの見積もりサイズを合計することで出せる
- → 期間・costを導ける
いつ何を見積もるのか
- Portfolio Backlogの見積もり
  - 作成するすべてのProductの優先順位づけ
  - ざっくりとした相対的な見積もり（Tシャツのサイズていど）
- Product Backlogの見積もり
  - product_backlogのgroomingの一環として行うactivity
  - 見積もりmeeting @初回のrelease planning
    - 以降も新たなproduct_backlog_itemの見積もりが必要なら見積もりmeetingを招集する
  - 成熟したScrum_teamならすべてのproduct_backlog_itemを同程度のサイズにまとめられる
  - 見積もる理由
    - すべてのproduct_backlog_itemが同時に同じサイズにはならない
    - チーム memberがすべてのproduct_backlog_itemのサイズを同程度にまとめられるようになるには，それなりに時間がかかる
    - 同じサイズにすることが目的となってしまい，不自然なところでstoryを分割せざるをえなくなることを避ける
    - 最重要なこととして，見積もりの最大の目的は，対話の過程でいろいろな気づきが得られる
      - 健全な議論を促す
- taskの見積もり
  - commitmentが達成可能だと確信するため
  - 大きさは理想時間単位で判断(a.c.a. 工数)
product_backlog_itemの見積もりの考え方
- チームで見積もる
  - development_teamが，全員で見積もる
  - 全員の意見をまとめて，それぞれのproduct_backlog_itemのサイズを判断できるようにする
- 見積もりはcommitmentではない
  - 数字を操作しないでよいようにする
- 正確性か精度か
  - 無駄は×
  - やり過ぎると逆効果
- 相対サイズの見積もり
product_backlog_itemの見積もりの単位
- story_point
  - product_backlog_itemの大きさを計測する指標
  - storyの複雑さ，物理的サイズなどを組み合わせて，相対サイズを測る単一の指標としたもの
  - development_teamの視点からの，storyの完成に要する作業を表す
- 理想日
  - 誤解を招くriskあり
    - あと（理想日）日で終わるというわけではない
  - 作業日数（人日）で表す
planning poker
- memberの同意ベースで見積もりを行うtechnique
- 見積もりの尺度
  - フィボナッチ数列や2の累乗などで，同程度のサイズのproduct_backlog_itemをひとまとめにして同じ数字をassign
- 進め方
- merit
  - チーム memberをまとめて，正確な見積もりとなる
  - 議論によりproduct_backlog_itemの理解が深まる/共有できる
Velocity
- 各sprintで完成した仕事量
- 計測対象: 生産量(サイズ)， not 成果(value)
- 利用目的
  - Scrumでのplanning
  - チームの現状を診断
Velocityの幅の算出
- 幅を持たせる → 不確定要素があることが伝わる
- min/max sprint数が分かる
- 最大値と最小値の平均や，90%信頼区間など単純計算で求める
Velocityの予想
- sprint planning
  - commitしたproduct_backlog_itemのサイズを合計してチームの予想Velocityとする
  - 2回のsprintで見積もりを行うなどで，幅を求める
Velocityへの影響
- 向上のための手段や悪影響のある手段など
Velocityの誤用
- performanceの指標としては使えない
  - 数字の操作(pointのインフレなど)や手抜きが起こる
- 見積もりの正確さの検証，チーム内での改善がどの程度進んでいるのかの判断にのみ使う
まとめ
- サイズの見積もり，Velocityの算出，期間の求め方
- 各levelでの見積もり
- story_point/理想日
- planning poker
- Velocityの使い方

Ch08 技術的負債

概要
- 負債の返済のために十分に注意が必要
- systemの設計や実装は，業務ドメインに関する知識をよく反映できるように発展させていく必要
- 無責任や不注意といった原因で発生する，ナイーブな技術的負債
- 不可避な技術的負債
- 戦略的な技術的負債
技術的負債の行く末
- 予測不可能な臨界
  - 負債のかさみ具合は予測不能かつ非線形
- deliveryに要する時間の長期化
- 不具合の多発
- development/support costの増加
- productの退化
- 予測可能性の減少
- 伸び悩み
- 募る不満
- 顧客満足度の減少
技術的負債を生む要因
- 納期を守るためのpressure
  - Velocityの偽装
- testを減らせばVelocityが向上するという神話
  - TDDのような優れた手法を使うのが〇
- 負債が生む新たな負債
技術的負債の管理
- どんなproductも技術的負債からは逃れられない
- 技術者の言い分とbusiness関係者の言い分のbalanceを取る
  - product_ownerが存在する理由の1つ
技術的負債の発生の管理
- 優れた技術的practiceの活用
  - ナイーブな技術的負債を増やさない
  - simple design, TDD, CI, 自動テスト, refactoringなど
  - refactoringによる負債の支払い
- 厳しい完成の定義の使用
  - checklistの技術的な網羅性を高める
- 技術的負債の経済的意味についての適切な認識
  - 技術的負債の多方面への影響
    - 真のcostより低く見積もってしまいやすい
技術的負債の可視化
- 技術的負債という例えの最大のmerit: development_teamと経営者の会話での共通認識の獲得
- business levelでの技術的負債の可視化
  - 組織のBalanceSheetに短期・長期の技術的負債の行を追加
  - Velocityの変化の追跡
    - 金銭的costを明確にできる
- 技術者levelでの技術的負債の可視化
  - 既存の障害管理systemに記録
  - product_backlog_itemを作成
    - 返済のcostが高い場合
  - 技術的負債だけを扱うBacklogを作成
    - 技術的負債の現状を把握
    - どの時期に負債を返済するか積極的に決められる
  - 同じ場所で作業なら，掲示板を壁に掲げるのもよい
技術的負債の返済
- category
  - 偶発的な技術的負債
  - 既知の技術的負債
  - 返済対象の技術的負債
- flow
  - 既知の技術的負債を返済すべきか判断
  - 作業中のコードに偶発的な技術的負債を見つければ，きれいにする
    - 多すぎるときもできるだけは対応する
    - 返済できない分は既知の技術的負債としてまとめる
  - sprintごとに既知の技術的負債のいくつかを返済対象の技術的負債とみなす．
    - とくに利率の高いものを選ぶ
- すべての技術的負債を返済すべきというわけではない
  - 寿命が近づいているproduct
  - 使い捨てのprototype
  - 短期間しか使わないproduct
- boy scout ruleに従う(負債を見つけたらその場で返済)
  - 「来た時より美しく」
  - 偶発的な技術的負債の返済用の時間を予めある程度見込んでおく
    - 5%~33%
- 技術的負債の返済はincremental
  - 一括払いは×
  - 返済のためだけのsprintが必要となってしまうような状況にしない
  - 既知の技術的負債をピックアップして返済対象の技術的負債とみなし，次のsprintで返済
- 金利の高い技術的負債から返済
  - 多くのコードが依存していて頻繁に変更が加わるモジュールなどでの負債
- 技術的負債を返済しながら顧客に価値をもたらす作業も行う
  - できるだけ，返済のためだけのsprintは作らない
  - 負債の返済だけを扱うproduct_backlog_itemは置かない
  - merit
    - 負債の削減の作業を顧客に価値を届ける作業とうまく組み合わせて進めれられ，product_ownerが適切に設定した優先順位に合わせられる
    - development_team_member全員が，技術的負債の削減に関する責務を共有．ほかの人が後で対応してくれるものではないとはっきりできる．
    - 技術的負債の予防や対策の力を養える．
    - 金利の高い分野を見つけやすくなる． ← 対応中のコードは何かしらの重要性がある（からこそ対応している）ため．
    - 対応不要な分野の技術的負債の返済に，時間を無駄遣いせずに済む．
  - 既知の技術的負債の返済をproduct_backlog_itemと関連付けて進めるのは，simpleに組み合わせられて〇
まとめ
- 技術的負債の概念
- 3つの分類
- 管理
- activity
  - 発生の管理
  - 可視化
  - 返済

Part 2 Role

Ch09 product_owner

概要
- product_owner: productの統括を認められた中心的な存在．Scrum_teamを構成する3つのRoleのうちの1つ．
- 2方向を見る → business analyst & tester
  - 組織内のstakeholder, client, userが持つneedsや優先順位について，代理ができるくらいに深く理解
    - product managerとして振る舞い，正しくsolutionが開発されていることを保証
  - development_teamに何をどの順番で構築するか伝える
  - & 受け入れ条件を明確にして，条件を満たすテストを実行させる
    - 抽象的なtestは書く
主な責任
- 経済性の管理
  - 各levelで適切な経済的意思決定が継続的になされるようにする
  - release levelの経済性
    - product development中に生じる経済的に重要な情報に対応
    - scope，納期，予算，品質との間で継続的にtradeoff
    - sprint終了時に，次のsprintを実施するかどうか判断
      - product_backlogによる柔軟性
  - sprint levelの経済性
    - sprintごとのROI(投資収益率)を高めるため
    - sprintのcost: 期間とチーム構成を把握
  - Product Backlogの経済性
    - 経済状態に応じた優先順位に責任
- planningへの参加
- product_backlogのgrooming
- 受け入れ条件の定義と検証
  - product_backlog_itemの受け入れ条件を定義する責任
    - 受け入れ条件: 機能要求や非機能要求が満たされているとproduct_ownerが納得できる条件
    - sprint planningの前に受け入れ条件が必要 ← 準備完了の定義に含まれる
  - 受け入れ条件が満たされていることを確認する最終的な責任
  - 検証は，sprint実施時に行う
    - sprint reviewまで待たない
      - sprint reviewでのデモは完成した機能のみ
- development_teamとの協力
  - 積極的な関与，献身，毎日果たすべきRole
- stakeholderとの協力
  - 内外のstakeholder
特性とskill
- domain skill
  - product visionをまとめ，そのvisionに向けてチームをleadできるvisionary
  - visionは詳細でも明確でもなくてよい
    - 進んで変化に対応
  - business, domainの知識が必要
    - → 機能の優先順位づけ
- 対人skill
  - stakeholderとよい関係が必要
    - → 交渉，合意形成
  - stakeholderとdevelopment_teamとの橋渡し
    - 適切な言葉で情報を伝えるcommunication skill
  - 特性
    - 現状に反する場合でも声を出す
    - ideaに自信がある
    - domain 知識がある
    - 単純かつ簡潔にわかりやすく情報を伝えられる
    - 信用されている
  - 周囲のmotivationを高められる
    - businessの課題を伝えて，仕事の目的を思い出してもらい，情熱を持続させる
- 意思決定力
  - 意思決定の権限が必要
  - 適切なtiming, 正当な理由
    - 最終的な意思決定者
  - business needsと技術的な実現性とのbalance
- 説明責任力
  - business resultを届けることへの説明責任
  - resourceを有効に活用する責任
    - product_backlogの変更，優先順位の調整，開発の中止が可能
- stakeholder, Scrum_teamともにかかわる，フルタイムの仕事
- product_owner, Scrum_master, development_teamは共通のgoalをもつ1つのunit
1日の様子
- 1週目，2週目
  - portfolio planning
    - portfolio managerや統治機構と，portfolioの期待値について議論
      - → 新しいproduct planningに影響．product planningのinputになる
  - product planning
    - 適切なstakeholderと一緒に新しいproductのvisionを考える
    - 終了したら，productの案をportfolio planningに提出
      - → 組織の経済的filterにかけられ，開発の予算やscheduleが決定
- 3週目
  - 初期のrelease planning
    - 内部stakeholder, development_team_member, ときに外部stakeholderも参加する，product_backlog_item記述(story writing) workshopを含む
      - release planningで使用する概要levelのproduct_backlogを作成
    - 見積もりworkshop
      - 1~2日
      - development_team_memberが価値の高いproduct_backlog_itemの規模を見積もる
    - 最初のrelease planningのfacilitation
      - product_backlogの優先順位づけ
      - 制約(scope, schedule, budget)のbalanceをとる
      - stakeholderに加え，development_team_memberの一部～全員で，product_backlog_itemの並び順に影響を与える技術的な依存性を特定
      - goal: releaseの全体像の明確化．いつ何ができるのかというbusinessの最初の質問に答える
      - 1~2日
      - 継続的なactivity
- 4周目～ Scrum_teamが最初のsprintを開始
  - 開始時に，sprint planningを統括
  - 実施中は，daily_Scrumに参加
  - 質問に答え，review可能になった機能をテスト
    - 毎日する必要があるので，できないときは代理を立てる
  - 内外のstakeholderに会って，次のsprintの優先順位が正しいことの確認
  - 今後のsprintで機能を選択するときに影響を与えるuserからの重要なinputを取得
  - product_backlogのgrooming
  - sprintの終わりに，検査と適応の2つのactivityに参加
    - sprint review, sprint_retrospective
誰がproduct_ownerになるべきか
- 社内開発
  - 開発の恩恵を受ける部門から任命された人がなる
- 商用開発
  - product managerやproduct marketerなど，clientの声を代弁する人がなる
  - できるだけ多くのactivityに責任をもつ
    - 1人でこなしきれないほど膨大ならproduct_owner チームを作るが，Scrum_teamのproduct_ownerの役割は常に1人
- 外部委託開発
  - 委託元の社員がproduct_owner
  - 固定価格契約は× → 複雑
- component開発
  - 技術componentに注力 → Backlogの優先順位を決定できる技術志向の人がなる
  - feature_teamの技術的要求の優先順位や統括方法がわかるproduct_ownerが必要
その他のRoleとの組み合わせ
- 余裕があれば，同じ人が複数のScrum_teamのproduct_ownerの担当も〇
  - それぞれの成果に関連があるときはこの方が簡単
- product_ownerとScrum_masterの兼任は×
product_owner チーム
- 1人の人間が, product_ownerとして意思決定し，stakeholderやScrum_teamとの橋渡しをする必要がある
- 1人のproduct_ownerに対してproductに問題があるだけなら，productの問題に対応するべき
  - 必要なときのみproduct_owner チームを作る
- product_owner proxy
  - 事業部門の人にproduct_ownerを担当してもらい，IT部門の人はproduct_ownerとチームのやり取りをするproduct_owner proxyを任せるcase
  - 特定の状況でproduct_ownerの代理になれる人
    - 本当のproduct_ownerではなく，代わりに戦術的な意思決定をする人
    - 責任はproduct_owner
- chief product_owner
  - 階層的にscale
  - 各チームのproduct_ownerが上の階層に投げることなく，ほとんどの意思決定をできるようにしておく
まとめ
- product_ownerのRole
  - productの統括を認められた中心的な存在
- product_ownerの重要な責任と特性
- Scrumの各activityにおけるproduct_ownerの行動
- 誰がなるべきか

Ch10 Scrum_master

概要
- Scrum_master: Scrumのvalue, principle, practiceがみんなに正しく理解され，受け入れられるようにする
  - as a coach
  - 自分たちに適したperformanceの高いScrum手法で開発できるように，processのleaderとして支援する
主な責任
- coach
  - Scrum_teamのAgile coach
    - development_teamとproduct_owner間の垣根を取り払う → product_ownerが直接開発を駆動できる
    - 問題には支援する．impedimentは解決する．
      - 新人product_ownerが責任を理解し，Roleを果たせるようcoaching
      - product_backlogのgroomingなどのactivityを継続的に支援
    - Scrum_masterとproduct_ownerの関係: sport チームのcoachとownerの関係に似ている
      - Scrum_master: Scrumでbusinessの成果を最大化，期待を管理，product_ownerがチームに必要なものを提供，変化に対するproduct_ownerの不満や要求を聞き出し，チームが実行可能な改善へと翻訳
- servant leader
- processの権威者
  - Scrumのvalue, principle, practiceを順守させる権限
  - チームのprocessの改善を継続的に支援して，届けるbusinessのvalueを最大化
  - 機能部門managerやproject managerが持つ権限とは異なる
    - チーム memberの採用や解雇はできない
    - チームに作業を依頼したり，仕事のやり方への指示はできない
    - 仕事を完成させる責任はない
    - チームが自分たちのprocessを定義して遵守することを支援するだけ
- 防御壁
  - チームがvalueを届けることに集中できるようにする
- impedimentの除去
- change agent
  - 意識の変化を支援
    - 変化の必要性やScrumの影響・利点を理解してもらう
  - 長期的な成功につなげる
  - 大きな組織では複数のScrum_master
特性とskill
- 博識
  - いずれも専門のtop levelでの知識は不要だが，ある程度の知識は技術でもbusinessでも必要
- 質問力
  - 内容を促す質問(probing question)
  - 自分で答えを見つけられることを認識してもらう
- 辛抱強い
  - 自分の方がチームの集合知よりも賢いと考えない
  - 定期的に内省を促す質問をして，チームにsolutionを見つけてもらう
- 協力的
- 保護力
  - 経済的に正しいbusiness judgeができるようにチームを保護
  - Scrum_teamが健全なbalanceを取れるように支援
  - Scrumからさまよい出るmemberを支援．チームが難しさを克服できるようにする
- 透明性
1日の様子
- Scrumのactivityの開催やfacilitationに毎日時間を使う
  - sprint planning
  - sprintの実施
  - sprint review
  - sprint_retrospective
  - daily_Scrum
  - activityの準備・統括・Scrum_teamが価値の高い成果を達成できるように支援することも含む
- 毎日チーム memberをcoaching
- 毎日一定時間をcommunicationに使う
- sprintでは，product_ownerとともにproduct_backlogのgrooming
- change agentとしての時間
- impedimentの除去
Roleを果たす
- 誰がなるべきか
  - project managerやproduct managerからScrum_masterになることもある
  - technical leadは△
  - managerとの兼任も△(×)
- 必ずしもfull timeではない
- ほかのRoleとの組み合わせ
  - ほかのRoleと兼任するより，複数のチームのScrum_masterになるのが〇
まとめ
- Scrum_masterのRoleなど

Ch11 development_team

概要
- 機能横断的
Role別のチーム
- 技術的skillを一通り備えたチームが必要
- できるだけ機能横断的
主な責任
- sprintの実施
  - 大半の時間を割く
  - 自己組織化
- 日々の検査と適応
  - daily_Scrumに全員で参加
- product_backlogのgrooming
  - sprintの10%を使い，product_ownerのactivityを支援
- sprint planning
  - sprintの期間に応じて，半日～1日
  - 反復して実施, just_in_time
- productとprocessの検査と適応
  - sprint review
  - sprint_retrospective
特性とskill
- 自己組織化
  - bottom up型の創発的な特性
    - 外部からの圧力なし
  - 複雑適応system
    - 多くのentityが様々な方法でやりとり
    - やりとりは，単純で局所的なruleで統括され，定期的なfeedback
    - 大いに堅牢で斬新
  - managerは自己組織化チームのための環境を設定・再構築する
- 機能横断的な多様性と十分な能力
  - product_backlog_itemを選択し，Scrum_teamの完成の定義を満たして動作する，高品質の機能を作り出す
  - 成果の手渡しの数を最小化
  - 複数の視点が良い成果になる
    - 問題解決のための認知toolの持ちより
      - 解釈，戦略，mental model，手法やsolutionの嗜好が異なる
      - → すばやいsolution，高品質の提供物，大いなるinnovation，という観点から良い成果につながり，経済的valueへと変わる
  - チームの多様性のために，senior, juniorを組み合わせる
    - みんなで協力して学習し合う健全な環境
- T型skill
  - 幅広さと深さ
  - 継続的に学習してskill setを増やせるような環境が必要
    - skill set: domain knowledge, technical knowledge, thinking skillなど
    - 学習と実験の時間がうまく作れるように，managerがチーム memberを支援
  - 専門家は，複数のチームに余裕がある状態で時間を分割するか，ほかのmemberの学習支援に時間を使う
  - チーム memberがcoreとなる専門分野をもち，全体として柔軟性をもたらすような，skillに重なりのあるチームを作ることがgoal
- 銃士の姿勢
  - one for all, all for one
  - 仕事を成し遂げる責任をチーム member全員が負う
  - できないことがあるときは，skillある人に学習支援をしてもらい，チームの総合力を高める
  - 1人に負担がかからないように作業を構成
  - 議論に多様性
- 広帯域のcommunication
  - 有益な情報をすばやく交換，overhead少なく効率的にやり取り
  - 情報共有の頻度と品質を向上
    - → 検査と適応の機会が増え，意思決定を迅速にできる
    - 情報の経済価値は時間に依存 → 共有速度が高まれば，チームは情報の価値を最大化できる
  - 方法
    - face to face
    - TV会議system
    - 機能横断的チーム
      - 形式的な提出物によるやり取りの量も回数が少なくなる
    - valueのない儀式を減らす
    - 小さなチーム
      - channel数の増加率
- 適切な規模
  - 小さなチームの理由
    - 社会的手抜きが少ない
    - 建設的なやり取りが頻繁に起こる
    - 調整に必要な時間が少ない
    - 誰も陰に埋もれない
    - 小さなチームの方がmemberを満足させられる
    - 有害な過度の専門化が発生しにくい
  - 人数が多すぎたら，9人程度にチームを分割
  - Scrum projectのscale: 複数のScrum_teamを作る
    - Scrum of Scrum
      - 上位levelのdaily_Scrum相当のものを開催する
- 集中とcommitment
  - 集中: チーム memberが積極的にかかわって，チーム goalに専念
  - commitment: よいときも悪いときも，チーム goalの達成に尽力
  - 3つ以上のprojectの仕事を同時に行うのは経済的でない
    - 調整・想起・情報の追跡に時間がかかり，valueを付加する仕事の時間が減るため
    - 基本は1つがよい
- 持続可能なpaceで仕事をする
  - Scrumの優れた技術的なpracticeで平準化
- 長寿
  - groupではなくチーム
  - チーム: 機能横断的で多様性のある協調性の高い人たちで構成され，visionを共有し，それを実現するために協力する集団
  - group: 共通のlabelがついた人の集団
  - 長寿は経済的に好ましい
  - forming, storming(争乱期), norming(規範期), performimg
  - 上手く機能したチームはbusiness資産になる
    - 歴史的に重要な情報を蓄積
      - Velocityや見積もりの履歴
  - Agileの通貨はチーム
    - 個人と対話に価値
  - チームの信頼，一貫性，作業効率を保つ
  - 人ではなくチームを移動させる方が，経済的に優れている
  - チームは資産
    - 同時に行うWIPの数やproductの種類を決めるときのcapacityの単位
まとめ
- development_teamのRole
  - product_backlog_itemを出荷判断可能なproduct incrementに変える責任
  - sprintにおける責任
  - 10個の特性
  - 自己組織化，機能横断的で多様性がある，仕事を成し遂げるために十分なskillがある
    - T型skill
  - 銃士の姿勢
  - 広帯域のcommunication
  - 小さなチーム
  - 集中とcommitment
  - 長寿

Ch12 Scrum_teamの構成

チームの構成や，チーム間のかかわり方が，Scrumをうまく進めるために重要になる
概要
- businessのvalueを提供するために，複数のScrum_teamsの協力が不可欠
feature_team or component_team
- feature_team: 機能横断型かつcomponent横断型のチーム
- component_team: 何か1つのcomponent, subsystem(featureの一部)のdevelopmentにのみ注力
  - a.c.a. asset チーム, subsystem チーム
  - 同じ専門skillを持った人たちの集まりで構成される実行部隊など
  - 中央管理型の共有resource的
  - 各component_teamが作ったcomponentを統合し，完全なfeatureにまとめてdelivery
- 一番良いのは，機能横断型のfeature_team
- 移行措置としては，1つのfeature_teamがfeatureをproduct_backlogから取り出し，作業完了までの責任を持ち，完成までの手配をする
  - 個々のcomponent_teamも残り，各チームからfeature_teamのmemberをassignし，仲介者・収穫者の責務を持たせる
  - 頻繁にやり取りするcomponentを1つのfeature_teamにまとめる
- component_teamを導入するのは，resourceを1つのチームにまとめて集中管理した方が合理的なときだけ
複数チーム間での調整
- Scrum of Scrum
  - チームをまたがる作業を複数チーム間で調整
  - question
    - 前回以降で各自のチームの作業で，ほかチームに影響しそうなもの
    - 次回の各自のチームの作業で，ほかチームに影響しそうなもの
    - 各自のチームの今抱えている問題で，ほかチームに助けてほしいもの
  - 階層化も〇
- release train
  - vision, planning, 複数チーム間の依存関係などを調整するための手法の1つ
  - チーム間でのsync
  - product levelでの高速で柔軟な流れに注力
  - featureが「駅を出発」するscheduleが決まっている
  - rules
    - 頻繁に定期的にplanning, solutionのrelease日またはPSI（出荷判断可能なincrement）の公開日を決めておく(固定期日，固定品質，可変scope)
    - すべてのチームでiterationの長さをそろえる
    - 全体での中立的かつ客観的なmilestoneを決める
    - 継続的なsystem integrationを，top level(system level)だけでなくfeature level, component levelで行う
    - releaseできるincrementを定期的に(一般的に60日/120日ごと)用意し，client向けのpreviewや内部review, system level のQAに使えるようにする
    - system levelのhardening iterationを実行し，技術的負債の返済やrelease levelの検証・テストを行う
    - 各チームを同じような構造にするために，基盤になる各種component(interface, SDK, 共通でinstallするsoftware, license, UX framework, data, Web serviceなど)をきちんとそろえる
  - richな概念
    - portfolio level, release levelなど，何段階かの詳細度で考えられる
    - enterprise backlog modelに基づく
      - portfolio_backlog, program backlog, チーム backlogの3段階のbacklog を使う
      - チーム levelのrelease train
        
        各チームが数個のfeature areaに分かれてまとまる
        
        現実的な頻度で，feature areaをまたがったsystem全体の統合やテストを行う
        
        列車が発射する直前をhardeningのための時間と決めていることもある
  - release trainの流れ
    - release planningのmeeting
    - sprintの実行
    - release train levelでの検査と適応
まとめ
- Scrum_teamを構成するさまざまな方法
  - feature_team
  - component_team
  - feature_team, component_teamの組み合わせ
    - 徐々にfeature_team主体に移行し，codeの共同所有を実現
- Scrum of Scrum
- release train
  - 数多くのScrum_teamのactivityを調整

Ch13 manager

組織内にはScrumと関係ないRoleがあり，それらも組織に必要
各managerのRoleを見る
概要
- Scrumでもmanagerはimportant
- functional_managerの責務: teamの編成と育成, 環境を合わせてなじませる，value創造の流れを作る
teamを編成する
- 境界を定める
  - managerが，product, project(砂場)を定める
    - teamの構成を決める(誰をどのprojectとするかを決める)
      - teamはprojectの中で自己管理する
    - 自己組織化したteamにどこまで許すか決定
    - いくつのprojectを作るか決定し，各projectの境界も定める
- 明確なgoalを定める
  - 目的と方向性をteamにもたらす
  - product_ownerがgoalをより具体化する
- teamの体制を決める
  - business上のneedsや制約とのbalanceをうまくとったteamを作る
  - 機能横断的なScrum teamを作る
  - 各分野やcommunity(functional area)にfunctional_managerがいて，各functional areaからmemberを選んでteamを組む
- teamの構成を変更する
  - memberの変更
- teamに権限を持たせる
  - 自己組織化したteamでお互いをよりうまく管理することの達成のため，team_memberに責務を委譲
  - 権限のlevel
    - 通知，説得，相談，合意，助言，確認，委譲
  - 信頼し，委譲した分は任せる
  - team_member間に銃士の姿勢を育てる
teamを育てる
- managerがteam を管理するわけではない
- teamを活気づける
  - 楽しくて創造的でvalueをもたらせるような環境を作るのが責務
    - → motivation, energyを引き出す
  - task levelの作業のassignはやる気をそぐ
- 能力を伸ばす
  - memberが常に何かを学び，skill setを磨き続けられるような環境づくりをする
    - 研修の受講，カンファレンスへの参加
  - 個別のfeedbackの頻度を調整し，各memberの直属の上司が属するteam内での学習loopにマッチさせる
    - sprint単位など
  - 個人のperformanceがteamのperformanceを以下に支えるかという観点で行う
- functional areaのleadershipを発揮する
  - functional area での一貫性を保ち，memberを指導する
  - areaに関する標準を設定
- teamの安定を保つ
  - teamの構成を可能な限り変えずに保ち続ける
環境に合わせてなじませる
- value chain 全体がScrumを受け入れるようにする
- Agileの価値を広める
  - managerはAgileの価値と原則を受け入れる
    - 理解し，信じ，実践し，周囲にも仕向ける
- 組織内のimpedimentを除去
- 社内調整
  - 全体をAgileのprincipleに合わせていく
- 対外調整
  - simplest: ほかの組織のScrum_teamをまるごと借りる
  - 固定金額の契約は×
価値創造の流れを作る
- manager's Role @Scrum
  - 戦略的な方向性を定める
  - 戦略目標を達成するための組織的resourceを，採算を考慮して揃える
- 全体的な視点で考える
- 財政の管理
  - 任された財源をどのように使うか責任
  - portfolio management, corporate governance
- 評価や報告の管理
  - 評価や報告をScrumの価値や原則に見合ったものにする
    - 作業の手待ちを評価
    - 動作する検証済みの成果物で進捗を見積もる
    - すばやいfeedback flow を作る
  - 革新会計の要点となる評価基準
    - 革新会計: 不確定要素が多い状況でproduct, serviceを作るような組織でimportant
    - 行動につながる評価基準を使って，自分たちがどの程度すばやく学べるか評価
      - → business valueのある結果を得るための進捗を見る重要な指標
    - 3段階
      - 実用最小限の製品(MVP)を作って，組織やproductの現状に基づいた行動につながる評価基準のbaselineを設定
      - productのincrementalな改良をもとに行動につながる評価を向上させ，目標値に近づける
      - 行動につながる評価の値から目標に向かっての進み具合が実証できればそのまま続行．実証できなければ，新たな戦略にpivotして，この手順を繰り返す
project manager
- Scrum_teamにおける project managementの責務
  - Scrumの3つのRoleに分散している
  - 調整を任せるのではなく，さまざまな分野にまたがる依存関係を把握して各所とやり取りし，ほかチームとの調整を効率的にできるようにすること
- project managerのRoleを残す
  - 大規模で複雑な開発の場合は，手配や調整にからむタスクが非常に多いので，そのままRoleを残すのも〇
  - ただし，かなり大規模になったときのみ
    - できる限り，チーム間でのcommunication channelを見直すべき
      - Scrum of Scrumなどを使う
  - 調整の責務を第3者に渡すべきではない
    - project managerはScrum_teamのassistant(servant leaderのようなもの)
      - system全体の視点で考えて，各clusterや個々のチームのために動く
      - チーム間の調整に何が必要か，誰もがきちんと理解している状態にする．実際の調整はチーム自身で行う
  - 大規模なproduct/service developmentでほんの一部だけがScrumを採用している場合にも使える
まとめ
- Scrumの組織におけるfunctional_managerのRole
- 4 category
  - team編成
  - team育成
  - 環境を合わせてなじませる
  - 価値を創造する流れを作る
- 伝統的な組織とScrumを使った組織でのfunctional_managerの責務の比較
- project managerの責務，Role

Part 3 planning

Ch14 Scrumのplanning principle

伝統的な開発よりplanningに時間を割く
Scrum principleの一部をさらに掘り下げ，planningにどのように適用するのか見る．その土台となる議論を見る．
事前にきちんと計画を作れると思うな
- 検査と適応の経験に従う
- 最初のうちにある程度はplanningの成果物を出す
  - 事前のplanningとjust_in_timeでのplanningのbalanceのため
事前のplanningのやり過ぎに注意
planningの選択肢は，最終責任時点まで変更可能にする
planを守ることよりも，planの調整や再計画を重視する
- knowledgeがない状態で作られたため，事前のplanは抜けがある
plan list management
- WIP management
- 無駄なplanningの作成物を作らない
早めにrelease, 頻繁にrelease
- すばやいfeedback, ROIの向上
- 市場に出せるlevelは保つ
早めに学び，必要ならpivot
- pivot: 方向転換しながらもそれまでに学習したことはそのまま維持し続ける
  - 製品，戦略，成長のengineに関する根本的な仮説を新たに策定し，それを検証できるコースに方向転換すること
- 学習loopを高速かつ経済的に回すことが目標であり，正しくない方向に向かっていればpivot
まとめ
- Scrumにおけるplanning principleの概要を見た
- 原則に従い，経済面で妥当なplanningを達成する
- 事前に用意する適度な量の計画と，実際の結果をふまえたより詳細なjust_in_timeの計画との間で，うまくbalanceをとる

Ch15 さまざまなlevelでのplanning

Scrumにおけるplanningの概要を全体的な視点で見る
概要
- 5種類のplanning
  - 範囲，作成者，対象，成果物
portfolio_planning
- 複数のproductの中から，どれをどの順番でどの程度の期間で進めていくか決める作業
- 概念的にはproduct_planningより上だが，inputの1つはproduct_planningで得られる新たに考え出したproduct idea
product_planning(envisioning)
- 作ろうとしているproductの本質を見出して，productを作るための大まかな計画を作る
- まずvisionを作り，その後，概要levelのproduct_backlogを作る
  - product_loadmapを作ることも多い
- product vision
  - user, clientといったstakeholderたちが得る価値を明確に説明するもの
- 概要levelのproduct_backlog
  - まったく新しいproductを作る場合なら，少なくとも最低限の要件は事前に決めて，product_backlogに含める
  - 少なくとも最優先のitemがどれになるかも判断する
  - 想定されるuser_storyを設定
- product_loadmap(release loadmap)
  - productを今後どのように構築してどのようにdeliveryするのかのincrementalな性質を示し，各releaseに含まれる重要なfeatureについても示す
  - continuous deploymentがあっても有用になりうる
- 意思決定者に十分な安心感を与え，product developmentを認めてもらうため
release_planning
- incremental deliveryに向けて，scope, 期日, 予算とのtradeoffを考慮する
- product_planningが終わったら，releaseの最初のsprintを開始する前に最初のrelease_planningを実施する
  - そのreleaseでどれだけのものを作るか，それをいつreleaseするのかの間でbalanceを取ったもの
- ある程度のitemをproduct_backlogに用意して見積もる必要がある
- product_backlogに線を引く
- product_loadmapとproduct_backlogをより強く結びつける
- 期間を，そのreleaseを達成するために必要なsprint数で表す
- 直近の数回のsprint程度の推測は，作業の調整や事前に必要な支援のために有用．それより先の推測は無駄
sprint_planning
- product_backlog_itemの中から，Scrum_teamが次のsprintでどのitemに取り組むかを決める
- 各sprintの最初に行う
- sprint backlogを作る
  - product_backlog_itemの完成に必要な作業を，task levelで記述
- より踏み込んだlevelで，just_in_time planning
daily_planning
- 最も詳細なlevelのplanning
- team_memberが集まり，高度に可視化されたstyleで，当日の大まかな予定を話し合う
- resourceのproblemに気づけるようにする場でもある
- 良い流れでsprintを進める
まとめ
- さまざまな詳細度でのplanningが，Scrumの開発中にどのように発生するのかを見た
- Scrumの階層的なplanningの図

Ch16 portfolio_planning

複数のproductを作るにあたって，product_portfolioをどのように管理するか，継続的に理にかなった選択をする必要がある
portfolioの管理processを，Agile practiceとうまく協調させる必要もある
概要
- portfolio_planning: portfolio_backlogのitemから，どれをどの順番にどの程度の期間で進めていくか決める作業
  - item: product, そのincrement(1回分のrelease), or project
- 素早く柔軟な流れを壊さないように実施する
- timing
  - product_planningのdataを使って，どのproductにどの順に投資するのかを判断し，portfolio_backlogにまとめる
  - 新たなproductに対してだけでなく，既存(仕掛け中)のproductについても見直す
- 参加者
  - 内部のstakeholder
    - business的な大局観が必要
      - portfolio_backlog itemの優先順位の決定や，仕掛け中のproductに対する判断のため
  - 各productのproduct_owner
    - 必要なresourceを主張
  - option: senior architect, technical leader
    - 技術的な制約を考慮
- process
  - output: portfolio_backlog, active product群
  - outputのために，4種類のactivityがある（→ 以下に続く）
schedulingの戦略
- 組織内のproductに割ける限りあるresourceを，経済的に理にかなった方式で配分するために，product群を優先順位づけ
- lifecycle 収益で最適化
  - 最適化が効いているかどうかをどの変動要因で判断するか決定する必要
  - → lifecycle 収益を使ってあらゆる判断やtradeoffを見る
    - 標準化されていて使いやすい経済的枠組み
  - lifecycle 収益の総量が最大となるように，portfolio_backlog内のproductを並べ替える
  - goal: portfolio_backlog itemを並べ替えて，portfolio全体のlifecycle 収益を最大化すること
  - 最も影響する重要な2つの変動要因
    - delay_cost
    - 存続期間(作業量やproductの規模の代替)
    - → いずれも各productで異なる場合は，重み付きで一番短いjobを優先する(WSJF)
      - delay_costを存続期間(or 実装の作業量)で割ったもの
- delay_costを算出する
  - 経済的な意思決定をするにあたって欠かせない情報
  - ほとんどの変動要因が時間の影響を受けるという事実
    - → 時間軸を必ず考慮してportfolio_backlog内のitemを並べ替える
  - 算出方法: spread sheetを2つ作り，遅延がない場合と遅延がある場合の2種類の収益をそれぞれ計算すればよい
  - model
    - user的な価値
    - 時間的な価値
    - riskの削減/機会の確保
    - 以上の3つの属性について，delay_costを1から10までの数字で設定し，合計したものがproductのdelay_costになる
  - または，よくありがちな特徴でdelay_costを分類する
    - 線形, 巨大なcost, すぐにでもやるべき, 固定期日, 対数, 実体がない
- 見積もるのは正確性であって精度ではない
  - portfolio_backlogのitemを適切にschedulingするために，各productの作業量/costを理解する必要
  - 最初の見積もりが必要になる時点では手持ちのdataはたかが知れているので，精度より正確性に注目する
  - Tシャツのサイズなどでcostの範囲を関連付け
  - → すばやく見積もれる，十分な正確さを得られる，portfolio levelで次の動きを決めるための情報を用意できる
  - → 無駄な時間を削減，見積もりの数字を過大評価したり誤った安心感を与えることもなくなる
inflowの戦略
- product developmentを始めるかどうかの判断において，組織の経済的filterを以下に適用するのかを見る
- 経済的filterの適用
  - envisioningのoutputは，product visionに加えて，信頼の閾値を明確にするための情報となる
  - → このdataをもとに，product developmentを進めるか中止するか判断
  - ↑ このactivityが新しいproductへの「経済的filterの適用」
    - 組織の資金需要を満たすかどうかを確かめるactivity
  - 組織ごとに経済的filterを定義
    - よいfilterはコストをはるかに上回る価値を生み出せる機会をすばやく承認できる
    - それ以外の機会は，やむを得ない事情がある場合を除いて却下すべき
      - costや価値に合意が取れず決断ができないなら，十分な資金援助が得られないことは明白
      - ほとんどの組織ではよい機会がありあまっている
- 追加と取り出しのbalanceを取る
  - 年に1度で達成内容の詳細をproduct levelまで全部決めてしまう必要はない
  - productをportfolio_backlogに追加する頻度を高くする（月に1度か少なくとも四半期に1度）
    - → 新しいproductのreviewやportfolioへの追加にかかるcostや労力を大きく軽減できる
    - → portfolio_planningの全体的な安定性や予測可能性を高められる
  - productを小さめにすることにも力を入れる
    - 頻繁に取り出せるようにしておく
    - → inflow, outflowのbalance〇
  - portfolio_backlogの肥大化 → portfolio_backlogに追加するproductの流れを絞る
    - 経済的filterを調整して，productを承認する条件を厳しくする
    - → より価値の見込めるproductだけを承認
- 創発的なchanceへの素早い対応
  - 創発的なchance: 事前に想定できなかった出来事や，まず起こりえないと思われていたこと
    - 経済的valueは急降下していく
  - 機会についての評価を月に1度などのpaceで頻繁に行っていて，適切な経済的filterを設定しており，releaseの規模を小さくしてWIPを増やさないようにしていれば，対応できる
- 小さめなreleaseを頻繫に行うための計画
  - 明白なmeritのほかに，コンボイ効果を回避できる
    - 大きなproductが共有resourceを占有することを回避
  - 徐々にreleaseしていった方が経済的なmeritが大きい
  - 一括releaseをできるだけ避けるようにplanning
outflowの戦略
- 作業者の手待ちではなく作業の手待ちに注目
  - productをportfolio_backlogからいつ取り出すのか判断するカギとなる戦略
- WIPを制限する
  - 自分たちが完了させられるだけの量に達したら，それ以上のproductをportfolio_backlogから取り出さない
  - 制限の程度
    - Scrum_teamがいくつあるか，それぞれのteamがどのtypeのproductの作業ができるかで判断
- team全員の準備が整うのを待つ
仕掛け品の戦略
- 現在作業中のproductについて，開発を続行するかpivotするか停止するかを判断する助けとなる
- 定期的に判断
- 臨時にも判断する
- 限界費用を使う
  - これまでにいくら使ったのかは一切無視して判断する
  - 判断のflow
    - 資金の追加投入に値するか → 維持
    - 必要最小限の機能が実装されているか → delivery
    - 別の未知はあるか → pivot
    - → 打ち切り
まとめ
- portfolio_planningに関する11の重要な戦略
  - すべて互いに補強し合う
  - 各categoryで1つずつのみの場合
    - delay_cost
    - 小さめのreleaseを頻繁に
    - WIPを制限
    - 限界費用

Ch17 envisioning(product_planning)

product_backlogを最初に作るときに，productについてのvisionのための事前の作成物を用意するactivity
概要
- goal: ideaを詳しく説明し，できあがるであろうproductの本質を示し，実際に作るための大まかなplanを用意
  - ideaをportfolio_planningに組み込めるだけの十分な自信が必要
- productの資金調達にまず不可欠なのは，visionを持つ
- client, feature, 概要levelのsolutionについて理解するために必要な程度に情報を把握する
- productにかかるであろうcostの見当をつける
- 短時間で実施する
- timing
  - 何度も繰り返す
  - きっかけは誰かからのidea
    - 組織の戦略的filterを通し，組織の戦略方針に一致しているか調べ，さらなる調査と資金投入の価値があるか判断
    - 通過したら，最初のenvisioning
      - これから作ることになるproductに関する十分な理解を得て，最初の最低限のreleaseがどんなものであるべきか定義
      - → 最大限の価値をすばやく提供，costを抑えられる，すぐに役立つfeedbackを得られる
      - feedbackで間違いを判断したら，pivotしenvisioningをやり直して計画を見直す
- 参加者
  - 最初のenvisioningに必ず参加が必要なのはproduct_ownerのみ
  - 内部のstakeholderも巻き込むことが多い
  - specialist(market分析，投資対効果の拡大，UX design，system architectureなど様々な分野)もかかわることが多い
  - Scrum_teamが割り当てられてからは，Scrum_master, development_teamも含めてteam全体で参加すべき
- process
  - input
    - 最初: 戦略的filterを通過したidea
    - 2回目から: pivotしたidea
      - userやclientからのfeedback, 財源の状況の変化，競合の予期せぬ動き，その他重要な変更から，ideaを更新，修正する
    - planningの範囲
    - いつまでにenvisioningを完了させるか
    - 割けるresourceの量や種類
    - 信頼の閾値
      - envisioningの完成の定義
      - より詳細な開発に向けた出資をするべきか否かを意思決定者が決断する際に，十分な確信をもって結果を出せるようにするために必要な情報をまとめたもの
SR4Uの例
- 最初の開発に進むべきか否かの判断材料
  - 最初のproduct vision, product_backlog, product_loadmap
  - userについての最初の前提の検証
  - userについてのそのほかの重要な前提・仮説や，最初のreleaseでテストしようとしているfeature群に関する説明
  - その他の全体を確かめたり，最初のreleaseが期待通りか判断したりするために使う，計測可能な基準
  - 対応すべき疑問点のlist
visionづくり
- 説得力のあるvisionを作って共有
- 説明しやすいsimpleなもの
  - 明快な指針を示せる
- stakeholderがいかにして価値を得るのかという観点で語られることが多い
  - category
    - 参入条件
    - 使用可能性
    - 差別化要因/clientを喜ばせる
    - 妨害/ハードルを上げる
    - cost削減/時間の節約
- formatの例 → 一番うまくあてはまるものを選ぶ
  - elevator statement
  - product data sheet
  - product vision box
  - conferenceのslide
  - press release
  - 雑誌のreview
概要levelのproduct_backlogの作成
- visionの完成: 概要levelのproduct_backlog_itemを上げる準備が整う
- user_storyでのepicをenvisioningで作る
  - product levelのplanningに対応した大規模なuser_story
  - epic levelのstoryとvisionを組み合わせて，もう少し詳細なlevelでproductを表現し，幹部経営者やScrum_teamに渡す
- visionを作ったのと同じ人たちが，storyも書く
product_loadmapの定義
- visionと概要levelのproduct_backlogが完成したら，最初のproduct_loadmapの作成に進める
- product_loadmap: 一連のreleaseでproduct visionのどの部分を達成していくか示す
- incremental deploymentについて，当初の概要を示す
  - 1回のreleaseの規模を小さくして，releaseをより頻繁に行う
  - 小さめのrelease 1度で済んでしまうような計画なら不要
  - 頻繁なrelease: 個々のreleaseをrelease可能な最小限のfeature(MRF)単位にまとめる
    - MRF, a.c.a. 実用最小限の製品(MVP), 市場性のある最小限のfeature(MMF)
  - MRFの補完として，定期的なrelease(四半期ごとなど)を採用するのも〇
    - product_loadmapがsimple
    - わかりやすい
    - 内外を含めた関係者全員へreleaseの周知がしやすい
    - 組織のreleaseを事前の予測通りに活用できる
    - ほかのgroupもその組織の計画に合わせて動きやすくなる
    - MRFの開発がrelease間隔より短く済む場合は，さらに追加で価値の高いfeatureを作る
- release goalの明示
  - releaseの目的と期待される成果を示す
  - solutionのreleaseの内容を決める助けとなるあらゆる要素を考慮
    - target client
      - 各segmentのclientに対していつどのように対応するか示す
    - 概要levelのarchitectureや技術面の課題
    - 市場の重要eventなど
  - 大雑把な予想に過ぎない
    - 詳細な情報が分かり次第loadmapを更新する
- どの程度の将来までカバーするか
  - 大規模なvisionでも，理にかなった必要な分だけのloadmapを作る
  - 誰かに出資をお願いする期間はカバー必要
その他のactivity
- 信頼の閾値を満たすために関係があると参加者が認めた作業なら，どんな作業を含めてもよい
  - e.g. 市場調査，競合productとの比較分析，大雑把なbusiness modelを作成して経済的filterと照合
- envisioningを複数のsprintに分けて行うときには，担当teamがenvisioning関連の作業のbacklogを管理する
  - 優先順位を決めて，短期間(1週間程度)のsprintを回す
  - 知識を得るためのsprintもある
経済的に理にかなったenvisioning
- envisioning系の作業は，project charteringやproject inception, or project initiationと呼ぶこともある
  - このprocessを，総合的なstage gate型管理modelの一部として組み込んでいる組織もある
    - 重厚で儀式的なprocessになってはいけない
- できるだけsimple
  - productの性質や規模，risk levelに基づいて，必要最小限の事前planning，そして知識獲得のための作業を行うのみ
  - 詳細な作成物はjust_in_time
  - goal: 現時点での最良な判断をするのに十分なだけの情報を，資金や期間を考慮して得ること
- 指針
  - 現実的な信頼の閾値を目指す
    - 信頼の閾値: envisioningを終えてproductをportfolio_planningに送るために，最後にクリアすべきハードル
      - ハードルを上げるほど，クリアするために長い時間を要する
        
        → delay_cost → クリアのためのcost up
      - WIPの無駄は避ける
    - → やり過ぎず，役立つlevelの閾値の設定が必要
      - 分かれ目は，組織やproductの特性で決まる
    - 一連の開発作業の明確なgoalと，結果を見て次の作業に進むかどうか判断するときの基準が知りたい
  - 注目するのは短期間だけ
    - 1度にやり過ぎず，主に，直近のreleaseで必須となるfeatureに注目する
  - すばやく動く
    - envisioningは手早く効率的に済ませる
      - → できあがるのが早まり，検証できる
      - → delay_costを小さくできる
    - 緊迫感をもってproductについての判断を下せるようになる
      - 適切なresourceを割り当てて，envisioningを適切なtimingで終えられるようにする助けとなる
    - 方法
      - envisioningの完了予定日をenvisioning teamに知らせておく
  - 検証による学びに投資する
    - envisioningのactivityを経済面で評価するときの基準
      - 対象とするclient, feature, and solutionについての検証による学びを得るためにどの程度役立ったのか
  - incrementalに出資する
    - 出資にかんする判断は，より正確な情報がそろうのに合わせて常に行う
    - envisioningに要する時間も短縮できる
  - 早めに学んでpivotする(fail_first)
    - 責任をもって効率的にresourceを管理し，手早く格安にenvisioningを行う
    - 資金負担を大きく減らすことができる
まとめ
- envisioningについて
- 具体例で，product visionや概要levelのproduct_backlog, product_loadmapを作る流れを見た
- envisioningの際の知識獲得sprintを実行する方法
  - envisioningを終えるための信頼の閾値を満たすために有用
- 経済的に合理的なenvisioningを行うための指針
  - 事前のproduct_planningとそれに続くScrumのclient value createとをうまく合わせられるようになる

Ch18 release_planning(長期計画)

release_planningでは，scope, schedule, budgetといった制約の下で，clientにもたらす価値と全体的な品質とのbalanceを取らなければならない
release_planningをどのようにScrum frameworkに組み込むのか，固定期日と固定scopeのそれぞれのreleaseで，release_planningをどのように行うか見る
概要
- featureをclientに届けるためのreleaseの周期を適切に定める必要
- continuous deployment(delivery): sprintの終わりを待たず1つのfeatureが完成するたびにrelease
- どの周期でも，ある程度の長期間にわたる概要levelの計画(release_planning)を作っておくと便利
- a.c.a. 長期的planning, milestone駆動planning
- 狙い: 重要な変動要因（期日，scope，予算など）のbalanceを取ったうえで，将来の状態を定める
- timing
  - sprintごと
  - envisioningやproduct_planningのあと
  - product_planningの目的: productがどうあるべきか思い描く
  - ←→ release_planningの目的: そのproductのgoalに向けて，次の一歩を定める
  - 初回releaseの前に最初のrelease_planningを行い，release planを作成する
    - 通常は1日から2日程度だが，productの規模やreleaseのrisk，参加者のproductへのなじみによって変わる
    - 完全でなくてよい
    - 検証による学びをもとに更新する
      - sprint review中でも次のsprintの準備のときでもよい
- 参加者
  - stakeholderとScrum_team全体が，互いに協力し合って行う
  - businessと技術のtradeoffを考慮して，もたらす価値と品質の間で最適なbalanceが必要なため
- process
  - input
    - product_planningのoutput: product visionや概要levelのproduct_backlog, product_loadmap
    - releaseにかかわるであろうteamのvelocity
  - 繰り返すactivity
    - releaseの制約であるscope, 期日, budgetを確認し，これまでの流れやわかってきたことから，制約を変更する必要があるかどうか見直す
  - product_backlogのgrooming
    - 概要levelのproduct_backlogをもとに，より詳細なproduct_backlog_itemを作ったり，見積もったり，優先順位をつけたりする作業
    - timing
      - product_planningを終えてから，最初のrelease_planningに入る前
      - 最初のrelease_planningの一環として
      - 各sprint中で，必要に応じて
  - envisioningで定義された明確に定義されたrelease可能な最小限のfeature(MRF)を，常に見直す
    - client視点で，実現最小限の製品になっていることを確かめる
  - sprint mapを作ることも多い
    - 各product_backlog_itemがどのsprintで作られるか示す
    - 直近の範囲の可視化
    - → team内の依存関係やresource配分を管理しやすくなる．複数のteamでの共同作業の調整にも役立つ
  - release_planningのoutputをひとまとめにしてrelease planと呼ぶ
    - どの時点までに判断できる妥当なlevelの正確さでの計画を表す
      - 開発作業がどれくらい残っているか，いつごろ終わるか，どのfeatureができあがるか，costがどの程度かかわるかなどを含む
    - そのreleaseで求められるMRFを明確化
    - releaseのための各sprintで対象となるproduct_backlog_itemをどのように扱うのか示すことも多い
release制約
- release_planningの目的: 次のreleaseで最も重要なものが何なのか，そしてそれをどの程度の品質で用意するのかを定める
- scope, 期日, 予算といった制約は重要な変動要因であり，どうやって目標を達成するかに大きく影響する
- product_planningにもとづいて，いくつかの制約が生じる
- 各制約の固定/可変の組み合わせ
  - すべて固定
    - 現実的でない
  - scopeと期日を固定
    - 多くの問題があり，厳しすぎる
    - 固定したものはいずれもかなり予測しづらい
      - いずれかは犠牲になる
    - resourceを投入すればするほど多くの作業をこなせ，作業の所要時間も短縮できるという想定だが，現実的でない
    - 実現できないか，持続可能なpaceに反するか
    - Scrumのiterative and incrementalなapproachを使うことで，何か問題が発生しても早めに気づけるようになる
  - scopeを固定
    - 実際問題として，scopeのほうが期日より重要な場合
    - 全体的なscopeがあまりにも大きすぎる場合
    - より小さ目なreleaseに分割して，それぞれを期日で固定した方がよい
  - 期日を固定
    - Scrumの原則に最もあてはまる
      - timeboxingを重視するScrumにぴったり
    - 優先度の高いfeatureから作るという原則に従うことで痛みを軽減できる
    - 優先度の高いfeatureが本当に（合意済みの完成の定義にもとづいて）完成している場合だけ
    - MRFを小さめに定義できるとき
  - 品質を可変に
    - 制約が厳しすぎる場合
    - 期待に添わないsolution, 技術的負債の発生
  - 制約の見直し
    - 現時点でわかっていることから，制約のbalanceを見直すべきかどうか見極めることが，release_planningにおいて重要
    - 継続的に判断する
product_backlogのgrooming
- 概要levelのproduct_backlog_itemを，user_story 記述workshopなどで，より詳細なlevelに踏み込んだproduct_backlog_itemにする
- → teamで見積もって，どの程度costがかかるかを判断できるようになる
- → releaseのgoalと制約に基づいて，各storyの優先順位を判断
  - MRFがrelease_planningの参加者間で常に合意の取れた状態である必要
release可能な最小限のfeature(MRF，Minimum Releasable Feature)の見直し
- MRF: clientが期待する価値や品質をもたらすために，今回releaseに必ず含める必要があるfeature
- release_planningの中でも重要なのは，真のMRFが何なのか再評価して見直すこと
- 責任: product_owner
- 各featureのsizeを知る必要
  - size: product_backlog groomingで判断
  - あらゆる判断は経済面の常識的な範囲内で行うため，各featureのcostを知っておけば，MRFの実現可能性をchackできる
    - 不可能ならpivotを考える
sprint_mapping
- 直近のsprintについて，product_backlog_itemを事前にmappingしてみるのが有用
  - 複数のteamで作業を進めている環境で，協調が上手くいくようになる
    - 移動する先読み範囲: 直近のsprintと少なくともその後数sprintで必要なproduct_backlog_itemを検討する
    - team間の依存関係が扱いやすくなる
- ある程度詳細なlevelまで落とし込み，見積もりが終わって，優先順位のついたproduct_backlogが必要
  - teamのvelocityを使って，product_backlog_itemをsprint単位に適切に割り当てられる
- 一般的なschedule表にsprint_mapを並べることもある
- 単一のScrum_teamのdevelopmentでは，mappingは最初のrelease_planningで行う
- そのsprintで各teamがどのfeatureを担当するかを最終的に決断するのは，最終責任時点，sprint_planningのとき
- product_backlog_itemとsprintのmappingをほとんど/全くしないこともある
固定期日のrelease_planning
- release_planningの手順
  - このreleaseでsprintを何回実行するか決める
  - product_backlogを適切な詳細度までgroomingする(backlog itemを細かくしたり，sizeを見積もったり，優先順位を決めたりする)
    - MRFを構成するfeatureは，与えられた時間の60~70%で完成できるようにしたい
  - teamのvelocityの範囲を計測する
  - 最も遅い場合のvelocityとsprintの数を掛ける．product_backlogの先頭からその結果分だけのitemを数え，そこに線を引く
  - 最も早い場合のvelocityとsprintの数を掛ける．product_backlogの先頭からその結果分だけのitemを数え，そこに2番目の線を引く
    - release日までにどのfeatureができあがるかという問いの答えがある程度分かる
    - release_planどおりに進んでいるか判断するためには，必須featureを表す線をproduct_backlogの上に重ねてみるだけでよい
- sprintが終わるごとにrelease_planを見直す
固定scopeのrelease_planning
- 実際には期日よりもscopeの方がずっと重要という場合
- 本当の意味でのMRFを厳選し，徐々に増やしていくようにする
- → 固定scopeのreleaseもいくつかの固定期日のreleaseに分割できる
- どうしても期日が最大の制約の場合の流れ
  - 少なくとも今回releaseしようとしているproduct_backlog_itemを含むよう，product_backlogをgrooming(新たなitemを作ったり，sizeを見積もったり，優先順位を決めたりする)
  - このreleaseでdeliveryするproduct_backlog_itemの合計サイズを決定する
  - team velocityの範囲を計測する
  - product_backlog_itemの合計サイズを最も早い場合のvelocityで割り，端数を切り上げる
  - product_backlog_itemの合計サイズを最も遅い場合のvelocityで割り，端数を切り上げる
costの算出
- 手順
  - team_memberを決める
  - sprintの長さを決める
  - team 構成とsprintの長さに基づいて，sprintあたりの人件費を算出する
  - 固定期日のreleaseの場合は，sprintあたりのcostとsprint数を掛ける
  - 固定scopeのreleaseの場合は，sprintあたりのcostと最大sprint数，最小sprint数をそれぞれ掛ける
- story_pointあたりのcostを把握しておけば，story_pointさえ求められればcostが分かるという別の方法がとれる
communication
- 固定scopeのreleaseにおける進捗の把握
  - 完了させない作業のscopeが分かっている
  - その作業の完了に向けて，今どの程度の進捗なのかを把握することが目標
  - burn_down_chart: 現在のrelease goalに達するまでの残作業の累計を，sprint単位で示したもの
    - y: 残story_pointの見積もり, x: release内のsprint
  - burn_up_chart: releaseにおける作業の総量をgoalとして示し，sprint単位でそのgoalに近づいていく様子を示した図
    - 軸はburn_down_chartと同じ
    - 好まれる理由: release内でのscopeの変更を表しやすいから
- 固定期日のreleaseにおける進捗の把握
  - releaseにおけるsprintの回数が分かっている
  - sprintごとの進捗を見ながら，最終的にどの程度のfeatureを完了させられそうなのか(deliveryできるscopeの範囲)を把握する
  - product_backlogの並び順を反転して，burn_up_chartを作成する
    - 目標とするfeatureの範囲に到達するまでの進捗の把握
    - - 必須featureの完成までの進捗も確認できる
まとめ
- release_planningについて
  - いつ，だれが，どんなことをするのか，最終的にどんなrelease_planができあがるのか
  - 固定期日/scopeそれぞれの場合でのrelease_planningの方法と，進捗を把握する方法について

Part 4 sprint

Ch19 sprint_planning

releaseは1つ以上のsprintで構成
- 各sprintでは，user/clientに価値を提供する
sprintはsprint_planningから始まる
- Scrum_teamが集まって，sprint_goalに合意し，sprintで何をdeliveryできるかを決定
Scrum frameworkにおけるsprint_planningの位置づけと実施方法について
概要
- sprintで構築する最も重要なproduct_backlog_itemを決定するために実施する
- sprint_goalについて合意する
- sprint_goalに合致しており，sprint終了までに現実的にdeliveryできるproduct_backlog_itemを決定する
- 決定したitemをきちんとdeliveryできる自信を持つために，product_backlog_itemを完成させるための計画が必要
  - 選択したproduct_backlog_itemと計画を合わせたものが，sprint_backlogになる
- timing
  - 継続的なjust_in_time activity
  - sprint開始時に実施する
  - 2週間から1か月のsprintの場合，sprint_planningに4~8時間かける
- 参加者
  - Scrum_team全員
  - product_owner: 最初のsprint_goalを共有して，product_backlogの優先順位を示し，product_backlog_itemに対するteamの疑問に答える
  - development_team: sprintで何をdeliveryできるか決定し，現実的なcommitment
  - Scrum_master: Scrum_teamのcoachとしてplanning activityを観察し，内省を促す質問をして，確実に良い成果が得られるよう支援する
    - 何を作るか代わりに決められはしない
    - teamのcommitmentに問題を提起して，現実的で適切なcommitmentができるようにする
- process
  - input
    - product_backlog
      - 最も重要
      - 準備完了の定義に合うように，sprint_planningよりも前にgrooming
        
        準備完了の定義: 受け入れ条件が定義済みで，適切なsizeで，見積もりが終わっていて，優先順位がつけられている
    - team velocity
      - 現実的な判断のため（以下2つも同じ）
    - 制約
    - team capacity
    - initial sprint_goal
      - development_teamのcommitmentが現実的なものになるため
      - teamは優先順位のbalanceが取れる
  - sprint_goalを達成するための計画を作る
    - sprint_backlog
      - product_backlog_itemを見積もり可能なtaskに分解
        
        1つのtaskは8時間以内
  - sprint_planningが終わると，development_teamのcommitmentが最終的なsprint_goal, sprint_backlogとなって伝えられる
sprint_planningの手法
- 二部構成のsprint_planning
  - what part
    - development_team capacityを決定し，sprint終了時にdeliveryできるproduct_backlog_itemを予想する
  - how part
    - product_backlog_itemをtaskに分解して，task完了に必要な工数を見積もり，計画を立てる
    - 見積もったtaskの時間とcapacityを比較して，最初のcommitmentが現実的かどうか確認
    - 予想がcapacityの範囲や制約に収まれば，commitmentを最終決定して，sprint_planningを終了する
- 一部構成のsprint_planning
  - itemの選択とそのための自信の獲得を交互に行う
  - まず，development_teamがcapacityを決定する
  - 次に, product_backlog_itemを選択して，それがsprintに収まるという自信を持つ
  - これをteamのcapacityの上限に達するまで続ける
  - 最後にcommitmentを最終決定して，sprint_planningを終了する
capacityの決定
- sprint_planningの最初の重要なactivity
- what's capacity
  - 影響を与える要因
    - sprint以外のactivityに必要な時間
    - sprint以外のcommitment
    - 個人的な休暇
    - 必要なbuffer
      - 経験的に決定
  - capacity
    - 単位
      - product_backlog_itemに使う単位(story_point or 理想日)
        
        team velocity
        
        teamのこれまでの平均velocityや前回のsprintのvelocityを参考にする
        
        そして今回のsprintとの違いを考慮する
        
        → 予測したvelocity
      - or sprint_backlog_taskに使う単位(作業時間)
        
        まず，team_memberが次のsprintで何日作業できるかを表明する
        
        次に，sprint以外のactivityにかかる日数を決定
        
        team_memberの1日の作業時間を決定
product_backlog_itemの選択
- sprint_goalがあれば，それに合わせてproduct_backlog_itemを選択する
- なければ，product_backlogの優先順位の高いほうから順番にitemを選択する
- skillの問題などでitemにcommitできないときは，優先順位がその次に高くて実現できそうなproduct_backlog_itemを選択する
- 完成できそうにない場合は，clientにとって価値のある小さなitemに分割するか，完成できそうな別のitemに着手する
  - 準備完了の定義を用意しておくことで，定義・resourceが不十分だったり，依存関係が未解決のproduct_backlog_itemを選択して，sprintで完成できなくなることを回避できる
- 「完成できそうなものだけを開始する」
  - WIPの制限や未完成作業のムダの原則に基づく
    - 出荷判断可能なproduct incrementがsprint終了時に必要
自信の獲得
- velocityを予測
  - commitmentが現実的かどうか確認
  - ただし，実際はtask levelにするまで分からない
- → さらに，product_backlog_itemをtaskに分解することで自信を獲得する
  - taskは見積もり可能で，team capacityを考慮して決定
    - 一種の設計で，itemを完成させるためのjust_in_timeの計画
  - 分解した結果がsprint_backlog
  - それぞれのskillを把握しておかないと，正しいcommitmentができない
    - ただし，個人へのtask assignは×
sprint_goalの洗練
- sprint_goal: sprintでのbusinessの目的と価値をまとめたもの
commitmentの最終決定
- sprint_planningが終了するまでに，development_teamはsprintでdeliveryするbusiness valueにcommit
- sprint_goalと選択したproduct_backlog_itemは，commitmentを具現化したもの
- 予想/commitment
  - ニュアンスの違いは，development_teamが何をdeliveryするかのscopeと，Scrum_teamがsprintの実施中に手に入れた新しい情報への対応に影響する程度
まとめ
- sprint_planningをいつ実施するか，誰が参加するか
- 2つの手法
  - teamがproduct_backlog_itemを選択して，それらをすべてdeliveryできるという自信を獲得
  - product_backlog_itemの選択と自信の獲得を交互に行い，少しずつcommitmentに追加する
- development_team capacityを決定するための2手法

Ch20 sprintの実施

Scrum_teamがsprint_goalを達成するための作業
sprintの実施において，Scrum_teamが計画，管理，実行，伝達するためのprinciple, technique
概要
- sprintの実施は，それ自体が1つのmini projectのようなもの
  - 出荷判断可能なproduct incrementをdeliveryするために必要な作業をすべて行う
- timing
  - sprint_planningが終わった後に始めて，終了したらsprint review
  - 8割程度はsprintの実施が占める
- 参加者
  - development_teamのmemberが自己組織化して，sprint_planningで設定したgoalを達成する最善の方法を決定
  - Scrum_masterは，あらゆる支援
  - product_ownerは，質問に答えたり，feedback, sprint_goalを調整，product_backlog_itemが満たすべき受け入れ条件を検証
- process
  - input
    - sprint_planningで作ったsprint_goalとsprint_backlog
  - output
    - 出荷判断可能なproduct_increment
      - 開発が終わったproduct_backlog_itemの集まり
        
        Scrum_teamの完成の定義に従う
  - 実施
    - testされた動作する機能に必要な計画，管理，実行，伝達
sprint_planning
- 万全な計画にはしない
- taskに依存関係があるときは，事前の計画が有用なこともある
- sprintの実施の原則: 事前に完璧な作業計画を立てるのではなく，状況に応じてtask levelの計画を立てる
  - teamで継続的にtask planningをすることで，sprintを取り巻く環境の変化に適応できる
flow management
- teamの責任
- どれだけの作業を並行でやるべきか，特定のitemにいつ着手すればよいか，task levelの作業をどのように構成するか，何の作業をすべきか，誰が作業すべきか，を決める
- 並列作業とswarming(群がる)
  - 単純なmulti taskでもoverheadは極めて高い
  - 並列作業が少なすぎてもムダ
  - swarming
    - 適切なbalanceのために，team_memberのT型skillやcapacityを活用できるだけのitem数に絞って作業する
      - deliveryするvalueを最大化しながらも，各itemの作業時間を短縮
    - 新しいitemに着手する前にcapacityあるteam_memberが集まって，すでに誰かが着手したitemを完成させる
    - taskではなくgoalに集中し，より多くより早く作業が終わる
    - 同時に作業するitemの数を極力減らすべき
      - 複数のitemが適切な場合もあるので，必ずしも1つではない
  - mini waterfallのようになるのは×
    - 同時にすべてのproduct_backlog_itemに着手することになるため
    - → riskが非常に高い
- どの作業から着手すべきか
  - itemの優先順位をproduct_ownerが決定
    - 技術的な依存関係やskill capacityの制約がitemの順番に影響を及ぼすため，常には上手くいかない
    - → development_teamは，itemを適時適切な順番で選択する能力が必要
- どのようにtaskを計画すべきか
  - 作業に論理的な順番はない
  - test first development
  - 適時team_memberがtaskや担当をうまく構成する
    - → 作業の手待ちを最小化し，team_memberがほかのmemberに手渡す作業の量や回数を減らせる
    - → すばやいfeedback, 課題の発見と解決が迅速に実施できる
- どの作業を完了させるべきか
  - team_memberが決定
    - 経済的に合理的な方法でinnovative solutionを作るための権限を与える必要
  - product_owner, managerは，どのtaskを完了させるべきかに影響を与えるinputを持っている
    - product_ownerが機能のscopeと受け入れ条件を確定する．いずれもtask levelの作業の境界線となる
    - 完成の定義に必要なbusiness 要件を提供する
    - product_ownerは，businessに重大な結果をもたらす技術的判断が経済的合理性をもって行われるように考慮しながら，teamと一緒に作業する
  - 決定の中には，完成の定義の技術的な側面に組み込まれているものもある
  - そのほかの決定は，機能に特化したもの
    - development_teamはproduct_ownerと一緒にtradeoffを行い，経済的に合理的な決定をすることが望まれる
- 誰が作業をするのか
  - 作業をすばやく正しくできる人が最適
  - 様々な要因が影響する
  - team_memberの共同責任
  - T型skillで，より効率的なteamになる
daily_Scrum
- team activityを高速にして，solutionまでの流れを柔軟にする，毎日の検査と適応のactivity
- 24時間ごとに15分のtimebox
- 自己組織化teamが仕事をより良くするために，検査とsyncを行う適応型planning activity
- goal: sprint_goalの達成に集中している人たちが集まって，何が起きているかの全体像を共有し，どれだけの作業をしているか，どのitemに着手したか，team_memberの最適な作業配分についてみんなで理解すること
- 待ち時間の回避にもなる
- flowの管理に欠かせない存在
taskの実行(technical_practice)
- 短期間のtimeboxというiterationで作業する → 出荷判断可能なproduct incrementを届けることを期待されている
  - 技術的負債を制御して仕事をやりきるというpressureがteamにかかる
  - → 適切な技術的skillを持っていなければ，長期にわたって継続的にbusiness valueを届けるために必要なagilityのlevelを達成できない可能性がある
- Scrumを使う場合は，software developmentのtechnical_practice_skillが必要になる
  - TDD, refactoring, simple design, pair programming, CI, codeの共同所有, coding standard, metaphor
    - called as XP
- 長期的なScrumの利点のためには，task levelの作業に，強力なtechnical_practiceが必要
communication
- information radiator(radiate: 放射 ← 光を放つ)
  - task_board, burn_up_chart, burn_down_chartの組み合わせ
- task_board
  - sprintの進捗が一目で伝わる簡単だが強力な手法
  - sprint_backlogの変化の状態を伝える (→ 図20.6)
  - sprint_backlog_itemが複数のtaskで表現
    - すべてのtaskはTO DOから
    - → 進行中
    - → 完了
  - カンバンではより詳細なboard
- sprint burn_down_chart
  - product_backlog_itemのtaskは，いつでもsprint_backlogに追加できる
  - y: 見積り残作業時間, x: sprint日数
  - 進捗管理に使える
  - 傾向線を書くことで，sprintのflowを管理するための知識となる重要なdataを得られる
  - 常に残りの見積もり時間を使用する．実際にかかった作業時間は不要．
- sprint burn_up_chart
  - sprintの進捗を可視化
    - 完了した作業の量を表す
  - y: story_point, or 作業時間, x: sprint日数
    - ほとんどはstory_point
      - ↑ business valueのための成果に注目するため
      - 作業の流れが滞っていないか，teamがどのようにproduct_backlog_itemを完成させているかの感覚がつかめる
まとめ
- sprintの実施について
  - sprintの大部分を占めるもの
  - who, what, whenの計画に従うものではない
  - teamのskillを活用して，完了した作業やsprintの予期せぬ環境の変化からfeedbackを受け取る
  - flow management principleに従う
    - 並行していくつの作業をするか，何の作業に着手するか，作業をどのように構成するか，誰が作業をするか，作業にどの程度の時間をかけるか，を決める
  - daily_Scrum meetingはflow managementのimportant activity
  - technical_practice's importance for high level agility
  - sprintの進捗を視覚的に伝える
    - task_board, sprint burn_down_chart, sprint burn_up_chart

Ch21 sprint_review

productに集中したもの
目的，参加者，事前準備，問題について
概要
- 作業結果(出荷判断可能なproduct_increment)の検査と適応をする．
- sprint終了間際に実施する
- product developmentのinputにかかわった人に対して，これまでに構築したものについて検査と適応をする機会を提供する
  - 質問，観察，提案したり，現状を考慮して今後の方針について議論する
- 正しいproductを開発中だと組織が確信できるようになる
  - → 最も重要な学習loopの1つ
    - sprintの期間は短いので高速
    - → 頻繁に軌道修正〇
参加者
- sprint_reviewは，Scrum_teamに対して，sprintの実施に毎日参加できないような人たちからのfeedbackを得る重要な機会を提供
- sprintで作成された成果について議論する最初の機会
  - すべての利害関係者が参加すべき
    - Scrum_team
    - 内部stakeholder
      - business area owner(developing systemの発注者), exective management, resource担当managerなど
      - → teamが経済的に合理性のある成果に向かっているか確認
      - 内部userがいる場合は内部userからのfeedbackも有益
    - そのほかの内部stakeholder
      - 営業，marketingから，productが市場で成功するかどうかの有益なfeedbackを得る
      - support, 法務部は，teamの進捗の把握や，timelyなinputを提供したり，自分たちの仕事をいつ開始すればよいか判断するために，参加することもある
      - ほかのdevelopment_teamの代表者も〇
    - 外部stakeholder
      - client, user
        
        direct feedback
      - 内部の議論で済むなら，必要はないかもしれない
      - 常識，熱意，人格を考慮して招待する対象を検討
事前準備
- 誰を招待するのか決める
  - 適切な人たちを集める
- schedule調整
  - Scrum_team以外の参加者が多いので，調整が難しい
  - important stakeholderが希望するscheduleを聞いてから，そのほかのactivityをその時間の前後に設定する
    - sprintの期間は固定されているので，ほぼすべてのsprint_reviewのscheduleが決まる
  - 長さ
    - sprintの期間，teamの規模，reviewに参加するteam数など複数の要因で決まる
    - 4時間のtimeboxを超えない
    - sprint 1週間につき1時間
- sprintの成果が完成したことを確認
  - 利用可能になったproduct_backlog_itemを，product_ownerがjust_in_timeでreview
- demoを準備
  - goal: productの検査と適応のために透明性を提供すること
  - 儀式を少なく，価値を高く
  - sprint 1週間につき30分から1時間をsprint_reviewの準備に使う
- 誰が何をするかを決める
  - facilitator, demoを誰がするか，Scrum_teamが決定
approach
- input
  - sprint_backlog, sprint_goal, teamが作成した出荷判断可能なproduct_increment
- output
  - groomingしたproduct_backlogと更新したrelease_plan
- sprint_goalの何を達成して何を達成していないかの概要を示し，出荷判断可能なproduct_incrementのdemoをして，productの現状について議論し，今後のproductの方向性を適応させる
- 概要
  - sprint_goal, sprint_goalに関連したproduct_backlog_item, sprintで実際に開発したproduct_incrementの概要をScrum_teamのmemberが伝えるところから始まる(product_ownerが担当することが多い)
  - sprintの成果とsprint_goalを比較したときの結果が分かる
    - 不一致なら，説明
      - 責任追及，非難はしない
    - 何が達成できたかをもとに，今後取るべき行動を決定する
- demo
  - sprint_reviewの目的はdemoではない
    - 最も重要な側面は，参加者たちの徹底した対話や協力
    - → 生産的な適応を可能にし，有効活用する
    - demoは，対話をより具体的にするための効率の良い方法
  - 準備完了の定義に，Scrum_teamがdemo方法を理解することも含まれる
  - product_ownerの要求を満たしていることをdemoするテストが必要
    - sprint_reviewでは，テストを使ってdemoできる
- 議論
  - product_incrementのdemoは会話の中心になる
  - productや今後の方向性に関する意見，コメント，妥当な議論が，参加者に強く求められる
  - sprint_reviewは問題解決の場ではない
  - Scrum memberが，client/userを喜ばせるためのfeedbackを得ることで，productのbusiness, marketingの認識を深める
- 適応
  - question
    - stakeholderは見たものを気に入っているか
    - 変更点を見たいと思っているか
    - 今でも市場やclientに受け入れられるのか
    - 重要な機能が不足していないか
    - 不必要なところに機能を作りこみすぎたり，costをかけすぎていないか
  - → product_backlogやrelease_planの適応のinputになる
  - grooming @sprint_review
    - より大きなscopeのrelease_planにも影響する
      - 変動要因に影響
        
        scopeの変更など
  - sprint終了ごとに，適応の方法，変化の反応方法，それらを実施できる時期を見つけるための機会を提供する
sprint_reviewのproblem
- signoff
  - 正式な認可やsignoffのeventではない
    - 事前にproduct_ownerが承認済み
    - product_ownerがproduct leadershipの権限を持つため，承認は決定事項
    - 要求があれば新しいproduct_backlog_itemを作成し，機能変更の予定を立てるのが〇
      - なぜ要求を出した人がstakeholderから外れていたか調査し，今後は調整する
- 参加者の不在
  - 数週間で価値のあるものを作り出せると思われていないため
  - 解決方法: business valueのある出荷判断可能なproduct_incrementをsprintごとに開発する
    - → 頻度の高いreviewに参加する価値を理解してもらえる
- 大規模project
  - sprint_reviewの共同実施
    - merit
      - stakeholderはsprint_reviewに1回だけ参加すればよい
      - 成果が統合できれば，個別のincrementではなく統合した結果をreviewすればよい
        
        すべてのteamが完成の定義に統合test要
    - demerit
      - 時間がかかる
      - 大きな部屋が必要
まとめ
- sprint_reviewの目的であるScrum developmentのfeedbackについて
- 参加者のgoalは，現状のproductの検査と適応
- 非公式なactivityだが，最小限の事前準備をする
- Scrum_teamは，reviewの概要とsprintで達成したことを説明する
- product_incrementのdemoをする
- 質問，意見，提案が歓迎される
- grooming, release_planの更新を行う

Ch22 sprint_retrospective

productを構築するのに使ったprocessを，Scrum_teamが調査する
目的，参加者の概要，事前準備，主要なactivityを見る
- 最も重要なのは，参加者が発見した改善をsprint_retrospectiveの後に継続的に行うこと
概要
- 考える機会を与えるもの
  - teamは何が起きているのかを調査したり，自分たちの仕事のやり方を分析したり，改善の方法を見つけたり，改善の計画を立てたりする
  - teamのproductの作り方に影響を与えるものであれば，なんでも自由に調査・議論できる
    - e.g. process, practice, communication, 環境, 作成物, tool
- 最も重要で，最も使用されているpractice
  - teamが自分たちの環境に合わせてScrumをcustomizeできる機会を提供するため
  - しかし「実際の」作業ではないので過少評価されている
- Scrumが提供する継続的改善に不可欠
  - sprintごとにretrospectiveを行い，insightやdataを見失うことなく活用できる
  - 早期にincrementalな学習ができる
    - → projectの成果に大きな影響
- theme
  - sprintでうまくいったので，今後も続けたいこと
  - sprintでうまくいかなかったので，今後は中止したいこと
  - これからやった方がよいこと，改善した方がよいこと
- → 行動可能な変更点を決定，incrementalに改善したprocessで次のsprintに取り組む
参加者
- Scrum_team全員
  - team memberの多様な視点で，さまざまな観点からprocessの改善点を見つけられる
  - Scrum_master: processに欠かせないRole，processの権威
    - teamが合意したprocessで守られていない点を指摘
    - teamにとって重要な知識やideaの源泉となる
  - product_ownerとteamの信頼関係をScrum_masterがcoachingして築くまでは，product_ownerは参加できない
  - 信頼と安全が確保できれば，product_ownerは欠かせない
    - 高速で柔軟性の高いbusiness valueのflowの達成のため
    - 要求のflowをteamに伝えるchannelやrouteなどのRoleを担う
- stakeholder, managerなどは，招待されたときだけ
  - 参加は安全性の問題がないときだけ
事前準備
- sprintの期間が短かったり，実践的で簡潔なretrospectiveのformatを使っていれば，事前準備には必ずしも時間はかけなくていい
- focusを定義
  - default: Scrum_teamが使用したprocessの関連する側面をすべてreviewする
  - 現状のteamの重要性や改善点に合わせて，別のfocusの選択も〇
    - e.g.
      - TDD skill up方法にfocus
      - 要求の誤解の頻発の理由にfocus
  - 開始前にfocusが分かることの効果
    - Scrum_team以外の人たちを招待するかどうか決定できる
    - 適切なexerciseを選択できる
    - retrospectiveを円滑にするために必要なdataの収集や準備に時間をかけられる
  - 具体的に定義 → retrospectiveから計測可能な価値を抽出〇
    - → 持続可能なhigh performance Scrum_teamになる
- exerciseを選択する
  - 協力して考え，探索し，意思決定するためのもの
  - 通常のexercise
    - event timelineの作成と発掘
    - insightのbrainstorming
    - insightのgroupingと投票
  - focusや参加者に合わせて変更可能
  - 新鮮さのために新しいexerciseを試すのも〇
  - 事前準備で決める必要はない, just_in_timeで決定〇
    - data, 備品が必要なexerciseは，事前準備で決めておく
    - 準備しながら，柔軟性は確保
- 客観的dataを収集する
  - data収集に必要な作業は，retrospectiveの開始前に済ませておく
  - 客観的data: 確実なdata(not 意見)
    - e.g. どのようなeventがいつ起きたか，着手したが完成しなかったproduct_backlog_itemの個数，完了した作業のflowを示したsprint burn_up_chartなど
  - この段階では，dataの構造化や分析は行わない
- retrospectiveを構成する
  - sprint_reviewと場所や時間を合わせるかどうか，参加者やexerciseの都合などから考えておく
  - 正確な時間は，team人数，年数，memberがremoteにいるかどうかなどの要因の影響を受ける
    - sprintの期間に合わせて時間を決定する
      - 2週間のsprintなら1.5時間をretrospectiveに割り当てる
  - 成功に最適な場所
    - 情報にaccessしやすい仕事場
    - 安全な環境のために仕事場以外
  - facilitatorは，Scrum_masterがやることが多いが，誰でもよい
    - 中立性のため外部から招くこともある
approach
- input
  - 合意したfocusなど，retrospectiveで使用するとteamで決めたものならどんなexerciseや道具でもいい
  - 事前に収集した客観的data
  - 参加者は，sprintについての主観的なdataを持参する
  - 前回retrospectiveで作成したinsight backlog
- output
  - 次のsprintで行う具体的な改善action
  - 今回retrospectiveで作成したinsight backlog
  - 仲間意識の向上
- theme
  - sprintでうまくいったので，今後も続けたいこと
  - sprintでうまくいかなかったので，今後は中止したいこと
  - これからやった方がよいこと，改善した方がよいこと
- 有効なapproach
  - retrospectiveの雰囲気づくり
    - team/個人を徹底検証するのは不愉快な経験なので，心地よくなってもらうための雰囲気づくりが必要
    - 報復を恐れずに自分の意見を言えるような，安全性を感じてもらう
      - rule設定/取り決め
        
        自分の意見や内輪の恥をさらしても安全であることを明確にする
        
        間違いを探しても安全だとわかるように，個人ではなく組織のsystemやprocessにfocusしていることを明確にするruleを設定しておく
      - 問題が人の問題であることもあるが，retrospectiveは問題解決の場ではない
        
        責任の所在を明らかにしたり，個人の振る舞いを非難したりする場ではなく，Scrum_teamのprocessを改善する場
        
        非難のない環境を作るためのruleであることを明確にしておく
    - 積極的な参加の前例を作る
      - 参加者に口を開いてもらう
        
        今の感情やenergy levelを一言で表現してもらうteamもある
        
        内容より，何かを言うことで，話そうという雰囲気を作る
  - 参加者によるcontextの共有
    - → 客観的に大局的にsprintを見ることができるようになる
    - 多様性のある個人の視点をteamの視点に統一
      - sprintのevent, 達成, 欠点に対する大局的な考えに基づくようにする
        
        × 個人的な経験
        
        → ただの意見の言い合いになる
    - contextを共有して行動可能な成果に注力
    - 雰囲気づくりができたら，客観的data(commited product_backlog_item, 完成したproduct_backlog_item, 不具合数など, retrospectiveのfocusに合ったもの)を共有する
    - 主観的dataも共有・議論する
      - → 誤解の回避のため
      - 誤解があると，他人のcommentや提案を理解できない
    - event_timeline
      - sprintのeventの流れをvisualに表現した作成物
      - 簡単で強力
      - event: buildが動かなくなった，本番環境の修正で手間取った，Salinaが休暇から戻ったなど
      - timelineを壁やwhiteboardに描き，eventを表すカードをtimelineに貼り付ける
        
        colorfulなcardを使う
      - sprintのactivityの流れが時間軸で可視化されて，contextがよくわかる
        
        → 見逃していたり忘れていたeventをすばやく特定できる
    - 感情seismogram(seiein: 揺れる)
      - event_timelineの補完
        
        上下に並べる
      - sprintにおける参加者の感情の起伏を視覚的に表現
      - 客観的dataだけでなく，主観的dataまで含めてcontextを共有できる
  - 改善につながるinsightの特定
    - dataを深く調査，理解，解釈して，process改善のためのinsightを獲得
    - system levelの(より大きな)focusが必要
      - → 表面的なproblemだけでなく，根本的な原因を特定できる
    - まずは共有したdataを発掘
      - insightを明らかにするための質問
        
        何がうまくいったか
        
        何がうまくいかなかったか
        
        やり方を変えるところはないか
      - → brainstorming
    - insight backlog
      - 優先順位をつけたが，まだ実行されていないinsight
      - 検討すべきものがあるか調査
    - insightを意味のあるgroupに分けて，類似や重複しているカードを示す親和図法のようなexerciseを行うことが多い
      - silent groupingは，時間の効率も効果も高い
      - 複数のcategory area(継続，中止，挑戦)に分けることもある
    - → 参加者同士の深い議論につながり，根本原因，重要なpattern，関連をよく理解できるようになる
  - 次のsprintで実施する具体的な改善actionの決定
    - insightからvalueを抽出するために，実際に行動可能なものにする
    - 前回から行われた改善actionのreviewもする
      - 何故できなかったのか把握
      - 改善を続けるか，優先順位を新しいinsightと入れ替えるかなどする
    - insightの選択
      - 短期間で実行できる以上のinsightが手に入る
      - 参加者がどれを重要と思っているか，どこを改善していきたいと思っているかで決めることが多い
      - ドット投票
      - 参加者がinsightに専念できるcapacityや期間によって，いくつ選択するか決定する
        
        期間: 次のsprint期間
        
        capacity: 前回のretrospectiveで見つけたactionの計画から決定できる
        
        product_ownerからのinputをもとに，Scrum_teamが時間を割り当てる
        
        capacityが分かれば，どのinsightに取り組むべきか分かる
    - actionの決定
      - 優先順位のついたinsightが手に入り，それらに取り組むcapacityが判明した状態
      - 具体的なactionの決定
      - ほとんどのactionは，次のsprintで1~2人のScrum_team memberが担当できる程度の具体的なtaskになる
      - development_team_memberのtask levelの作業が必要
        
        誰がどれだけの時間をかけるかteamで決定する
        
        → insightが実行可能かどうか決まる
      - すぐにinsightには取り組めない
        
        次のsprintではinsightの調査が必要
        
        まず問題をよく理解するためのactionを作る
    - insight backlog
      - retrospectiveで発見したが，すぐには改善できない課題をまとめる
      - backlogのinsightと新しいinsightを比較して，次のsprintで集中するところを決める
      - 定期的にgrooming
      - 選択肢しなかったinsightを破棄することもある
        
        必要ならまた発見できるという考え
  - retrospectiveの終了
    - 学んだことをふまえて，決定したteamのactionを再確認する
      - commited actionと担当者を読み上げるだけの簡単なものでいい
    - 感謝を述べる絶好の機会
    - retrospectiveを改善できる提案を求める
その後のfollow
- 参加者が選択したactionをfollow_up
  - 何度も言い続けるしかないものもあるが，それ以外はsprint_planningで指摘する
- actionに関連するtaskをsprint_backlogに追加して，新しい機能よりも優先順位を高くする
  - 分離×．統合〇．
  - team_memberの時間を必要としないactionは，Scrum_masterのimpediment listに加える
  - ほかのteamや組織のactionは，担当者の適切なbacklogに入れておく
    - 確実に実行されるように，Scrum_masterは外部の人たちをfollow
sprint_retrospectiveのproblem
- retrospectiveを実施していないか，参加者が少ない
- All fluff(ふわふわしたもの, つまらないこと), no stuff(本当に役立つこと)
  - 外部からretrospective facilitatorを招いて支援してもらう
- 部屋にいる象を無視している
  - 劇的な影響をもたらす重大な問題に誰も触れない
  - Scrum_masterがleadershipのRoleを担い，まずそのimpedimentを除去する
- facilitatorのskill不足
  - 外部からretrospective facilitatorを招いて支援してもらう
- 気がめいってenergyが奪われる
  - 雰囲気づくりの時間を作る
- 責任追及game
  - facilitatorがすぐに悪い振る舞いを消滅させるようにする
- 不満大会
  - face to faceで対話するようにする．
- 現場の改善をつぶす
  - retrospectiveは改善活動そのものではない
- 意識が高すぎる
  - Scrum_masterが熱意を和らげるよう支援する
- followがない
  - Scrum_masterの支援が必要
まとめ
- sprint_retrospectiveは，teamがScrumをうまく活用できたか振り返る時間，改善案を策定する時間
  - Scrum_team member(必要ならそれ以外の人たちも)の共同作業
  - 事前準備が終わったら，雰囲気づくりをして，dataに基づいたcontextを共有して理解を統一し，改善insightを見つけ，改善actionを決定し，retrospectiveを終了する
  - 終了後は，参加者をfollowして，改善actionを実行していくことがimportant
    - → 次のsprintでteamがより効果的になる
  - 成功を阻害する問題に注意を払い，すばやく対処することもimportant

Ch23 未来へ

Scrumを実践するうえでの，普遍的な最終目的はない
agilityに向かって，独自の道を定義する必要がある
最終形態などない
- Scrumの適応やScrumの移行について完成の定義はない
  - 継続的改善の一形態
  - より効率的かつ経済的にbusinessの目的を達成するための手段に過ぎない
  - productによって状態が異なる
独自の道を探し出す
- 学び，検査し，適応して，進むべき道を探る
  - base: 組織独自の目標・文化，変わりゆく複雑な環境
- 自分の学習loopを素早く完結させて，その学びに基づいて，検査と適応を行う
best practiceを共有せよ
- practice: Scrumの核心的基礎的な側面
- approach: Scrumのpracticeの1つの実装
Scrumを使って，進むべき道を探し出せ
- enterprise_transition_community
  - managerと経営者で構成されたgroup
  - 組織変革のための取り組みや，Scrum_teamを妨げている重大なimpedimentの除去がbacklogに入る
  - Scrumを適用するためにScrumを用いる
    - iterative and incrementalによりいっそうAgileになっていくうえで適切なapproach
歩みを止めるな
- 経験上，teamの最初の2回程度のsprintはうまくいかない
- 次のsprintで，前のsprintより良くなっていさえすればよい
  - 始めるのを遅らせてはならない
- Scrumの実施を難しくするimpedimentが必ずある
  - 機能不全やムダが可視化される
  - こうした課題の解決は，Scrumでは組織の中にいる人にゆだねられる
- 現状維持をしたいという強い力の考え
  - 組織を変革するために確固たる信念をもって辛抱強く立ち向かう必要
  - 変革に対する抵抗は自然なもの
  - 協力し合うことで障害を取り去る
  - → team, product development, 組織が，Scrumの実践の恩恵を十二分に理解できるようになる

Learning Records

『エッセンシャルスクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド』学習メモ

まえがき

Ch01 Introduction

Part 1 Core Concept

Ch02 Scrum framework

Ch03 Agile principle

Ch04 sprint

Ch05 要件とuser_story

Ch06 product_backlog

Ch07 見積もりとVelocity

Ch08 技術的負債

Part 2 Role

Ch09 product_owner

Ch10 Scrum_master

Ch11 development_team

Ch12 Scrum_teamの構成

Ch13 manager

Part 3 planning

Ch14 Scrumのplanning principle

Ch15 さまざまなlevelでのplanning

Ch16 portfolio_planning

Ch17 envisioning(product_planning)

Ch18 release_planning(長期計画)

Part 4 sprint

Ch19 sprint_planning

Ch20 sprintの実施

Ch21 sprint_review

Ch22 sprint_retrospective

Ch23 未来へ