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

672 views

Published on

QCon Tokyo 2009の時のスライド。

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
672
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

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

×