GMOテクノロジーブートキャンプ2015(アジャイル編)
•
8 likes•2,826 views
自社の新卒エンジニア向け研修(GMOテクノロジーブートキャンプ)のアジャイル編で使った資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to GMOテクノロジーブートキャンプ2015(アジャイル編)
Similar to GMOテクノロジーブートキャンプ2015(アジャイル編) (20)
More from Arata Fujimura
More from Arata Fujimura (20)
GMOテクノロジーブートキャンプ2015(アジャイル編)
- 2. 2 自己紹介
- 6. 6 2015年の近況報告
- 8. 8 2/25 ザッパラス社セミナー • リーンスタートアップについて • アジャイル開発について • スクラムについて
- 9. 9 2/28 Regional Scrum Gathering Tokyo 2015 • 開発モデルの作り方 ～守破離の破！～
- 11. 11 4/16 Agile Japan 2015 • アジャイルなオフショア開発
- 12. 12 5/29-30 Regional Scrum Gathering Vietnam 2015 • 参加予定(自費)
- 16. 16 スライドをアップロード
- 17. 17 フィードバック
- 18. 18 楽天 Tech Talk
- 19. 19 オフショア大學
- 20. 20 私がやりたい事
- 21. 21 ＋ 正しく続ける
- 22. 22 正しいものを(プロダクトディスカバリーフェーズ) デザイン思考 顧客開発モデル リーンスタートアップ ビジネスモデルキャンバス(リーンキャンバス) ユーザーエクスペリエンス(カスタマージャーニー)マップ ユーザーストーリーマッピング インセプションデッキ
- 23. 23 正しくつくり(開発フェーズ) アジャイル開発 スクラム XP ドメイン駆動設計 正しく続ける(運用フェーズ) リーン開発 継続的デリバリー(CD) 今時インフラ インフラCI Immutable Infrastructure
- 24. 24 ところで先週…
- 27. 何分かかりましたか？
- 29. 何分かかりましたか？
- 30. 自分のチーム、覚えてますか？
- 32. 32 HRT重要 伝えたいこと
- 39. 39 ■ルール チーム全員が1つのピンポンボールに触れると1ポイント ボールの受け渡しは一度ボールが宙に浮く必要がある(手渡禁止) 単位時間(120秒)でのスコアが高いチームが勝ち ■ステップ 1) 戦略を考えてスコアを見積もる(60秒) 2) 実行する(120秒) 3) スコアを計測して報告(60秒) 4) ふりかえり(60秒) 5) 1に戻る(5回実施します)
- 40. 40 アジャイル開発概要
- 42. 42 プロセスやツールよりも個人と対話を 包括的なドキュメントよりも動くソフトウェアを 契約交渉よりも顧客との協調を 計画に従うことよりも変化への対応を アジャイルマニュフェスト
- 44. 44 プロセスやツールよりも個人と対話を ➡個人と対話よりもチームのビジョンと規律を 包括的なドキュメントよりも動くソフトウェアを ➡動くソフトウェアよりも有効で妥当な学習を 契約交渉よりも顧客との協調を ➡顧客との協調よりも顧客の開拓を 計画に従うことよりも変化への対応を ➡変化への対応よりも変化の提案を アジャイルマニュフェスト(2.0)
- 45. 45 Kent Beck(2010年) XP, デザインパターン, TDD, Junit, … 署名は行われていない 何が変わったか 個人 ➡ チーム 手段 ➡ 目的 何をすべきか ➡ なぜすべきか アジャイルマニュフェスト(2.0)
- 46. 46 変動制と不確実性 役立つ変動性を受け入れよ イテレーティブでインクリメンタルな開発を採用せよ 検査、適用、透明性を通じて変動性を活用せよ あらゆる形の不確実性を同時に削除せよ 目的の不確実性(What) 手段の不確実性(How) 顧客の不確実性(Who) アジャイルの原則
- 48. 48 予見と適応 選択肢を広げておく 最終責任時点を可能な限り先延ばしにする 事前に正しく行なうことは不可能だと認める 適応型で探索型のアプローチを好む リーン・スタートアップ的なアプローチ 経済的に妥当なやり方で変化を受け入れる 初期に予見し過ぎない 予見的な事前の作業と適応型のジャストインタイムの作業とのバ ランスを取る 事前の予見を最小化する
- 49. 49 検証による学び 重要な想定をまず検証する 重要な想定の数を最小化する 複数の学習ループ(1日単位、スプリント単位など)を平行して活用する すばやいフィードバックのためのワークフローをまとめる 仕掛中の作業(WIP) 作業は経済的に妥当なサイズにまとめよ バッチサイズは1に近づける 在庫(WIP)を認識し、適切な流れで管理せよ 作業者の手待ち(キャパシティ)ではなく、作業の手待ち(実施したいのに何らかの原因 でできていない作業)に注目せよ リレーにおいて、走者ではなくバトンを見ろ 遅延コストを考慮せよ 作業の手待ちの方が高くつく
- 50. 50 進捗 リアルタイムの情報に適応して再計画せよ 計画に従うことが目的ではない 動作する資産を検証することで進捗を測れ 顧客にとって価値のある作業を終わらせたかどうかが重要 価値に主眼を置いたデリバリーに集中せよ 顧客は価値の高いフィーチャーから順に継続的に受け取れる 作業効率 すばやく進め、しかし、あわてるな 持続可能なペース 品質を作り込め 必要最低限の儀式を行え 必要なドキュメントは書く エッセンシャルスクラム 図3.2より抜粋
- 53. 53 まとめ
- 54. 54 • アジャイル開発の歴史は古い • 時代に合わせて解釈も変わってきている • アジャイルの原則を理解する • 計画駆動(WF)の原則との違いで考える • アジャイル開発が適するのは対象が複雑な 場合のみ • 適さないケースもある
- 55. 55 リーン開発のカンバン
- 56. 56 • 次研で一番活用されているのはカンバン • アジャイルなオフショア開発もカンバン • カンバンはアジャイルソフトウェア開発におけるリーンな アプローチ • XPとスクラムは、イテレーションやスプリントと呼ばれ る「期間」を区切ってチーム内に存在する在庫を制 限するリーン手法 • カンバンは「WIP」(仕掛り)を直接制限するリーン手 法 • 両者とも、ソフトウェアのモジュールではなく顧客の 目でわかる機能ごとに開発を行い、「ふりかえり」と いう活動を通じて、現場のチームで改善活動を行う。 ※「リーン開発の現場」 p.183 から抜粋 リーン開発のカンバンについて
- 59. 59 • リーンという言葉は、TPS(トヨタ生産方式)が源流 • TPSの考え方は、リーン(ムダがない)というコンセプトで生 産方式を超えて抽象化され、さまざまな分野に適用された • リーン製品開発 • リーン・コンストラクション (建築) • リーン・サービス (サービス産業) • リーン・ソフトウェア開発 (アジャイル開発) http://www.atmarkit.co.jp/ait/articles/1311/15/news015_3.html
- 60. 60 • 3つのムダを無くす(リーン) • 間違ったものを作るというムダ • 「しなくてもいいことを効率的 にやってもムダである」 • 学び損ねるというムダ • 過度な作業切り替えによるムダ
- 63. 63 私からのお願い。 「美味しいラーメンを作ってください」 ※チームで作業をしてください 1. 美味しいラーメンを作るために必要な作業を洗い出し、付箋に 書き出してください(5分) 2. 作業順に付箋を並べてください(5分) 3. チーム毎に発表してください(1分×6チーム)
- 64. 64 スクラム概要
- 68. 68 スクラムプラクティス ■役割 プロダクトオーナー(1人) スクラムマスター 開発チーム(３～９人) ■作成物 プロダクトバックログ スプリントバックログ プロダクトインクリメント ■アクティビティ スプリント(１～４週間) スプリントプランニング(2～8時間) デイリースクラム(15分) スプリントレビュー(1～4時間) レトロスペクティブ(1~3時間) プロダクトバックログリファインメント (作業時間の10%以下)
- 71. 71 プロダクトオーナー 開発において行う投資に対する効果(ROI)を最大にすることに責任を持つ バックログへの追加、削除、順位付けの最終的な責任を持つ 開発チームに機能を説明して理解してもらう責任がある 一人の人間が担当し、委員会のような合議制の体制にしてはいけない 開発チーム 3名以上、9名以下でないと効果が出にくい(7±2とも言われている) 実際に開発を行うチーム 職能横断的に様々な技能を持った人が集まり、自律的に行動する 自己組織化されたチーム 製品の価値を高めることに責任を持つ 役割
- 72. 72 スクラムマスター スクラムチーム全体が自律的に協働できるように場作りをする ファシリテーター的な役割 開発チームが抱えている問題を取り除くために何でもやる コーチとしてメンバーの相談に乗る 外部の割込みから守る チームの障害を取り除くために外部との交渉を行う プロダクトオーナーを支援する 製品のビジョン作りやバックログ管理など サーバントリーダー 役割
- 74. 74 プロダクトバックログ 製品へ追加する機能(要求)のリスト。 ユーザーの価値で書かれている必要がある ユーザーストーリー形式 優先順位順に並んでいる必要がある プロダクトオーナーが管理する スプリントバックログ プロダクトバックログから抜き出された、今回のスプリントで追加する機能の リスト スプリント計画でプロダクトオーナーの決めた順位と開発チームが決めた見 積もりの両方の情報を併せて抜き出される 一回のスプリントにだけ使用される 作成物
- 75. 75 プロダクトインクリメント 一回のスプリントの成果であり、スプリントで完了した製品の機能 スプリントの終わりにはインクリメントが動く状態である必要がある インクリメントは、「出荷判断可能ソフトウェア」の必要がある プロダクトオーナーがレビューして、実際に製品をリリースするかどうか を決定する 作成物
- 77. 77 スプリント 反復(イテレーション)の単位 スプリントは1～4週間の時間枠(タイムボックス) 予定されている機能が完成できなくても延長されることはない 期間内で開発チームは「スプリントバックログ」の開発に集中し、動作する 製品(インクリメント)を作り出す スプリントプランニング スプリントの開始に先立って行われるミーティング 「プロダクトバックログ」から今回のスプリントで扱う「スプリントバックログ」を 抜き出して決定する。 その後開発チームが計画を詳細化し、タスクにまで分割する 開発チームのコミットメントが重要 アクティビティ
- 78. 78 デイリースクラム(朝会) メンバーは一人ずつ、「昨日やった事」、「今日やる事」、「困っている事」を 順に話す 上長への報告にならないように注意する 開発チームのコミットメントが重要(今日やる事) 15分で打ち切る 別途話し合いが必要な場合は朝会終了後に関係者のみで話す スプリントレビュー スプリントの終了時、関係者を呼び集めてできあがった製品のデモを行う 開発チームはプロダクトオーナーやステークホルダーからのフィードバックを もらうことが重要 アクティビティ
- 79. 79 レトロスペクティブ(ふりかえり) このスプリントでうまくいったこと、うまくいかなかったこと、どうやったら次 のスプリントでよりうまくできるかを話し合う KPT2(Keep, Problem, Try, To Do)形式で行われることが多い 「検査と適応」の機会となり、チーム学習、チーム改善の活動となる プロダクトバックログリファインメント 「PBIの作成と改良(詳細の追加) 」、「PBIの見積もり」、「PBIの優先順位 付け」の3つのアクティビティの総称 プロダクトオーナー主導で行う共同作業 内外のステークホルダー、スクラムマスター、開発チーム 最終決断を下すのは、プロダクトオーナーの役割 デイリースクラムの後、スプリントレビュー中や、スプリント中に行う アクティビティ
- 81. 81 まとめ
- 82. 82 • 全てのルールはスクラムガイドに書いてある • "スクラムの一部だけを導入することも可能だが、それはスクラムとは 言えない。" • スクラム風 • "すべてをまとめたものがスクラムであり、その他の技法・方法論・プ ラクティスのコンテナとして機能する。" • XPとのハイブリッドが一般的 • 読むべき書籍 • アジャイルサムライ • アジャイルな見積りと計画づくり(読書会やってます！) • スクラム実践入門 • エッセンシャルスクラム
- 83. 83 守破離とは
- 84. 84 CSM研修で学んだ守破離 • 守 - ルールに従え - どうやるかを見て練習を繰り返す • 破 - 工夫してみる - 原因と結果をつなげる実験 • 離 - ルールを忘れろ - 新しい技術を一瞬で考えて使える段階
- 86. 86 守破離の語源
- 88. 88 • その後千利休が詠んだ(らしい) • 「規矩(きく)作法 守りつくして 破ると も 離るるとても 本(もと)を忘るな」 • 『利休百首』
- 89. 89 • そして千利休の茶道の修行観 を、後世の川上不白(かわか みふはく)が表現した • 「守ハマモル、破ハヤブル、 離ハはなると申候。 弟子ニ敎ルハ此守 と申所計也。弟子守ヲ習盡 し能成候へバ自然と自身よりヤブル。これ上手 の段なり、さて、守るにても片輪、破るにても片 輪、この二つを離れて名人なり、前の二つを合 して離れてしかも二つを守ること也。 」 • 『不白筆記』 • 「守破離といふ事軍法用、尤用方違ひ候へ共、 茶道に取て申候はば、守は下手〈略〉破は上手 〈略〉離は名人」 • 横井淡所の『茶話抄』への添え書き
- 90. 90 守破離とは 「道」 の指針
- 91. 91 俺の守破離
- 93. 93 • 「アジャイルサムライ」と「アジャイルな見積りと計画 づくり」を読んだだけで、ソシャゲプロジェクトへア ジャイル開発初導入！ - アジャイル開発を体感できた - 自分が分かっていないということが分かった
- 94. 94 • 「スクラムガイド」と「塹壕よりScrumとXP」を読んだ だけで、ECツール開発プロジェクトへスクラム"風" 初導入！ - スクラムを体感できた - プラクティス厨じゃダメだということが分かった
- 99. 99 CSPO研修受講 日時：2013年5月20日～21日 場所：株式会社ミクシィ 講師：ジェフ・パットン
- 101. 101 CSM研修受講 日時：2013年6月20日～21日 場所：ビジョンセンター日本橋 講師：江端一将、Sergey
- 103. 103 • 勉強会、ワークショップ、イベントに参加 • アジャイルサムライ横浜道場 • POStudy • レゴスクラム(見学) • AEP読書会 • Scrum Masters Night • Agile Japan 2014 • Regional Scrum Gathering Tokyo 2014
- 105. 105 • 担当プロジェクトへ各種プラクティス導入 • リーンカンバン、WIP • 朝会、ふりかえり、計画MTG • グループ会社への導入支援 • インセプションデッキ • 導入事例を書く、話す • 採用ブログに書く • 自社、他社に話す • 部署内での啓蒙活動 • アジャイルな見積もりと計画づくりまとめ • アジャイル開発取り組み状況
- 106. 106 第1回アジャイルミーティング主催 日時：2013年10月9日 場所：GMO Yours 内容 1. PMIアジャイルPM研究会立ち上げプロジェクトの紹介 2. 次世代システム研究室 3. GMOリサーチ 4. GMO ECラボ 5. GMOペパボ 6. 交流会
- 107. 107
- 108. 108 • 次世代システム研究室では GMOベトナムラボセン ター(ベトナム/ハノイ)と密接に連携しながらGMO インターネットグループのシステム開発(オフショア 開発)に取り組んでいたが、必ずしもうまくいってい るとは言えない状況だった • オフショア開発プロセス改善に取り組むことになっ たため、国内プロジェクトで実践していた各種プラ クティスを導入するも問題多発
- 110. 頑張っても 効果が薄い事を 諦めてみた
- 111. 111
- 114. Rough Fill Closing
- 115. ベースは リーン開発の カンバン
- 118. Rough Fill Closing
- 119. 119 • ザックリ開発するフェーズ • 7割程度の完成度を目指す • 着手する前にザックリ開発工数を見積もっても らう
- 120. Rough Fill Closing
- 122. Rough Fill Closing
- 124. 124 開発モデルを作るということ
- 127. 127 形を持つ人 だけが、 形を破れる
- 128. 128 • 十八代目 中村 勘三郎が19の時、唐十郎の巨 大テントで「下町唐座」を見たときのこと なんだこれは！？ 自分がやっている歌舞伎座での 落ち着いた空気とは全く違うじゃ ないか！ でも待てよ、昔の歌舞伎はこう だったのでは？
- 129. 129 • 早速親父(十七代目 中村 勘三郎)に直訴 これこそ歌舞伎の原点だ。 歌舞伎もこれに戻らなきゃいけない。 俺もあのような歌舞伎がしたい。 百年早い。 そんなことを考えてる間に百回稽古 しろ。
- 131. 131 • 父の言う「百年早い」の意味が分かった 古典をしっかり学んで自分の形を作 れ。 19や20の未熟者が土台もないのに 新しいことをやるな。 • 2000年(45才)に平成中村座を上演
- 134. 134
- 135. 135 • 同時に、あ、こういうモデルを考えだすのって、そんなご大層なも のじゃないんだとか思った • こんなん自分でも考えられるぜ！って言いたいのではなくて超 頭いい人が美しい理論のもとに弾きだした答えではなく、僕の ような普通の人が苦しみ苦しみ抜いてその時々考えたことを 集めて体系化したという意味でなんだかすごい身近に感じた。 • というか、今自分のチームでも自分たちなりのKAIZENをいろ いろしてるし、それをまとめればそれだけでひとつのモデルに なるなー http://daily.belltail.jp/?p=1880
- 136. 136 そうなんです！
- 140. 140 まとめ
- 141. 141 • まずはしっかりと型を学ぼう(守) • 型をしっかりと身に付けた上で、 現場の改善に取り組もう(破) • 取り組んだ内容を体系化し、開発 モデルとしてアウトプットしよう
- 144. 144 コインゲーム ワークショップ
- 145. 145 ■ルール 利き腕と逆の手を使う 1枚ずつコインを全て裏返す 1人が最初の山と同じ状態にしたら、次の人が作業に入れる ■ステップ 1) 戦略を考えて作業時間を見積もる(60秒) 2) 見積もりを報告 3) 作業時間を計測する 4) 作業時間を報告 5) ふりかえり(60秒) 6) 1に戻る(5回実施します)
- 146. 146 新企画、新機能開発の進め方
- 153. 153 リーンスタートアップとは
- 154. 154 リーン・スタートアップについて • 今回お話しする内容は、主にRunning Lean • Running Leanは複数の方法論の組み合わせ • リーン・スタートアップ • エリック・リース • 顧客開発＋アジャイル開発＋リーン手法 • 顧客開発 • スティーブ・ブランク • 「アントレプレナーの教科書」 • 建物の外に出よ。 • ブートストラッピング • ビジョイ・ゴスワミ • 顧客からの収益で資金をまかなう
- 155. 155 • Running Leanの本質は、3つの手順に分けられる 1. プランAを文章化する 2. プランで最もリスクの高い部分を見つける 3. プランを体系的にテストする ※RUNNING LEAN 2nd Edition P.165 Figure 14-2 から転載
- 156. 156 手順1.プランAを文章化する • 顧客を考えるフェーズ • リーン・キャンバスを書く • 最初は1枚のキャンバスにまとめる • その後、顧客セグメントごとにリーン・ キャンバスを書く • まずは一気に書く(15分以内) • 空欄があっても良い • 簡潔に書く • 今分かる範囲で書く
- 157. ※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載 リーン・キャンバス
- 158. 158 手順2.プランで最もリスクの高い部分を見つける • リーン・キャンバスを順番に並べて、どのビジネスモ デルから手を付けるかを決めるフェーズ • 最も大きなリスクは、誰も欲しくないものを作ること • リスクはステージによって決まる • スタートアップには3つのステージがある 課題/解決フィット 製品/市場フィット 拡大 ※RUNNING LEAN 2nd Edition P.8 Figure 1-3 から転載
- 159. 159 第1ステージ：課題/解決フィット(P/S Fit) • 解決に値する課題はあるか？ • アイデアは安くても、それに取り組むコストは高い • それは顧客が必要としているものですか？(必 要性) • 顧客はお金を支払ってくれますか？支払ってくれ ないのであれば、誰が支払ってくれますか？(成 長性) • それは解決可能ですか？(実現性) リーン・スタートアップについて
- 160. 160 第2ステージ：製品/市場フィット(P/M Fit) • 誰かに必要とされるものを構築したか？ • そのソリューションがどれだけ課題を解決しているか をテストする • 定性的に検証する • 定量的に検証する 第3ステージ：拡大(Scale) • どうやって成長を加速させるのか？ リーン・スタートアップについて
- 161. 161 • リスクは3つのカテゴリに分けられる • 製品リスク(P) • 顧客リスク(C) • 市場リスク(M) ※RUNNING LEAN 2nd Edition P.50 Figure 4-1 から転載 リーン・スタートアップについて
- 162. 手順3.プランを体系的にテストする • 検証による学習ループ(実験)を行うフェーズ 1. アイデアや仮説を用意 2. 仮説をテストする製品を構築 3. 製品を顧客に提示して、反応を定性的、定量的 に計測 4. このデータを仮設の検証、反証の学習に使う 5. 再び構築に戻る リーン・スタートアップについて
- 163. BMLループ
- 164. ステージ＼リスク 製品リスク(P) 顧客リスク(C) 市場リスク(M) 第1ステージ 課題/解決 フィット (P/S Fit) 課題を 理解する 解決に値する課題 かどうかを確認する 不満を持っている 人を特定する 既存の代替品から 競合他社を特定し、 ソリューションの価 格を設定する ソリューション を決定する 最小限のソリュー ション(MVP)を決定 する 製品を今すぐに欲 しいと思うアーリー アダプターに範囲 を狭める 顧客の声を聞いて、 価格をテストする (口約束) 第2ステージ 製品/市場 フィット (P/M Fit) 定性的に 検証する MVPを構築して、小 規模に検証する (UVPのデモ) アウトバウンドチャ ネルから開始して も構わない 顧客の行動を見て、 価格をテストする 定量的に 検証する 大規模に検証する 少しずつ拡大可能 なインバウンドチャ ネルも構築/開発 する ビジネスモデルが うまくいくように、 コスト構造を最適 化する
- 165. ステージ(イテレーション)毎に実際にやること 1. 課題を理解する • 見込み客を見つける • 課題インタビュー • 学習すべきこと • 製品リスク：何を解決するのか？(課 題) • 市場リスク：競合は誰なのか？(既存 の代替品) • 顧客リスク：誰が困っているのか？ (顧客セグメント)
- 166. 2. ソリューションを決定する • デモを構築する • ソリューションインタビュー • 学習すべきこと • 顧客リスク：誰が困っているのか？(アー リーアダプター) • 製品リスク：課題をどのように解決するの か？(ソリューション) • 市場リスク：どのような価格モデルにする のか？(収益の流れ) • MVPを構築する ステージ(イテレーション)毎に実際にやること
- 167. 3. 定性的に検証する • ダッシュボードを構築する • MVPインタビュー • 学習すべきこと • 製品リスク：製品の魅力は何か？(独自の 価値提案) • 顧客リスク：十分な顧客はいるか？(チャネ ル) • 市場リスク：価格は適正か？(収益の流 れ) • UVPを実現する • 顧客ライフサイクルを検証する ステージ(イテレーション)毎に実際にやること
- 168. 4. 定量的に検証する • 機能を制限する • 追加機能は独自の価値提案(UVP)を薄める • 進捗を計測する • 初期のトラクションを達成する • ユーザーの40%が定着 • ショーン・エリスのテストを通過 • 製品が使えなくなった時残念に思うか？ • 成長エンジンを特定する • 粘着型：高い定着率 • ウィルス型：高い紹介率 • 支出型：高い利益率 ステージ(イテレーション)毎に実際にやること
- 169. 169 • 作ってみなくても分かることは多々ある • やみくもに作らない • 作らずに検証できないか考える • 作る場合でもMVPを意識する • ケチな考えを持つ • 自分のお金でも作りますか？ • 課題ありき、顧客ありきで考える • ソリューションありきでは無い なぜ導入したいのか？
- 171. 171 リーンキャンバス ワークショップ
- 173. ※RUNNING LEAN 2nd Edition P.27 Figure 3-1 から転載 リーン・キャンバス
- 174. 174 • テーマは以下の3大欲求から選択 • 英語 • ダイエット • お金 • 1～5の順に書いてみる 1. 課題 • 既存の代替品 2. 顧客 • アーリーアダプター 3. 独自の価値提案 • ハイレベルコンセプト 4. ソリューション 5. 圧倒的な優位性 書いてみよう(個人)
- 177. 177 インセプションデッキ • 10の手強い質問と課題から構成されている • 関係者全員の認識を合わせるために実施 • テンプレート • https://github.com/agile-samurai- ja/support/tree/master/blank- inception-deck
- 178. 178 背後にある考え 「しかるべき人をみんな同じ部屋に集めて、プロ ジェクトにまつわる適切な質問をすれば、自分た ちのプロジェクトに対する期待を共有して、認識 を合わせることができるはずだ」 作成にあたっては、ステークホルダーを巻き込むこ とがとても重要 インセプションデッキ
- 179. 我々はなぜここにいるのか? • 大事な理由 #1 • 大事な理由 #2 • 大事な理由 #3 <#1 reason for doing this project>このプロジェクトを行う最大の理由をここに
- 180. エレベーターピッチ • [必要性や機会を記述]を望んでいる • [対象顧客]にとって • [プロジェクト名]は • [製品カテゴリ]に属しており • [キーベネフィット, 購入への説得力ある理由]がある. • [他の主要な競合製品]と違って • 我々のプロジェクトは[主要な違いの記述]がある.
- 184. テクニカルソリューション 危険! 範囲外 技術: - <言語> - <ライブラリ> - <ツール> - <その他技術要素>
- 185. 夜も眠れないようなこと • <恐ろしいこと #1> • <恐ろしいこと #2> • <恐ろしいこと #3>
- 186. どのくらい大きいのか？ 出荷! 構築 UAT トレーニング ~3ヶ月 1週間 1 週間 これは想定です. 約束ではありません.
- 187. トレードオフ スライダー 典型的な４つの分類 フィーチャーが完了すること(スコー プ) 予算内に収まること(予算) 時間通りに納入すること (時間) 高い品質、少ないバグ(品質) ON OFF その他の大事なこと 簡単に使えること 考えさせない! 詳細な証跡(なんでもログを取る) <好きなのをいれる> ON OFF ON OFF ON OFF ON OFF ON OFF ON OFF ON OFF
- 188. 最初のリリース 出荷! 構築 UAT トレーニング ~3ヶ月 1 週間 1 週間 3 人, 3.5ヶ月, 250Kドル
- 195. 195 早速チームでやってみよう！
- 196. 196 朝起きてから家を出るまで ■ステップ 1)ストーリーカードを書く 2)マッピングする 体験順に時系列で左右に整理 似た機能は上下に整理 基本機能は上へ、派生的な機能は下へ 3)フィーチャ(機能)名をつける 時系列のグループ毎に名前を付ける 今回、アクティビティ名はつけません
- 198. 198 ふりかえり
- 200. 200 ふりかえりをやってみよう(チーム) ■ステップ 1) Keepを付箋紙に書く 今日聞いて良かったこと、これからも続けたいこと チームの皆に発表しながら貼る １人１枚交代、全員が無くなるまで回す 2) Problemを付箋紙に書く 今日気付いた問題点(個人、チーム、講義など) チームの皆に発表しながら貼る 3) Tryを付箋紙に書く 今後取り組みたい、改善したい、より良くしたいこと チームの皆に発表しながら貼る 4) Tryの中から１枚だけTodoを選び、チームの皆にコミットメント 5) ふりかえりのサマリーをチーム毎に発表
- 201. 201 まとめ
- 203. 検査 適応 透明性
- 204. 204 おわり