SIerにおくる、 アジャイルプロセスの実践

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