スクラムについて

上記2冊を読みスクラムに関するまとめ

スクラムとは

スプリントと呼ばれる固定された期間を何度も繰り返し、その中で設計・開発・テスト・デリバリー(提供)などを実施し、価値あるプロダクトをムダなく構築していくフレームワークのこと。

原則

イテレーティブ（反復的）

• 間違いや失敗が起こった後でなければ正解は分からないという前提
• 計画的な手戻り戦略により優れたソリューションを目指す

インクルメンタル（漸進的）な開発

• 少しずつ作ることで短期間の間にフィードバックを受け、手戻りのコストを最小限にする

スクラムのイベント

主に5つある

スプリント

繰り返される開発期間のこと。通常は1カ月以下で設定する。

スプリントプランニング

スプリントで何を実施するかの計画ミーティング

デイリースクラム

スプリントのゴールを達成すべく、日々の進捗や優先順位、障害などを確認する。
毎日同じ時間・場所で実施する15分以内のミーティング。同じ目的のミーティングとして朝会があるが、デイリースクラムは朝の実施を必ずしも前提とはしない

スプリントレビュー

スプリントの終わりに作成物をレビューしてフィードバックをもらうミーティング

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

プロセスなどを検査し、カイゼンするためのミーティング

ロール

主に3つある

プロダクトオーナー

プロダクトの価値の最大化に責任を負う

• プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。ただしその作業は、組織・スクラムチーム・個人によって大きく異なる。
• プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。
• プロダクトバックログの管理には、以下のようなものがある。
  • プロダクトバックログアイテムを明確に表現する
  • ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
  • 開発チームが行う作業の価値を最適化する。
  • プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を示す。
  • 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。
• 上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
• プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロダクトオーナーと相談しなければいけない。
• プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの意見を尊重しなければいけない。
• プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。
• 開発チームに作業を依頼できるのは、プロダクトオーナーだけである。
• 開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない。

開発チーム

自己組織化された専門家集団

• 開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。
• インクリメントを作成できるのは、開発チームのメンバーだけである。
• 開発チームは、自分たちの作業を構成・管理する。そのことは組織からも認められている。その相乗効果によって、開発チーム全体の効率と効果が最適化される。
• 開発チームには、以下のような特徴がある。
  • 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
  • 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
  • ある人にしかできない作業があったとしても、メンバーの肩書きは開発者だけである。このルールに例外はない。
  • テスティングやビジネス分析のような領域であっても、スクラムは開発チームのサブチームを認めていない。このルールに例外はない。
  • 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。

スクラムマスター

チームが成果を上げるために支援・奉仕する

• スクラムマスターは、スクラムの理解と成立に責任を持つ。
• そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。
• スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。
• スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。
• スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。

スクラムマスターはプロダクトオーナーを支援する

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。

• 効果的なプロダクトバックログの管理方法を探す。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 経験主義におけるプロダクトプランニングについて理解する。
• 価値を最大化するためにプロダクトバックログを調整する方法を知っている。
• アジャイルを理解・実践している。
• 必要に応じてスクラムイベントをファシリテートする。

スクラムマスターは開発チームを支援する

スクラムマスターは、さまざまな形で開発チームを支援する。

• 自己組織化・機能横断的な開発チームをコーチする。
• 開発チームが価値の高いプロダクトを作れるように支援する。
• 開発チームの進捗を妨げるものを排除する。
• 必要に応じてスクラムイベントをファシリテートする。
• スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。

スクラムマスターは組織を支援する

スクラムマスターは、さまざまな形で組織を支援する。

• 組織へのスクラムの導入を指導・コーチする。
• 組織へのスクラムの導入方法を計画する。
• スクラムや経験的プロダクト開発を社員や関係者に理解・実施してもらう。
• スクラムチームの生産性を高めるような変化を促す。
• 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。

スクラムチームの作成物

プロダクトバックログ

実装するプロダクトの要求、要望、機能の一覧。一覧の一つひとつをプロダクトバックログアイテムと呼び、詳細や見積もりなどを記載

スプリントバックログ

プロダクトバックログからスプリント期間内で作成すると決定したプロダクトバックログアイテムとその作業リストの一覧

インクリメント

動作するプロダクト

スタンス

透明性、検査、適応を重視

透明性でスプリントの情報や状況を見える化し、共通認識を得ることを助ける。
そして、チームやプロダクト、プロセスの状態を常に検査して、問題をいち早く検知する。
問題が発生したらカイゼン案を検討し、問題解決に向けて適応する

イベントやロールはあくまで切り口や目印である。
メンバーの状況に応じて目的理解のあるものが行動を実現すれば良い。

経験を元にカイゼンしていく経験主義
不確実な状況においても漸進的に物事を進めていくという考え方。
各工程の成果物ベース
ウォーターフォールとは、概念が異なる

書籍情報

市谷 聡啓, 新井 剛, カイゼン・ジャーニー
https://amzn.to/2sRNCqA

JonathanRasmusson, 西村直人, 角谷信太郎 アジャイルサムライ
https://amzn.to/2RXHso3

雑感

全てをアジャイルにすべきでもなく、上流の一部などはウォーターフォール的に、実装フェーズ辺りはアジャイル的にというやり方も良いと思う