SIerにおくる、アジャイルプロセスの実践
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 387 views
Uploaded on

QCon Tokyo 2009の時のスライド。

QCon Tokyo 2009の時のスライド。

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
387
On Slideshare
387
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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