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

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

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

実践編

p250〜270

24 やり残したことはないかい？

リリースに必要なことをする

• Scrumだからといって、リリースのためにやることは変わりない
  • 様々なテスト
  • パフォーマンス
  • ドキュメント作成
  • etc.

リリースに必要な作業とは？

• スプリントごとにPBLの項目を実現してきた
  • 全て完了の定義を満たしている
    • スクラムチーム内部での何が終わったかの認識合わせ、本当の意味で終わったとは言えない
• 本当に終わったと言える時は
  • どんな時？
    • リリースに求められる基準を満たした時

リリースに必要な作業 = リリースを満たす基準 - 完了の定義

リリースに必要な作業はいつやる？

• 自分たちで判断する
  • 例
    • 完了の定義に含めて毎回のスプリントでドキュメント揃える
    • 数スプリントおきにパフォーマンスの確認をする
  • リリースまでに終わればいいので、自分たちのやりやすいようにする

リリーススプリント

• Scrum初心者 チームがよく採用している
  • 通常のスプリントが終わったあとに、リリースに必要な作業を片付けるための期間を取るやり方
    • やり方は特に決まってない
    • スクラムイベントも特にやらなくていい
• 最初に作業の全貌を知っておく
  • 必要な作業を洗い出す
  • 見積もり
  • 長くても１，２スプリント
  • プロジェクトの後半にしたほうがより正確
• あとは期間内に終わらせる

リリーススプリントの暗黒面

• リリースのための作業にはリスクが伴う
  • 本番環境で落ちる、想定外のデータが入る、etc
• 早い段階で検証を行うべき
  • リリースに必要な作業だからといって何でも後回しはいけない
    • なるべく残す作業を少なくしておく

本来はリリーススプリントが無くてもいいようにする

• リリース判断可能なものをスプリント毎に提供していく
  • 状況によっては途中でリリースしようとしてもすぐに対応できる
  • 毎回出来るスクラムチームもある
    • 完了の定義にあらゆる事が含まれている
    • そこまで出来るスクラムチームは少ない
    • やれることは前倒しで

完了の定義の拡張

• スクラムチームもプロジェクトを通して成長していく
  • やれることも増える
  • なにか１つでも早く取り組めるようにしていく
  • リリーススプリントがあることを言い訳にして、後回しは駄目
  • なんでもリリーススプリントに回すのは良くない

25 ここからが始まりさ

実践編で伝えたかったこと

最後までよんでくれてありがとう

• Scrumは非常にシンプルな反面、実際の現場でどうやっていくのかを悩むかもしれない
• 初めてのスクラムチームでも成果を出すことは出来る
• 本に書かれているようなプリジェクトばかりではない
  • 実際によく質問されることに触れる
    • 大人数での開発
    • 分散拠点での開発

Scrumで大人数による開発はできるのだろうか？

• 開発チームの規模は10人未満と決められている
  • 大人数開発のときはどうする？？
    • 必要な分の開発チームとスクラムマスターを用意する
    • POは一人、PBLも１つ
      • POを支える専門の体制を用意する
    • スクラム・オブ・スクラム
      • プロジェクト全体に関わる問題、話題、検査
      • 他のチームとの調整
      • デイリースクラムのあとに、チームの代表者が集まって話す
      • 普通のデイリースクラムと変わらない
    • 前提
      • それぞれのスクラムチームがやり方に慣れていること
      • 開発チーム内の問題は自分たちで解決できること
      • もしそんなチームが沢山ないなら、大人数開発はやめておく
        • それでもScrumでやるメリットが大きいならば、少なくとも 開発チーム内の問題は自分たちで解決出来るように進める
        • 慣れたやり方である程度まで作って、その間にScrumやり方を少しでも取り入れて、問題を解決する練習をしていく
        • どこかのタイミングでScrumに切り替える
          • 切り替えた途端にうまく進まなくなるといったデメリットもある

Scrumで離れた拠点との開発はできるのだろうか？

• 遠隔地とのやり取りが上手く行かない
• 向こうの状況がよくわからない
  • Scrumでも解決できない
  • 置かれている環境や状況に応じて解決していこう
    • POが毎週出張する
    • 性能の良い会議システムで拠点をつなぐ
  • ただし、一度も会ったことが人同士でチームを組むのは大変
    • 同じ拠点で一緒に開発してみる
    • その後離れて開発する

Scrumをやったからってうまくいくわけではない

• 最初は全員が近くにいて、１つのスクラムチームだけで扱えるプロジェクトから始めたがいい

• Scrumはうまく行ってないことを見逃さず、対処しやすいように以下を提供するだけ

  1 どこがうまくいっていないかを特定しやすい
  2 実際にうまく行っていないことを解消する機会を与えている
  3 うまくやるためのやり方に変えられる余地がある
  4 やり方を多少変えても影響が少ないようになっている
  

プロジェクトの問題を見つけられるのは、現場の人

• カイゼンする
• 現場の人達が中心となって問題となりそうなことを見つけて、仕事の進め方から見直して解決していく
  • もしカイゼンがなかったら
    • Scrumは自分たちがつくるものをもっと良くすることを重視している
      • プロジェクトに常に問題があったら、作るものをよく出来ない

実践編で伝えなかったこと

• 最初からカイゼンをうまく出来るチームはほとんどない
• 伝えなかったこと
  • スプリントレトロスペクティブ
    • チームがもっとよい仕事の進め方を考えていくためのイベント
      • 作ったものを更に良くしていく
      • スクラムチームが更によくなる
        • 新しい手法を取り入れる、そのための勉強時間を確保する
    • 最初の頃は問題解決のイベントになりがち
      • 問題解決のイベントではない
  • プロダクトという考え方
    • スクラムチームが作り上げていくものの全体を指す言葉
      • プロダクトを良くすることを考えていくのは難しい
        • プロジェクトがどう進んでいくかに意識が向きがち
    • プロジェクトが上手く進んでも、周りの期待に応えられるわけではない
      • プロダクトをどれだけ良くしていくかが大事

周りの期待に応えていけるスクラムチームになれるのか？

• 少しずつ学んで上達していけばいい
  • エンジニアリングのスキル
  • デザインスキル
  • マネジメント
  • etc
• Scrumを通じて学んでいける
  • 協業、努力、体験、挑戦

Scrumの本質は体験を通して学んでいく仕組み

• 皆に喜ばれるプロダクトを作るのは簡単ではない
  • 平凡なスキルを持たない私達でも、学び続けていけば、いつか自分たちの代表作だと胸を張れる物が作れる。

最後に

この本をきっかけに、Scrumに取り組んで見たり、少しでも良いスクラムチームになったり、もっと学んで行こうということに繋がれば、私達に取ってそれ以上に嬉しいことはない。