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

Copyright© 2009 atWare,Inc. All rights reserved.

1

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

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

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

株式会社アットウェア

牧野隆志


2

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

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

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

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

http://www.agileprocess.jp/

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

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

自己紹介


3

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

今日の目的


4

ターゲット

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

生命

(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

重要度

人数

コーバーンの尺度


5

•不安定な要求

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

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

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


6

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

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

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

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

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

アジャイル宣言


7

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

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

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

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


8

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

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

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

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


9

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

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

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

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


10

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

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

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

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


11

•全体包括的なモデル

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

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

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

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


12

•長期間のプロジェクト

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

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

‒モチベーションの維持

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


13

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

‒目的（ゴール）の共有

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

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

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


14

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

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

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

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

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


15

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

‒標準

‒企業毎の規約

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

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


16

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

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


17

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

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

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

ＸＰのプラクティス


18

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

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

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

本格的に適用するには


19

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

ベースとなる規約

プラクティスマインド

アジャイル

統一プロセス


20

ライフサイクル

方向付け

推敲作成移行

要件

設計

実装

テスト

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


21

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

•技術的リスクの明確化

•推敲フェーズの計画

•数日～1週間程度

方向付けフェーズ


22

•ＵＰより

•価値の共有

‒顧客⇔開発者⇔開発者

‒アジャイル宣言、原則

‒プロジェクト・クレド

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

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


23

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

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

‒リスクの高いストーリ

‒プロトタイプではない

•全体包括モデル構築

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

•詳細な計画は立てない

推敲フェーズ


24

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

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

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

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


25

実装量

方向付け

推敲作成移行

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

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


26

チーム編成

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


27

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

•ドメイン・モデル

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

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

•用語集

‒ Wiki

全体包括モデル構築


28

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

•テーマ

作成フェーズ


29

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

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

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

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

テーマ


30

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

方向付け推敲作成移行

イテレーション

リリース計画ゲーム

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

バッファ

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

リリース

ふりかえり


31

•二段階朝会

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

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

•情報ボード

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

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

コミュニケーション


32

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

• Skype（チャット)

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

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

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

‒要件定義チーム

オンサイト顧客


33

要件定義チーム

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

実装設計・テスト



テストシナリオ

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

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

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

テストシナリオ


34

•チーム毎に個別所有

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

•チーム内で共有

コード所有


35

見える化

タスクボード

バーンダウン


36

タスクボード

優先順位


37

タスクカード

付箋が付いてたり・・・

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


38

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

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

•運用テスト、運用訓練

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

•ドキュメント整備

移行フェーズ


39

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

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

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

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

ドキュメント


40

守破離

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

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

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

最後に


41

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

[email protected]

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

Documents

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