ウォーターフォール型とエンタープライズアジャイル型の違い
機能Ａ
機能B
機能C
機能D
要件定義
詳細設計
基本設計
実装
テスト
移行
ウォーターフォール型 イメージ
機能Ａ
機能B
機能C
機能D
機能Ａ
機能B
機能C
機能D
機能Ａ
機能B
機能C
要件定義
（DB設計、UI設計含む）
ﾘﾌｧｸﾀﾘﾝｸﾞ
テスト
移行
設計.実装
ﾘﾌｧｸﾀﾘﾝｸﾞ
機能D
エンタープライズアジャイル型イメージ
☆要件定義はDB設計、UI設計実装を含めるため工数増となる。
プロジェクトの気づきから始まった開発プロセス見直し
プロジェクトの振り返りと気づき
-
2015年に実施したOutSystems開発プロジェクトでの振り返りをきっかけにOutSystems開発プロジェクトにおける開発プロセスの抜本的な見直しを開始
-
Outsystemsで作成したアプリのシステムテストでの品質評価の結果、全バグの75％が要件定義が起となっている不具合であることが判明（要件漏れ・誤り、実現不可、価値のない要件 等）→ 要件定義の品質向上が課題
開発プロセス見直しPoint
-
OutSystemsの機能を活用した要件定義手法により要件定義段階でユーザーとの合意形成を実現
～エンタープライズアジャイル開発での考慮点～
-
ウォーターフォールプロセス（期間・期限付きフェーズ）内でスプリント開発実施
-
開発チーム体制、３人から４人のセル単位のチームが開発する機能について設計、実装、テストにおける生産 性・品質の責任を負う
-
テスト工程でのテストは可能な限り自動化する、特に回帰テストの自動化は不可欠
エンタープライズ型アジャイル開発イメージ
エンタープライズ型アジャイル開発体制
このチームで担当機能における設計、実装、テストの責任を負う
プロダクトオーナー
スクラムマスター兼アーキテクト
チームメンバー（３~４名）
スクラム体制（Cellチーム)
プロダクトオーナー
-
プロダクト・バックログの作成と優先順位付けの最終責任者
-
チームの仕事がうまくいっているか、困っていることは何かを確認するリーダー
-
OutSystemsのアーキテクトを兼務
-
実装メンバーの実装・テスト内容を日々チェックする
-
進捗報告する
-
スクラムマスター兼アーキテクト
-
スプリントバックログに基づき実装・テストするメンバー
チームメンバー（３~４名）
エンタープライズ型アジャイル開発手法
XP (eXtreme Programming)のプラクティス
キープラクティス①
ペアプログラミング
-
2人（場合によってはそれ以上）のエンジニアが共同でコードを開発します。
キープラクティス②
コードシェア
-
すべてのコードに対して全員が責任を負うことを意味します。
-
メンバーのバックアップ強化、知識の共有、コードの品質の向上に繋がります。
etc ...