少し前に読んだのでアウトプットします。

実践編

p218〜249

20 本当に着手していいのかな？

PBLの手入れをしたら様々な問題が出てきた

手戻りをなくしていく

手戻りはScrumで進めていても起きる。
手戻りが起きやすいとき
- どんな時？
- 何を実現したいかがあいまいな時
曖昧だと色々問題が出てくる
- 見積もりの誤差が大きくなる
- 確認に手間取る
- 次のスプリントに影響が出る（実績が信頼できない）
- PBL全てを明確にすべきということではない（そもそも出来ない）
直前のスプリントの分だけ曖昧さを無くす

まずは大きな手戻りが発生しないようにする

何を実現すればプロジェクトで達成すべきことを満たせそうか、スプリント着手前に確認する
- 例
  - POが開発チームの意見をもらう
  - 実際に使う人達から意見をもらう
    - ペーパープロトタイピング（UIで視覚的に確認）
ちょっとした工夫で手戻りは防げる
- 実現したいことは先に深く理解しておく
  - POは理解の助けとなる物を用意する
    - そうすることで、大きな考慮漏れもなくなる
- 決めるべき仕様を先に決めておく
- 技術的にどういうふうに実現するといいかを確認しておく
  - 開発チームは、具体的に考えておく
    - 困りそうな点、仕様の曖昧な点、調査事項など

スプリントで着手するための準備は大事か？

スプリント期間を開発作業に集中出来る（最重要）
- 曖昧さの除去
  - スプリント計画MTGでは確実な計画が作りやすい
  - スプリントレビューで達成すべきことを満たしているかに十分に時間が取れる
  - 結果ベロシティが安定する
- スクラムチームで準備のやり取り
  - 手間をかけずに、プロジェクトの進む先を微調整しやすい
  - いいアイデアが出るかも
  - 他の項目も出来るかも

スプリントの準備はプロジェクトをうまく進めるために不可欠

スプリントの準備はスプリント計画MTGで洗い出した作業と平行に進める必要がある
- 最初は準備まで手が回らない
  - 準備のためのイベントを用意する
    - 定期的に集まって、POが次回以降のスプリントで実現したいことを伝えて、皆で話し合う
    - 多くのチームでは、準備のために10〜20%位の時間を確保して、スプリントの計画に組み込んでいる
スプリントの期間中に準備の作業を出来るようにしておく
- 準備が出来ていない項目は、スプリント計画MTGでは扱わないってルールを決めてもいい。
  - 仕様が決められない、プロトタイピングがないなど
- 日々の作業としてスプリントの準備に取り組まないといけない

 次のスプリントで実現したいものは、実現しても大丈夫だという確信がPOにあること
 開発チームに必要なことを伝えられるようになっていること
 開発チームも、これなら実現できそうだと判断出来ていないといけない

21 あれ間に合わない

溢れそうなものを調整する

いつもゴールに向かう

なにか問題が起きたら早期に解決
ゴールから大きく外れるのは避けられる #### どうやってゴールに近づく？
どうやって１？
- スクラムチームの仕事の進め方を改善する
  - すぐに効果は出ない、定量的に測れない。漸次的な改良となる
どうやって２
- 何かを調整してゴールに近づく
  - 品質、予算、期間、スコープ
- 品質
  - 常に一定、犠牲にしたら駄目
- 予算
  - 即効性はない
  - 簡単に出来ない
- 期間
  - リリース日をずらす
    - リリース日が大事な場合が多いので難しい
    - 何度も出来ない
    - 伸ばすと予算も増える
- スコープ
  - PBLの何からどこまでやるかを見直す
  - 優先順位を変えてゴールに辿り着く
  - 達成して欲しい事がスコープを守ることだったら？
    - 何も調整出来ない場合が多い
    - そもそも難しいプロジェクト（手法問わず）
    - それでも最初にスコープを調整する
      - プロジェクトで達成して欲しいことはほんとにスコープ？
        
        ドキュメント、エビデンス、etc
      - 本当の目的を達成できるものを他に提供すればいい
- 優先順位の見直し以外でスコープを調整するには？
  - 実現する方法を見直す（強弱をつける）
    - 例：確認画面減らす、アラートにする、質素にする
  - どう実現するかを調整する
    - 方法で調整するのはPBLの項目自体を調整するより手間がかかる
      - PBLの中身の十分な理解
      - 何十ポイントも稼ぐには多くの項目の実現方法を調整
  - スクラムチームとしては一番取り組みやすい
  - 最初に決めたことを守り通して、ボロボロのものが出来るよりはいい
- 常にゴールに向かう
  - 厳しいプロジェクト大きな調整は難しい
  - プロジェクトがゴールに向かっているか常に確認し、微調整しておく
  - そうすれば、少しずつゴールに辿り着く

22 この作業は苦手です

様々な状況に対応する

協力して乗り越えていく

Scrumチームの特徴
どんなん？
- 自己組織化
- 機能横断的
優秀なメンバーだけじゃないとScrumはうまく行かないのか？
- ソンナコトナイヨー
自己組織化
- 自分たちで状況に応じて役割を決める
- その時々の状況で最も力を発揮できる人がリーダーシップを発揮してチームを引っ張る
  - 得意分野が人によって異なる
機能横断的
- 全てのスキルを兼ね添えた人はそうそういない
  - 一人ひとりが全部を完璧にこなせるようなスキルを持つことではない
- 開発チームだけでスプリントを円滑に進めていけるようになっていること
  - 新人だけでも、PGが得意って人ばかりでもうまくいかない
- わかりやすくする
  - スキルマップを書いてみる
    - 得意、経験あり、未経験
    - 出来ることが見えてくる、プロジェクトを進める上で足りてないものは関係者と相談
大事なことは、開発チームとしていろんな事ができるかどうか
皆が得意なことだけやってても駄目
- 協力、手伝い、色々学び少しずつスキルを上げていく
- チームが見違えるほどよくなる

Scrumが求めていること

ここまでしかしません、ではなく、皆で協力して作業進めていくような開発チーム
- 誰かが困っていたら他の人が助ける

23 それぐらいはできるよね？

より確実な判断をしていく

失敗からどんどん学んでいこう

Scrumはコミットメントという言葉をとても大事にしている
- 責任を伴う約束
  - 例：
    - デイリースクラム
      - 何を終わらせるかを約束する
    - スプリント計画MTG
      - 今回どれだけの項目を実現されるか
実際に作業に関係のない人の意見は参考意見
- Scrumチームの意見を尊重するのは理由がある
  - 様々な判断が必要で、それはScrumチームにしか出来ない
  - 判断を的確にやるのは簡単ではない
    - 責任を持って取り組む必要がある
      - コミットメントの機会を数多く増やしている
コミットメントのダークサイド
- 約束を守ろうとして無理してしまう
コミットメントは自分たちがやるべき作業にベストを尽くして取り組んで行くためにある
- どうやって責任を持って約束できるのか？
  - 自身を持つこと
    - 失敗してもいいから学んでいく、次の機会には自身を持ってコミットメント出来る
- ある程度の失敗は許す
  - 最初の頃のスプリントなら被害は少ない
最初からうまくは出来ないので失敗から学んでいこう
- 良い循環を作っていく

SCRUM BOOT CAMP The Book 第1版を読む Vol.6

実践編

20 本当に着手していいのかな？

手戻りをなくしていく

まずは大きな手戻りが発生しないようにする

スプリントで着手するための準備は大事か？

スプリントの準備はプロジェクトをうまく進めるために不可欠

21 あれ間に合わない

溢れそうなものを調整する

いつもゴールに向かう

22 この作業は苦手です

様々な状況に対応する

協力して乗り越えていく

Scrumが求めていること

23 それぐらいはできるよね？

より確実な判断をしていく

失敗からどんどん学んでいこう