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

1Copyright© 2009 atWare,Inc. All rights reserved.

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

- アジャイル統一プロセス -

アジャイルプロセス協議会アジャイルプロジェクトマネジメントＷＧ

株式会社アットウェア

牧野隆志


• 牧野隆志（まきのたかし）

–株式会社アットウェア代表取締役

http://www.atware.co.jp/

–アジャイルプロセス協議会アジャイルプロジェクトマネージメントＷＧ

http://www.agileprocess.jp/

–日本Ｊａｖａユーザグループ幹事

http://www.java-users.jp/

自己紹介


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

今日の目的


ターゲット

• 中～大規模のＳＩ（システム構築）

生命

(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

重要度

人数

コーバーンの尺度


• 不安定な要求

• ビジネス要求の変化への追随

• ドキュメントだけを工程間、技術者間のインタフェースにすることのロス

（改めて）なぜアジャイルプロセスか


私たちは、プロセスとツールよりも

個人と対話に、包括的なドキュメントよりも

動くソフトウェアに、契約交渉よりも

顧客との協調に、計画に沿うことよりも

変化に対応することに、価値をおく

アジャイル宣言


• ＸＰでは「中小規模のチーム」(ＸＰ入門初版)、「多くの人が関与する場合、プラクティスを増やし、変える必要がある」(ＸＰ入門第二版)

• Scrumでは「チームのメンバは最大7人」「複数チームで構成」

• ＦＤＤでは、比較的大規模にも適用可能（モデル駆動、設計を重要視）

中・大規模開発とアジャイル


• コミュニケーションとりづらい

–毎日のスタンドアップミーティングで全員が発言できない

–チームに分割した場合のチーム間でのコミュニケーション

なぜ大規模に向かないか①


• オンサイトする顧客がビジネス要求の全てを把握できていない

–ある程度以上の規模では情報システム部署の担当者がオンサイト

–現場担当者からのフィードバックを継続的に受けれない

なぜ大規模に向かないか②


• 核となるアーキテクチャ

–ＸＰの「最良のアーキテクチャ、要件、設計は、自己組織的なチームから生み出される」のは、能力の高いプログラマがモチベーション高くチームを形成しているから

–アーキテクチャがインクリメンタルに変化したら、大規模＝多人数に浸透させることが困難

なぜ大規模に向かないか③


• 全体包括的なモデル

–プロジェクト全体（全員）でのコード共有が難しいため、整合性とれてないモデルが点在する

–大規模なリファクタリングはコストがかかる

–データベースリファクタリング

なぜ大規模に向かないか④


• 長期間のプロジェクト

–あまりにも遠い未来のゴールを見失う

–変化がない、同じことの繰り返し

–モチベーションの維持

なぜ大規模に向かないか⑤


• 日本のSI=多重請負モデル

–目的（ゴール）の共有

–スキルや経験のばらつきが激しい

–アジャイルに馴染めない人をバスから降ろすわけにいかない

なぜ大規模に向かないか⑥


• なんだかんだといってもドキュメント

–規模が大きくなるにつれ、コード共有どころか全体の仕様を把握することすら難しくなる

–操作マニュアルの元ネタ

–コードが読めない顧客への運用・保守の移管

なぜ大規模に向かないか⑦


• 体系化されたガイドラインがない

–標準

–企業毎の規約

–未経験なものにチャレンジする勇気

なぜ大規模に向かないか⑧


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

教科書通り実行して成功するのは


• ＸＰは全てのプラクティスがなんらか関係を持っていて、全てを実践することで成り立つ

–カスタマイズせず、そのまま適用することを推奨している

–現実的にはかなり難しい

ＸＰのプラクティス


• プラクティス集ではない、体系化したガイドラインが必要

–経験が無くてもその通りやればある程度うまくいく

–必要以上にカスタマイズ(取捨選択)の幅を持たせない

本格的に適用するには


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

ベースとなる規約

プラクティスマインド

アジャイル

統一プロセス


ライフサイクル

方向付け

推敲作成移行

要件

設計

実装

テスト

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


• ビジョン、ゴール、スコープの合意

• 技術的リスクの明確化

• 推敲フェーズの計画

• 数日～1週間程度

方向付けフェーズ


• ＵＰより

• 価値の共有

–顧客⇔開発者⇔開発者

–アジャイル宣言、原則

–プロジェクト・クレド

• 開発ルームの壁に貼る、開発者に配る

ビジョン、ゴール、スコープの合意


• 実行可能な中核アーキテクチャを実装し、主要リスクを軽減–アーキテクチャの早期確立

–核となる部分とそれ以外の分離

–リスクの高いストーリ

–プロトタイプではない

• 全体包括モデル構築

• 全ての要求を定義しない

• 詳細な計画は立てない

推敲フェーズ


• ソフトウェアプロダクトラインより

• プロダクトライン開発(厳格)とプロダクト生産(アジャイル)

–アーキテクチャの核となるフレームワークやコンポーネントとそれを利用したビジネスアプリケーションを分離

核となる部分とそれ以外の分離


実装量

方向付け

推敲作成移行

核となるF/W、コンポーネント

その他のビジネスロジック


チーム編成

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


• ＦＤＤ、アジャイルモデリングより

• ドメイン・モデル

–ホワイトボード→電子データに転記

• メンテナンスが容易になる

• 用語集

–Wiki

全体包括モデル構築


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

• テーマ

作成フェーズ


• 複数回のイテレーションを束ねたリリース

• イテレーション、リリースのテーマの明確化

• テーマを達するために適切なイテレーション、リリースの長さを決定

–システムとして意味のある状態に保つ

テーマ


リリース内でのフェーズリリース

方向付け推敲作成移行

イテレーション

リリース計画ゲーム

技術リスクの解消

主ストーリ

バッファ

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

リリース

ふりかえり


• 二段階朝会

–全体：全員参加、チーム代表者のみ発言（全体周知）

–チーム毎：チーム内の全員が発言

• 情報ボード

–テーマや直近のイベント、周知事項など

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

コミュニケーション


• 開発室内に顧客用の席を確保

• Skype（チャット)

–オンサイトでないときのリアルタイムな情報共有

• 顧客先と開発室との頻繁な行き来

–ホントのユーザと会話しやすい

–要件定義チーム

オンサイト顧客


要件定義チーム

要件定義要件定義要件定義

実装設計・テスト



テストシナリオ

• 顧客＋専任メンバ＋開発チーム

– 各開発チームのうち一名が参加

→ 次イテレーションの開発リーダ

テストシナリオ


• チーム毎に個別所有

–プロジェクト全体での共有はしない

• チーム内で共有

コード所有


見える化

タスクボード

バーンダウン


タスクボード

優先順位


タスクカード

付箋が付いてたり・・・

ユースケースや区分毎に色分け


• 本番環境相当でのシステムテスト

–障害テスト、負荷テスト

• 運用テスト、運用訓練

–システム全体のフィードバック

• ドキュメント整備

移行フェーズ


• ＵＰではオプションとして大量のドキュメントを定義

→ 現実的に必要なドキュメントのみに絞って、必須とする

• 名称、内容は各社固有のもの転用可能とする

–ただしどの工程で作成すべきか考慮

ドキュメント


守破離

師匠の教えを忠実に守り、

師匠の教えに自分のアレンジを加え、

自分オリジナルなやり方を確立する

最後に


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

[email protected]

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

Documents