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

• 少し前に読んだのでアウトプットします。
• Vol.1〜7にまとめています

基礎編

• 20〜40ページ

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

動機

• アジャイル開発、読みかじり聞きかじりだった
• アウトプットすることで記憶に留めたい
• もしかすると知りたい人がいるかも
• 積ん読してた

はじめに

ソフトウエアを作る上で大事なこと。

• できたものを使って、利用者が便利になったり、お金を稼いだりといった、成果を上げること
• そのためには、当初のアイデアよりよいアイデアが出てくれば、目的を達成するために作るものを変えていく

アジャイル開発ってなんだろう

• 関係者は目的達成のためにお互いに協力し合いながらすすめる
• 利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する
• 1度にまとめてではなく少しずつ作る。そして実際に出来上がったものが求めているものと合っているかを頻繁に確認する

アジャイル開発の前提

• 事前にすべてを正確に予測し、計画することは出来ない

方向性

• おおよその全体像を決めて、大事な要求から順にプロダクトを作っていく
  • プロダクトとは（アジャイル開発において実際に作られるもの。ドキュメントなども含みます）
• 要求分析、設計などに必要以上の時間をかけない

Scrumってなんだろう

• アジャイル開発手法の一つ
  • 他、エクストリームプログラミング、リーンソフトウエア開発など幾つかある。

Scrumの特徴

これらを継続的に実施してプロジェクトを進める

• 要求を常に順番に並べ替えて、その順位プロダクトを作ることで成果を最大化します。
• Scrumでは実現される価値やリスクや必要性を基準にします。
  • 固定の短い時間に区切って、作業を進めます（=タイムボックス）
• 現在の状況や問題点を常に明らかにします。（=透明性）
• 定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認します。（=検査)
• やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変える。(=適応)

Scrumでは仕事の進め方にフォーカスした最低限のルールだけを定めていく

• ルールの適用の仕方は自分たちで考える
  • コードの書き方、テストの仕方、、etc

Scrumで決められていること

要求の並び替え

成果物1.プロダクトバックログ

• 実現したい要求をリストにして並び替える。常にメンテナンスして保つ。
  • 順番は要求が実現された時に得られる価値・リスク・必要性等によって決定される
  • それぞれの項目は見積もられている必要がある
  • 見積もりは作業量を相対的に表した値をよく使う
  • 項目の書き方は、ユーザーストーリーと呼ばれる形式で書くことが多い

責任者は誰？

ロール1. プロダクトオーナー

• プロダクトの責任者。結果責任を取る
• PBLの管理、並び替え、最終決定権者
• プロジェクトに必ず一人
• 開発チームを活用して、プロダクトの価値を最大化する
• 開発チームに相談は出来るが、干渉は出来ない
• プロダクトのビジョンを明らかにし、周りと共有する
• おおよそのリリース計画を定める
• 予算を管理する
• 顧客、ステークホルダーとの折衝

ロール2. 開発チーム

• リリース判断可能なプロダクトを作る
  • 機能横断的なチーム
    • 開発チームはプロダクトを作るために必要な全ての作業が出来なければならない
    • メンバー毎に得意分野が違ったり、能力に差があっても、個々人が複数の事を出来ることが望ましい。
• 3人〜9人で構成する
• 全員揃えばプロダクトを作れる
• 上下関係はない
  • 自己組織化されたチーム
    • 開発チームの合意のもとに進める
    • 外部から仕事の進め方を指示されることがあってはならない
    • 主体的に作業をすすめることで、開発チームの能力を継続的に向上させていく

短く区切って繰り返す

スプリント

• 最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。この期間をスプリントと呼ぶ。
• スプリントの期間は固定する
• リリース判断に必要な全てのことを行う
• 期間は延長しない

頻繁に計画する

会議体1. スプリント計画ミーティング

• 何を作るのか、どのように作るのかを計画する
• 1ヶ月スプリントの場合は8時間。2週間スプリントであれば4時間
• 二部構成
  • 第一部
    • プロダクトオーナーは何が欲しいのか
    • 開発チームはどれくらいでできそうか
  • 第二部
    • 開発チームはどうやってそれを実現するか

第一部 スプリントでどのPBLを開発するのか検討・確認する

• プロダクトオーナー、開発チーム、スクラムマスターが参加
• 開発する量は過去のスプリントの実績と今後の予測を参考にして内容を決定する
  • ベロシティと呼ぶ=過去の実績
• PBLの順位が上のものから順に、今回のスプリントで開発する対象として検討する。
• スプリントゴール
  • 第一部で検討した内容を踏まえて今回のスプリントの目標を完結にまとめておく。

第二部 作業タスクの洗い出し

• 第一部で選択したPBLの項目を完了させるために必要な全作業を開発チームによって洗い出す
  • =作業タスクの洗い出し
• タスク一覧
  • スプリントバックログ

成果物2スプリントバックログ

• 開発チームの作業計画
• タスクの一覧
• 個々のタスクは一日以下の単位とする
• タスクはあとから増えることもある
• 計画を完了することに全力を注ぐ必要はあるが、全ての完了を約束するものではない
• 作業者が項目を選択する

リリース判断可能ってなに？

成果物3.リリース判断可能なプロダクト

• 完了の定義
  • プロダクトオーナーと開発チームが「リリース判断可能」の指す内容について共通の基準を保つ必要がある。＝品質基準
  • 何を持ってリリース判断可能化を定める
  • コードレビュー、カバレッジ、ユニットテスト、セキュリティ、性能、etc

毎日状況を確認する

会議体2 デイリースクラム

• 開発チームは毎日、同じ場所、同じ時間に状況を確認する会議を開催する
  • 朝会など。朝に実施しなくてもいい。
    - 15分のタイムボックスで行う。延長なし。
    - 以下を簡潔に報告する
  • 前回のデイリースクラムからやったこと
  • 次回のデイリースクラムまでにやること
  • 困っていること
    - 開発チームの為の会議
  • 誰かへの報告や、問題解決の場ではない

出来あがったプロダクトを確認する

会議体3 スプリントレビュー

• 開発チームの成果物をプロダクトオーナーが確認する
• 動く環境を用意する
• スプリント毎にプロダクトが要求どおりに作られているか検査することによって、最後にまとめて確認して多くの手戻りが出るのを防ぐ。
• 1ヶ月スプリントの場合は4時間。2週間スプリントであれば2時間

もっとうまく出来るはず

会議体4 スプリントレトロスペクティブ(振り返り)

• プロセス・ツールの観点で今回のスプリントを検査する
• うまく行ったこと、改善点を整理
  • 仕事のやり方を常に検査して、より良いやり方に変え続けていく
• 今後のアクションプランを決める
  • 直近のスプリントでのプロダクトの開発に関わる活動において問題がなかったか、もっと成果を出す為に出来ることがないか検査を行い、次回以降のスプリントのアクションプランを決める
• 1ヶ月スプリントの場合は4時間。2週間スプリントであれば2時間
• スプリント期間に関係なく毎週やってもいい

縁の下の力持ち

ロール3 スクラムマスター

• プロセスがうまく回るようにする
• 妨害を排除する
• 支援と奉仕をする
• 教育、ファシリテート、コーチ、推進役

スクラムチーム

• プロダクトオーナー
• 開発チーム
• スクラムマスター

まとめ

Scrumに取り組むときは、ここで説明したScrumの全体像を関係者全員が理解することが必要となる