1. アジャイル開発の勘所 〜Scrum、XP、ツール、そして組織〜 h"p://bit.ly/QqERbo 2012/10/5 #javafesta Ryutaro YOSHIBA
2. 吉羽 龍太郎 Ryutaro YOSHIBA アジャイルコーチ Web: http://www.ryuzee.com Twitter: @ryuzee 認定スクラムプロフェッショナル 認定スクラムマスター 認定スクラムプロダクトオーナー Microsoft MVP for Visual Studio ALM
6. 2013/1/15-16 at Akihabara UDX Scrum Alliance Regional Gathering Tokyo 2013 http://bit.ly/LtunLe
8. http://bit.ly/ptKnqR 企業のおかれた状況
11. 以前の競争 http://bit.ly/rioQDZ
13. 迅速な 意思決定 が必要 http://bit.ly/pccwAN
14. 意思決定をもと に素早く 具現化する必要 http://bit.ly/r1ziWL
16. 変化への対応 “事前に綿密” にたてた計画を “長期間遵守” して大丈夫なのか？
17. 変化への対応 “変化が起こる” ことを前提に “頻繁に軌道修正” することが必要 http://bit.ly/oX9ImQ
18. 変化に対応できなけれ ばマーケットから 見捨てられる
19. 価値がなくなれば滅びる http://bit.ly/qJg8EX
21. プロセス プロダクト イノベーション イノベーション http://bit.ly/qpjFXr http://bit.ly/ornfUo
22. マインド イノベーション http://bit.ly/nrDcZf
24. 顧客が説明した要件 顧客が本当に必要 だった物
25. 従来型の開発モデル 受⼊テスト 要件定義 基本設計 総合テスト 詳細設計 結合テスト 実装・単体テスト V字モデル
26. 従来のやり⽅でありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重⼤な問題が出ています 受⼊試験でニーズ不⼀致が判明 リリースできません 多くのリスクが後半に顕在化 http://www.flickr.com/photos/kwazar/2289418010/
27. 付加価値を 高めない 各種現象や 結果を ムダ と呼ぶ
28. ü 作り過ぎのムダ ü 手待ちのムダ ü 運搬のムダ ü 加工のムダ ü 在庫のムダ ü 動作のムダ ü 不良をつくるムダ
29. システムの機能の利⽤割合 いつも使う 7% よく使う 13 % 45 % たまに使う 16 % ほとんど使わない 19 % まったく使わない Standishの2000年の調査より
30. http://bit.ly/olku51 64% の機能は、使われない
31. Agileな開発 してますか？ http://bit.ly/shZMnK
32. アジャイルマニフェスト 1. プロセスやツールより人と人同士の相互 作用を重視する。 2. 包括的なドキュメントより動作するソフ トウェアを重視する。 顧客満足を最優先し、 価値のあるソフトウェアを 3. 契約上の交渉よりも顧客との協調を重視 する。 早く継続的に提供します。 4. 計画に従うことよりも変化に対応する ことを重視する。
33. マーケットに製品 を早期に投入して 投資を回収し利益 に結びつける必要 性がある
34. フィーチャー駆動・ スコープ駆動から価 値駆動へ。ビジネス 価値を評価せよ
35. 会場調査 • • • • • • • 頻繁にリリースを⾏って価値を届けている 仕事のやりかたは⾃分たちで決められる ユニットテストを書いている 結合テストを⾃動化してる 継続的インテグレーションサーバを使っている デプロイを⾃動化している 環境構築を⾃動化している 全部できている方は 帰って大丈夫ですｗ
36. 一日にしてならず http://bit.ly/vPmiFJ
37. No Silver Bullet† http://bit.ly/vj0b0v
38. 自分たちのプロセス は自分たちで進化さ せるしかない！ http://bit.ly/sygcE9
39. しカ てイ るゼ ？ン h6p://bit.ly/xKgVwh
40. Inspect and Adapt h6p://bit.ly/zkrl3t
41. 我社も(Agile Scrum XP)やればうまくいく! (ﾟДﾟ)ﾊｧ?
43. 守破離 http://bit.ly/qRvi51
44. チームの能力を 最大限に発揮する h6p://bit.ly/zLyLc0
48. Don't Do Agile, Be Agile
49. Scrumとは？ 可能な限り価値の高いプロダク トを生産的かつ創造的に届ける ためのもの
51. 参考リソース http:// www.scrum.org/ scrumguides/
52. 複雑で変化の激しい 問題に対応するための 仕事の進め方
53. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (6±3⼈) 製品の利⽤者、出資者、管理職 などの利害関係者。鶏と称す プロダクトの開発を⾏う。 製品の成功に向けて最⼤限 の努⼒をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒積もり。 項⽬の追加はいつでも⾃由だが実施有無や優 先順位はPOが決める。 毎⽇チームが以下の３つの質問に答える ・昨⽇やったこと ・今⽇やること ・困っていること バーンダウンチャート 完了の定義 何をもって「完了」とするかを 定義したリスト スプリント計画会議 スプリントタスクの「推定残り時間」を 更新してグラフにプロットする スプリント プロダクトバックログを再度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬ をタスクにばらす 最⼤4週間までのタイムボックス 各スプリントの⻑さは同⼀。この間は外部 からの変更を受け⼊れない タスク 時間で⾒ 積もり 毎⽇の繰り返し スプリントバックログ そのスプリント期間中に⾏う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する レトロスペクティブ スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
54. 同じペースで!! 誤 #1 #3 #2 #N 正 #1 #2 #3 #N
55. ⼤事なものは先に！ 1番⽬にほしい 2番⽬にほしい 3番⽬にほしい 4番⽬にほしい 5番⽬にほしい 99番⽬にほしい 100番⽬にほしい 欲しいものを リストにして 順位をつける。 順位は状況に よって変わる。
56. 出荷可能？ 部品だけでは出荷できない 小さくても使えるものを作る
57. 出荷可能？ これもあれもでき てないじゃない？ ここまでできれば 終わりだと思って たんだけど…
58. モノを作る チームで進める http://bit.ly/N4I8LV
59. 成果物の頻繁な確認 1番⽬にほしい 2番⽬にほしい 3番⽬にほしい 4番⽬にほしい 5番⽬にほしい 99番⽬にほしい 100番⽬にほしい よし頼んだ通りなのでOKです。 完了だ！ あれ、ここクリックすると遷移先 が違うね。これは未完了 あ、こうなるのか。頼んだ通りだ から完了だけど、次のスプリント で機能追加しようか！ この感じだと、秋ごろリ リースかな。次のスプリ ントはこの内容でどう？
60. フィードバックループ 短いスプリント単位で 頻繁に確認と調整を行い 製品をよりよくする もちろん仕事の やり方ももっと うまくできるはず
61. 繰り返す… #1 #2 #3 #N タイムボックスを繰り返して ü POがほしいものから順に ü 出荷可能な製品を届け続ける ü うまく届けられるように改善 し続ける
62. Scrumで技術面が大事ではな いなんて一言もいってない
63. 共通理解 完了の定義を作り、何をもっ て出荷可能かを定める。 コード レビュー チェックイン ユニット テスト カバレージ ドキュメント セキュリティ 性能 デプロイ 技術面も当然大事 →XPと組み合わせる などなど
64. XP – 19個のプラクティス 反復 テスト駆動開発 責任 ストーリー作成 メタファー ペアプロ 擁護 リリース計画 作業空間 リファクタリング 四半期毎の 見直し 受け入れテスト ふりかえり コードの 共同所有 ミラー 短期リリース 継続的インテグ レーション YAGNI 持続可能な ペース
65. Kent Beck h6p://bit.ly/QqTATG
66. ITアーキテクト「機能テストの⾃動化について考える」 より引⽤ http://www.itarchitect.jp/print/?menu3=24601 テスト自動化の損益分岐点 は相当早期にある感覚
67. Scrum＋XP ü Scrumではフレームワークの定義のみで、テスト ⾃動化については触れられていない.しかしアジャ イル開発においてはテスト⾃動化は必須 ⼩規模リリー スのたびに⼿ アジャイルかウォーターフォールかという話では 動でテストす るとコード なく、現代のソフトウェアのライフサイクルを考 ベースが⼤き 慮すると、テスト自動化は当然の流れと言える くなるにつれ てテストコス トが膨らむ ⾃動化しないとソフトウェア規模に応じて、テスト⼯数の占め る割合が増加してき価値への投資が減少する
69. テスト⾃動化バックログ プロダクトバックログ テスト⾃動化の進め⽅ スプリント バックログ レガシーコードにおい て、製品コードの開発 をとめて自動化のみへ 投資するのは現実的に 難しいので、投資割合 をきめて、予めバック ログに組み込むことが 望ましい
70. Agileテストの4象限 ビジネス⾯（ビジネス的品質） 【⾃動と⼿動】 ー チ 機能テスト Selenium ストーリーテスト Cucumber プロトタイプ Rspec シミュレーション FitNess … CI推奨 第２象限 ム を ⽀ 【⾃動化】 援 単体テスト コンポーネントテスト TDD xUnit PMD, CPD … CI必須 第１象限 【⼿動】 探索的テスト シナリオテスト ユーザビリティテスト ユーザー受⼊テスト アルファ版、ベータ版 ⼀部CI可能 第３象限 【ツール】 パフォーマンステスト Jmeter 負荷テスト WebScarab セキュリティテスト RatProxy ValGrind … CI推奨 技術⾯（技術的品質） 第４象限 製 品 を 批 評
72. 毎日何回も本番環境にデプロイで きているか？ 顧客に頻繁に価値を届けられてい るか？
73. http://bit.ly/shZMnK デプロイするたびに人手 で全体をテストするのは 無理
74. 清水の舞台から 飛び降りない http://bit.ly/tnB8i0
75. 継続的デリバリー 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ 継続的デリバリーとは、ソフトウェア全体のライ フサイクルを通じて常にソフトウェアが本番環境 にリリース可能であるということを意味する。 すなわちどのビルドもボタン一発で、完全に自動 化されたリリースプロセスを通じてリリースする。 それによってビジネス側がビジネス状況に応じて リリース判断できるようになる。
76. 継続的デリバリー 継続的デリバリー 繰り返し型の 開発 継続的 インテグレーション 継続的 デプロイ Scrum u 要求に順位付け u タイムボックス による制御 u 検査と適⽤によ る継続的改善 u 透明性の確保 u ⾃⼰組織型チー ム u 技術的プラク ティスの定義な し Scrum＋XP u xUnit等による テスト⾃動化 u テスト駆動開発 u コーディング規 約 u ペアプロ等 u 常時出荷可能な 品質を保持 u 主に技術的プラ クティスから構 成される Lean u Just in Timeで 顧客が必要なも のを必要なとき に。 u サイクルタイム を測定し改善す る。 u ビジネス活動そ のもの u 全体最適
78. 通常のリリース ü テストが完了してから リリースまで1日以内？ ü テストが完了してから リリースまで3日以内？ ü テストが完了してから リリースまで1週間以内？ ü それ以上かかる？ h6p://bit.ly/wo4eyD
79. 障害時のリリース ü テストが完了してからリリースまで1日以内？ ü テストが完了してからリリースまで3日以内？ ü テストが完了してからリリースまで1週間以内？ ü それ以上かかる？ h6p://bit.ly/zeFv2G
80. 障害時に1日でリリース できるのであれば、 今のリリースプロセスに は組織的なムダがある
81. ワンクリックでデプロイできたと しても、リリースの意思決定に時 間がかかったら無意味！ http://bit.ly/rZyM3H
82. ツール導⼊アンチパターン ü 全社で標準を作成したので○○を使え！ ü ○○で他の会社はうまくいったらしいの で使おう！
83. 唯一の例外 バージョン管理は 開発者のしつけ http://bit.ly/utD8aA
84. ツール導⼊のプロセス ü いまのプロセスがどうなってい るかを明らかにする(現状分析) ü 改善したいポイントをチームで 整理する ü ツールでカバーした方がよい箇 所と、それ以外の箇所の整理 ü ROIの高い箇所から改善してい く(初期、保守、教育のコスト を踏まえる) ü 複数のオプションがあれば評価 する
85. 例えば要求の管理に問題？ ü なにが問題なんだろう？なぜ問題なん だろう？ ü あるべき要求管理はどんな方法か？ ü それはプロジェクトに適用可能か？ ü それはツールによってカバーできる？ ü いままでより作業が増えたり、効率が 落ちることはないか？ ü 投資が必要な場合、どのくらいで回収 できる？
86. ⼤事なこと ツールによって 対面のミーティングがなくなる わけではない
87. MSにおけるデイリースクラム h6p://bit.ly/LGDhk6
88. ツール導⼊を成功させる ü みんなが分からない状態で の導入は大変 ü ツールとプロセスの同時学 習のコストへの考慮 ü 導入バックログ(優先順位 付け) ü 社内外からのプロジェクト 支援体制の確立
89. h6p://bit.ly/yFe3Za 組織における問題点
90. 組織規模の拡大 →問題の深刻化 h6p://bit.ly/xHSLfl
91. 組織分割における 顧客価値との不一致 h6p://www.flickr.com/photos/_suika/3913063515/
92. h6p://www.youtube.com/watch?v=4u5N00ApR_k リリースは2週間に1回で、 かつ2週間前までに申請してく ださい。 規則で決まってるし、 忙しいんです。 もっと頻繁に すぐできないの？ ü 規則の意図が理解されず、ただ制約化される ü 仕事のための仕事？？？
93. チーム解体による 連続性の放棄 h6p://bit.ly/zjyVUl
94. 稼働率という名の幻想 h6p://bit.ly/AiGcma
96. マルチタスクのムダ マルチタスクは脳にとってよくないことが証 明されている
97. 複数プロジェクトの兼任はムダ ü マルチタスクはストレスの原因になる ü マルチタスクはエラーを起こしやすい ü 従って仕事の質が低下する ü タスクの切り替えは高コスト ü 中途半端なタスクは全て未完了
98. チームを強く保つ h6p://bit.ly/ygbMSj
99. 常に 改善する 責任 http://bit.ly/mRLszj
100. プラクティス の採用理由を チームや 顧客や ステークホル ダーに 説明する責任
101. http://bit.ly/ovenYk 自己組織化されたチームで仕事を できるようにするためには、 外部からのマイクロマネジメント を止める必要がある。
102. ⾃⼰組織化 ü 上司は責任とチームで解消で きない問題の解決を担う ü 上司は後方支援、ファシリ テーター役になる ü チームを信じる http://bit.ly/r0Lc8F
103. リーダーや管理職の役割の変化 ü 従来の役割や振る舞い ü 求められる役割や振る舞い ü ピラミッド組織 ü ネットワーク型組織 ü コマンド・コントロール ü 自律・自発の支援 ü 権威的 ü 民主的 ü 流動性がない ü 流動性のある ü 答えをいう ü 導く ü 叱る ü 褒める ü 否定 ü 肯定 ü マイクロマネジメント ü チームの自主性に任せる
104. 権限の7レベル ü 指示する ü 売り込む ü 相談する ü 同意する ü アドバイスする ü 問い合わせる ü 移譲する
106. http://bit.ly/pdq0xn 全てのアジャイルなプロセスはチームへの 権限移譲とチーム内での文化および規範の 確立を必要とする
107. http://bit.ly/qEBgGV 組織の多様性は強さ
110. ⾃分のくだらない組織に どう対処すればいいか？ • 無視する • 仕事をやめる • チェンジマネジメント について学習する
111. “Scrum is a framework for surfacing organizational dysfunction.” Tobias Mayer Scrumは組織の機能不全を明るみに 出すためのフレームワークである
112. スクラムマスターは 解雇されて一人前！ h6p://bit.ly/xnoOUO
113. Agileな開発 してますか？ http://bit.ly/shZMnK
114. 健闘を 祈ります h6p://bit.ly/zJczAB
