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