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

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

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

実践編

p180〜217

15 問題をみつけやすくする

皆で協力してすすめて行く

• POがいない等、代理では無理なこともある
  • POは忙しい人が多い
• 全員参加のイベント

    スプリント計画ミーティング
    スプリントレビュー
    スプリントレトロスペクティブ

• 参加すべき理由
  • それぞれのロールには各イベントでやらないといけないことがある
  • プロジェクトにとって大事な情報を得る
    • 期待、やり取り、etc
• どうしても参加できないとき
  • タイムボックスは変更できない
    • 開発チームは他のメンバーから聞ける
    • スクラムマスターは他のイベントで注意深く
  • PO
    • 参加すべき理由を伝える
    • 粘り強く理由を聞く
    • 都合のつく時間に合わせる
    • 仕事を手伝う
    • スクラムマスターが支援の中心となる
    • ロールは問題を見つけやすくするためにある
  • ロールで担当分けをしているので問題を見つけやすい
    • PBLが更新されていない、レビュー後に触ったらバグだらけ

16 意図を明確にしておく

うまく伝わってるのかな？

• ScrumではPOから開発チームに実現したいものを伝える

  • ロールによって考えていることが違う
    • 分けているので考える事に違いが生じる

• どうやってうまく伝えるのか？

  • 実現したいものを実際に使う人達の立場で伝えること

• そのための工夫

  • ユーザーストーリー

• フォーマット

  1 <ユーザーや顧客>として
  2 <どんな機能・性能>が欲しい
  3 それは<どんなことが達成したい>ためだ
  

• PBLにそのまま書ける

  • 例： 口コミ連携機能

  1 クリニックとして
  2 評価してくれるユーザをグーグルの口コミに誘導する機能が欲しい
  3 それは、グーグル口コミの評価を上げて、患者を増やすためだ
  

• 開発チームもユーザーストリーに書かれていることをどう実現するか、どう使ってもらうかをPOにつたえられる

  • そのままデモ手順に出来る

  送信完了画面に、おすすめするボタンを置く
  次の画面にGメールアカウント持ってるか尋ねるボタンを置く
  持ってるボタンを押下したらGoogleの画面が開く
  

• ３つのうちで1番大事なのは
  どれ？

  • 3 意図が大事
    • 意図が分かっていれば対応がしやすい。
    • 大事なのは機能ではなく、達成したいこと。
    • 優先度もやらないことも決めやすい

• ユーザーストーリーの形式では全部書ききることは出来ない

  • 細かい部分は話す必要あり
  • わざと短くすることで話し合う機会を設ける

• 大事なことは実現したいものをなんとしてでも伝えること

17 プロジェクトを支援していく

何かがおかしい

• みんなを支えてゴールを目指す

  • 開発チームへの期待
    • スプリントの最後にソフトウエアを届けること
      • 気がつくと以前より作業がうまく進まなくなっている時がある
      • どうしてそうなった？
        • 技術的負債の場合が多い
          • 良くないコードが増えている
        • 仕様の決定が遅れる
        • POとのやり取りが上手く行ってない
  • 問題だけに対処しても、問題が繰り返し起こってしまう

• 問題を生まないようにする

  • 常に良い状態にしておくのがスクラムマスターの役目
  • スクラムマスターが予兆に気づく
    • 見逃さない工夫
      • ソースコードの最終コミット時間を自動送信

• 問題を見つけたら

  • スクラムマスターが皆に声をかけ、良い状態を保つ

• 良い状態か悪い状態判断
  どうやって？

  • 夜遅くまでやってる
  • レビューに間に合わない事に気づいておきながら声をあげない
  • 遅刻が多い
  • イライラ

• サーバント・リーダーシップ

  • みんなをサポートして目的を達成していくのがスクラムマスター

18 すぐに解決できない

より良い状態にしていく

• 少しでも理想に近づけていくぞ！！

• スクラムチームは日々、問題になりそうなことやうまく行っていないことに素早く対処して、プロジェクトを進めていく

  • 実際はそううまく行かない

• どうしても問題が出てくる

    プロジェクトのゴールを直接脅かしてくるもの
    例：バグ、POの要求が頻繁に変わる、技術的負債の蓄積、etc
  

  • 全員が抱えている問題を把握しておくことが重要

    • どうやって把握する
      • デイリースクラム、スプリントレビュー
        • プロジェクトが混乱している時はうまく機能しない場合がある
          -チームが慣れていない場合もある
      • タスクボード
        • 例えば、問題を全て貼り出す
    • 問題が起きたらすぐに対処することが大事

  • スクラムチーム

      スクラムチーム自身
      例 報告会になってる、ホワイトボード置くスペースさえない
    

• スクラムマスターが問題の解消に務める

  • 理想を思い浮かべて、そこに近づける
  • どうやって？
    • 理想とのギャップを見つける
    • プロジェクト全体をよく観察する
      • 例
        • スクラムイベントで一方的に話している時間が長い
        • 使いにくいツールで開発していて文句も言わない
      • なぜそうなっているかを考える
  • 妨害＝ギャップのこと
    • 理想的に進むのを妨げる事柄
    • スクラムマスターは妨害を見つけて取り除く

• 妨害を管理しておく

  • 妨害リスト
    • スクラムマスターのもちもの
    • 良いスクラムマスターは50個以上項目を書いていたりする
    • 見えるところにおいておく
      • 進捗がなければスクラムマスターも問題を抱えている事がわかる
      • 皆に興味をもたせる

• スクラムマスターは少しでも解消していく

  • 周りのみんなも関心をもってくれる
  • 勇気とあきらめない粘り強さが必要

19 今後のことがわからない？

先の事をいつも明確にする

• こまめに手入れする

  • PBLはずっと変更されていく
    • いろんなことが追加されると、誰にもよくわからない状態になる
    • 書ける人を決める、追記ルールを決める
      • 様々な意見が集まるように、いつでも誰でも書けるようにしておく
  • 整理してプロジェクトに取って最善の方法を見つける
  • 以下の作業を行っていく

  1. 重要なことを見逃さないための順序の見直し（PO）
  2. 見積もりを最新にする
  3. プロジェクトの進む先を整理するために、順序をもう一度見直す
  

• ゴールを満たすために、何を実現するのかを判断していく

  • Scrumは状況に合わせてプロジェクトの進む先を修正していく

• プロジェクトの進む先をいつも明確にするために整理し続ける

  • プロダクトバックログ・グルーミング
    • 日頃からやるので、定期的なイベントとして規定されてないが、不慣れなら定期的にやる
  • Scrumはプロダクトバックログに従ってプロジェクトを進めていく。放置すると先のことがわからなくなる。だからプロダクトバックログには最新の状態を反映させておく必要がある。