スクラムとは

概要

• 変化に対し柔軟に開発を運用するためのアジャイルフレームワーク

• 開発に常に優先度をつける

• 仕事を進めることを主眼に考え、そのために改善を常に行う

• ロールが3つあり、協調しあい開発する

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

• POが満足するアウトプットがあったかのみを検証

• 5つのイベントがある（後述）

• 2つのアウトプット（成果物）がある（後述）

特徴

• 非常にシンプルなフレームワーク

  • 定められたルールが他の手法より少なくアレンジが容易

• 実践的で経験主義

• 世界的に普及している

アジャイル開発とは

アジャイルとスクラムの違い

スクラムとはアジャイル開発手法のひとつ

他にもXPとかがある

アジャイルソフトウェア開発宣言

ここ にいろいろな言語で宣言されています

この宣言では以下のことを重要視している

• 個人と対話
• 動くソフトウェア
• 顧客との協調
• 変化への対応

スクラムとウォータフォールの違い

• ウォータフォール

  • 計画、設計、実装、テストが一方向に進む
  • リリース直前の実装や仕様に漏れがあると最悪の場合プロジェクトがぽしゃる
  • 運用・保守には強い。新規案件向けではない

• スクラム

  • 開発期間中に計画、設計、実装、テストのリサイクルを何度も回す
  • 細かいスパンでリリースするので、大きな手戻りが少ない

スクラムで登場するロール（役割）

あくまでテンプレの内容を紹介

自分のチームに合わせて変えてOK（むしろカスタマイズすることが重要）

プロダクトオーナー（PO）

• 役割

  • プロダクトのビジネス価値に責任を持つ
  • リリース判断をすることができる
  • 優先度の判断役

• 求められる力

  • 情報アウトプット（見える化、透明性） → 実現したいことをちゃんと伝える力
  • クライアントとチームを繋ぐハブ役

スクラムマスター（SM）

• 役割

  • スクラム開発に関わる全ての人を支援し、成功に導く
    • POのビジネス的な相談を受けたり、開発チームの技術的な相談を受けたり などなど
  • スクラムの理論や価値を関係者全員に教え、理解してもらう
  • 開発チームへの障害や外部干渉を取り除き、防ぐ

• 求められる力

  • サーヴァントリーダシップ（奉仕型リーダー）
    • 下からみんなを持ち上げるようなリーダー
  • 理解と実行の話づくりと良きファシリテーター

SMが開発に加わるのはOK？

チームが良しとするならばOK。

はじめから参加することは基本的にない。

開発チーム

• 役割

  • 具体的な開発を遂行
  • リリース可能なプロダクトバックログアイテムを完成させる
  • 何をどのように作るか決定する（POは実現したいものを言うが、どうやって作り上げるかは開発チームに委ねる）

• 求められる力

  • 主体性と協調性（ただ作るだけの存在にならない） → 受注体質はだめ
  • 仮説や知識を理解し、サービス価値向上の施策を立案する

関係図

ランダムロールってうまくいく？

ランダムロール：SMがおらず、スプリントごとにランダムにロールを決定すること

ランダムロールは難しい。各ロールを理解が出来ていることが重要。

全員が「ロールの役割をチーム内で合意できている状態」になっていることが重要。

見切り発車は危険。チームが成熟しているとうまくいきそう。

スクラムは「イベント」で構成されている

定義

イベントとはスプリント内に規則性を作り出すためのタイムボックスのこと

→ 定義されていないMTGの必要性を最小限にできる

目的

進むべき方向が間違っていないかを確認する

イベントの種類

以下5つのイベントがある。

1. スプリントプランニング

• 達成できるプロダクトバックログアイテムを約束する

• 開発チームとSMでやり、POに報告する

• 何をどのように作るか、どういう状態をゴールとするか決定する

• チーム全員が同意していることが大事

• 二部制で実施

  • 第一部：何を作るか 検討
    • どのくらいできるか
    • どれをやるか
  • 第二部：どう作るか 検討

2. デイリースクラム

• 開発チームが毎日やる短い打ち合わせ

  • 15分以上やってはいけない

• スプリントゴールとバックログの進捗の検査を行う

• 現在のスプリント終了までに期待される成果物を作成できるのか毎日把握しなければいけない

• 内容は開発チームが設定し、質問ベースで会話したり、議論ベースで会話してもよい

• POとSMは参加しない

  • 参加すると、開発チームからPO、SMに報告する場になってしまうから、開発チーム内での議論が弾まなくなる。 ただし、スクラム初心者のチームに関してはSMがファシリテーターとして参加することもある。

• デイリースクラムは問題解決の場ではない

  • この場では「こういう問題が発生した」という障害となる事柄を伝えるだけにする（その後当事者を集めたりしたらいい）

3. リファインメント

• POによるプロダクトバックログアイテムの詳細化と優先順位の見直しや調整を行う

• POと開発チームが参加し、ロードマップやサービスビジョンからプロダクトバックログアイテムの作成する

  • 新しく増えたプロダクトバックログアイテムの優先度見直して、全体の並び替えを行う

• 時間は未定で、チームで決める

4. スプリントレビュー

• スクラムチームとステークホルダーが強力し、成果物の検査・適応をする

• 開発チームがPOとステークホルダーに対して、完了した成果物のデモを行い、イベント参加者からの質問に答える

• リリースするかどうかPOの判断に一任され、そこで出た不具合や新たな要求はプロダクトバックログに追加される

• 大事なことは動くものを見せること。そして、素直に話すこと（機能改善などについて思ったことを素直に話す）

5. レトロスペクティブ

• 日本語にすると「振り返り」

• スプリントの検査を行い、改善計画を立てる

• 反省会ではないことを意識する。

  • 反省会：悪かったことを言うだけで、次の行動を決めない状況

• 会話から出た項目に関して、その結果を確認するためのアクションを洗い出し、次回のスプリントバックログに含めなければいけない。

スクラムにおける成果物とは

プロダクトバックログ（PBL）

定義

優先順位が決められた要求事項（プロダクトバックログアイテム（PBLI））が集まって一覧化されたもの

責任者

POが責任を持つ

ライフサイクル

★調べて追記する予定

スプリントバックログ（SBL）

定義

スプリントにおける開発チームのしごとを定義したタスクリスト

責任者

開発チームが責任を持つ

ライフサイクル

スプリントの間だけ存在する（スプリントごとに更新される）

まとめ

スクラムはあくまでフレームワークである。

銀の弾丸ではない。