close

Enter

Log in using OpenID

2 - オージス総研

embedDownload
アジャイル開発
事例紹介
~適応と計画のバランス~
株式会社オージス総研
ES4部第3チーム 入江 茂喜
2010/7/25
1
発表内容

1.プロジェクトの概要(5分)
1.1 システム化の背景および目的
1.2 プロジェクトの特徴
1.3 システム全体概要

2.プロジェクト管理(10分)
2.1
2.2
2.3
2.4

反復型開発 ~戦略と計画~
品質管理
進捗管理
メトリクス
3.まとめ(15分)
3.1
3.2
3.3
3.4
3.5
2010/7/25
プロジェクト実績まとめ
反復開発の効用
今回の気付き
今後の課題と展開
あれから2年・・・
2
1.1 システム化の背景および目的

旧システムの老朽化
 1997年に構築し、H/W、S/W共に老朽化
 改造に次ぐ改造で、メンテナンスが大変

ビジネスニーズとのアンマッチ
 業務に合わなくなってきた
 連携先他システム再構築に伴い、I/F変更
2010/7/25
3
1.1.1 旧システムの概要



PowerBuilder + COBOLで27万6千ステップのC/S
独特な画面で使いづらい(使い方がよくわからない)
ドキュメントはCOBOL部分の詳細設計書だけ
ラベル?
ソートバー?
いえ、ボタンです
暗号のような
チェックボックス
担当者Mさんのコメント
「ボタンを押すと何が起こるか分からないので怖い…」
2010/7/25
4
1.3 プロジェクトの特徴






旧システムと同等機能を備え、業務が滞りなく遂行可能なこと
連携他システムとの親和性を向上
言語を統一、OSSを活用しWebシステムに
使い勝手を向上させ、スリム化したい
連携他システム開始に絶対間に合うこと
一括請負が希望(要件ほとんど固まってないけど…)
・旧システムは、規模から算出すると200人月以上
・スリム化するとは言え、工期は8ヶ月しかない
・さらに機能を向上させる要件を盛り込めるのか?
2010/7/25
5
1.4 システム全体概要




全面的にOSSを採用したJ2EE 3層Webシステム
フレームワークにOJF(Seasar2)
DBMSはPostgreSQL
バーコードリーダに接続する専用GUIアプリ
クライアント
APサーバ
ブラウザ:
アプリケーション
F/W:
OJF, JasperReport
Web/AP: Apache, Tomcat
GUI:
Swing
2010/7/25
OS:Red Hat Enterprise Linux
DB: PostgreSQL
IE6~7
FireFox
DBサーバ
プリンタ
サーバ
他システム
6
2.1 反復型開発 ~戦略と計画~

使い勝手を向上させ、スリム化したい
 タイムボックスの反復型開発で、何度もリリースする
 変更要望を積極的に受け入れ、改良する

連携他システム開始に絶対間に合うこと
 ドキュメンテーションは出来る限り減らす
 OJFを活用し、アーキテクチャだけは早期安定させる

一括請負が希望(要件ほとんど固まってないけど…)
 外部設計完了時に再見積り
 見積もったファンクションポイントは固定し、死守する
 反復型でリスクを徐々に討ち取る
2010/7/25
7
2.1.1 開発手法=UP+アジャイル?
実際の「プロジェクト計画書」に書いた今回の開発手法の説明


開発手法は端的に言えば、「UP(統一プロセス)+アジャイル」である
UPからは、プロジェクトの安定性に関する概念を引き継ぐ



アジャイル開発から、プロジェクトの適応性に関する概念を引き継ぐ





アーキテクチャ中心
リスク駆動
プロセスやツールよりも、個人との対話を優先
包括的なドキュメントよりも、動作する製品を優先
契約の交渉よりも、顧客との協調を優先
計画に従うよりも、変化への対応を優先
そして、中核となる反復型開発は両者の概念を引き継ぐ


2010/7/25
UPからは、「インクリメンタルな反復型プロセス」
⇒ユーザビリティが重要で、複雑な機能を洗練する反復
アジャイルからは、「反復型でフィーチャ(機能)ベースの提供」
⇒反復ごとに実際に稼動する機能セットを提供する
8
2.1.2 反復計画時の悩み

要件定義開始から2ヶ月強でリリースしないと…
 いきなり実装?いくらアジャイルでも設計が足りなすぎる
 ユースケース駆動は採用してない。何から開発しよう?

UPのような作業分配の概念を適用できるか?
 どうやって?始めにWBSで全てのタスクを決める?
 そんなお堅い計画駆動をやってる時間はない
有名なUPの図。
でも…どうやっ
たらこんな作業
分配を計画で
きるの?
2010/7/25
?
全反復のWBS
を最初に計画
するの?それ
はアジャイル
じゃないはず。
9
2.1.3 実際の反復計画



反復毎に完了すべきトランザクションファンクション
ポイント(TFP)だけを最初に決めた
反復毎に“ストーリー“を計画し、意味ある機能のま
とまりを反復毎にリリース(機能毎の重要度も意識)
計画した反復毎TFPに収まるのであれば、反復間
で、開発対象機能を入れ変えることも可とした
300TFP
292
200TFP
100TFP
設計作業の
割合
258
テスト作業の
割合
70
30
2010/7/25
反復1
反復2
反復3
反復4
10
2.2 品質管理

単体テストは自動テストコードと機能テストを併用

OJF TestTool(S2Test)による回帰テストコードを作成
 単体と言いつつ、反復毎リリースに向けて結合的なケースも含む

結合テストは単体テストで出来ないものだけを実施

機能間連携、他システムI/F、シナリオ、性能テスト
単体テストケース数
UTカバレッジ(C0基準)
結合テストケース数
不具合件数(※1)
障害件数(※2)
530
90%以上
320
(予測せず)
実績
1,600
80%
400
63
5
6
前倒しされた?
計画
※1 結合テスト中の不具合、 ※2 ST、リリース後の顧客起票障害
2010/7/25
11
2.3 進捗管理



全体の進捗管理はWBS(途中で放置したが…)
結局、リリースが完了した機能数(TPF)だけを管理
テスト時はテストケース消化数で管理
GDBプロジェクト反復進捗
700
【反復1完了(12/10)】
70トランザクションFP消化
600
トランザクションFP
500
【反復2完了(1/11)】
292トランザクションFP消化
(累計362、残288)
残FP
反復毎計画FP
400
【反復3予定(2/9)】
258トランザクションFP消化
300
【反復4予定(2/29)】
30トランザクションFP消化
200
100
20
07
/1
1/
20
5
07
/1
1/
12
20
07
/1
1/
19
20
07
/1
1/
26
20
07
/1
2/
20
3
07
/1
2/
10
20
07
/1
2/
17
20
07
/1
2/
24
20
07
/1
2/
31
20
08
/1
/7
20
08
/1
/1
4
20
08
/1
/2
1
20
08
/1
/2
8
20
08
/2
/4
20
08
/2
/1
1
20
08
/2
/1
8
20
08
/2
/2
5
0
2010/7/25
日付
12
2.3.1 各反復中の進捗管理


バーンダウンチャートで時間単位の予実管理
毎朝スクラムミーティング、毎昼全体ミーティング
チームリソース
残作業時間
500
450
迅速なリカバリ
400
工数(人時)
350
300
250
200
150
100
50
2010/7/25
1/10
1/11
7
1/9
12/20
6
1/8
12/19
5
1/7
12/18
4
12/27
12/17
3
12/26
12/14
2
8
9
10
日付/日数
11
12
13
14
15
16
12/25
12/13
1
12/21
12/12
0
13
2.4 メトリクス(1)

OJFの活用で、コードは反復1で一番成長
 EntityGenによってDaoやEntityを一気に自動生成

後半、完了FPは増えても、コード生産量は伸びない
 リファクタリングでコードが“減る“コンポーネントも出る
800
700
600
500
400
300
200
100
0
SLOC
150,000
100,000
50,000
0
11/1
12/7
1/8
2/13
3/4
コード量
完了FP
FP
200,000
4/18
コード生産量とリリース完了TFPの成長
2010/7/25
14
2.4 メトリクス(2)


反復1で設計に注力している影響でテストは少ない
後半、本体コードよりテストコードが成長する
最終的にテストコードは本体コードの2/3の規模
 少ないかも?OJF TestTool(S2Test)の生産性が良いのは確実

SLOC
300,000
250,000
全てのコード
200,000
テストコード抜き
150,000
テストコード
100,000
50,000
0
11/1
12/7
1/8
2/13
テストコードの成長
2010/7/25
3/4
4/18
15
3.1 プロジェクト実績まとめ



途中で再見積りし、追加費用を頂く
生産性は計画をかなり上回る
JUAS標準開発工期より30%短縮
※JUAS: 日本情報システ
ム・ユーザー協会
※標準工期: 投入人月の
立方根の2.4倍
計画
-
実績
計画比110%
利益率(%)
納期(リリース日)
2008年6月
計画比130%
2008年6月
投入要員(人月)
78.5
4
12.8
95.8
4
15
16万7千
売上(百万)
CS満足度
生産性(FP/人月)
規模(有効ステップ数)
2010/7/25
-
16
3.2 反復開発の効用(1)


反復毎に小さな要望を取り込み、機能を洗練する
最終的には外部設計時から大幅に機能が変更

ウォーターフォール型だったら、この大変更を一気に取り込むのは
困難だっただろうし、そもそも変更を受け入れなかっただろう
◎小さくホップステップジャンプ
2010/7/25
×命がけの大ジャンプ
17
3.2 反復開発の効用(2)

開発作業自体が改善される
ある作業のやり方がまずければ、次の反復で大胆に見直す
 顧客へリリースするため、ビルド&配置、データ移行も改善


設計が最適化される
最初はシンプルに。必要に応じて再設計やリファクタリング
 前回の反復で捨てた設計上のアイデアを再度採用することも


モチベーションが向上する

1ヶ月ごとに訪れる、ほど良い緊張感と終わったあとの達成感
 事実が成功を裏付けているという安心感
2010/7/25
18
3.3 今回の気付き

成功要因を一つ選ぶとしたら“何度もリリース“
要件・設計・実装・テスト・移行の全ての開発作業を繰り返す
 ただし、最低4回は繰り返さないと効果は薄い


変化(適応)と安定(規律)は両立できる
今回のブレンド手法が理論的に正しいか否かは分からないが…
 QMS外部審査にもパス。従来の品質マネジメントにも適合は可能


反復型では保守性が生産性を左右する
開発者が保守性を切実な問題と受け止めた
 保守容易性は未来への投資ではなく、今の推進力に必須になる

2010/7/25
19
3.4 今後の課題と展開

お客様の理解を得るためは?
 反復やアジャイル手法への抵抗感はまだ強い
 効果的にメリットを説明する提案へ(保守性向上など)

CCPMの適用
 通常とは逆にメンバーはギリギリの工数見積りをしがち
 プロジェクト全体での効果的なバッファ管理が必要

さらに大規模、さらに短納期に応える手法へ
 どれだけ独立化したチームが作れるかが鍵?
 横断的に仕様を調整する専任チームが必要か?
2010/7/25
20
3.5 あれから2年・・・

ウォーターフォール型開発再び

ウォーターフォールは怖い



アジャイルからの気付き



統合テストまで見つからない仕様ミス、解決されないリスク
運用しないと気付かないムダな機能、真のユーザ要求
計画に柔軟性を取り込むことの重要性(CCPM)
密なコミュニケーションの重要性(暗黙知の活用、見える化)
アジャイルの今

大規模開発への適用、契約のあり方は、未だ模索中


アジャイルへの誤解(過小or過大評価、)は少なくなりつつある



“計画駆動とアジャイルは対立軸でない”、“PJごとにカスタマイズが必要”など
検索→「アジャイルは単に廃れつつある流行語なのか?」
適用事例は増えつつあり、徐々に市場からの要請も増えている


2010/7/25
検索→「キーパーソンに聞くエンタープライズ・アジャイルの現在 」
検索→「非ウォーターフォール型開発に関する調査結果公開」
“RFPにアジャイル適用を盛り込むユーザ企業も多い”日経BP池上氏談
21
補足- マスタスケジュール
2007
9
10
推敲
作成
11
12
3
4
5
要件 外部
定義 設計
アーキテクチャ
設計・構築
反復 反復 反復 反復 追加
1
2
3
4
開発
移行
結合テスト
一括契約
2010/7/25
2008
1
2
システムテスト・
移行・リリース
SES契約
22
Author
Document
Category
Uncategorized
Views
6
File Size
334 KB
Tags
1/--pages
Report inappropriate content