📌

2018/05/02 Scrum勉強会@社内

2022/05/24に公開

資料

https://scrumguides.org/download.html

メモ

定義・用途

  • Scrum自体は軽量で理解が容易だが修得は困難
  • Scrumの本質は少人数制のチーム
    • 7人程度までが理想
    • あまりに少人数(3人程度)だとまわらない

理論

  • 結果責任を持つものに対して見える化されていることである
    • プロセスの用語を参加者全員で共有している
    • 作業する人と検査する人が「完成」の定義を共有している
  • ツールを使うことによって見える化を行うことは可能だが見えたことによる解決には至っていない。
  • 検査
    • 成果物やゴールまでの進捗を頻繁に検査する
    • 好ましくない変化を検知する必要がある
    • ただ頻繁にやりすぎても作業の妨げになってしまう
  • 適応
    • プロセスの不備が許容値を超えてしまい検査する担当者がこれ以上受け入れられないと判断した場合は構成要素や今後の工程の調整を行う必要がある

チーム

  • Scrumチームは以下の3つで構成される
    • プロダクトオーナー
      • プロダクトバックログの管理に責任を持っている人
    • 開発チーム
      • 各スプリント
      • 属人化している作業が合ったとしても、Scrumにおける開発チームのメンバーに肩書は存在しない
      • ビジネス分析や運用、アーキテクチャのような専門領域があってもScrumではサブチームの存在を認めていない
    • スクラムマスター
      • スクラムガイドで定義されたScrumの促進と支援に責任を持つ
      • Scrumの理論・ルール・価値基準を全員に理解してもらえるように支援する
      • 教えるをしてはいけない。支援をする。(スクラムガイド2017年版Page 7を参照)
  • 開発チームの中には○○担当者といったものは存在しない
    • 「テスト担当、実装担当」や「デザイン担当、DB担当、インフラ担当」といった括りはまず無い
    • ・iOS担当、Android担当といったものも無し
    • 「コンポーネントチーム」と「フィーチャーチーム」
      「コンポーネントチーム」と「フィーチャーチーム」
    • Scrumではフィーチャーチームとして活動していくべき
  • チームに必要なのは各個人のリーダーシップ力と管理能力
    • Scrumでは管理する人は時に決められていない。じゃあ誰が管理するの?自分でしょ

スクラムイベント

  • Scrumと言えば以下の図
    Scrum
  • Scrumで定義されていないミーティングの必要性を最小化する
  • Refinementについては定期的にやっている所もあれば不定期でやっている所もある

スプリントプランニング

  • スプリントの作業を計画する。
  • スクラムチームの共同作業。
  • タイムボックスは1週間の場合だと最大2時間(不慣れの場合は3時間程度になることも)
  • 2時間の中では以下の2点を打ち合わせ/計画してみる
    1. スプリントで何ができるのか
    2. 選択した作業をどのように成し遂げるか
  • 打ち合わせではプランニングポーカーが有効

デイリースクラム

  • デイリースクラムは毎日、同じ時間、同じ場所で開催する
    • 毎日(マスト)
  • 話す内容の例
    • 自分が昨日やった内容は何か
    • 自分が今日やる内容は何か
    • 障害となるものを発見したか
  • 一つ一つに質疑応答するのではなく、気になることはデイリースクラムが終わった後にして他のメンバーの作業妨げない
  • 開発チームのためのミーティングであるため、開発チーム以外の人が参加する分には問題ないがどうこう言う資格はない
    • 言われる/言われそうな場合はスクラムマスターが止める(障害を除外する)

スプリントレビュー

  • 基本的にはドヤ顔する場面
    • ここまでやってやったぜHAHAHA
  • 今回できなかったものが合あった場合は次回のスプリントにまわしていく

スプリントレトロスペクティブ

  • 人・関係・プロセス・ツールの観点から今回のスプリントを検査する
  • うまく言った項目や今後の改善が必要な項目を特定・整理する
  • スクラムチームの作業の改善実施計画を作成する

成果物

プロダクトバックログ

  • プロダクトに必要だと把握しているものを全て順番に並べた一覧
  • プロダクトバックログは唯一のものなのでパターンA, パターンBという複数候補はまず無い
    • プロダクトバックログを決める打ち合わせに開発チームは参加した方が良いのか
      可能であれば参加したほうが良い
      • プロダクトオーナーには分からないことを助言/発言できるため
      • ただし順番を並べる資格はない

スプリントバックログ

  • スプリントバックログは開発チームのためのものであり、開発チームが管理していく

成果物の透明性

完成の定義

  • プロダクトバックログアイテムやインクリメントの完成を決める際はチーム全員がその完成の意味を理解しておかなければならない
  • リリーススプリントが発生しているチームがあるが、これはダメ
    • 基本的には週や月毎にやっているスプリントに含めるべき
    • リリーススプリントが発生しているということは完成の定義が曖昧となっている
GitHubで編集を提案

Discussion