イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発~アジャイルとtocの融合

3,011 views

Published on

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,011
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
87
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

イノベーションスプリント2011 nttデータにおける制約理論を活用した分散アジャイル開発~アジャイルとtocの融合

  1. 1. NTTデータにおける制約理論を活用した分散アジャイル開発 ~アジャイルとTOCの融合~ 2011年1月13日 株式会社NTTデータ Copyright © 2011 NTT DATA CORPORATION 技術開発本部 柴山 洋徳
  2. 2. INDEX 1. なぜ分散アジャイル? 2. 事例プロジェクト概要 3. 分散アジャイル開発プロセス概要 4. 分散アジャイル開発プロセス詳細 5. 分散アジャイル開発プロセス適用の結果 6. 今後の挑戦 Copyright © 2011 NTT DATA CORPORATION 1
  3. 3. 1. なぜ分散アジャイル? Copyright © 2011 NTT DATA CORPORATION 2
  4. 4. Keep: アジャイルによる短期開発  近年の短期開発ニーズの増加 ⇒ 開発期間短縮により,お客様へ「ビジネス変化への対応力」という価値を提供 NTTデータ短期開発案件(新規、更改)の件数の変化 (案件数指標) ~2005年度の案件数を100とした場合の比率の変化~ 約2.5倍 300 の増加 250 200 開発期間 150 6~12カ月 100 ~6カ月 50 0 2005 2006 2007 2008 2009 (年度) (NTTデータ社内調査より) 短期開発へのNTTデータの取り組み ~アジャイル開発はその一実現手法~ Copyright © 2011 NTT DATA CORPORATION 3
  5. 5. Problem: グローバルリソースの活用  NTTデータグループにおけるグローバル規模での体制整備 ⇒ グローバルリソース活用により,お客様へ「最高のサービス」という価値を提供 30countries 128cities 20,134members Europe North America 46 cities 49 cities 3600 members 6200 members Asia Pacific 33 cities 11300 members 9000 members in India 2011.1.1時点 グローバルリソース活用へのNTTデータの取り組み ~分散開発はその一実現手法~ Copyright © 2011 NTT DATA CORPORATION 4
  6. 6. Try: 分散開発 + アジャイル開発  徹底した顧客指向の追求を目指して アジャイル + 分散開発 開発 Copyright © 2011 NTT DATA CORPORATION 5
  7. 7. 2.事例プロジェクト概要 Copyright © 2011 NTT DATA CORPORATION 6
  8. 8. 事例システム概要 ● 業務: プロジェクトマネジメントシステム(社内システム) ● 技術: C#,.NET,Microsoft Project, Microsoft Project Server ● アーキテクチャ Webシステム ● 規模 100K Step ● 特徴 ・ Microsoft Project,Microsoft Project Server上のアドオンソフトウェア ・ ベースとなるMicrosoft製品の機能はブラックボックス Copyright © 2011 NTT DATA CORPORATION 7
  9. 9. 事例プロジェクト概要  日本拠点(NTTデータ)とインド拠点(VERTEX)の分散拠点 ・ 日本とインドの各開発チームの役割はほぼ同一 ・ 要求・仕様の決定は日本拠点 ●Tokyo Japan Pune India ● 開発メンバ:8名 開発メンバ:14名 Copyright © 2011 NTT DATA CORPORATION 8
  10. 10. 事例プロジェクト体制  プロジェクトマネジメントコミッティ(PMC)を設置 ・ 日本・インド開発チームのコミュニケーションを円滑にするためのヴァーチャルチーム ・ 重要な意思決定要素(プロセス構築,リリース計画策定etc)はPMCで決定 日本(NTTデータ) インド(VERTEX) 私はここ! Product Owner Delivery Manager PMC SCRUM Master SCRUM Master QA Team QA Team 3名 4名 GUI Team GUI Team 2名 3名 Dev Team Dev Team 2名 5名 Copyright © 2011 NTT DATA CORPORATION 9
  11. 11. 3.分散アジャイル開発プロセス概要 Copyright © 2011 NTT DATA CORPORATION 10
  12. 12. 分散アジャイル開発プロセスのオーバービュー  スプリント: スケジュールの最小単位 (本プロジェクトでは4週間単位)  スプリントの単位で定義された小機能(フィーチャ)の開発を複数完了  QAチームがスプリントにより開発されたフィーチャのテストをスプリント終了後に実施  リリース: 複数のスプリントにより構成する単位(本プロジェクトでは2~3スプリント単位)  リリースの単位で,ユーザ要求視点での大機能(Requirement Sub Group)の開発を完了  QAチームはリリースの単位でテストを行い,Quality Gateをパスしたらリリース リリース イテレーション アーキテクチャ確立 スプリントイテレーション 要 スプリント開発 概要要件 件 (India) テシ 定義 シ スス 要 ス 定 スプリント開発 トテ Quality (リリース 計画) 件 ウォーター フォール テ ム 義 (Japan) ム Release Buffer Gate ×3 定 テ 要 スプリント開発 義 開発 ス 件 (India) テシ ト スス 定 スプリント開発 トテ ム 義 (Japan) Copyright © 2011 NTT DATA CORPORATION 11
  13. 13. スプリント内のオーバービュー  スプリント内開発の特徴  依存関係の強いフィーチャをまとめたグループ(セル)単位で五月雨式に開発  各分散拠点は,要件定義後からは結合テストまでは独立並行に開発 セル単位で五月雨開発 スプリント セル GUI開発 フィーチャ機能実装 結合テスト フィーチャA GUI 仕様 内部 コーディン フィーチャB デモ テスト準備 開発 作成 設計 グ JAPAN セル インタフェース設計 フィーチャ結合テスト フィーチャC シ DB I/F テスト 要 CI ス フィーチャD 設計 設計 準備 テ 件 インテグレー ム 定 セル ション テ 義 ス GUI開発 フィーチャ機能実装 ト フィーチャE GUI 仕様 内部 コーディン フィーチャF デモ 開発 作成 設計 グ INDIA セル 結合テスト インタフェース設計 フィーチャ結合テスト フィーチャG DB I/F テスト CI フィーチャH 設計 設計 準備 Copyright © 2011 NTT DATA CORPORATION 12
  14. 14. 分散アジャイル開発プロセスのコンセプト  コンセプトの特徴  アジャイル開発コンセプトGDD(GUI Driven Development),分散開発コンセプトDD (Distributed Development)にTOC(Theory of Constraints:制約理論)を融合したもの Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 13
  15. 15. 分散アジャイル開発プロセスのコンセプト  コンセプトの特徴  アジャイル開発コンセプトGDD(GUI Driven Development),分散開発コンセプトDD (Distributed Development)にTOC(Theory of Constraints:制約理論)を融合したもの Management As a Service GDD DD TOC アジャイル開発 =短期開発 Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 14
  16. 16. 分散アジャイル開発プロセスのコンセプト  コンセプトの特徴  アジャイル開発コンセプトGDD(GUI Driven Development),分散開発コンセプトDD (Distributed Development)にTOC(Theory of Constraints:制約理論)を融合したもの Management As a Service GDD DD 分散開発 TOC =グローバル Exchan- SCRUM FDD Just リソース活用 ge ACM JIT Release Quality Enough Communi Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 15
  17. 17. 分散アジャイル開発プロセスのコンセプト  コンセプトの特徴  アジャイル開発コンセプトGDD(GUI Driven Development),分散開発コンセプトDD (Distributed Development)にTOC(Theory of Constraints:制約理論)を融合したもの Management As a Service GDD DD TOC 科学的マネジメント Inter- =効率と品質の追求 Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 16
  18. 18. 4.分散アジャイル開発プロセス詳細 Copyright © 2011 NTT DATA CORPORATION 17
  19. 19. 分散アジャイル開発プロセスのコンセプト~GDD  分散アジャイル開発プロセスの「アジャイル面」において中心となるコンセプト  SCRUMの短期タイムボックスマネジメントによって過剰スコープ実現のムリを抑制  FDDによる小機能単位開発により作業量,変更量のムラを低減  GUIベースの開発により仕様検討・ドキュメント作成のムダを排除 Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 18
  20. 20. 分散アジャイル開発プロセスのコンセプト~SCRUM  分散アジャイル開発プロセスの「アジャイル面」において中心となるコンセプト  SCRUMの短期タイムボックスマネジメントによって過剰スコープ実現のムリを抑制  FDDによる小機能単位開発により作業量,変更量のムラを低減  GUIベースの開発により仕様検討・ドキュメント作成のムダを排除 Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 19
  21. 21. 分散アジャイル開発プロセスのコンセプト~SCRUM  Time-box Management  1スプリント=4W  要件変更・仕様変更は一切禁止  全権限を開発チームに委任.自律性を重視した自由な開発  遅延への対策はスコープ調整 スプリント1 GUI開発 フィーチャ機能実装 スプリント 要件定義 結合テスト インタフェース設計 フィーチャ結合テスト スプリント2 スプリント3 【ワンポイント】 要求変更,仕様変更は丌可避なものと考える. 変更は開発作業を止めると同時に,開発者のモチベーション(生産性)を下げる. Copyright © 2011 NTT DATA CORPORATION 20
  22. 22. 分散アジャイル開発プロセスのコンセプト~SCRUM  Onsite Customer Meeting  顧客が開発メンバーの一員となって,開発メンバーとのやり取りをする仕組み  3つのMeeting,WebEXとメーリングリスト • 要件定義フェーズにて要求内容の共有と仕様の確認を行う定期ミーティング(週2回) 要件定義ミーティング • インドVertex社にてスプリント内の最終的な仕様確定を行う(リリース直前スプリント) • インドVertex社にてアジャイル開発プロセスの振り返りを実施する 振り返りミーティング • 各スプリントの振り返り結果で次スプリントの開発プロセス是正する アプリケーション • 各スプリント実施中のアプリケーションをWebEXを利用し直接操作して確認 デモミーティング • 直接操作したアプリケーションを元に具体的な要求を次スプリントへ上げる Customer • 丌明確な要求や仕様の問い合わせで開発が止まらないためのツール メーリングリスト • 基本はワンデーレスポンス 【ワンポイント】 スプリント外で密なコミュニケーションを図る. スプリント内ではできる限りコミュニケーションを発生させず,開発に集中する. Copyright © 2011 NTT DATA CORPORATION 21
  23. 23. 分散アジャイル開発プロセスのコンセプト~FDD  分散アジャイル開発プロセスの「アジャイル面」において中心となるコンセプト  SCRUMの短期タイムボックスマネジメントによって過剰スコープ実現のムリを抑制  FDDによる小機能単位開発により作業量,変更量のムラを低減  GUIベースの開発により仕様検討・ドキュメント作成のムダを排除 Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 22
  24. 24. 分散アジャイル開発プロセスのコンセプト~FDD  Small-size Lot Production(小ロット開発)  バッチ型開発から小ロット開発へ  フィーチャの依存性を考慮してグループ化したセル単位をロットサイズとして開発 サブプロジェクト作成 プロジェクト作成 運用管理 ・・・ ・・・ タスク一覧表示 タスク報告 進捗情報提出 フィーチャ ・・・ プロジェクト管理 進捗管理 タスク承認 ・・・ ・・・ 階層作成 セル チーム作成 リソース定義 チーム管理 要求 ・・・ ・・・ ・・・ グループ 要求サブ グループ 【ワンポイント】 FDD(フィーチャ駆動開発)では,開発を一貫してフィーチャで管理を行う. 影響分析とバージョン管理,仕様管理が重要. Copyright © 2011 NTT DATA CORPORATION 23
  25. 25. 分散アジャイル開発プロセスのコンセプト~Just Enough  分散アジャイル開発プロセスの「アジャイル面」において中心となるコンセプト  SCRUMの短期タイムボックスマネジメントによって過剰スコープ実現のムリを抑制  FDDによる小機能単位開発により作業量,変更量のムラを低減  GUIベースの開発により仕様検討・ドキュメント作成のムダを排除 Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 24
  26. 26. 分散アジャイル開発プロセスのコンセプト~Just Enough  Just Enough Documentation  GUI(画面)については全く設計書は作成しない  80%ルール(正常系は固まった,など)による,仕様意思決定スピードの高速化  要件定義フェーズで決まりきらなかった要求は,次スプリントへフォワード 要件定義 スプリント 開発 画面プロトを 実装に利用 Product Owner GUI GUIプロト GUI開発 Team 開発 QA ワークフロー GUI ワークフロー スプリント 要求 Team 作成 デモ 修正 計画 共有 (正常系) (異常系) 会議 要件定義の主要成果物 Dev は,議事録と画面プロトタ Team イプ. 【ワンポイント】 Just Enoughとは,できる限り設計書を読まなくてもよい状態. コードを綺麗に維持するためのコーディング規約を重視. Copyright © 2011 NTT DATA CORPORATION 25
  27. 27. 分散アジャイル開発プロセスのコンセプト~DD  分散アジャイル開発プロセスの「分散面」において中心となるコンセプト  アジャイル開発をスケールする可能性が広がる一方で,純粋なアジャイル開発よりも効率面で务る  時差の壁が大きい分散開発では,非同期化によりコミュニケーションを最小化,効率ロスを少なくする Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 26
  28. 28. 分散アジャイル開発プロセスのコンセプト~Exchange Communication  分散アジャイル開発プロセスの「分散面」において中心となるコンセプト  アジャイル開発をスケールする可能性が広がる一方で,純粋なアジャイル開発よりも効率面で务る  時差の壁が大きい分散開発では,非同期化によりコミュニケーションを最小化,効率ロスを少なくする Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 27
  29. 29. 分散アジャイル開発プロセスのコンセプト~Inter-communication  Cross Estimation & Review & Testing  分散開発拠点間のコミュニケーション齟齬の早期発見と品質向上  お互いの成果物に対して,相互見積り,相互レビュー,相互テスト 要件定義 スプリント開発 JAPAN INDIA JAPAN INDIA JAPAN GUIプロト 各種 スプリント スプリント フィーチャ フィーチャ レビュー 開発 設計 結合 結合 Cross 見積 見積 テスト テスト GUI レビュー (Demo) INDIA JAPAN 各種 スプリント スプリント GUIプロト INDIA JAPAN レビュー 結合 結合 INDIA 設計 開発 フィーチャ フィーチャ テスト テスト 見積 見積 【ワンポイント】 Cross Testingでは,結合テストにおいて, 自開発拠点のモジュールが問題ないことを相手開発拠点フィーチャの視点で確認する. Copyright © 2011 NTT DATA CORPORATION 28
  30. 30. 分散アジャイル開発プロセスのコンセプト~ACM  分散アジャイル開発プロセスの「分散面」において中心となるコンセプト  アジャイル開発をスケールする可能性が広がる一方で,純粋なアジャイル開発よりも効率面で务る  時差の壁が大きい分散開発では,非同期化によりコミュニケーションを最小化,効率ロスを少なくする Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 29
  31. 31. 分散アジャイル開発プロセスのコンセプト~ACM  Code Ownership Mode / Code Sharing Mode  開発を止めないための仕組み  スプリント期間中=コード占有型 ⇔ スプリント完了後=コード共有型  自拠点開発フィーチャに関係するコードを所有  フィーチャ(コード)の品質保証責任の明確化 要件定義 スプリント開発 要件定義 (Code Sharing Mode) (Code Ownership Mode) (Code Sharing Mode) Code Continuous Code JAPAN Base Integration Base Next Sprint Code Continuous Code Code Base Integration Base Base Continuous Integration INDIA Code Code Base Integration Base 【ワンポイント】 楽観モデルに基づき,スプリント開始後はあまりインタフェース変更は起らない, 最終的にインテグレーション時にコンフリクトはあまり発生しないと考える. Copyright © 2011 NTT DATA CORPORATION 30
  32. 32. 分散アジャイル開発プロセスのコンセプト~ACM  Publish/Subscribe Change Request  インタフェース所有者を事前に決定  インタフェースの変更は所有者のみ  影響範囲の責任は,影響関係者が負うことで負荷分散 PROJECTにデータAを 事前にインタフェースの所有者(Publisher)を定義 追加変更なう A-san し,影響するクラス所有者は,Subscribeを行う. Publisher Subscriber Model Owner A-san B-san Mr.C Ms.D Database Schema PROJECT A-san ○ ○ PROJECT_TASK A-san ○ ○ TASK TASK_DETAIL A-san B-san ○ ○ Twitter ! TEMPLATE Ms.D ○ TEMPLATE_TASK Ms.D ○ Web Service ProjectManagementService Mr.C ○ ○ ○ TaskManagementService Mr.C ○ TemplateManagementService A-san ○ ○ Mr.C B-san 【ワンポイント】 基本はスプリント開始後のインタフェース変更はNG. インタフェース変更が必要な改修はバックログへフィードフォワードする. Copyright © 2011 NTT DATA CORPORATION 31
  33. 33. 分散アジャイル開発プロセスのコンセプト~TOC  分散アジャイル開発プロセスの「効率追求面」において中心となるコンセプト  アジャイル開発のプラクティスにTOCの理論をエッセンスとして加えることで,科学的なマネジメントを可 能とし,生産性向上を追求する Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 32
  34. 34. 分散アジャイル開発プロセスのコンセプト~JIT  分散アジャイル開発プロセスの「効率追求面」において中心となるコンセプト  アジャイル開発のプラクティスにTOCの理論をエッセンスとして加えることで,科学的なマネジメントを可 能とし,生産性向上を追求する Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 33
  35. 35. 分散アジャイル開発プロセスのコンセプト~JIT  Just-In-Time Resource Management  ソフトウェア開発の効率低下の最大の原因は,リソースネック  開発プロセスの同期性(プロセス停止期間)排除とリソース稼働効率最大化  ボトルネック工程とボトルネックリソースを可視化 設計 設計 設計 プール 設計 レビュー 設計 レビュー 設計レビュー済み プール 後作業の作業待ち(滞留作業)をモニタリング コーディング 【ワンポイント】 プロセスの流れをスムーズにすることを重視. マルチプロセスを可能とするリソースで「助け合い」,生産量の変動に対応する. Copyright © 2011 NTT DATA CORPORATION 34
  36. 36. 分散アジャイル開発プロセスのコンセプト~Release Buffer  分散アジャイル開発プロセスの「効率追求面」において中心となるコンセプト  アジャイル開発のプラクティスにTOCの理論をエッセンスとして加えることで,科学的なマネジメントを可 能とし,生産性向上を追求する Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 35
  37. 37. 分散アジャイル開発プロセスのコンセプト~Release Buffer  Release Buffer Scope Management  リリース前にリリースバッファを設置  サスペンドした作業をバッファ消費に換算  リリースバッファの消費量をモニタリング リリースイテレーション Release Buffer スプリント1 スプリント2 スプリント3 F1 OK F2 OK F3 OK F8 Buffer Consumption F4 Suspend F5 Buffer Consumption F5 Suspend New F8 F4 Buffer Consumption Case: Release Buffer is Yellow Stack to the next or onward Sprint Case: Release Buffer is Red Back to the current Sprint or Product Back Log Product Case: Release Buffer is Green Back Log Stack to Release Buffer 【ワンポイント】 各スプリントスコープ値はチャレンジ目標で設定. (チャレンジ:五分五分の可能性で達成できる範囲) Copyright © 2011 NTT DATA CORPORATION 36
  38. 38. 分散アジャイル開発プロセスのコンセプト~Quality Gate  分散アジャイル開発プロセスの「効率追求面」において中心となるコンセプト  アジャイル開発のプラクティスにTOCの理論をエッセンスとして加えることで,科学的なマネジメントを可 能とし,生産性向上を追求する Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 37
  39. 39. 分散アジャイル開発プロセスのコンセプト~Quality Gate  Quality Gate  品質管理活動の開発プロセスへの組み込み  品質実測データ分析に基づくチェック観点を重視 リリース イテレーション 全てのレベル1バグのFIX スプリントイテレーション 要件 スプリント システム テストカバレッジチェック Quality 定義 開発 テスト Release Gate 要件 スプリント システム Buffer パフォーマンスチェック 定義 開発 テスト 運用性チェック フィーチャA 品質実測データ フィーチャA 品質実測データ 品質データ分析からの類似派生 故 フィーチャA 品質実測データ チェック 障 故 故 密 障 障 ・ ・ 度 密 密 ・ 度 テ 度 スプリント実施回/リリース試験回 ス テ スプリント実施回/リリース試験回 テ スプリント実施回/リリース試験回 ト ス ス ※ バグを3段階に分類して管理 密 ト ト 密 レベル1バグ:仕様とソフトウェアとのギャップ 度 密 スプリント実施回/リリース試験回 度 レベル2バグ:仕様のバグ 度 スプリント実施回/リリース試験回 スプリント実施回/リリース試験回 レベル3バグ:最新ユーザ要求とソフトウェアとのギャップ 【ワンポイント】 設計作業の品質評価はあまり重視しない. テストにおける検証項目の網羅性と検証結果による評価が重要. Copyright © 2011 NTT DATA CORPORATION 38
  40. 40. 分散アジャイル開発プロセスのコンセプト~Management As a Service  分散アジャイル開発プロセスの「プロジェクトマネジメント」において中心となるコンセプト  「管理(プロジェクトマネジメント)」から「サポート」へ  「後だし(フィードバック)」ではなく,「段取り(フィードフォワード)」へ Management As a Service GDD DD TOC Inter- Just Release Quality SCRUM FDD communi ACM JIT Enough Buffer Gate cation GDD: GUI Driven Development FDD: Feature Driven Development DD: Distributed Development ACM: Asynchronous Change Management TOC: Theory of Constraints JIT: Just-In-Time Copyright © 2011 NTT DATA CORPORATION 39
  41. 41. 分散アジャイル開発プロセスのコンセプト~Management As a Service  Management As a Service  「管理(プロジェクトマネジメント)」から「サポート」へ  「後だし(フィードバック)」ではなく,「段取り(フィードフォワード)」へ  外部のノイズから開発チームを守る あれもやって! これも変更して! スプリント GUI開発 フィーチャ機能実装 顧客 スプリント 段取り 結合テスト SCRUM Master インタフェース設計 フィーチャ結合テスト 今どうなってるんだ? 開発チームメンバ 品質は大丈夫なのか? 経営層 上位マネージャ 【ワンポイント】 開発プロセスと開発チームはアジャイル成功の重要な要素. スプリント外における開発サポート活動もアジャイル成功の重要な要素. Copyright © 2011 NTT DATA CORPORATION 40
  42. 42. 分散アジャイル開発プロセスのコンセプト~Management As a Service  Progress Management  開発チームへのマイクロマネジメントから脱却  「要求実現量の変化予測(バーンダウンチャート)」によって「進捗状況」を透明化 【ワンポイント】 進捗の透明化とはプロジェクト内の信頼関係を構築すること. Copyright © 2011 NTT DATA CORPORATION 41
  43. 43. 5.分散アジャイル開発プロセスの適用結果 Copyright © 2011 NTT DATA CORPORATION 42
  44. 44. 分散アジャイル開発プロセスの適用効果 分散アジャイル開発プロセスの適用の結果は,以下の通り. △  従来型開発手法と比較して,開発期間は同程度 ○  従来型開発手法とほぼ同等の品質レベルを達成 ○  当初計画以上の要求スコープカバー率を達成 ○  エンドユーザ要望へのほぼ完全な対応を実現 ◎  開発メンバーの社員満足度向上 ◎  エンドユーザの満足度向上 Copyright © 2011 NTT DATA CORPORATION 43
  45. 45. 6.今後の挑戦 Copyright © 2011 NTT DATA CORPORATION 44
  46. 46. 今後のTRY!  お客様案件への適用  開発スピードアップ(開発期間短縮)  分散開発拠点のスケールアップ(INDIA – CHINA – JAPAN ・・・)  アジャイル開発プラクティスの定着化・横展開 Copyright © 2011 NTT DATA CORPORATION 45
  47. 47. Microsoft Projectおよび Microsoft Project Server は、米国 Microsoft CORPORATIONの米国およびその他の国における登録商標または商標です。 その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。 Copyright © 2011 NTT DATA CORPORATION 46

×