【技術書メモ1】スクラムチームで始めるアジャイル開発 SCRUM BOOT CAMP THE BOOK
「スクラムチームで始めるアジャイル開発 SCRUM BOOT CAMP THE BOOK」を読みました！
職場でスクラム開発をしており、先輩が本を貸してくれたのがこの本を読むきっかけです！
この本は漫画を挟みながらスクラム開発について分かりやすく説明してくれているので、スクラム初心者の私でもとても理解しやすかったです♩
基礎編
アジャイル開発とは
・関係者は目的達成のためにお互いに協力しながら進める。
・利用者の反応や関係者からのフィードバックを継続的に得ながら。計画を調整する。
・計画は一度にまとめてではなく、少しずつくくる。そして実際に出来上がったものが求めているものに合っているかを頻繁に確認する。
・「事前に全てを正確に予測し、計画することはできない」という前提を意識する。
重要なもの、リスクの高いものを先に作り、重要度の低いものは後に回すことで、必要以上の時間をかけないようにする。
スクラムってなんだろう？
・要求を常に順番に並べ替えて、その順にプロダクトを作ることで成果を最大化すること。
・スクラムでは実現される価値やリスクや必要性を基準にする。固定の短い時間に区切って、作業を進める。この期間のことをタイムボックスと呼びます。？
・現在の状況や問題点を常に明らかにする。これを透明性と呼ぶ。
・検査⇨定期的に進捗状況や作っているプロダクトが正しいか、仕事の進め方に問題がないかを確認。
・適応⇨やり方に問題があったり、もっとうまくできる方法があったら、やり方そのものを変える。
・最低限のルールだけを決める。そのルールをどのように適用していくかは自分たちで決めなくてはいけない。
要求を並べ替える
プロダクトバックログ⇨製品やサービスの要件リスト。要求を抽出し、順番に並び替える
・順位の高いものから開発される。
・常にメンテナンスをして最新の並び順に保つ。
プロダクトの責任者は誰？
ロール1：プロダクトオーナー
・プロダクトのビジョンを明らかにし、周りと共有する。
・おおよそのリリース計画を定める。
・予算を管理する。
・顧客、プロダクトの利用者や経営者などのプロジェクト関係者と、プロダクトバックログの項目の内容を確認したり、作る順番や実現時期を相談したりする。
・既存のプロダクトバックログの項目の内容を関係者が理解できるように説明する。
・作られたプロダクトが要求にあっているかどうかを検査する。
⇨ つまり、要求や仕様、計画といったことに深く関係する作業を行う
ロール２：開発チーム
・リリース判断可能なプロダクトを作る
・３〜９人で構成
・上下関係はない
短く区切って繰り返す
スプリント⇨スプリント期間は固定する。（最長１ヶ月）
開発チームはこの期間の中で、計画、設計、開発、テストなどのプロダクトのリリース判断に必要なすべてのことを行う。
スプリント最終日に作業が残っていても、スプリントは終了し、期間は延長しない。
頻繁に計画する
計画は、スプリント計画ミーティングと呼ばれる。
開発する量は過去のスプリントの実績と、今後の予測を参考に決める。過去の実績のことをベロシティと呼ぶ。
第一部⇨スプリントの内容を簡潔にまとめる。これをスプリントゴールと呼ぶ。
※開発チームはスプリント計画で合意した内容を完了させることについて全力で尽くす必要はあるものの、計画したことをすべて完了させることについて約束をしているわけではない。
毎日状況を確認する
チームメンバ全員で進捗状況を確認したり、困りごとの相談を毎日実施する。
これをデイリースクラムと呼ぶ。
デイリースクラムで伝えること
・前回のデイリースクラムからやったこと
・次回のデイリースクラムまでにやること
・困っていること
出来上がったプロダクトを確認する
スプリントの最後にプロダクトオーナーがプロダクトを確認する機会を設定する。これをスプリントレビューと呼ぶ。
依頼したものと異なる場合は作業は完了していないものとし、プロダクトバックログに戻す。
・開発チームが完了できなかったプロダクトバックログの項目について説明する。
・プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する。
・プロジェクトを進める上で問題となる事項について関係者で議論する。
・現在の進捗を踏まえてリリース日や完了日を予測する。
もっとうまくできるはず
スプリントの最後はスプリントレトロスペクティブを行う。（振り返り）
縁の下の力持ち
プロダクトをうまく作れるようにプロダクトオーナーや開発チームを支えるのがスクラムマスターである。
スクラムの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守る。
スクラムマスターの役割
・分かりやすいプロダクトバックログの書き方を、プロダクトオーナーや開発チームに教える。
・プロダクトバックログの良い管理方法を探す。
・スプリント計画ミーティングやスプリントレトロスペクティブなどの会議の進行を必要に応じて行う。
・プロダクトオーナーと開発チームの会話を促す。
・プロダクトオーナーや開発チームの生産性が高くなるように変化を促す。
・仕事を進める上での妨げになっていることをリスト化する⇨妨害リスト
実践編
大丈夫だと思う見通しを立てる
・これくらいなら大丈夫だという見通しを立てる。
・ユーザーストーリーは実際に使うユーザーに何を提供して、その目的はなんなのかを簡潔に書くやり方。最初に重要な項目が漏れないようにすることが大切。
プロダクトバックログの順序
・超重要
・重要
・普通
・なくても良い
まずは大雑把に分類する
見積もりは素早くやろう⇨見積もりはあくまで推測にすぎない
時間やお金で見積もるのではなく、プロダクトバックログの項目を終わらせるためにどれくらいの量の作業があるかに注目する。
スクラムでは実際に作業をする人が最終的な見積もりをする。
作業量を考えるには、過去に実施した作業と比較する。
比較の基準になる作業は、簡単すぎてはダメ。比較対象の作業量が10倍くらいに収まるような基準になっているのが良い。
基準の見つけ方
⇨大雑把に3つに分ける
・簡単に終わらせられる
・少し大変そう
・結構大変そう
分類したら「少し大変そう」の項目を、作業の量が少ないと思う順にさらに一列に並び替える。
並んだ項目の真ん中あたりから作業が具体的にイメージできる項目を選んで、それを基準にする。
これから先のことを知っておく
ポイント⇨実現したいことそれぞれがどのくらいの作業になりそうかの単位？
ベロシティ⇨スプリントごとに終わらせることのできるポイント数
プロジェクトの先のことは以下のようにベロシティを使うと見えてくる
・絶対に必要な項目の見積もりの合計÷ベロシティ＝必要なスプリント数
・ベロシティ×期間内に実施できるスプリント数＝実現できるポイント数（どこまで実現できそうか）
確実に終わる計画を作ろう！
スプリント計画ミーティング⇨これから始まるスプリント計画を作るための活動。確実に終わらせられる計画を作る。
プロダクトバックログの中からどれを実現するかを、二段階のステップを踏んで決める。
第一部では、プロダクトオーナーと開発チームで今回のスプリントでどこまで終わらせられそうか見当をつける。
第二部では、開発チームが中心となって実際の開発作業を洗い出し、今回のスプリントで達成するプロダクトバックログの項目はどれかを決定する。
スプリントレビュー
完了の定義を決めておく。
完了の決め方
１、プロダクトオーナーがスプリントごとにどこまで終わっていてほしいかを伝える。
２、開発チームがどんな基準を設けるかを話し合う。
３、プロダクトオーナーが本当にこれでいいのかを判断する。
スクラムチーム全員が終わったと確実に判断できるようにしておかなければいけない。
問題になる前に見つける！
スプリントの期間は思っている以上に短いので、どんなに些細なことでもスクラムチーム全員で対処する。
タスクボードなどを使うと、スプリントが順調に進んでいるのかを確認できる
タスクボード⇨未着手、着手、完了でタスクを分ける
タイムボックスは譲れない！
まずはタイムボックスを守ることから始める。
・スプリントの期間は最大１ヶ月
・デイリースクラムは15分以内
・スプリント計画ミーティングは8時間以内（スプリント期間が1ヶ月の場合）
・スプリントレビューは4時間まで（スプリント期間が1ヶ月場合）
・スプリントレストロスペクティブは4時間まで（スプリント期間が1ヶ月の場合）
タイムボックスの考え方⇨制限時間を設けてその中で必要なことをやり、時間内に終わらなかったものは次のタイムボックスに回す。
実施できるスプリントの回数が決まっていれば、実現できることが可能。
プロジェクトの先を見通すためにタイムボックスは不可欠。
少し早くおわったぞ！
もし、スプリントで予定していたものが早く終わったら、プロダクトバックログを見て、次の項目に着手する。
（この時、開発チームからプロダクトオーナーに連絡をする）
ベロシティに惑わされるな！
ベロシティは先のことを考えるのに必要不可欠。ベロシティに求められるのは安定をしていること。
ベロシティを無理にあげるのはよくないが、日々の作業を工夫したり協力することによって、作業をよりうまく進めていくことが大切。ベロシティはあくまで目安。
みんなで協力して進めていく
スクラムチームが全員参加すると決められているイベント
・スプリント計画ミーティング
・スプリントレビュー
・スプリントレトロスペクティブ
ユーザーストーリー
フォーマット
＜どういったユーザーや顧客＞として
＜どんな機能や性能＞が欲しい
それは＜どんなことが達成したい＞ためだ
このフォーマットで書けば、プロダクトオーナーや開発チームでの誤解が生じにくくなる。
プロダクトバックログはこまめに手入れをする
プロダクトバックログは誰でも自由に書き込めるようにしておいて、様々な意見を取り入れていく。
・重要なことを見逃さないように順序を見直す。
・見積もりを最新にする。
・プロジェクトの進む先を整理するために順序をもう一回見直す。
手戻りをなくしていく
手戻りは実現したいことが曖昧な時に起こる。
プロダクトオーナーは、プロダクトバックログの中から直近で実現したい項目を明確にしていくことに注力する。
手戻りをなくしていくために、スクラムチームは以下のことに取り組む。
・実現したいことは先に深く理解しておく。
・決めるべき仕様を決めておく。
・技術的にどういう風に実現するといいか理解しておく。
協力をして乗り越えていこう！
スクラムではスプリント期間中に様々な作業をしなくてはならない。状況に応じて誰かがリーダーシップを取ることが大切。
そのために、スキルマップを書いてみるのも良い。
そのために以下のことを話し合ってみる。
・これまでどんなプロジェクトにいたか。
・自分が仕事をする上で大切にしていること。
・自分に期待されていることはなんだと思うか。
今度の金曜日にある会議では、この本の内容を思い出しながら出席しよう！
