Copyright© 2009 atWare,Inc. All rights reserved.
1
SIerにおくる、アジャイルプロセスの実践
- アジャイル統一プロセス -
アジャイルプロセス協議会アジャイルプロジェクトマネジメントWG
株式会社アットウェア
牧野隆志
Copyright© 2009 atWare,Inc. All rights reserved.
2
•牧野隆志(まきのたかし)
‒株式会社アットウェア 代表取締役
http://www.atware.co.jp/
‒アジャイルプロセス協議会アジャイルプロジェクトマネージメントWG
http://www.agileprocess.jp/
‒日本Javaユーザグループ幹事
http://www.java-users.jp/
自己紹介
Copyright© 2009 atWare,Inc. All rights reserved.
3
SIerがよりよいシステムを構築するための手段として、実践的なアジャイルプロセスを提案
今日の目的
Copyright© 2009 atWare,Inc. All rights reserved.
4
ターゲット
• 中~大規模のSI(システム構築)
生命
(Life) L6 L20 L40 L100
重大な経済的損失
(Essential money) E6 E20 E40 E100
軽微な経済的損失
(Discretionary money) D6 D20 D40 D100
使い勝手
(Comfort) C6 C20 C40 C1001~6 ~20 ~40 ~100
重要度
人数
コーバーンの尺度
Copyright© 2009 atWare,Inc. All rights reserved.
5
•不安定な要求
•ビジネス要求の変化への追随
•ドキュメントだけを工程間、技術者間のインタフェースにすることのロス
(改めて)なぜアジャイルプロセスか
Copyright© 2009 atWare,Inc. All rights reserved.
6
私たちは、プロセスとツールよりも
個人と対話に、包括的なドキュメントよりも
動くソフトウェアに、契約交渉よりも
顧客との協調に、計画に沿うことよりも
変化に対応することに、価値をおく
アジャイル宣言
Copyright© 2009 atWare,Inc. All rights reserved.
7
•XPでは「中小規模のチーム」(XP入門初版)、「多くの人が関与する場合、プラクティスを増やし、変える必要がある」(XP入門第二版)
• Scrumでは「チームのメンバは最大7人」「複数チームで構成」
•FDDでは、比較的大規模にも適用可能(モデル駆動、設計を重要視)
中・大規模開発とアジャイル
Copyright© 2009 atWare,Inc. All rights reserved.
8
•コミュニケーションとりづらい
‒毎日のスタンドアップミーティングで全員が発言できない
‒チームに分割した場合のチーム間でのコミュニケーション
なぜ大規模に向かないか①
Copyright© 2009 atWare,Inc. All rights reserved.
9
•オンサイトする顧客がビジネス要求の全てを把握できていない
‒ある程度以上の規模では情報システム部署の担当者がオンサイト
‒現場担当者からのフィードバックを継続的に受けれない
なぜ大規模に向かないか②
Copyright© 2009 atWare,Inc. All rights reserved.
10
•核となるアーキテクチャ
‒XPの「最良のアーキテクチャ、要件、設計は、自己組織的なチームから生み出される」のは、能力の高いプログラマがモチベーション高くチームを形成しているから
‒アーキテクチャがインクリメンタルに変化したら、大規模=多人数に浸透させることが困難
なぜ大規模に向かないか③
Copyright© 2009 atWare,Inc. All rights reserved.
11
•全体包括的なモデル
‒プロジェクト全体(全員)でのコード共有が難しいため、整合性とれてないモデルが点在する
‒大規模なリファクタリングはコストがかかる
‒データベースリファクタリング
なぜ大規模に向かないか④
Copyright© 2009 atWare,Inc. All rights reserved.
12
•長期間のプロジェクト
‒あまりにも遠い未来のゴールを見失う
‒変化がない、同じことの繰り返し
‒モチベーションの維持
なぜ大規模に向かないか⑤
Copyright© 2009 atWare,Inc. All rights reserved.
13
•日本のSI=多重請負モデル
‒目的(ゴール)の共有
‒スキルや経験のばらつきが激しい
‒アジャイルに馴染めない人をバスから降ろすわけにいかない
なぜ大規模に向かないか⑥
Copyright© 2009 atWare,Inc. All rights reserved.
14
•なんだかんだといってもドキュメント
‒規模が大きくなるにつれ、コード共有どころか全体の仕様を把握することすら難しくなる
‒操作マニュアルの元ネタ
‒コードが読めない顧客への運用・保守の移管
なぜ大規模に向かないか⑦
Copyright© 2009 atWare,Inc. All rights reserved.
15
•体系化されたガイドラインがない
‒標準
‒企業毎の規約
‒未経験なものにチャレンジする勇気
なぜ大規模に向かないか⑧
Copyright© 2009 atWare,Inc. All rights reserved.
16
•毎日のスタンドアップミーティングで全員が発言できる程度の人数の優秀なプログラマが、常にコミュニケーションをとりながら全体を把握できる規模
教科書通り実行して成功するのは
Copyright© 2009 atWare,Inc. All rights reserved.
17
•XPは全てのプラクティスがなんらか関係を持っていて、全てを実践することで成り立つ
‒カスタマイズせず、そのまま適用することを推奨している
‒現実的にはかなり難しい
XPのプラクティス
Copyright© 2009 atWare,Inc. All rights reserved.
18
•プラクティス集ではない、体系化したガイドラインが必要
‒経験が無くてもその通りやればある程度うまくいく
‒必要以上にカスタマイズ(取捨選択)の幅を持たせない
本格的に適用するには
Copyright© 2009 atWare,Inc. All rights reserved.
19
•反復型開発として体系化されている統一プロセス(UP)にアジャイルマインドとXP、Scrum、FDDなどのプラクティスを注入
ベースとなる規約
プラクティスマインド
アジャイル
統一プロセス
Copyright© 2009 atWare,Inc. All rights reserved.
20
ライフサイクル
方向付け
推敲 作成 移行
要件
設計
実装
テスト
アジャイルに要求/設計/実装/テストを
Copyright© 2009 atWare,Inc. All rights reserved.
21
•ビジョン、ゴール、スコープの合意
•技術的リスクの明確化
•推敲フェーズの計画
•数日~1週間程度
方向付けフェーズ
Copyright© 2009 atWare,Inc. All rights reserved.
22
•UPより
•価値の共有
‒顧客⇔開発者⇔開発者
‒アジャイル宣言、原則
‒プロジェクト・クレド
•開発ルームの壁に貼る、開発者に配る
ビジョン、ゴール、スコープの合意
Copyright© 2009 atWare,Inc. All rights reserved.
23
•実行可能な中核アーキテクチャを実装し、主要リスクを軽減‒アーキテクチャの早期確立
‒核となる部分とそれ以外の分離
‒リスクの高いストーリ
‒プロトタイプではない
•全体包括モデル構築
•全ての要求を定義しない
•詳細な計画は立てない
推敲フェーズ
Copyright© 2009 atWare,Inc. All rights reserved.
24
•ソフトウェアプロダクトラインより
•プロダクトライン開発(厳格)とプロダクト生産(アジャイル)
‒アーキテクチャの核となるフレームワークやコンポーネントとそれを利用したビジネスアプリケーションを分離
核となる部分とそれ以外の分離
Copyright© 2009 atWare,Inc. All rights reserved.
25
実装量
方向付け
推敲 作成 移行
核となるF/W、コンポーネント
その他のビジネスロジック
Copyright© 2009 atWare,Inc. All rights reserved.
26
チーム編成
• 推敲フェーズのメンバが作成フェーズの各チームのチーフプログラマに
Copyright© 2009 atWare,Inc. All rights reserved.
27
•FDD、アジャイルモデリングより
•ドメイン・モデル
‒ホワイトボード→電子データに転記
•メンテナンスが容易になる
•用語集
‒ Wiki
全体包括モデル構築
Copyright© 2009 atWare,Inc. All rights reserved.
28
•XPなどのプラクティスを用いて、要求/設計/実装/テストをイテレーティブに、インクリメンタルに
•テーマ
作成フェーズ
Copyright© 2009 atWare,Inc. All rights reserved.
29
•複数回のイテレーションを束ねたリリース
•イテレーション、リリースのテーマの明確化
•テーマを達するために適切なイテレーション、リリースの長さを決定
‒システムとして意味のある状態に保つ
テーマ
Copyright© 2009 atWare,Inc. All rights reserved.
30
リリース内でのフェーズリリース
方向付け 推敲 作成 移行
イテレーション
リリース計画ゲーム
技術リスクの解消主ストーリ
バッファ
フィードバックリファクタリング結合テストコードデザイン適用性能テスト
リリース
ふりかえり
Copyright© 2009 atWare,Inc. All rights reserved.
31
•二段階朝会
‒全体:全員参加、チーム代表者のみ発言(全体周知)
‒チーム毎:チーム内の全員が発言
•情報ボード
‒テーマや直近のイベント、周知事項など
• Skype(グループチャット)
コミュニケーション
Copyright© 2009 atWare,Inc. All rights reserved.
32
•開発室内に顧客用の席を確保
• Skype(チャット)
‒オンサイトでないときのリアルタイムな情報共有
•顧客先と開発室との頻繁な行き来
‒ホントのユーザと会話しやすい
‒要件定義チーム
オンサイト顧客
Copyright© 2009 atWare,Inc. All rights reserved.
33
要件定義チーム
要件定義 要件定義 要件定義
実装設計・テスト
実装設計・テスト
実装設計・テスト
テストシナリオ
• 顧客+専任メンバ+開発チーム
‒ 各開発チームのうち一名が参加
→ 次イテレーションの開発リーダ
テストシナリオ
Copyright© 2009 atWare,Inc. All rights reserved.
34
•チーム毎に個別所有
‒プロジェクト全体での共有はしない
•チーム内で共有
コード所有
Copyright© 2009 atWare,Inc. All rights reserved.
35
見える化
タスクボード
バーンダウン
Copyright© 2009 atWare,Inc. All rights reserved.
36
タスクボード
優先順位
Copyright© 2009 atWare,Inc. All rights reserved.
37
タスクカード
付箋が付いてたり・・・
ユースケースや区分毎に色分け
Copyright© 2009 atWare,Inc. All rights reserved.
38
•本番環境相当でのシステムテスト
‒障害テスト、負荷テスト
•運用テスト、運用訓練
‒システム全体のフィードバック
•ドキュメント整備
移行フェーズ
Copyright© 2009 atWare,Inc. All rights reserved.
39
•UPではオプションとして大量のドキュメントを定義
→ 現実的に必要なドキュメントのみに絞って、必須とする
•名称、内容は各社固有のもの転用可能とする
‒ただしどの工程で作成すべきか考慮
ドキュメント
Copyright© 2009 atWare,Inc. All rights reserved.
40
守 破 離
師匠の教えを忠実に守り、
師匠の教えに自分のアレンジを加え、
自分オリジナルなやり方を確立する
最後に