BOOK IT  ビジネス書

【要約】SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発|本のまとめ。

次の方を対象にしています!


SCRUM BOOT CAMP THE BOOK」を参考に説明します。


参考: SCRUM BOOT CAMP THE BOOK


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

SCRUM BOOT CAMP THE BOOK 要約|スクラムってなに?。まとめ

ソフトウェアを効率よく開発するためにアジャイル開発があります。


次の特徴です。

  • 関係者は目的の達成のためにお互いに協力しながら勧める
  • 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届けて評価を繰り返す
  • 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する



詳しくはアジャイルソフトウェア開発宣言を見てください。アジャイル開発とはなにか単一の開発手法ではなく、様々な開発手法に共通した価値観や行動原則に名前がついたものです。


主にスクラム、エクストリーム・プログラミング、カンバンがあります。共通するのは事前にすべてを予測し、計画できない、ということを前提にしている点です。アジャイルでは最初にコストをすべて見積もるのではなく、どのくらいの期間や人数かを决めて、その範囲内で大事な要求から順番にプロダクトを作っていきます。

スクラムとは?

スクラムには以下の特徴があります。

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



5つのイベント、3つのロールと、3つの作成物

  • イベントは「スプリント」「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ」
  • ロールは「プロダクトオーナー」「開発チーム」「スクラムマスター」
  • 作成物は「プロダクトバックログ」「スプリントバックログ」「インクリメント」


ひとつずつ説明します。

プロダクトバックログ(作成物)

スクラムでは機能や要求、要望により必要なものを順番に並べたプロダクトバックログというリストを作成します。プロダクトバックログはプロダクトにつき1つです。


常にメンテナンスして最新に保ちます。項目の追加・削除や順番は定期的に見直します。上位の項目は見積もりをします。順番は実現したときに得られる価値やリスクで决めます。

プロダクトオーナー(ロール)

プロダクトバックログの管理の責任者がプロダクトオーナー(PO)です。1プロダクトにつき1人です。そのプロダクトが生み出す価値を最大限にする責任があります。


プロダクトバックログの管理の他に、ビジョンを明らかにして共有したり、リリース計画を决めます。予算や、顧客や組織の調整と共有も役割です。

開発チーム(ロール)

プロダクトバックログの項目を順番に開発してきます。人数は3〜9人です。プロダクトを作るために必要なすべての作業が行える必要があります。コードを書き、インフラを用意し、ドキュメントを整えます。機能横断的なチームと言えます。逆に分析など1つのことしか出来ないチームは作りません。開発チーム内はメンバーの合意のもとで進めていきます。外部から仕事の進め方を指示されることはありません。

スプリント(イベント)

スプリントは最長1ヶ月までの固定の期間に区切って、繰り返し開発をします。この固定期間をスプリントと呼びます。この期間の中で、計画、設計、開発、テストなどプロダクトバックログ項目を完成させるに必要な作業を行います。


スプリントは固定に区切るので1〜4週間になります。また最終日にスプリントの作業が残っていてもスプリントは終了し延長はしません。状況によりスプリントが意味をなさない場合は中止がありえます。

スプリントプランニング(イベント)

まずスプリントで何を達成するかを决めます。対象となるプロダクトバックログの項目を選びます。バックログの個数や時間配分はチームの状況によって変えます。スプリントの目標を决めたら、それをスプリントゴールと呼びます。


バックログの項目の中身を具体的にし、疑問点を解決し、ゴールを明らかにする、自分たちが扱えるサイズに分割し、見積もる、これからの一連の流れをプロダクトバックログリファインメントと呼びます。略してリファインメントとも言います。


次に実行計画を立てます。個々のタスクは1日以内で終わるように分割していきます。スプリントバックログを検討した結果、プロダクトバックログの項目を完成させるのが難しい場合は、プロダクトオーナーと相談します。

インクリメント(作成物)

インクリメントはこれまでのスプリントでの成果と現在スプリントで完成したプロダクトバックログ項目を合わせてものを指します。スプリント終了時点で完成していて正常に動作しなければなりません。「完成」の定義はプロダクトオーナーと開発チームで認識をあわせる必要があります。

完成の定義は次のようなものです。

  • コードレビュー
  • チェックイン
  • ユニットテスト
  • カバレッジ85%
  • 結合テスト
  • 受け入れテスト
  • クロスブラウザ
  • 静的解析
  • ドキュメント
  • 性能
  • セキュリティ
  • デプロイ


デイリースクラム(イベント)

デイリースクラムは開発チームの人数に関係なく、15分間のタイムボックスで行い延長はしません。次の3つの質問に答える形で進めます。

  • スプリントゴールの達成のために、自分が昨日やったことはなにか?
  • スプリントゴールの達成のために、自分が今日やることはなにか?
  • スプリントゴールを達成するうえで、障害となるものがあるか?


スプリントレビュー(イベント)

スプリントの最後にプロダクトオーナー主催で成果をレビューするイベントを行います。成果物(完成したもの)を関係者にデモする形です。


フィードバックを得て、プロダクトバックログを見直し、全体の進捗や残作業を確認します。次のことを議論すると良いでしょう。

  • スプリントで完成しなかったプロダクトバックログの項目について説明する
  • スプリントでうまくいかなかったことや直面した問題点、解決した方法について議論する
  • プロダクトオーナーがプロダクトの状況やビシネスの環境について説明する
  • プロダクトバックログに追加すべき項目の有無について議論する
  • プロダクト開発を進めるうえで問題となる事項を議論する
  • 現状の進捗を踏まえて、リリース日や完了日を予測する


スプリントレトロスペクティブ(イベント)

直前のスプリントでプロダクト開発に問題がなかったか、もっと成果を出すためにできることがないか検査し、次のアクションを决めます。


改善をし、バグを生まれるプロセス自体を見直します。人、関係、プロセス、ツールを検査し、うまくいったことを整理します。一度にたくさん変更しようとしないことも大切です。

スクラムマスター(ロール)

スクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、スクラム外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守るのがスクラムマスターです。

  • スクラムがうまくまわるようにする
  • 妨害の排除
  • 支援と奉仕
  • 教育、ファシリテーター、コーチ、推進役
  • マネージャーや管理者ではない(タスクのアサインも進捗管理もしない)


スクラムの5つの価値基準があります。

  • 確約:ゴールの達成に全力を尽くす
  • 勇気:正しいことをする勇気を持ち、困難に立ち向かう
  • 集中:全員がスプリントでの作業やゴールの達成に集中する
  • 公開:すべての仕事や問題を公開することに合意する
  • 尊敬:お互いを能力ある個人として尊敬する


き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

SCRUM BOOT CAMP THE BOOK 要約|どうやればうまくいくの?。まとめ

プロダクトオーナーは誰だ?

プロダクトオーナー、開発チーム、スクラムマスターはロールです。人選はそのロールを一生懸命やってくれる人です。スキルが足りない場合は、どのように補えるかも考えてみましょう。


またロールは肩書とは別ものです。部長だからプロダクトオーナーという訳ではありません。ロールは単なる目印です。ただスクラムマスターとプロダクトオーナーは方向性が違うため兼任はしません。

どこに進んでいくのか?

スクラムで開発を進めるために「どういうことを実現するのか(ゴール)」と「絶対に達成したいことはなにか(ミッション)」を明確にしておく必要があります。


ゴールとミッションに深く関係しているのはプロダクトオーナーで、達成するためにプロダクトバックログを管理します。


開発を始める前に必要な活動を明らかにするインセプションデッキがあります。インセプションデッキは https://github.com/agile-samurai-ja/support/tree/master/blank-inception-deck にサンプルがあります。みんなで話し合い、これは何ができるの?誰に向けたものなの?利点は?などを話し合いながら明確にしていきます。

いつ頃終わるの?

プロダクトバックログを見ることで、最初のリリースでどこまで含められそうか、いつ頃までかかりそうかが分かっている。


たとえばプロダクトバックログの単位としては「ログイン機能」「営業日報入力機能」「取引先検索機能」などがそれに当たる。目的や詳細も忘れずに書こう。


様々な視点で考え、重要な項目が漏れていないことを確認しましょう。漏れなく出し終えたら重要なものから優先順位をつけていきます。「超重要」「重要」「普通」「あればうれしい」のような大雑把な順位をつけて、直近は詳細な順位で整理していきます。

正確に見積もれません?

作業の量を確認します。自分たちが実際にやるとして簡単そうか、難しそうか、などを基準にします。似たような作業は同じような難易度にし、最終的に数値で表わせば、それが見積もりになります。


これが分かればリリースに必要な工数と、必要なスプリント回数がでます。数値にするときは普通のタスクを5としたら、簡単なら3、難しければ8のように决めます。


大事なのは素早く見積もることです。あくまで推測なので、どれだけ時間をかけても正確にはなりません。

見積もりをより正確にする

見積もりは不確実であいまいなものと理解した上で、開発チームが自分たちで見積もる必要があります。メンバーの見積もり数値を見た上で話し合い、数値を明確にしていきます。

この先の計画を立てる

スクラムでは、プロダクトバックログの項目を見積もれば、先のことも考えることができる。実現したいことが整理されていて、それがどのくらいの作業量か見積もれているからです。


たとえば全部200ポイント必要だとして、1回のスプリントで20ポイント消費できるなら、10回のスプリントが必要だと分かります。1回のスプリントが1週間であれば10週間になります。1回のスプリントで消費できるポイントをベロシティと呼びます。


開発をはじめる前にどのくらいのベロシティか分からないときは、過去の実績を利用します。同じような作業をしたことがあるなら、その経験を元に考えます。


またダメなパターンとしては期限が決められているので、それに合わせてポイントを割り振ってしまうことです。これでは現実と乖離してしまい、プロジェクトを進めるのは難しいでしょう。


先の見通しを立てる活動はリリース計画とも呼びます。リリース計画は何度も見直していきます。計画当初は予想にしかすぎないので、進むにつれて調整していきます。


詳細な計画を立てる

スプリントプランニングでは2つ話し合う「このスプリントで何ができるか?」「どのように達成するか?」


「このスプリントで何ができるか?」はプロダクトオーナーが今回のスプリントで達成したいことをプロダクトバックログを見ながら開発チームに伝えます。プロダクトバックログは達成したことの順番に並んでいるので、上からどこまでを実現してほしいかを伝えます。


どのくらい実現できるかの目安にいなるのがベロシティです。次に「どのように達成するか?」を明らかにします。資料やホワイトボードで認識があっているか確認しながら具体的な内容を確認します。不安や疑問点もこのときに確認します。


スプリントプランニングでは確実に終わらせられる計画を作ります。そのためタスクの洗い出しと見積もりは確実にします。疑問や不安がない状態です。

素早くリスクに対応する

問題がないかを検査します。デイリースクラムを15分おこない。不安や疑問を解消していきましょう。1日1回、同じ時間に同じ場所で行います。時間の延長はしません。確認する内容は次の3つ。

  • スプリントゴールを達成するために昨日やったこと
  • スプリントゴールを達成するために今日やること
  • スプリントゴール達成の妨げになる障害や問題点


15分で決着がつかない場合は、一度切り上げて、別でミーティングを設定します。

状況をうまく把握する

スクラムでは透明性を大切にします。問題になりそうなことを個人で抱えず、すぐに共有することで全員で対処していきます。問題はチームで見つけ、チームでかいけつしていきます。


スプリントバーンチャートというのを容易してタスクと残り時間が順調に減っているか確認するのも良いでしょう。

何が完成したかを明らかにする

スプリントは、スプリントレビューとスプリントレトロスペクティブの2つのイベントを開催して終わります。


スプリントレビューは、今回のスプリントで完成したものと今後について明らかにしていくイベントです。スプリントレトロスペクティブは今回のスプリントでの作業の進め方を確認して、次のスプリントをよりうまく進めるために用意されています。要は振り返りです。


完成の定義は次のものです。

  • デモ手順の通りに動作する
  • publicメソッドのテストコードがある
  • 調査した内容はwikiにまとめてある
  • 最新の仕様がwikiにまとめてある
  • リポジトリからいつでも最新のデモ可能でテスト済みのソフトウェアが取得できる


完成の定義はスクラムチームで合意をとります。完成の定義があいまいだと人により、できたものに差ができてしまいます。バグはあるけど動く状態のものを完成としてしまったり。

先を予測しやすくしておく

タイムボックスはかならず守るようにしましょう。

  • スプリントの期間は1ヶ月以内
  • デイリースクラムは15分以内
  • スプリントプランニングは8時間まで(スプリント期間が1ヶ月の場合)
  • スプリントレビューは4時間まで(スプリント期間が1ヶ月の場合)
  • スプリントレトロスペクティブは3時間まで(スプリント期間が1ヶ月の場合)


スプリントの期間は一定なので、タスクがあと少しで終わりそうであっても延長はしません。その期間で終わるか終わらないかも含めて今後の予測に使えます。調整してタイムボック内で収まるように調整していくのです。

次にやることを明確にする

スプリントが早く終わったらリファクタリングや自動テストなど普段できてないことを進めるのが良いでしょう。またプロダクトバックログは順番に進めていくため順序がとても大事になります。


状況は常に変わるので、プロダクトバックログも頻繁に更新されます。そしてプロダクトオーナーは順番を決定していきます。

自立を促していく

デイリースクラムはルールを守ることが大事です。


デイリースクラムのルールの例

  • デイリースクラムは11時から行う
  • タスクボード前で行う
  • 重要な連絡事項はボードに書いておく
  • 欠席の人は、夕方に追加で報告する場を用意する
  • 15分悩んだら誰かに相談する
  • 5分前には会議室にいく


振り返りを楽しくするためのコツは「お菓子を用意する」「少しでもうまく行ったところを見つける」の2点です。

ベロシティを上げていく

良いスクラムの場合はベロシティが安定する。先週20ポイント消化、今週19ポイント評価のように。悪いベロシティだと先週50ポイント消化、今週3ポイント消化のように不安定になります。


ベロシティが安定しないと先の予測ができません。そのため安定させることが大事です。タスクの消化が遅くベロシティを上げたいと考えた場合は、何かする必要があります。さらにベロシティが上がったのなら、それを維持する必要があります。工夫したり協力したりしてベロシティを上げてみましょう。

問題を見つけやすくする

スクラムチームは「スプリントプランニング」「スプリントレビュー」「スプリントレトロスペクティブ」の3つに全員参加します。それぞれのロールで責務を全うします。ロールを分けていることで、どこに問題があるか発見しやすくなります。

意図を明確にしておく

実現したいものを伝えるのは意外と難しいものです。そこで大事なのが実際にそれを使う人の立場で表現することです。これによりプロダクトオーナーと開発メンバーと立場や考えが違っても、伝わるようになります。「○○のユーザとして、○○の機能がほしい。それは○○を達成したいためだ」で考えてみましょう。

スクラムチームを支援していく

開発を進めていくと問題にぶち当たることがあります。すぐに解決できない場合は、プロダクトオーナーと相談し、解決するためのタスクをプロダクトバックログに追加します。


たとえばプログラムが複雑化してまって修正が難しくなってしまった場合のリファクタリングなどです。うまくいってないときこそ「大丈夫?」など声を掛け合うことが大事です。またスクラムチームを良い状態に保つのはスクラムマスターの仕事です。

より良い状態にしていく

達成したいゴールを脅かすことがあれば、それは全員把握しておきましょう。全部公開してみんなで解決させていくのが良いスクラムです。


また良い状態にできない原因も管理しておきましょう。一度にすべての解決が難しい場合は、全部を書き出して一覧化することが大事です。障害にも優先順位を付けて対応していきます。

先のことをいつも明確にする

プロダクトバックログは常に最新化するため、こまめに手入れする必要があります。「重要なことを見逃さないために順序を見直す」「見積もりを最新化する」「最適な優先順位となるように調整する」。ゴールを満たすために何を実現するかを常に判断することになります。進む方向を明確にするためにも常に整理し続けることが大切です


手戻りをなくしていく

一度作ったけど実装が間違っていて、やり直しになることがあります。なぜこのような事になるかというと、実現したい内容があいまいだからです。あいまいが多いほど認識違いによる実装漏れやミスが発生します。プロダクトオーナーや開発チームに確認しながら進めましょう。


明確になってないまま着手してしまうと、今後のことも見えなくなってしまいます。見積もりやベロシティにも関係しているため、あいまいを排除していきましょう。まずは目の前のスプリントが明確になっているかを確認しましょう。また大きな手戻りはちょっとした工夫で防げます。

  • 実現したいことは先に深く理解しておく
  • 決めるべき仕様を決めておく
  • 技術的んいどういうふうに実現するといいかを確認しておく


ゴールに近づいていく

ゴールに近づくためにはスクラムチームの仕事の進め方をよくすること。次に何かを調整することです。調整するものは「品質」「予算」「期間」「スコープ」です。


しかし品質は調整できません。機能によって品質に差があってはいけません。


予算は人件費だったり開発環境や本番環境や運用のコスト。予算が取れるかは重要な項目となります。期間も決められていなければ変えることはできるでしょう。しかし、展示会の日が決まっていたり、期日が決まっている場合は変えるのが難しい場合もあります。


スコープはどうだろうか、もしかしたらゴールを達成する別の方法があるかもしれない。これもスコープの調整に含まれる。また本当は実現してなくても良い機能が含まれているかもしれない。同実現するかを調整するのもスコープの調整です。

さまざまな状況に対応する

メンバーどのようなことができるのは把握しておきましょう。一人が得意な作業だけをやってもダメで、みんなで協力しながら進めていくのが開発チームです。

より確実な判断をしていく

大切なのは失敗から学んでいくことです。そのためにある程度、失敗を許容することが必要です。

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

リリースに必要な作業は「リリースを満たす基準 - 完成の定義」です。リリースするためにはドキュメントが揃っていたり、負荷試験を行ったりと作業がいくつもあります。リリース用の作業をするスプリントを作ることもあります。しかし、できればリリース用のスプリントを作らずとも、いつでもリリースできるように進めるのが理想です。

参考: SCRUM BOOT CAMP THE BOOK


\ 聞き流せる本!Audilbe無料体験期間中 /

好きな本が聴き放題!アマゾン Audible 30日間 無料体験を試す

>> 詳しく知りたい方へ!Audibleで無料で本を聴く方法を徹底解説

  • この記事を書いた人

おやすみドリー

本の要約をする人 | 年間100冊は本を読む | Audible(オーディオブック)、kindle(電子書籍)など読書方法を紹介 | 良い本をたくさんの人に届けたい | ビジネス書・マーケティング・自己啓発・小説を幅広くインプット | ビジネス関連・忘れない読書方法・文章の書き方なども発信中

-BOOK, IT,  ビジネス書