ダッシュで奪取

ゲーム、読書、人生

『SCRUM BOOT CAMP THE BOOK 増強改訂版』を読んだ

転職先でスクラム開発へ参加することになったのですが、各イベントにどんな心持ちで参加すればいいのかな〜とか、自分の見積もりに不安があったので読みました。

メモ

  • 開発チームは3〜9人が適切とされている
    • 少なすぎるとチームの恩恵が薄いし、多すぎるとコミュニケーションコスト増大
  • メンバーごとの能力に差があるのは仕方ない
    • 作業を進めていく過程で なるべく個人がいろいろできるようになること が望ましい
      • フロント分かりませんではなく、分かりたい気持ちがいっそう強くなった
        • その前にまずバックエンド独り立ちをしないといけないのですが…
  • プランニングでの作業分け
    • 作業それぞれは1日以内で終わるぐらい小さくする
      • 初めてのタスクに4日ぐらい使って大迷惑をかけてしまった
        • 4日はやりすぎ
  • デイリースクラム
    • 問題解決の場ではない
      • 問題があれば報告はする
      • デイリースクラム外で別途時間を取って解決する
    • 困っていることがない?
      • 「そろそろ手が空きそう」も困っていること
  • 見積もりは推測である
    • 詳細な見積もりは、詳細に推測しているだけ である
      • 実際にやってみたら「何これ?」は出てくるもの
  • プランニングポーカー
    • メリット
      • 認識の違い、曖昧な部分を明らかにすること
        • 毎回自分だけ大きな数字を出しがちなので気になったところ
          • 認識の違いが明らかになっていただけだった…
    • 見積もれないということも重要な情報
      • 分からないことがあって数字が出せないなら、その分からないことを解決するための場でもある
  • 計画立て
    • 1日に使える時間は5〜6時間ぐらいと見ておく
      • 割り込み作業は意外と多いから
  • 不安な点を積極的に言い合えるチームはよいチームである
    • 大声で分かりませんを言えるようになっていきたい
      • もちろん、事前に(できる範囲で)調べた上で…
  • 自分が一番気になっていた「ふりかえり」についてはほとんど触れられていなかった

ひとこと

  • 入社早々インフルエンザでめちゃくちゃ休んでしまったので、明日(連休明け)から気持ちを入れ替えて頑張ろうと思った