1. Scrumプロジェクト開始のベストプラクティス Best Practice for Initiating Scrum Project Regional Scrum Gathering Tokyo 2018 株式会社アトラクタ 吉羽龍太郎 (@ryuzee)
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ ✤ アジャイル開発 / 改善 / 自動化 / チーム育成 / クラウドコンピューティング / ド メインモデリングなどが専門領域 https://www.attractor.co.jp/
4. 今日の話 ✤ スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームで スプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最 後にスプリントレビューとレトロスペクティブを実施することになっています ✤ つまりプロダクトバックとスクラムチームが存在するところがスタート地点になって います。言い換えるとそれらがないとスプリントが開始できません ✤ 本セッションでは、スプリント開始前にどんなことを行うと良いのかを考察していき ます
5. “When you present a collec0on of good prac0ces as a 優れたプラクティスのコレクションを fixed method or a solid framework, you forget about the 固定的なメソッドやフレームワークとして扱うのは、 nature of complex systems. 複雑系の特性を無視してしまっている。 These systems (including people) don’t learn from 複雑系（人間を含む）は、固定と停滞から学ばない。 fixa>on and stagna>on. They learn from uncertainty, 不確実性、変動性、驚きから学ぶのだ。 variability, and surprise.” –Jurgen Appelo 『Management 3.0』、『How to Change the World』などの著者
6. “Prac0ce is different depending on your skill level. あなたのスキルレベルによってプラクティスは異なる。 他の人の経験はあなたのものと同じではない。 No one else’s experience is the same as yours. ゆえに、単純にCan’t just “cargo cult” it.” カーゴ・カルト することはできないのだ。 –Andy Hunt 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』、 『リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法』などの著者
8. カーゴ・カルト（積荷崇拝） ✤ カーゴ・カルト（積荷崇拝）とは、いつの日か、先祖の霊・または神が、天国から船 や飛行機に文明の利器を搭載して自分達のもとに現れる、という現世利益的な信仰で、 ニューギニア諸島で多く見られた ✤ つまり、ある戦略が成功を導いた理由や状況を完全に理解せずに、見よう見まねで行 動を真似たり、ツールを導入したりすること
9. 自分たちで考える ✤ 「⃝⃝というプラクティスをやっておけばよい」という思考を捨てる ✤ どれだけ流行っていたりメジャーなプラクティスでも同じ ✤ つまり初期フェーズの組み立てを自分たちで考える必要がある ✤ もちろん… ✤ プロジェクトやプロダクトがうまくいかない点には類似性がある ✤ 既存の知識やプラクティスは参考になる
10. アジャイル導入時に遭遇した課題 63% 企業文化がアジャイルの価値観とあわない 47% 45% 43% 41% アジャイル開発手法の経験が不足 マネジメントからのサポートが不足 組織が変化に抵抗する ビジネスサイド/顧客/プロダクトオーナー不在 34% 34% 31% トレーニング不足 従来型開発手法がすでに普及 一貫性のないアジャイルプラクティスとプロセス 20% 19% 15% ツールやデータなどの分散 コラボレーション不足 コンプライアンスとガバナンス 0 20 VersionOne 11th Annual State of Agile Report 40 60 80
11. よく初期フェーズで行われるプラクティスは？ (みなさんご存知のアレです…)
13. インセプションデッキとは？ ✤ アジャイル開発のプラクティスの1つ (どの方法論や手法にも属してない) ✤ プロジェクトを始める前に明らかにしておくべきことを知るための活動 ✤ 11個の質問に答える形で整理する ✤ チーム全員で話し合い合意したものをアプトプットする ✤ これでプロジェクトの向かう先や考え方を共有する (プロジェクト憲章) ✤ 定期的に更新していく
14. 11個の質問 ✤ 我々はなぜここにいるのか ✤ 技術的な解決策の概要 ✤ エレベーターピッチ ✤ 夜も眠れなくなる問題は何？ ✤ パッケージデザイン ✤ 俺たちのAチーム ✤ やらないことリスト ✤ 期間を見極める ✤ ご近所さんを探せ ✤ トレードオフを決める ✤ 初回リリースに必要なもの
16. インセプションデッキも単なるフレームワーク ✤ ドキュメントを作ることが目的ではない ✤ 形骸化したドキュメント、使われないドキュメント、本音が隠された建前のドキュメ ントなどに意味はない ✤ 目的は共通理解の形成 ✤ 共通理解を形成すべき領域を明らかにしている
17. 共通理解を形成する観点(ざっくり) ✤ ✤ プロダクトに対する観点 ✤ 技術や品質に対する観点 ✤ 我々はなぜここにいるのか ✤ 技術的な解決策の概要 ✤ エレベーターピッチ ✤ トレードオフを決める ✤ パッケージデザイン ✤ やらないことリスト 人に対する観点 ✤ ご近所さんを探せ ✤ 俺たちのAチーム ✤ 計画やマネジメントの観点 ✤ 夜も眠れなくなる問題は何？ ✤ 期間を見極める ✤ 初回リリースに必要なもの
18. 共通理解を形成する観点(ざっくり) ✤ ✤ プロダクトに対する観点 ✤ 技術や品質に対する観点 ✤ 我々はなぜここにいるのか ✤ 技術的な解決策の概要 ✤ エレベーターピッチ ✤ トレードオフを決める ✤ ✤ 計画やマネジメントの観点 パッケージデザイン これらの観点は相互に影響を与える ✤ やらないことリスト 人に対する観点 ✤ ご近所さんを探せ ✤ 俺たちのAチーム ✤ 夜も眠れなくなる問題は何？ ✤ 期間を見極める ✤ 初回リリースに必要なもの
19. これら4つの観点を順番に見ていきましょう！
21. プロダクトゴールや価値の明確化 ✤ ✤ これから作るもののビジネス価値やプロダクトビジョンを明確にする ✤ これから作るものの責任を負っている人はだれなのかが明らかでないとこれは決 まらない（人の観点に依存） ✤ この時点では詳細な要求に踏み込まず、全体像を把握する ✤ 開発以前の話としてビジネスモデルの整理をしないといけないこともある ✤ 例えばビジネスモデルキャンバス、ユーザーインタビューなど 作るものの特性が分からないとどんな開発の仕方をするか決まらない ✤ つまりスクラム一択ではない
22. クネビンフレームワーク (問題ドメイン分類)
23. クネビンフレームワーク (問題ドメイン分類) 正解が存在し変化の少ない領 域。状況を理解・分類し、ベ ストプラクティスに基づいて 進めていく
24. クネビンフレームワーク (問題ドメイン分類) 正解が1つではないものの、 比較的予測しやすい領域。状 況を専門家が分析して理解し、 取り得る手を検討して進めて いく。うまくやる方法は複数 あるためそれをグッドプラク ティスとして活用していく
25. クネビンフレームワーク (問題ドメイン分類) 問題を把握するために試行錯 誤（探索）を行い、それによっ て状況を把握・理解する領域。 そのあとに次の対応を考えて いく。この場合、うまくやる 方法はあとからわかることに なる
26. クネビンフレームワーク (問題ドメイン分類) 革新的なことが求められる領 域で正しい答えもわからない ので、まず行動してから理解 していくしかない領域。既存 の知識が役に立たないことも ある
27. クネビンフレームワーク (問題ドメイン分類) そもそも上記の4つのどれにあ てはまるかもわからない状況 を指す
28. 領域ごとの例 領域 対象業務 典型例 明白な領域 業務の一部 経理システム、データ入力、エンドユーザーコンピュー ティング 込み入った領域 バックオフィス業務 ERP 複雑な領域 他部署や社外との連携 サプライチェーンマネジメント カオスな領域 新規事業 R&D、スタートアップ、ソーシャルゲーム
29. 領域ごとの例 領域 対象業務 典型例 明白な領域 業務の一部 経理システム、データ入力、エンドユーザーコンピュー ティング 込み入った領域 バックオフィス業務 ERP 複雑な領域 他部署や社外との連携 サプライチェーンマネジメント 対象領域によって開発手法を選ぶ必要性 カオスな領域 新規事業 R&D、スタートアップ、ソーシャルゲーム
30. スクラムによる開発の合意 ✤ 対象プロダクトの特性を踏まえてスクラムがよいのであれば、その合意をステークホ ルダーから取る ✤ 必要に応じて関係者にはアジャイル開発やスクラムの価値観、従来型との違いを説明 して理解してもらう ✤ 従来のプロジェクトマネジメントとは考え方が大きく異なるので、合意が取れていない と後で従来型とのギャップに苦しむことになる ✤ 従来の報告の仕方とは異なる可能性が高いので、どのような報告が必要かを確認し、 あわないものは交渉してやめる
31. 初期のプロダクトバックログの準備 ✤ まずは全体像を見る ✤ ユーザーストーリーマッピングを使ってみるとよい（が他の方法でも構わない） ✤ 見える化による共通理解の形成が目的
32. ユーザーストーリーマッピング 商品 を探す 利用者のアクティビティ 商品を購 入する 商品 検索 商品 詳細 商品 選択 確認と 修正 アカウン ト更新 商品 購入 購入 確認 商品名 で検索 詳細情報 表示 数量と色 の選択 選択内容 確認 送付先登 録 JCBカー ドで決済 注文番号 表示 利用者のタスク その他 商品受領 履歴 返品 購入履歴 一覧 連絡先 表示 リリース1 写真付き で見える メーカー で検索 類似品が 見える 価格で検 索 あいまい 検索 サイズの 選択 選択解除 送付先更 新 VISAで 決済 数量・色 の変更 カード番 号保存 Paypal で決済 サイズ変 更 口コミが 見える 購入確認 メール 到着予定 日通知 履歴から 再購入 リリース2 プロダクトバックログ項目(ストーリー) カード更 新依頼 銀行振込 決済 アンケー ト送付 リリース3
33. 送付先登 録 優先順位 詳細情報 表示 厳密 プロダクトバックログ化 JCBカー ドで決済 写真付き で見える 数量と色 の選択 直近は とりあえず ここまで 注文番号 表示 メーカー で検索 有象無象 価格で検 索 類似品が 見える 連絡先 表示 商品名 で検索 送付先更 新 購入履歴 一覧 サイズの 選択 選択解除 選択内容 確認 VISAで 決済 カード番 号保存 Paypal で決済 数量・色 の変更 サイズ変 更 購入確認 メール 到着予定 日通知 着手する前に 最新の情報で 履歴から 再購入 内容や優先順位を 見直す
34. プロダクトバックログ ✤ 初期のプロダクトバックログが全部実装されることはない ✤ 全部が ✤ 着手する順番に並び替える ✤ 上位の項目ほど具体的に、下位の項目は詳細化しすぎなくてよい ✤ それぞれの項目をラフに見積もる（S / M / L / XLなど） ✤ 上位の項目はスプリント1に向けて受け入れ基準を用意することになる っている必要はないが、優先順位が高い項目は洗い出す
36. ロールの明確化 ✤ スクラムチームを取り巻く人たちは誰？ ✤ プロダクトオーナーは誰？ ✤ 開発チームは誰？ ✤ スクラムマスターは誰？
37. スクラムチームを取り巻く人たちを明らかにする ✤ スクラムチームをとりまく利害関係者 = ステークホルダー ✤ 顧客、ユーザー、スポンサー、営業、マネジメントチーム、スペシャリストチー ム、QAチーム、運用チーム、社内管理部門、システム連携先などなど ✤ スクラムチームと外側の間には境界がある ✤ 境界の門番を置くことで開発チームが集中できるようにする ✤ プロダクト面：プロダクトオーナー ✤ プロセス面：スクラムマスター ✤ すなわちプロダクトオーナーとスクラムマスターは外部と協働する
38. 開発チームの適切なメンバーの選定 (1) ✤ これからスクラムの開発チームをつくる場合にはそれに適したチームを作る ✤ 適任者の特性 ✤ 新しいことに抵抗がない ✤ 常に変化する状況にストレスを感じない ✤ 個人の責任範囲ではなく、全体の成果を気にすることができる ✤ 自分のことばかりではなく、人が困っているときに助けられる ✤ 意見や反論を言える ✤ コードが書ける・インフラが作れる・必要な技術スキルがある
39. 開発チームの適切なメンバーの選定 (2) ✤ 他のプロジェクトを兼任しているとそれに引きづられてプロジェクトに十分にコミッ トできなくなってしまうため、プロジェクトに専任でアサインする ✤ チームをこれから形成する場合、同じキャリアや考え方に を持たせる ✤ メンバーが分散している場合は1箇所に集めて全員同席になることが理想 ✤ い過ぎないように多様性 特に導入初期からリモートにするのは難しいので要注意
40. 開発チームの適切なメンバーの選定 (3) ✤ 既存のチームで実施する場合は、ここまでの内容を踏まえる ✤ あまりにアジャイル開発やスクラムの考えにあわないチームはリスクが高い ✤ リスクが高い例 ✤ パートナー比率が非常に高い (開発者が全員パートナー) ✤ 既存のチームが強力な指示型で運営されている ✤ 開発経験が非常に少ないメンバーだけで構成されている
42. スクラムの知識レベルを ✤ える スクラムチーム(プロダクトオーナー、開発チーム、スクラムマスター)とステークホル ダーの知識レベルを える ✤ 価値観や仕事の流れを中心とする ✤ これから行う活動において従来型の考え方をそのまま持ち込んでムダが発生する のを防ぐ ✤ その後も定期的に短時間のトレーニングを行う ✤ プロセスに対する共通理解を持つ
44. ファシリティ ✤ ✤ スクラムチーム全員が集まれる場所を用意する ✤ 全員同席はXPのプラクティスの1つ ✤ コミュニケーションのオーバーヘッドを大きく削減できる プロジェクトルームが用意できると心理的にも安全にしやすい ✤ 特に社内で初めてのアジャイル開発で、かつ日常的に静かな環境の場合、他の チームからクレームがつく場合がある
45. 道具を える ✤ 付箋紙 ✤ 模造紙 ✤ ホワイトボード ✤ 大きなディスプレイ ✤ コーヒー ✤ おやつ ✤ 冷蔵庫 ✤ ペン、マーカー、定規、その他文房具類 ✤ もちろん速いPC
46. ワーキングアグリーメントを設定する ✤ スクラムチームが規律を守って生産的に物事を進めるために用意するもの ✤ ✤ スクラムチーム全員で議論して納得した内容を明文化する ✤ ✤ ✤ Googleなどは良いチームのポイントとして「集団規範」を挙げている プロダクトオーナーやステークホルダーが強制するものではない スプリント1の開始前までに用意して、以後レトロスペクティブごとに見直す ✤ 守るのに注意が必要な項目に絞り込む（ホワイトボードの脇に貼れるくらいの量） ✤ 当たり前にできるようになったことを削除するなど ✤ チェックリストではない スクラムチームによって内容は異なる
47. ワーキングアグリーメントの例 (1) ✤ 午前9時∼午後4時がコアタイム。コアタイム外にスクラムイベントを設定しない ✤ スクラムイベントは休暇以外は全員参加。不参加の際は意思決定を委ねる ✤ デイリースクラムは午前10時に開始 ✤ デイリースクラムの前までにタスクの残時間を更新しておく ✤ 毎週火曜日の午前11時からスプリントレビューを実施する ✤ レビューの準備には1時間以内 ✤ イベントやミーティングは時間通りに開始して、タイムボックス内で終了する ✤ イベントやミーティング中は携帯に出ない ✤ レトロスペクティブでは、スクラムマスター以外はノートPCを閉じる ✤ プロダクトオーナーは午前11時∼午後3時まではチームの部屋にいる
48. ワーキングアグリーメントの例 (2) ✤ テストがすべて終わったものを完成とする ✤ ビルドが失敗した場合、修正コード以外のプッシュをしない ✤ 誰かに助けを求められたら「よろこんで」と返事する ✤ 予定休暇は1週間前までに共有する ✤ マスターブランチへの直接プッシュは禁止 ✤ ペア作業をする場合は50分に1回10分休憩を入れる ✤ ドキュメントはマークダウン形式でバージョン管理システムに入れる ✤ 1つのことに30分ハマったら周りに助けを求める ✤ 体調が悪い場合は無理して来ない。周りに移す方が迷惑 ✤ 休日の前日午後4時以降はリリースしない
50. 非機能要件の明確化 ✤ ✤ 非機能要件について共通理解を持つ（プロダクトの特性を踏まえ重要な箇所を検討） ✤ 可用性（継続性、耐障害性、災害対策、回復性など） ✤ 性能・拡張性（業務処理量、性能目標値、リソース拡張性、性能品質保証など） ✤ 運用・保守性（運用時間、バックアップ、運用監視、計画停止、予防保守など） ✤ 移行性（移行時期、移行方式、移行対象データ、移行計画など） ✤ セキュリティ（制約条件、セキュリティ診断、アクセス制限、データ秘匿など） ✤ システム環境・エコロジー（システム特性、適合規格、環境条件など） 非機能要件はアーキテクチャ、コスト、開発期間などに影響を与える ※IPA公開の非機能要求グレードを元に作成 https://www.ipa.go.jp/sec/softwareengineering/reports/20100416.html
51. アーキテクチャや開発言語などの選定 ✤ ✤ 選定項目の例 ✤ プロダクトのアーキテクチャをどのようにするか ✤ どの開発言語でどんなフレームワークを使うか ✤ テスト自動化にはどんなライブラリを使うのか ✤ インフラに何を使うか 技術検証の結果変更することもある（後述）
52. 技術検証(スパイク) ✤ ✤ 開発を進める上でブロッカーになるような技術の検証を行う ✤ 全ての検証を行う必要はない ✤ 検証はキリがないのでタイムボックスを設定する ✤ 残った項目はプロダクトバックログに入れたり、リファインメントの一環で検証 結果によってはアーキテクチャや要素技術を変更したり、プロジェクトを中止するこ ともあり得る
53. 完成の定義の作成 ✤ 完成の定義（DoD）はプロダクトの性質やビジネスのゴールによって変わる ✤ ✤ ✤ 目的やリスク、ROIにも依存する プロダクトオーナー(最終決定者)と開発チームが中心となって考える ✤ プロダクトオーナーはもちろんステークホルダーと協働する ✤ ステークホルダーには社内の品質管理部門などが含まれることが多い ✤ 「なぜ？」「なにを？」「誰のために？」をはっきりさせる 本番にリリースするために必要なことと、スプリントでやることに差が少ないほど、 速やかなリリースが可能になる（だが成熟度に依存する）
54. 完成の定義 (≒非機能要求) ✤ プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために実施しな ければいけないことの一覧 ✤ 例えば、ユニットテストする、統合テストをする、静的解析する、リリースノートを 書く、レビューするといった活動を明確化する ✤ 定義を満たしてはじめて「完成」となる。満たしていない場合はプロダクトオーナーの 受け入れ確認もしてはいけない ✤ プロダクトバックログ項目単位での完成の定義、スプリント単位での完成の定義、リ リース単位での完成の定義といった形で定義をすると分かりやすい
55. ドキュメントの扱い ✤ 必要な時期に必要なものを書く ✤ すなわちプロジェクト初期に必要なものを明らかにする必要がある ✤ 法令順守に必要な文書は、開発初期から必要なわけではない ✤ 一方で保守・運用の資料はひとたび本番としてリリースしたタイミングから常に 保守される必要がある ✤ 自動化できるものは自動化する ✤ 完成の定義にドキュメントを含める
56. (参考) 受け入れ基準 (≒機能要求) ✤ 受け入れ基準とは「プロダクトバックログ項目」で満たしていないといけない機能性 を定義したもの ✤ したがってプロダクトバックログ項目単位で受け入れ基準は異なる ✤ 一方で、完成の定義は非機能要求の定義なので、（ほぼ）全プロダクトバックログ項 目に適用される
57. スプリントにおける活動 ✤ スクラムではコーディング作業とテスト作業は密接につながっている ✤ つまりコーディングやテストとやその他必要な作業が完成し、プロダクトオーナーの 受け入れが終わって、はじめてその機能が完了したことになる ✤ 完成の定義を満たしていない(非機能要求が未対応)もの、プロダクトオーナーが受け入 れない(機能要求が実現されていない)ものは、スプリントでの成果と見なされない ✤ もちろん成果としてベロシティなどを部分計上しても意味がない
58. 完成の定義の例(あくまで) プロダクトバックログ項目の 完成の定義 • • • • • • • • 項目がJIRAに存在する テストコード、プロダクション コード含め全てのコードが チェックインされている コードレビューを受けている コードフォーマッタがかかって いる 静的解析で必須修正事項がない 全てのユニットテストをパスし ている 全ての受け入れテストが用意さ れ、それにパスしている (略) スプリントの 完成の定義 • • • • • • • 全てのプロダクトバックログ項 目の完成の定義を満たす プロダクトのバックアップが更 新されている パフォーマンステストが完了し ている パッケージ、クラス、アーキテ クチャのダイアグラムを更新 全てのバグが解決しているか、 対応の時期を決めている ユニットテストによる全コード カバレージが80%以上 (略) 内部リリースの 完成の定義 • • • • • • • • JIRAでマイルストンが作成され ている 全てのスプリントの完成の定義 を満たす インストーラーが作られている マニュアルが更新されている トラブルシューティングガイド が更新されている 障害発生時の復旧計画が更新さ れている 全てのテストスイートにパスして いる (略) 正式リリースの 完成の定義 • • • • • • • • • JIRAでマイルストンが作成され ている 全ての内部リリースの完成の定 義を満たす 負荷テストが実施されている パフォーマンステストが実施さ れている ネットワークダイアグラムが更 新されている セキュリティアセスメントに合 格している 脅威分析試験に合格している 障害発生時の復旧計画がテスト されている (略) ✤ どのタイミングで何ができていれば完成かを具体的に定義しておく(容易に判断できるくらい) ✤ スプリントでの完成とリリースでの完成に差があると、エンドゲームの時間が長くなる
59. 完成の定義作成シート(例) 対象：プロダクトバックログ項目 項目 # 1 意図 プロダクトバックログ トレーサビリティの確 項目の存在 保 • JIRAのプロダクトバックログ一覧に当該項目があること ユニットテストの作成 モジュール単体での品 と実施 質の確保 • Controller、Model、ユーティリティなどでユニットテストがあること • テストケースはC0以上であること • ユニットテストはすべて合格していること • プロダクトコードとともにGitにPushされていること • • プロダクトバックログの受け入れ基準がコード化されていること コード化されたテストケースはすべて合格していること • テストコードがGitにPushされていること 2 3 受け入れテストの作成 機能性の担保 と実施 （略） ・・・ ✤ 確認方法・基準値 (略) (略) できるかぎり具体的にして、全員が共通認識を持てるようにする
60. 開発環境の作成 ✤ 個人の開発環境を用意する ✤ 後から参加した人が簡単に開発環境を手に入れられるように仮想化や自動化など を組み合わせる ✤ デモ環境やプロダクトオーナー受け入れ確認環境も早期からあるとよい ✤ その他開発に必要なツールセットの準備（後述）
61. ツールセットの準備 ✤ コードは初期から全てバージョン管理システムに登録する ✤ バージョン管理システムのメインライン、ブランチ等の使い方を教育 ✤ これができない人には本番コードを書かせない ✤ CI/CDサーバの構築等 ✤ 要求やバグなどのチケット管理システム ✤ テスト環境など ✤ プロダクトバックログの上位に入れることもある
63. テスト自動化の必要性 機能数 コード行数 テスト件数 ✤ 小規模リリースのたびに手動でテス トするとコードベースが大きくなる につれてテストコストが膨らむ(特 に回帰テスト) ✤ スクラムではフレームワークの定義 のみで、テスト自動化については触 れられていないが、 実際はテスト自動化は必須 1200 900 600 300 0 Sprint#1 #2 #3 #4 #5 #6 #7 #8
64. プラクティスの選択 ✤ スクラムは3つのロール、3つの作成物、5つのイベントすべてを実施しないといけない ✤ XPでは必要なものを選べばよい ✤ ほかにも必要なプラクティスを選択する ✤ 最初から盛り込みすぎると学習コストが高すぎたり時間がかかりすぎたりする ✤ 後で変えても良い
66. 全体の規模を明らかにする 商品 を探す 商品を購 入する 利用者のアクティビティ 商品 検索 商品 詳細 商品 選択 確認と 修正 アカウン ト更新 商品 購入 購入 確認 商品名 で検索 M 詳細情報 表示 L 数量と色 の選択S 選択内容 確認M 送付先登 録 M JCBカー ドで決済 X 注文番号 表示 M 写真付き で見える M サイズの 選択S 選択解除 S 送付先更 新 S VISAで 決済 X 数量・色 の変更S カード番 号保存L Paypal で決済L メーカー で検索S 類似品が 見えるS 価格で検 索 M あいまい 検索L サイズ変 更 S 口コミが 見える M 利用者のタスク その他 購入確認 メール M 商品受領 履歴 購入履歴 一覧M 到着予定 日通知M 履歴から 再購入S S 2pt M 5pt L 8pt X 13pt 返品 連絡先 表示 S リリース1 74pt リリース2 41pt リリース3 36pt プロダクトバックログ項目(ストーリー) カード更 新依頼L 銀行振込 決済 X アンケー ト送付S
67. スケジュールに影響するパラメータ ✤ パラメータの例 ✤ ビジネス上の都合（マーケティング、新製品発売、法令改正、売上確保など） ✤ 予算 ✤ 開発チーム外への依存関係（QA、セキュリティ） ✤ 開発作業のボリューム（スコープ、完成の定義） ✤ 開発チームの能力（ベロシティ） ✤ 全部を同時に固定することは不可能なので、何を優先すべきか共通理解を形成する ✤ 初期の精度は低いのでスプリントを繰り返しながら見通しを更新していく ✤ 同一チーム、同一技術の場合は、過去の実績を活用できるので予測精度は高い
69. 250 200 150 100 50 スプリント開始後も測定を続けて予測の精度をあげていく 0
70. スプリントの長さを決める ✤ ✤ 決定に影響を及ぼすものの例 ✤ 想定の期間 ✤ 変化の度合い ✤ フィードバックの回数 ✤ プロダクトの規模 ✤ 開発チームのキャパシティや場所 ✤ 完成の定義 長さの例 ✤ 小規模なら1∼2週。大規模なら2∼4週であることが多い ✤ 実は期間が長い方が難しい
71. リスクを管理する ✤ 初期の段階ほど分からないこと、不確定なことが多い ✤ なんらかの形でバックログ化、見える化する ✤ プロダクトオーナーとスクラムマスターが中心となって対処していく ✤ 例えばリスク一覧やリスクバーンダウンチャートなどを用意してもよい # リスクの内容 顕在化確率 発生時の影響日数 ポイント 1 接続先システムとのインターフェースがあわない 50% 10 5 2 マスタデータの提供が遅れる 30% 30 9 3 社内品質管理部門の指摘 40% 10 4 4 専用線の調達の遅延 60% 20 12 5 ブラウザ間の非互換性 30% 5 1.5 6 App Storeからのリジェクト 40% 10 4
72. レポーティング ✤ 組織によって必要なレポートは異なる ✤ 初期フェーズの段階で、どんな頻度で、どんな内容を、誰にレポートしないといけない のかを明らかにする ✤ 全体像やリスクを把握できるようなものにとどめる（最初は最低限から始める） ✤ プロジェクトバーンダウンでも十分なことが多い ✤ スプリントの活動を詳細にレポートするのは意味がないことがほとんど ✤ 開発チームの時間をレポート作成に使うと勿体無いので、自動で作るか、スクラムマス ターやプロダクトオーナーが作成する ✤ レポートに対するフィードバックやそれを受けてのアクションがないなら作らない
74. スプリント#1開始までの準備期間 SA+A 2013 Agile Project Initiation Survey http://www.ambysoft.com/surveys/ 母集団160 6% <1週間 7% 1週間 2週間 13% 3週間 13% 14% 4週間 11% 5-6週間 7-8週間 3% 18% > 8週間 不明 14%
75. 準備の進め方 ✤ ここまで説明した全ての項目の検討を行わないといけないわけではない ✤ 最初にタイムボックスを決めて、その範囲の中で行う ✤ 検討すべき項目や実施すべき項目を洗い出して並び替える ✤ ✤ 並び替えた上位の項目から進めていく。進める過程で検討項目が増減する ✤ ✤ それぞれの項目は何をもって完了とするかを決めてから着手する スプリント開始後でよいものは初期にやらない つまり、準備期間もスクラムの考え方で進めていく ✤ プランニング、デイリースクラム、レトロスペクティブなど
