2. 環境の変化 ü ビジネスの速度が爆速に – 新しいことを – 競争相⼿がやる前に ü チャレンジングな領域が増える – R&D – 新規サービス – それ儲かる？ ü 物事の予測の精度は？ – ⾼いはずがない…
4. 全てを予測することはできない h"p://bit.ly/LT89jU
5. ソフトウェアの不確実性 ü 不確実性コーン From 10 Deadly Sins of Software Estimation by Steve McConnell, ©2002-2007
6. 変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
7. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
8. システムの機能の利⽤割合 いつも使う 7% よく使う 13 % 45 % たまに使う 16 % ほとんど使わない 19 % まったく使わない Standishの2000年の調査より
9. http://bit.ly/olku51 64% の機能は、使われない
10. アジャイルマニフェスト 2001年に、ケント・ベック、マーティン・ファウ ラー、ケン・シュウェイバーら、17⼈によって採択 されたAgileソフトウェア開発の原則を指す。
11. アジャイルマニフェスト 1. プロセスやツールより人と人同士の相互 作用を重視する。 2. 包括的なドキュメントより動作するソフ トウェアを重視する。 顧客満足を最優先し、 価値のあるソフトウェアを 3. 契約上の交渉よりも顧客との協調を重視 する。 早く継続的に提供します。 4. 計画に従うことよりも変化に対応する ことを重視する。
12. 従来型と異なるアプローチ リソース と期間で 総量規制
13. AgileとWFの違い 出典：Scaling Software Agility プロセス WF 成功の測定 計画への適合 変化への対応 動作するコード マネジメント⽂化 命令と制御 リーダーシップ 協業的 要求と設計 ⼤きくて前払い 継続的・発現的 ジャスト・イン・タ イム コーディングと実装 全機能を同時開発。後 でまとめてテスト コーディングと UnitTestのセット 順番に納品 テストと品質保証 ⼤きく・計画に基づく PJ終盤に実施 継続的・同時的 早期からテスト継続 計画とスケジュール PERT・詳細・範囲固 定 時間と⼯数を⾒積もり 期⽇固定で範囲を⾒ 積もり。 Command & Control 反復型開発 Agile
14. Scrum 複雑で変化の激しい 問題に対応するための フレームワーク
15. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (6±3⼈) 製品の利⽤者、出資者、管理職 などの利害関係者。鶏と称す プロダクトの開発を⾏う。 製品の成功に向けて最⼤限 の努⼒をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒積もり。 項⽬の追加はいつでも⾃由だが実施有無や優 先順位はPOが決める。 毎⽇チームが以下の３つの質問に答える ・昨⽇やったこと ・今⽇やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更新してグラフにプロットする 何をもって「完了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬ をタスクにばらす 最⼤4週間までのタイムボックス 各スプリントの⻑さは同⼀。この間は外部 からの変更を受け⼊れない タスク 時間で⾒ 積もり 毎⽇の繰り返し スプリントバックログ そのスプリント期間中に⾏う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
16. 組み合わせ ü フレームワークなので、他の⽅法論を取 り⼊れることが可能 State of Agile Survey 2011 ©VERSIONONE
17. ⼤事なものから先に！ 1番⽬にほしい 2番⽬にほしい 3番⽬にほしい 4番⽬にほしい 5番⽬にほしい 99番⽬にほしい 100番⽬にほしい 欲しいものを リストにして 順位をつける。 順位は状況に よって変わる。
18. 優先順位の決め⽅（狩野モデル） ü フィーチャーが実現された場合、 実現されない場合にどう考えるかを ５択で選ぶ Q1:ホテルの部屋に無料のミネラルウォーターが あったらどう思いますか？ 1. とても嬉しい 2. それって普通でしょ 3. 特になんとも思わない 4. 別にそれでも構わない 5. それは困る Q2:ホテルの部屋に無料のミネラルウォーターが なかったらどう思いますか？ 1. とても嬉しい 2. それって普通でしょ 3. 特になんとも思わない 4. 別にそれでも構わない 5. それは困る http://www.flickr.com/photos/darrylh/392577074/
19. プロダクトオーナー ü 製品に必要な機能をとりまとめる ü リリース⽇とリリース内容を決める ü 製品が⽣む利益について責任を持つ 製品のかじ取り役。発注者側か ü 機能の優先順位を定める またはビジネスアナリストが担当 ü 機能と優先順位を⾒直す ü 作業の結果を受け⼊れる、 または拒否する ü スプリントを中⽌できる
20. プロダクトオーナーの役割(まとめ) プロダクトオーナーはプロダクト(製品)の成功についての責任がある。 プロダクト ビジョンを作成し ロードマップを管 理する プロダクトバック ログを整備※する (グルーミング) リリース計画を 策定する ※優先順位付含む プロダクトの 出荷準備を⾏う 予算を管理する 顧客、利⽤者、内 部のステークホル ダーと協調する プロダクト ビジョン プロダクトオーナー プロダクト バックログ プロダクト ロードマップ スクラムマスター やチームと⼀緒に 働く リリース バーンダウン
21. 全体の流れ Sprint Sprint Sprint Sprint Sprint Sprint ü 同じ長さのスプリントを繰り返す ü 各スプリントの最後には出荷可能な製品を 用意する ü 各スプリントの最後にはデモを行う ü 出荷可能＝完了の定義を全て満たしている
22. スプリントの過ごし⽅ ü 基本的に全てのスプリントで同じ過ごし方 をし、全てのイベントを必ず行う ü スプリントに入るためには順位付けされた プロダクトバックログが用意されている必 要がある(スプリント前に準備しておく) ふりかえり スプリントレ ビュー デイリースクラム デイリースクラム デイリースクラム デイリースクラム デイリースクラム デイリースクラム スプリント計画 第⼆部 スプリント計画 第⼀部 スプリント
24. バックログ グルーミング スプリント 計画会議第1部 WHAT スプリント 計画会議第2部 HOW POを中⼼に、製品の開発に 必要なPBIを作成したり、更 新し、並べ替える POとチームを中⼼にスプリ ントで何を作るか選択し相対 ⾒積を⾏う。不明点も明確化 チームを中⼼に選択したPBI をどのようにこなすのか決め 実時間で⾒積もる #1 #1 #2 #2 開発チームにバッ クログを供給する のに必要⼗分なだ け新たに作成した り更新する。それ がないと開発チー ムは仕事ができな い ReadyなPBI • 受け⼊れ基準が明確 • デモ⼿順を決められる • 可能な限り独⽴ • ⾒積可能 • 適切な⼤きさ #3 #4 #5 #6 開発チームの過去 の速度(ベロシ ティ)をもとに取り 組むPBIを決定。 開発チームは内容 に関する質問をPO に⾏う。第2部で作 成したタスクの合 計時間がキャパシ ティを超える場合 は下から除外 受け⼊れ基準とス プリントレビュー で成果を検証 ReadyではないPBI • 受け⼊れ基準が不明確 またはない • デモ⼿順が分からない • ⾒積不可能 • 巨⼤なサイズ 実際の作業タスク。何 が出来たらタスクが完 了するか明らかにする。 個々のタスクはDone の定義の該当箇所を満 たす必要がある Doneの定義 チームとして定めた「出荷可能な製品」を作 成するために実施しなければいけないことの ⼀覧。例えば、ユニットテストする、カバ レージN％、リリースノートを書く等。Done の定義なくしてのScrumはあり得ない。
25. 開発チームのミッション チームは出荷可能な 製品の増分を作り続ける
26. 出荷可能？ これもあれもでき てないじゃない？ ここまでできれば 終わりだと思って たんだけど…
27. 共通理解 完了の定義を作り、何をもっ て出荷可能かを定める。 コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ !!!! ツールの助けが必要 !!!! などなど
28. フィードバックループ 短い時間間隔で 頻繁に確認と調整を行い 製品をよりよくする もちろん仕事の やり方ももっと うまくできるはず
29. 毎日何回も本番環境にデプロイで きているか？ 顧客に頻繁に価値を届けられてい るか？
30. 継続的デリバリー 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ 継続的デリバリーとは、ソフトウェア全体のライ フサイクルを通じて常にソフトウェアが本番環境 にリリース可能であるということを意味する。 すなわちどのビルドもボタン一発で、完全に自動 化されたリリースプロセスを通じてリリースする。 それによってビジネス側がビジネス状況に応じて リリース判断できるようになる。
31. 継続的デリバリー 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ Scrum u 要求に順位付け u タイムボックス による制御 u 検査と適⽤によ る継続的改善 u 透明性の確保 u ⾃⼰組織型チー ム u 技術的プラク ティスの定義な し Scrum＋XP u xUnit等による テスト⾃動化 u テスト駆動開発 u コーディング規 約 u ペアプロ等 u 常時出荷可能な 品質を保持 u 主に技術的プラ クティスから構 成される Lean u Just in Timeで 顧客が必要なも のを必要なとき に。 u サイクルタイム を測定し改善す る。 u ビジネス活動そ のもの u 全体最適
32. Scrum＋XP ü Scrumではフレームワークの定義のみで、テスト ⾃動化については触れられていない.しかしアジャ イル開発においてはテスト⾃動化は必須 ⼩規模リリー スのたびに⼿ アジャイルかウォーターフォールかという話では 動でテストす るとコード なく、現代のソフトウェアのライフサイクルを考 ベースが⼤き 慮すると、テスト自動化は当然の流れと言える くなるにつれ てテストコス トが膨らむ ⾃動化しないとソフトウェア規模に応じて、テスト⼯数の占め る割合が増加してき価値への投資が減少する
33. Agile開発の採⽤例 プロダクト提供企業およびサービス提供企業での採⽤事例が 特に多い。これはビジネスとITが直結しているためである。 多くの企業では従来型のウォーターフォールプロセスと併⽤ しているケースが多い。 また同⼀企業内でも成功事例と失敗事例の双⽅がある状況。 ⼀⽅Sierは顧客要求によって着⼿するケースが多い。
34. 導⼊の決定者 • 海外の場合経営や上級管理職主導の導⼊が多い State of Agile Survey 2010 ©VersionOne より
35. 導⼊の動機 • マーケットへの投⼊時間の短縮と変化への対応 が強い動機になっている State of Agile Survey 2010 ©VersionOne より
36. 導⼊による効果 • 優先順位変更への対応、プロジェクト可視性、 ITとビジネスの融合、Time to Market向上等 State of Agile Survey 2010 ©VersionOne より
37. 導⼊による改善の割合 • 多くの組織でなんらかの改善がみられる Dr.Dobbʼs 2008 Agile Surveyより
38. 採⽤している⼿法 • ⼤多数がScrumを採⽤ State of Agile Survey 2010 ©VersionOne より
39. 導⼊のプロセス ü いまのプロセスがどうなってい るかを明らかにする(現状分析) ü 改善したいポイントをチームで 整理する ü ROIの高い箇所から改善してい く(初期、保守、教育のコスト を踏まえる) ü 複数のオプションがあれば評価 する ü Small Start ü Small Success
40. 導⼊アンチパターン ü 全社で標準を作成したので○○を使え！ ü ○○で他の会社はうまくいったらしいの で使おう！
41. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9 もちろん、現代のソフトウェア開発 プロセスの方向性については、知識 を獲得しておく必要はある！
42. 導⼊を成功させる ü みんなが分からない状態で の導入は大変 ü ツールとプロセスの同時学 習のコストへの考慮 ü 導入バックログ(優先順位 付け) ü 社内外からのプロジェクト 支援体制の確立
44. 顧客・経営層が考慮すべき点 2012/6/25 IPAセミナー資料より抜粋
45. 導⼊時の考慮点 2012/6/25 IPAセミナー資料より抜粋
