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

今日の目的

SIerがよりよいシステムを
構築するための手段として、
実践的なアジャイルプロセ
スを提案

3

ターゲット
• 中～大規模のＳＩ（システム構築）
コーバーンの尺度
生命
(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

（改めて）なぜアジャイルプロセスか
• 不安定な要求
• ビジネス要求の変化への追随
• ドキュメントだけを工程間、技術者
間のインタフェースにすることのロ
ス

5

アジャイル宣言
私たちは、
プロセスとツールよりも
個人と対話に、
包括的なドキュメントよりも
動くソフトウェアに、
契約交渉よりも
顧客との協調に、
計画に沿うことよりも
変化に対応することに、
価値をおく
6

中・大規模開発とアジャイル
• ＸＰでは「中小規模のチーム」(Ｘ
Ｐ入門初版)、「多くの人が関与す
る場合、プラクティスを増やし、変
える必要がある」(ＸＰ入門第二版)
• Scrumでは「チームのメンバは最大7
人」「複数チームで構成」
• ＦＤＤでは、比較的大規模にも適用
可能（モデル駆動、設計を重要視）
7

なぜ大規模に向かないか①
• コミュニケーションとりづらい
– 毎日のスタンドアップミーティングで
全員が発言できない
– チームに分割した場合のチーム間での
コミュニケーション

8

なぜ大規模に向かないか②
• オンサイトする顧客がビジネス要求
の全てを把握できていない
– ある程度以上の規模では情報システム
部署の担当者がオンサイト
– 現場担当者からのフィードバックを継
続的に受けれない

9

なぜ大規模に向かないか③
• 核となるアーキテクチャ
– ＸＰの「最良のアーキテクチャ、要件、
設計は、自己組織的なチームから生み
出される」のは、能力の高いプログラ
マがモチベーション高くチームを形成
しているから
– アーキテクチャがインクリメンタルに
変化したら、大規模＝多人数に浸透さ
せることが困難
10

なぜ大規模に向かないか④
• 全体包括的なモデル
– プロジェクト全体（全員）でのコード
共有が難しいため、整合性とれてない
モデルが点在する
– 大規模なリファクタリングはコストが
かかる
– データベースリファクタリング

11

なぜ大規模に向かないか⑤
• 長期間のプロジェクト
– あまりにも遠い未来のゴールを見失う
– 変化がない、同じことの繰り返し
– モチベーションの維持

12

なぜ大規模に向かないか⑥
• 日本のSI=多重請負モデル
– 目的（ゴール）の共有
– スキルや経験のばらつきが激しい
– アジャイルに馴染めない人をバスから
降ろすわけにいかない

13

なぜ大規模に向かないか⑦
• なんだかんだといってもドキュメン
ト
– 規模が大きくなるにつれ、コード共有
どころか全体の仕様を把握することす
ら難しくなる
– 操作マニュアルの元ネタ
– コードが読めない顧客への運用・保守
の移管

14

なぜ大規模に向かないか⑧
• 体系化されたガイドラインがない
– 標準
– 企業毎の規約
– 未経験なものにチャレンジする勇気

15

教科書通り実行して成功するのは
• 毎日のスタンドアップミーティング
で全員が発言できる程度の人数の優
秀なプログラマが、常にコミュニ
ケーションをとりながら全体を把握
できる規模

16

ＸＰのプラクティス
• ＸＰは全てのプラクティスがなんら
か関係を持っていて、全てを実践す
ることで成り立つ
– カスタマイズせず、そのまま適用する
ことを推奨している
– 現実的にはかなり難しい

17

本格的に適用するには
• プラクティス集ではない、体系化し
たガイドラインが必要
– 経験が無くてもその通りやればある程
度うまくいく
– 必要以上にカスタマイズ(取捨選択)の
幅を持たせない

18

ベースとなる規約
• 反復型開発として体系化されている
統一プロセス（ＵＰ）にアジャイル
マインドとXP、Scrum、FDDなどのプ
ラクティスを注入
アジャイル
プラクティス

マインド

統一プロセス
19

ライフサイクル
方向
推敲
付け

作成

要件
設計
実装

アジャイルに
要求/設計/実
装/テストを

テスト

20

移行

方向付けフェーズ
•
•
•
•

ビジョン、ゴール、スコープの合意
技術的リスクの明確化
推敲フェーズの計画
数日～1週間程度

21

ビジョン、ゴール、スコープの合意
• ＵＰより
• 価値の共有
– 顧客⇔開発者⇔開発者
– アジャイル宣言、原則
– プロジェクト・クレド
• 開発ルームの壁に貼る、開発者に配る

22

推敲フェーズ
• 実行可能な中核アーキテクチャを実
装し、主要リスクを軽減
– アーキテクチャの早期確立
– 核となる部分とそれ以外の分離
– リスクの高いストーリ
– プロトタイプではない

• 全体包括モデル構築
• 全ての要求を定義しない
• 詳細な計画は立てない
23

核となる部分とそれ以外の分離
• ソフトウェアプロダクトラインより
• プロダクトライン開発(厳格)とプロ
ダクト生産(アジャイル)
– アーキテクチャの核となるフレーム
ワークやコンポーネントとそれを利用
したビジネスアプリケーションを分離

24

実装量
方向
付け

推敲

作成

その他のビジ
ネスロジック
核となるF/W、
コンポーネント

25

移行

チーム編成
• 推敲フェーズのメンバが作成フェーズの各
チームのチーフプログラマに

26

全体包括モデル構築
• ＦＤＤ、アジャイルモデリングより
• ドメイン・モデル
– ホワイトボード→電子データに転記
• メンテナンスが容易になる

• 用語集
– Wiki

27

作成フェーズ
• ＸＰなどのプラクティスを用いて、
要求／設計／実装／テストをイテ
レーティブに、インクリメンタルに
• テーマ

28

テーマ
• 複数回のイテレーションを束ねたリ
リース
• イテレーション、リリースのテーマ
の明確化
• テーマを達するために適切なイテ
レーション、リリースの長さを決定
– システムとして意味のある状態に保つ

29

リリース内でのフェーズ
リリース
方向付け

推敲

移行

作成

イテレーション
リリース計
画ゲーム

バッファ
フィードバック
リファクタリング
結合テストコード
デザイン適用
性能テスト

技術リスク
の解消
主ストーリ

30

ふ
り
か
え
り

リ
リ
ー
ス

コミュニケーション
• 二段階朝会
– 全体：全員参加、チーム代表者のみ発
言（全体周知）
– チーム毎：チーム内の全員が発言

• 情報ボード
– テーマや直近のイベント、周知事項な
ど

• Skype（グループチャット）
31

オンサイト顧客
• 開発室内に顧客用の席を確保
• Skype（チャット)
– オンサイトでないときのリアルタイム
な情報共有

• 顧客先と開発室との頻繁な行き来
– ホントのユーザと会話しやすい
– 要件定義チーム

32

要件定義チーム
• 顧客＋専任メンバ＋開発チーム
– 各開発チームのうち一名が参加
→ 次イテレーションの開発リーダ
要件定義

要件定義
テストシナリオ

実装
設計・テスト

テストシナリオ

実装
設計・テスト

33

要件定義

実装
設計・テスト

コード所有
• チーム毎に個別所有
– プロジェクト全体での共有はしない

• チーム内で共有

34

見える化

タスクボード
バーンダウン
35

タスクボード

優
先
順
位

36

タスクカード
ユースケースや
区分毎に色分け

付箋が付いてたり・・・

37

移行フェーズ
• 本番環境相当でのシステムテスト
– 障害テスト、負荷テスト

• 運用テスト、運用訓練
– システム全体のフィードバック

• ドキュメント整備

38

ドキュメント
• ＵＰではオプションとして大量のド
キュメントを定義
→ 現実的に必要なドキュメントの
みに絞って、必須とする
• 名称、内容は各社固有のもの転用可
能とする
– ただしどの工程で作成すべきか考慮

39

最後に

守破離
師匠の教えを忠実に守り、
師匠の教えに自分のアレンジを加え、
自分オリジナルなやり方を確立する

40

ご清聴ありがとうございました

makino@atware.co.jp
41

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

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

Semelhante a SIerにおくる、アジャイルプロセスの実践 (20)

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