読書メモ 「Scrum Boot Camp The Book」

初めに

妹『アジャイル開発って知ってる？』

姉「モンハンのオトモに委託する開発方法だっけ」

妹『それはアイルー開発』

姉「なんかスクラムとかって聞いたことあるかも～」

妹『それそれ！私たちもスクラムを導入したいなーって思って』

姉「おっけ～！じゃあ体鍛えておくね！」

妹『ラグビーは関係ないよ？』

姉「わかってるよ～！私のことバカちんと思ってない～？」

妹『あわわ、ごめんね！それでね、買っておいてほしいものがあるの！』

姉「アメフトボールだよね」

妹『Scrum Boot Camp The Book だよこのバカちん！』

目次

1. 参考文献
2. Scrum Boot Camp The Book 感想
3. 姉メモ

参考文献

• SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

Scrum Boot Camp The Book 感想

姉「読み終わったよ～。メモしながら読んだらすごく時間かかっちゃった～」

妹『おつかれさまー！感想聞いてみてもいい？』

姉「とにかく1度スクラム開発やってみたいな～って」

妹『おっ！』

姉「チームとして成長していけるフレームワークっていうのがすごくいいなって思ったの」

妹『だよね！私も読みながら、こんなチームで開発したいなーって思ったもん！』

姉「実践編が漫画・対話形式で導入してくれるからすごく読みやすかったな～」

妹『最初の基礎編だけだとイメージしづらいけど、実践編読むと一気に明瞭になるよね！』

姉「一度読んでおけば、いつか実際やるときに基礎編だけ読み返せばだいたい思いだせそう」

妹『基礎編だけなら量も少ないもんね。下手なメモとか読み返すよりよっぽどいいよね！』

姉「あとはボク君とキミちゃんの恋路の行方が気になるな～って」

妹『あーわかる！出てくる登場人物なにげにいいよね！』

姉「最後にボク君とキミちゃんがカフェに向かう途中、急に大雨が降ってくるの」

妹『ん？あれ？そんなシーンあった？』

姉「雨宿り先に飛び込んだ建物。そこはネオンライトが怪しく光るホテルだった───」

妹『あー始まっちゃった』

姉「ちょっと薄い本書いてくるね～」

妹『まってやめて』

姉「R-18」

妹『やめろ！！！』

姉メモ

姉「見てみて！めっちゃメモしたんだよ～」

妹『えらいえらい！』

姉「えへへ！」

妹『でも文脈が抜け落ちちゃってるから、やっぱ本の基礎編読み返すほうがよさそうかなー』

姉「ｼｭﾝ」

基礎編

• アジャイル開発

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

• スクラム開発

  • 特徴
    • タイムボックス：固定の短い時間に区切って作業を進める。
    • 透明性：現在の状況や問題点を常に明らかにする
    • 検査：進捗状況や成果や仕事の進め方を定期的に確認する
    • 適応：やり方に問題あったりもっとうまい方法があれば変更する
  • 5つの価値基準、心構え
    • 確約：それぞれゴールの達成に全力を尽くす
    • 勇気：正しいことをする勇気、困難な問題に取り組む
    • 集中：全員がスプリントでの作業やゴールの達成に集中
    • 公開：すべての仕事や問題を公開することに合意する
    • 尊敬：お互いを能力ある個人として尊敬する
  • 構成要素：
    • 5つのイベント
      1. スプリント：
         • 1週間～4週間の区切り
         • プロダクトオーナーの判断でのみ中止可能
      2. スプリントプランニング：
         • 1ヵ月のスプリントに8時間まで
         • トピック1：達成目標
           • スプリントゴールの設定
         • トピック2：目標の実現方法
           • 具体的な作業計画
      3. デイリースクラム：
         • 15分のタイムボックス（延長なし）
         • 定型はないがセオリーはある
           • 昨日やったこと
           • 今日やること
           • 障害となるものがあるか？
      4. スプリントレビュー
         • スプリントの最後に実施。1ヵ月であれば4時間まで
         • 成果物を披露し、ステークホルダーからフィードバックを得る
      5. スプリントレトロスペクティブ（振り返り）
         • 1ヵ月スプリントで3時間まで
         • うまくいったこと、改善点を整理し、今後のアクションプランを作る
         • 出たアクションプランのうち最低1つは次のスプリントで実施
    • 3つのロール
      1. プロダクトオーナー：1人
         • プロダクトのWhatを担当
           • プロダクトのビジョン
           • プロダクトバックログの管理
           • 予算管理
           • おおよそのリリース計画
           • 関係者との連携
      2. 開発チーム：3人～9人
         • プロダクトのHowを担当
           • 機能横断的なチーム
           • 肩書やサブチームはなし（自己組織化）
      3. スクラムマスター：1人
         • スクラムがうまくまわるようにする
           • マネージャーや管理者ではなく、タスクのアサインも進捗管理もしない
           • 支援、奉仕、教育、ファシリテーター、コーチ、推進役等
    • 3つの作成物
      1. プロダクトバックログ
         • 実現したいもの（≠優先度）順に並び変える
         • 常に最新に保つ
         • ユーザーストーリーという形式が多い
      2. スプリントバックログ
         • 選択したプロダクトバックログ項目と実行計画
         • プロダクトバックログを具体的な作業に分割
         • 1タスクは1日以内で終わるサイズ
      3. インクリメント
         • 過去に作ったものと今回完成したものを合わせたもの
           • 多くの場合、動作しているソフトウェア
         • 完成の定義
           • プロダクトオーナーと開発チームの共通基準
           • スプリントでどこまでやるか事前に決める
  • スクラムガイド

実践編

SCENE1：ロールを現場に当てはめる

• 一番重要なこと

  • 一生懸命に取り組んでくれる人
    • プロダクトオーナー：
      • より良いものを作れるかよく考えられる人
    • スクラムマスター：
      • よりうまく仕事を進められるようにしたいという想い人
    • 開発チーム：
      • 技術的な観点でより良い方法を常に模索できる人

• プロダクトオーナーの見つけ方

  • スキルはプラスにはなるが決定打ではない
  • 全てを備えている人はいない

• スキルが足りない時の解決

  • チームで補う
    • スクラムの知識がないなら研修に参加するなり
    • 発言力がなければ発言力の強い人の協力を要請したり
  • 熱意はチームで補えない！

SCENE2：どこに目指すのかを理解する

• スクラムチームに期待されている2つのことを知る
  • どういうことを実現するのか（ゴール）
    • 実現するものへの期待
  • 絶対に達成したいことは何か（ミッション）
    • 達成しないと開発する意味のなくなること
• インセプションデッキ
  • 上記を知るアジャイルサムライに記されたプラクティス
    • 10個の質問に皆で考えながら応える
    • 1つの質問ごとに1つのスライドにまとめる
    • 皆で話し合うという過程も、成果物と同じくらい大事。
  • 作り方
    • 誰かがたたき台を作る
    • 集まって話し合いをする
  • 注意点
    • 制限時間。1枚長くても1時間半。
      • 時間を越えるならたたき台が弱い可能性高い
    • 意見がでなければ、まず全員に付箋に書いてもらうなど

SCENE3：プロダクトバックログを作る

• プロダクトバックログとは
  • 実現したいことが全て書かれている一覧
  • フォーマットの詳細は定まっていない
    • ほしい機能を列挙したもの
    • ユーザーストーリー形式
• 最初に作るときの注意事項
  • 大きな漏れをださない
    • １つのやりかた：スクラムチーム皆で項目を付箋に出す
  • 項目の順番はスクラムチームで決める
  • 項目を大雑把に、超重要、重要、ふつう、などに分ける
  • 縦に並べる際、直近のものは詳細に。
  • 開発を円滑に進められる機能が重要になることもある
  • あとからプロダクトバックログに追加なども逐次していく
  • 逐次プロダクトバックログは更新をしていく

SCENE4：見積もりをしていく

• 見積もりの前提

  • 詳細に見積っても、ズレが生じる

• 見積もりのポイント

  • 素早く
    • まずおおざっぱに分類する
    • S M L など
  • 相対的に
    • 上記Mの中で中央付近の、詳細がわかるタスクを基準とする
    • 基準タスクと比べて、各タスクに数値を振る
    • 振る数値は、フィボナッチ数を使用することが多い
  • 直近だけ詳細に
    • 直近数スプリントは詳細に見積もる
    • 未来になるほど無駄になる可能性が高まるので詰めない
  • 作業量で見積もる
    • ポイント等といった、時間等とは違う作業用の単位を振る

• 注意点

  • 基準タスクは簡単すぎてはいけない
    • 重いタスクが100倍などになり、把握しづらくなる
      • 開きが10倍ぐらいがちょうどよさげ
    • 基準が適切でなければ基準タスクを見直すべき
      • 無理に見積もっても意味がない

SCENE5：見積もりをより確実にする

• 見積もりポーカー
  • 利点
    • 開発チームの皆の意見を組みやすい
    • 全員の目を通るから様々な観点で見れる
    • 素早い見積もりが可能
    • ゲーム感覚で前向きに取り組める
  • ポイント
    • 数字がずれたら、理由を話し合って最終的に数値を決める
    • 疑問が解消されず見積もれないなら無理に数字を入れない
      • 重要な項目の場合、多少時間かけても疑問をなくすべき
    • 全員一緒でも1人くらい話したほうが良い（ズレの確認）
  • 注意点
    • 話し合いが長くなりすぎないように注意
    • 1人の声が大きい人ばかりの発言になるのはよくない兆候
      • アドバイザーになってもらい抜けてもらうなどする

SCENE6：この先の計画を立てる

• リリース計画
  • 期間の見積もったり先の予想をすること
    • ベロシティとプロダクトバックログの総ポイントから算出
  • ベロシティ
    • スプリント内で消化できるポイント数
      • 実際にスプリントで計測するのが一番よい
  • 絶対ごまかさないこと
    • スクラムの見積もり内で唯一確実な数字
  • 開発の始まる前の見積もり方法案
    • 過去のベロシティを参考にする
    • 数ポイント分先にやり、その期間からベロシティを算出
    • 開発チームに判断してもらう
  • 注意点
    • ベロシティでもわからないこと
      • リリース関連
      • 重要な予定や夏季休暇等のイベント
  • 対処法
    • リリースを別出し（リリーススプリント）
    • マイルストーンとして重要な予定を記す
      • その図を見える位置に置いておくとよい
  • リリース計画は何度も見直すもの

SCENE7：詳細な計画を立てる

• スプリントプランニング
  • トピック１：このスプリントで何ができるか？
    • メイン：プロダクトオーナー
    • プロダクトバックログを元にどこまでやるか決める
      • 量はベロシティを参考
      • どうなったら終わりかも決める
  • トピック２：どのように達成するか？
    • プロダクトバックログの項目をタスクに分解する
    • タスクの見積もりは時間単位が多い
    • タスクは１日以内に終わる量にする
    • １日は５～６時間程度を目安
      • 理想時間（会議や開発以外に使う時間を除いた時間）
  • 成果物：スプリントバックログ
    • 洗い出したタスクと見積もり時間をまとめたもの
• 重要事項
  • スプリントゴールの認識合わせ
    • スプリントの目標
    • 複数の項目で実現したいことを端的に表したもの
  • 実現出来たか判断するための方法の事前設定
    • デモ手順を決めておく
    • 受け入れ基準を決めておく
  • スクラムチーム全員が、確実に達成できると思う詳細な計画
  • 認識合わせは重要。この話し合いに時間を割くチームも多い
  • スプリントで扱うプロダクトバックログの項目が多いと大変
    • スプリントゴールがわかりづらくなる
    • タスクがうまく洗い出せなくなる
    • ここまでなら確実に達成できると確信持てる数に絞る

SCENE8：素早くリスクに対処する

• デイリースクラム（朝会）
  • 毎日15分、同じ時間、同じ場所で行なう会議
  • 多くのチームは立ったまま行う
  • 主体は開発チーム
  • 目的は検査。
    • 少しでも問題が起きてないか確認し、必要なら見直し。
  • 以下の3つの質問に応える形が多い
    • スプリントゴールを達成するために昨日やったこと
    • スプリントゴールを達成するために今日やること
    • スプリントゴールを達成の妨げになる障害や問題点
• ポイント
  • デイリースクラム前に、何を話すか考えるよう声かけなど
• 注意点
  • 誰かへの報告会になってたら要警戒
  • 報告会にはなりがち
    • 問題に気づきやすい質問をしてあげたりする
      • なぜ自分に向かって報告するのか？
      • その作業はあとどれくらいで終わるの？
  • 問題が見つかっても、デイリースクラムでは解決しない
    • 別途会議等を立て、必要な人だけ残ってもらって対策

SCENE9：状況をうまく把握する

• 透明性を大切にする
  • 問題を早期にみつけ、スクラムチーム全体で解決する。
• 透明性を高める手法
  • タスクボード（カンバン）
    • タスクの状況を把握する
    • 未着手、着手、完了に付箋をつけて見える化。
      • 未着手がどれくらいあるかを把握しやすくする
      • 着手中で止まってる＝問題発生している可能性あり
        • 経過日数をメモするのもあり
  • スプリントバーンダウンチャート
    • 理想線と比較し、順調かを確認する
    • タスクの見積もり時間の合計と消化率を比較
    • リリースバーンダウンチャートも同様に可能
• 大切なこと
  • 目的を皆に理解してもらう
    • 透明性が重要であることを認識してもらう
    • 問題を隠さないような意識

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

• スプリントレビューの準備
  • デモ（動くものを実際に動かす）はとても重要
    • 動くものでないと建設的なフィードバックは出ない
    • デモには必要なステークホルダーを招待する
      • 時には重大な変更などが出たりする
  • デモだけでなく、中身も重要
    • 完成していることを定義する
    • 開発チーム：完成の定義
      • スプリントの最初に定義
      • 何をもって完成とするかを定義する
    • プロダクトオーナー：スプリントで達成したいこと
      • プロダクトバックログの意図を満たしているか確認
  • スプリントレビューは完成したものを披露する場
    • 完成していることを重視する

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

• タイムボックスの重要性
  • スプリントの期間は1ヵ月以内
  • デイリースクラムは15分以内
  • スプリントプランニングは8時間まで（スプリント1か月）
  • スプリントレビューは4時間まで（スプリント1か月）
  • 振り返りは3時間まで（スプリント1か月）
• 上記の時間を越えてはいけない
  • スクラムチームの未熟な点を教えてくれる
  • タイムボックスがスクラムチームを成長させる
• ポイント
  • 最初はスプリント1週間がおすすめ
    • 作るものが少なくなる
    • 最終的に期間を変えてもよい
      • 変えるのは1度だけとかにすべし
    • タイムボックスを守れないなら、扱うものを小さくする

COLUMN：ふりかえり

• ふりかえりのアクションを小さくやろう
  • １回で全てを解決しようとしない
  • SMARTなアクションを意識する
    • Specific：具体的な
    • Measurable：測定可能な
    • Achievable：達成可能な
    • Relevant：問題に関連のある
    • Timely Time-bouded：すぐに達成できる　期日のある
• 楽しく効果的なふりかえりの場を作るのは重要
  • １．お菓子を用意して明るい場にする
  • ２．少しでもうまくいったところを見つける
    • ポジティブで楽しいふりかえりの場にすべし

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

• スプリント内ではやく終わった場合
  • 次のプロダクトバックログアイテムに着手しよう
    • やることを一言プロダクトオーナーに言えばいいだけ
    • プロダクトバックログの直近の順序は常にメンテナンスする
  • プロダクトバックログアイテムは誰でも書き込もう
    • １元管理できていることが重要
    • 常によりよいものを目指し、追記が多いのが望ましい
  • プロダクトバックログの順序を変えやすいように工夫する
    • 付箋やスプレッドシート、GitHubプロジェクトボード等を使う

SCENE13：皆の自律を促していく

• スクラムイベント、ロールには意味がある
  • 目的を知っておくことはとても大事
• 守れないときや、守りやすくするためのルールを決めるのが大事
  • 自分たちのルールを皆で話し合って決める
    • ルールを守れなければお菓子を買ってくるとか

SCENE14：ベロシティを上げていく

• ベロシティには良いベロシティと悪いベロシティがある
  • 良いベロシティ：安定している
  • 悪いベロシティ：安定していない
    • 安定してる＝仕事の進め方が順調な証拠
• ベロシティを上げるのは、ふりかえりで無駄をなくしたりする。
  • 単に人を増やすとか、慣れで上がっていくものではない。
  • ベロシティは単にタスク量を測定するための目安
    • ベロシティはスクラムチームの実力と共に徐々に上がる

SCENE15：問題を見つけやすくする

• スクラムイベントは大切な情報が眠っているのでできる限り参加
• スクラムイベント参加できない場合
  • 開発チーム：他の人からフォローバックを受ける等
  • スクラムマスター：他のイベントで問題ないかを確認
  • プロダクトオーナー：あまり替えが利かない
    • POが参加できない時、スクラムチームで代替手段を見つける
      • タイムボックスをずらす
      • スクラムマスターが仕事を手伝う
      • 細切れでもいいから参加してもらう
        • 色々な方法を試すことが大事
        • 別のロールのことも解決に向けてチームでアイデアを出す

SCENE16：意図を明確にしておく

• ユーザーストーリー
  • プロダクトバックログを記述する手法のひとつ
    • 以下の形式で書かれる
      • 「どういったユーザーや顧客」として
      • 「どんな機能や性能」が欲しい
      • それは「どんなことが達成したいため」だ
    • 3行目がとても大事。開発チームが意図を受け取りやすくなる
    • 開発チームのそれに対する答えがそのままデモ手順になる
  • ユーザーストーリーは意図的に短い文章で書かれている
    • 足りない部分はその都度話し合いながら決める
    • 細かい文章よりも話しながら決められるのが一番良い
      • 頻繁な話し合いが取れない場合は別途資料も必要！
        • 画面イメージ・受け入れ基準
• ユーザーストーリーでなくても「なんのため」の項目は用意すべき

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

• スクラムチームが問題を抱えた時の対処方法
  • 一番多いのは技術的負債による開発工数の増加
    • 時間を捻出して対処するしかない
  • 問題を生まないように、予兆を発見すべし
    • 不安に思っていることを紙に書かせる手法
    • スクラムマスターの「大丈夫？」で解決する問題も多々ある
      • サーバントリーダーシップ（奉仕する）

SCENE18：より良い状態にしていく

• 問題は出てくる
  • バグが多い
  • 他部署からの仕事が多い
  • 他部署に任せた仕事が帰ってこない
  • ＰＯの要求が頻繁に変わる
  • 扱いにくいコードが累積していく
• 問題を把握することが大切
  • タスクボードに貼る等
    • 問題を有無原因＝障害
    • プロダクトバックログと同様、障害を管理する
      • 対処すべき順に並べる
• スクラムマスターの問題もチームで理解すること
• 問題の解決は大変だが、小さくても取り組んでいくべき
  • スクラムマスターがそのきっかけにならなければいけない

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

• プロダクトバックログは全員が書けるもの
  • 日々増えるため、手入れが必要（リファインメント）
    • 熟練のスクラムチームは日々手入れしている
    • 未熟なら、スクラムイベントとして定義してもいいかも
• プロダクトバックログの項目が増えたら、最初と同様順序づける
  • 既存の項目と新規の項目を意識せずに見直すほうがよい
• 順序を付けたら、開発チームが見積もりをしなおす
  • 過去見積もったものも見積もりなおすとよい
• プロダクトバックログの日々の手入れは超重要！

SCENE20：手戻りをなくしていく

• スプリントが始まる前の準備が大切
  • 手戻りは、あいまいなものに着手すると発生しやすい
    • 直近のスプリントで扱う項目は詳細まで詰めておくとよい
      • 準備をイベントとして用意するのもよい
      • 準備（リファインメント）に10%以内の時間を確保する
    • スプリントプランニングで取り扱う条件を決めてもよい
      • ペーパープロトタイピングが実施されていること
      • プロダクトオーナーが仕様を決めていること
• プロダクトバックログの項目を詳細化するための手法例
  • ペーパープロトタイピング
    • 紙に画面を書いて、おれで認識あわせをする方法
  • 画面のスケッチ
• 手戻りをなくすために取り組むべき項目
  • 実現したいことは先に深く理解しておく
  • 決めるべき仕様を決めておく
  • 技術的にどう実現するとよいかを確認していく

COLUMN：なぜこの機能を作るのか？

• プロダクトバックログの項目を伝えるコツ
  • 広い観点から施策の目的・背景を考える
    • ステークホルダーと、それぞれの期待を整理することから始める
  • チームに助けを求める
    • プロダクトオーナーはひとりしかおらず、質の維持が難しい
    • チームに助けをもとめることで、チーム全体に理解が深まる

SCENE21：ゴールに近づいていく

• ゴールの達成が難しいときに検討すべきこと
  • 開発を進めるうえで調整できるものは以下の４つのみ
    • 品質
    • 予算
    • 期間
    • スコープ
  • この中でもスコープをまず調整していこうという話
• 品質
  • 犠牲にできない。調整できないもの。
  • 特定の人が使うだけの機能でも、そこから別の悪影響を及ぼす可能性あり
• 予算
  • チームに新しいPCを提供し、開発効率を高めるなど。
    • 単純に人数増は特効薬にならない
    • 予算を増やすには様々な手続きが必要であることが多く特効薬になりづらい
• 期間
  • できるなら効果的ではある
  • 期間を伸ばすとその分予算も増えるので要考慮
  • 何度もできることではない
• スコープ
  • 一番最初に検討すべき、スクラムチーム内で一番調整しやすいところ
    • リリースまでに必要ない機能をそぎ落とす
    • 必要な機能であっても、別の簡易的な代替手段で可能か検討する
    • 最初に決めたことを守ることより、ゴールを達成することが重要

COLUMN：コミュニティイベントを利用してチームビルディング

• スクラムがうまくいかない時は、他のチームがどうしているかを知るなどが大切
  • コミュニティイベントが存在するので、チーム皆で参加するなども良い
    • RSGT

SCENE22：様々な状況に対応する

COLUMN：タスクを皆で寄ってたかって終わらせるスウォーミング

• スクラムチームは自己組織化した開発チームが望ましい
  • １人がリーダーを常にするのではなく、得意な人がその分野を先導する
    • それが自然とできるチームが自己組織化した開発チーム
• 得意分野を皆で共有する方法
  • スキルマップ
    • 必要なスキルを書き出し、それぞれ得意・未経験などを埋める
    • 最低限必要なスキルが足りない場合はスクラムチーム外の関係者と相談が必要
  • ドラッガー風エクササイズ
    • これまでどんな開発をしていて何が得意か
    • どのように仕事をするタイプか
    • 自分が大切に思う価値は何か
    • 自分はどうやって貢献できそうか
• 得意分野の作業だけをやっていてもいけない
  • 属人化が発生してしまう
  • スウォーミングも有効のため、仕事の分担と使い分ける
  • スウォーミング
    • 複数人で同じ仕事を取り組む
    • モブプログラミング・ペアプログラミングなど
      • 完了までのリードタイムが短くなる
      • 知識の移転が進む
• 皆で助け合って、苦手を克服していく。
  • 「私はここまで担当」といったことを発生させないのが理想

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

• コミットメントの価値観が大事
  • コミットメント
    • 責任を伴う約束のこと
    • 必ず達成するものでも無理をして守るものでもない
    • スクラムチームがコミットメントを決めることが大事
      • チーム以外の人の意見は参考意見に過ぎない
      • 周りからの圧力で決めた約束では意味がない
• 責任をもって約束できるようになるためには
  • 自信を持つこと
    • 自信をもってやれないうちに適当な約束ばかりしてはいけない
  • 最初は失敗してもいいから自分たちでやれるかどうかを判断する
    • 失敗したら、その経験を次に活かす
    • スクラムでは何度も経験するため経験を活かしやすい環境
  • 自分で約束したことは責任を持って前向きに取り組む
• スクラムで求めること
  • ×コミットメントを必ず果たす
  • ●コミットメントに責任をもって取り組むことに価値を感じる

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

• リリース作業を後回しにせずスプリントに含めてこなしていこう
  • スクラムでもリリース作業は通常のプロジェクトと変わらない
    • スプリントごとに完成したものを、リリースに耐えうるものにする作業が必要
      • 初心者チームはリリーススプリントを用意する手もある
• リリーススプリントについて
  • リスクがあるためできるだけ作業を残さないほうが良い
    • 本番環境で動かしたらエラーが出てきたなど、色んなトラブルが起きる

SCENE25：実践編で伝えたかった事

• よくある質問２つ
  • Q：大人数での開発はどうする？
    • 開発チームは3~9人がベスト。それ以上の場合は開発チームを分ける。
    • プロダクトオーナーは1人のまま。やることが増えるので補佐をつける。
    • スクラム・オブ・スクラムで開発チーム同士連携する
    • 開発チームがスクラムのやり方に慣れていなければやめたほうがよい
  • Q：分散開発はどうする？
    • 遠隔地だととても大変。
    • 様々な工夫をしているチームがあるため参考にする
      • 最初は同じ拠点で一緒に開発とかがおすすめ。
• スクラムに慣れていくために
  • 最初から普段のやり方でやり、ある程度進んでからスクラムに取り組むなど。
• 本書で触れていなかった２つ
  • 振り返りの内容
    • 本来はスクラムチームの仕事の進め方をもっといいものに変えるためのイベント
    • 最初は問題解決の場になりがち
      • ●●のプラクティスを導入したい、などが提案できていくのが理想
  • プロダクトについて
    • プロダクトを考えると、チームのよりも開発の進め方に目が行きがちのため
• 著者の思い
  • スクラムは毎日の経験を通じて体験して学んでいく仕組み
  • 本書にない、皆の蓄積したノウハウも大事だよ