ウォーターフォールとアジャイルを考える #ita_ws
•
13 recomendaciones•16,759 vistas
2016/6/21に開催した勉強会「ウォーターフォールとアジャイルを考える」の資料とワークのディスカッションメモです。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ウォーターフォールとアジャイルを考える #ita_ws
Similar a ウォーターフォールとアジャイルを考える #ita_ws (20)
Más de Yusuke Suzuki
Más de Yusuke Suzuki (13)
Último
Último (8)
ウォーターフォールとアジャイルを考える #ita_ws
- 1. アジャイルと ウォーターフォールを考える 2016/6/21 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 ITアーキテクトワークショップ #ita_ws
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. はじめに 今日、話さないこと • 顧客との信頼関係構築とか • 精神論 »広義のアジャイル的ななにか • 多重下請けとか契約とか分業とか • ただ、例のあれには言及します 2
- 4. アジェンダ • プロジェクトマネジメント • ウォーターフォールのアプローチ • アジャイルのアプローチ • アーキテクチャのこと • 例のあれ 3
- 6. プロジェクトマネジメント 目標達成のための活動 • プロジェクトとは、独自の製品、サービス、所 産を創造するために実施される有期性の業務 »特定の成果を達成するために組織 »期間が限定されている ： 有期性 »個別にユニークで同じものはない ： 独自性 »相互に関連する作業の調整がなされる：相互関連性 • 対としては「プロダクト」 »プロダクトが終了までの継続的な活動 5
- 7. プロジェクトマネジメント 基本はPDCA • 計画する：QCDSを決める • 実行する：計画従って作業する • 計測する：計画と実績のズレを測る • 調整する：ズレに対応する（QCDSの変更） ※QCDS：Quality（品質）、Cost（費用）、Delivery（期限）、Scope（機能） 6
- 8. プロジェクトマネジメント 失敗あるある • 計画の失敗：そもそも計画が正しくない • 実行の失敗：計画された通りに作れない • 計測の失敗：正しく進捗を測れない • 調整の失敗：ズレがあっても調整できない 7
- 11. ウォーターフォール 10 立ち上げ 計画 実行 監視・コントロール 終結 統合 計画策定 計画実行 統合変更管理 スコープ （目的と範囲） 立ち上げ スコープ計画/定義 スコープ検証/変更管理 時間（期間） アクティビティ定義/順序設 定/期間見積 スケジュール作成 スケジュールコントロール コスト（予算） 資源管理 コストの見積/予算化 コストコントロール 品質 品質計画 品質保証 品質管理 人的資源 組織計画 要員調達 チーム育成 コミュニケー ション コミュニケーション計画 情報配布 実行報告 完了手続き リスク リスク・マネジメント計画 リスク識別 定性的/定量的リスク分析 リスクの監視・コントロー ル 調達 調達/引合計画 引合 発注先選定 契約管理 契約完了 ステークホル ダー 特定 ステークホルダー計画 関与促進 関与のコントロール 計画 実行 調整
- 13. ウォーターフォール PDCAをフェーズで管理する • 計画：全体を定義し、計画立案 • 実行：計画に沿って実行 • 計測：計画従って実績を監視 • 調整：計画と実績のズレをコントロールする • フェーズで管理する »プロジェクトのライフサイクルをフェーズに分ける »フェーズごとに完了判定し、次に進む（進まない） 12
- 14. ウォーターフォール ウォーターフォールあるある • 計画の失敗：そもそも計画が正しくない • 実行の失敗：計画された通りに作れない • 計測の失敗：正しく進捗を測れない • 調整の失敗：ズレがあっても調整できない • フェーズが完了していないのに次に進む »そもそも完了基準も完了判定も曖昧で、結局、日付 でしか見てない 13
- 15. アジャイルの アプローチ 14
- 16. アジャイル ウォーターフォールへの反省（私見） • 最初の計画がある程度は正しい必要がある »計画通りが前提で、どうしてもバイアスがかかる • 最初にフェーズやプロセスへの分解が行われて しまうので、それを実行することが目的化する • PMが知識職になってしまった »本来は技術的な計画能力と政治的な調整能力が重要 なはず 15
- 17. アジャイル 逆転の発想 • 計画：精度が出るぐらい小さな計画にする • 実行：計画通りに実行する • 計測：計画終了時に動くソフトウェアで判断 • 調整：定期的に関係者全員で話し合う »実行中にはスコープ調整は行わない • 失敗するにしても範囲が小さい »うまくいかないことも成果の1つ 16
- 22. アジャイル アジャイルでないもの • マネジメントがないもの »マネジメント＝計画＞実行＞計測＞調整 • コミュニケーションが健全でないもの »顧客も含めたチームとの信頼感は前提 »必要なドキュメントは作るべき • これはウォーターフォールでも同じ 21
- 23. アーキテクチャのこと 22
- 27. 例のあれ 26
- 28. 例のあれ 27
- 30. まとめ 29
- 31. まとめ 基本はPDCA • 計画する：QCDSを決める • 実行する：計画従って作業する • 計測する：計画と実績のズレを測る • 調整する：ズレに対応する（QCDSの変更） ※QCDS：Quality（品質）、Cost（費用）、Delivery（期限）、Scope（機能） 30
- 32. まとめ ウォータフォール • 計画：全体を定義し、計画立案 • 実行：計画に沿って実行 • 計測：計画従って実績を監視 • 調整：計画と実績のズレをコントロールする • フェーズで管理する 31
- 33. まとめ アジャイル • 計画：精度が出るぐらい小さな計画にする • 実行：計画通りに実行する • 計測：計画終了時に動くソフトウェアで判断 • 調整：定期的に関係者全員で話し合う »実行中にはスコープ調整は行わない • PMがいない、フェーズがない 32
- 36. まとめ ウォーターフォールかアジャイルか • マネジメント手法は道具 • 道具の適用を判断するのは人間 • 個別の現場の文脈で正しい判断をしてください 35
- 40. とはいえWFを採用するケースは？ • メンバーの力量が読めない場合 • 約束されたリリースがある（法律改定など） • スコープが確定的 • 基幹システム連携がある（基幹側がWF） • チームやプロジェクトが永続的ではない • パッケージの横展開 • 発注者が公共（計画レビューありき） 39
- 41. とはいえWFを採用するケースは？ • 実現性検証が十分にできている • 研究開発ではない • 期間に対して量が多い（大量要員投入が必要） • 業務のパターンが読み切れている 40
- 42. なぜアジャイルにできない？ • 保守開発（メンバーが決まっている）なら、や りやすい • パッケージベンダーの指定でアジャイルをやっ たが、うまくいかなかった • そもそもユーザー/開発者にやる気がない »都度「スコープを決めて見積もり」という仕事の仕 方では難しい »開発会社としても、年初に請負の売上計画を作るこ とになるとWF型にしたくなる ▸かといって、派遣契約はモチベーションが下がるからいや 41
- 45. アジャイルとはいえ、PMっぽい人が必要になるケ ースがある • 全体計画を見る人が必要になる場合はいる • 進捗がぐずぐずになるチーム/人がいる場合 »毎回、見積もりに失敗するチーム/人がいた »それぐらい「どう？」って声をかける人がいれば十 分では • なんらかの仕切ったりが必要になる場合にいる • 全体的な要求コントロールが必要な場合 »プロダクトオーナーがやるべきでは？ »WF慣れしたPOがやるとスコープが無限に広がる 44
- 46. アジャイルとはいえ、PMっぽい人が必要になるケ ースがある • 逆にPMでも手を動かすのが好きならアジャイ ル型がいかもしれない • チーム同士が仲が悪くて調整役が必要になった 場合 • スクラムマスターやプロダクトオーナーとの違 いは？ »お世話係ならスクラムマスターでいいのでは »現場に手を出し始めたらスクラムマスターがPMっぽ くなっちゃう 45