SCRUM BOOT CAMPを読んで (基礎編)

読んだものをアウトプットして、さらに理解を深めようと思ってブログにしています。

今回は SCRUM BOOT CAMP です。

これはカイゼン・ジャーニーを読んで、アジャイルの知識をもっと深めようと思い読んだ書籍です。

カイゼン・ジャーニーについてもまたアウトプットしたいと思います。

この本はだいぶ読みやすくマンガも織り交ぜて工夫されており、開発を行う上で起こり得るだろう出来事に対して、スクラムを用いて解決していくという手法で書かれているので開発者にとってはすごくわかりやすいです。やや登場人物の説明などが書かれており、そのあたりは構成上仕方はないのですが、回りくどいなって印象もありますが、そのあたりはこの本の特性上仕方ないでしょう。

それでは僕が良いと思った内容をアウトプットしていきたいと思います。

目次

アジャイルってなに？？ Scrum ってなに？？

基礎編としていきなり読者の疑問を解決してくれようとしてくれてます。導入部分で概要だけでもざっくりと説明してくれているのはすごくありがたいですねっ。

• アジャイル開発とは何？？

・関係者は目的達成のためにお互いに協力しあいながらすすめる

・利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する

・一度にまとめてではなく、少しずつつくる。そして実際にできあがったものが求めているものとあっているかを頻繁に確認する

 前提としては、「事前にすべてを正確に予測し、計画をすることはできない」ということです。

• Scrum とはなに？？

アジャイル開発を円滑に実施するために、全員が一丸となって行う作業、会議、成果物を定めたものです。

特徴としては以下となります。

• 要求をプライオリティー順で並べ替えて、成果を最大にする
• 価値やリスクや必要性を基準にする
• 状況、問題点を常に明らかにし透明性を保つ
• 定期的に進捗確認やプロダクトが意図したものになっているか、仕事の進め方が問題がないかどうかを確認する。これを検査と呼ぶ。
• やり方に問題があった場合、もっとうまくできる方法があればやり方を変える。それを適応と呼ぶ。

これらの特徴があり、Scrum ではこの特徴を有している作業、会議体、成果物が定められています。

Scrum の役割、作業、会議体、成果物 

成果物 - プロダクトバックログ

・実現したい要求をリストにして並び替える。
・常にメンテナンスして最新に保つ。

Scrum ではプロダクトの要求を抽出し、順番を優先順位に従って並び替えたプロダクトバックログというリストを作成します。このリストの順番から開発を行っていきます。

役割 - プロダクトオーナー

・プロダクトのビジョンを明らかにし、周りと共有する

・おおよそのリリース計画を定める

・予算を管理する

・顧客、プロダクトの利用者や経営者などのプロジェクト関係者と、プロダクトバックログの項目の内容を確認したり、つくる順番や実現時期を相談したりする

・既存のプロダクトバックログの項目の内容を最新の状態に更新する

・プロダクトバックログの項目の内容を関係者が理解できるように説明する

・つくられたプロダクトが要求にあっているかどうかを検査する

 プロダクトバックログの作成や更新などは開発チームとともに行うこともあります。プロダクトが生み出す価値を最大化する義務もあります。プロダクトオーナーはプロダクトにおける責任者ですねっ。

役割 - 開発チーム

・リリース判断可能なプロダクトをつくる

・3人〜9人で構成する

・全員揃えばプロダクトをつくれる

・上下関係はない

開発チームで意外なのは、上下関係はないってところですかね。全員がフラットな関係です。また要求を分析する、設計する、コーディングする、サーバーを構築する、テストをする、ドキュメントを書くといった能力を持ったメンバーが開発チームには必要です。機能横断的なチームになるということですねっ。

チームがアウトプットする成果物はチーム全体の責任になります。 そのため「抽象的で自由度のある指示」でも動ける組織でないといけません。いわゆる自己組織化ですねっ。それに相対する組織がマイクロマネジメント組織です。この組織は「具体的で細かな指示」が必要となります。

開発チームはスプリントという固定の期間を区切って、イテレーティブに開発を行います。この期間の中で、計画、設計、開発、テストを行います。期間はいろいろな要素によって変動はしますが、1週間から4週間の単位で設定されることが多いです。スプリントは作業が残っていても延長はしません。残った作業は次回のスプリントに回されます。

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

スプリント計画ミーティングは二部構成で、一部ではプロダクトバックログの順位の上のものからどの項目を今回のスプリントで開発するかを検討します。

開発の量は過去の実績を参考にします。この過去の実績のことをベロシティと呼びます。

これらの決定を踏まえて、本スプリントにおける目標も決定します。これをスプリントゴールと呼びます。これにより、開発チームはなぜ本スプリントでこの項目が選択されたかが容易に理解できるようになります。ここで重要なのは開発チームはこのミーティングで合意した内容について全力を尽くす必要はあるものの、計画をすべて完了させる必要はないということです。

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

スプリントを実施するにあたって、プロダクトバックログの項目を完了させるためにさらに細かなタスクに分けます。このタスクの一覧をスプリントバックログと呼びます。

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

Scrum ではスプリント単位でリリース判断可能なプロダクトを作ることが求められます。これは何かというと、リリース判断が可能であるというものがどういうものなのかということをプロダクトオーナーと開発チームが共通の基準を持つ必要があります。その共通の基準のことを完了の定義と呼びます。何を持ってリリース判断可能かということを定めておきます。

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

開発チームの状況を毎日確認するため、15分ほどのミーティングを行います。その内容としては以下の内容を報告します。

・前回のデイリースクラムからやったこと

・次回のデイリースクラムまでにやること

・困っていること

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

 スプリントの最後にプロダクトオーナーがプロダクトを確認する機会を設定します。それをスプリントレビューと呼びます。

スプリントレビューで確認するのは動作するプロダクトであることに注意してください。

スプリントレビューでは以下について報告、議論を行います。

・開発チームが完了できなかったプロダクトバックログの項目について説明する。

・プロダクトオーナーがプロダクトの状況やビジネスの環境について説明する。

・プロダクトバックログに追加すべき項目の有無について議論する。

・プロジェクトを進めるうえで問題となる事項について関係者と議論する。

・現在の進捗を踏まえて、リリース日や完了日を予測する。 

 スプリントレビューの時間の目安は1ヶ月のスプリントであれば4時間、2週間であれば2時間となります。

会議体 - スプリントレトロスペクティブ

いわゆる振り返りです。振り返りの方法は特に決まっておらず、KPTなどを使っても問題ありません。

・プロセスやツールなどの観点で今回のスプリントを検査する。

・うまくいったこと、今後改善すべき点を整理する。

・今後のアクションプランを作る。

 スプリントレトロスペクティブの時間の目安は1ヶ月のスプリントであれば4時間、2週間であれば2時間となります。

役割 - スクラムマスター

縁の下の力持ち、スクラムマスターですねっ。プロダクトをうまく作れるようにプロダクトオーナーや開発チームを支えるのがスクラムマスターです。

・このプロセスがうまくまわるようにする。

・妨害を排除する。

・支援と奉仕をする。

・教育、ファシリテート、コーチ、推進役。

スクラムを行う上で妨害となるものを排除するのには時間のかかるものがほとんどだと思います。そのためプライオリティーを決めて排除するために管理しておく必要があります。そのリストを妨害リストと呼びます。 

またプロダクトオーナー、開発チーム、スクラムマスターを合わせて、スクラムチームと呼びます。

おわりに

ざっくりと基礎編に書かれているものをまとめてみました。ここに書かれていることでスクラムについての概要は理解できますし、実施することも可能だと思います。

ただスクラムを実施するには問題が起きたときの対処方法や、想定外のことが起きた場合の対応などや会社の体制などによりスクラムからどんどんと離れていき、なんちゃってスクラムになります。

SCRUM BOOT CAMP ではそのあたりのことを実践編として具体例をあげて説明してくれています。

また機会があればそのあたりの要点もまとめたいと思います。