Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

Agility@Scale (ゕジャ゗ル開発のスケールゕップ) を実現する14のベストプラクテゖス 19-B-2 玉川憲 (twitter.com/KenTamagawa) 日本ゕ゗・ビー・エム株式会社 Rational事業部テクニカルセールス部長 IBMソフトウェゕエバンジェリスト Developers Summit 2010

なぜ今、アジリティが求められる？  経営戦略の寿命が短期化  世界売上高ランキング上位50社の平均滞留年数4.8年 →ピーク迄は2年半  競争力を持続させていくには下記が求められる  商品・サービスの市場・顧客ニーズ変化への俊敏な対応  業務提携による新規ビジネスの早期実現  経営統合によるシナジー効果の早期実現出典：ITゕーキテクトVol.12 2007 Developers Summit 2010 2

アジャイル導入の効果は魅力的ゕジャ゗ル導入により、改善されたと答えている人の割合生産性品質 82% 87% 顧客満足度コスト 78% 72% Source: Dr Dobb’s 2008 Agile Adoption Survey Developers Summit 2010 3

IBMソフトウェアグループでの開発手法の変遷  ウォーターフォール 1980年代 • 要求の変更が少ない市場 • 最初に要求を決めて厳密な方法で開発 • 多くのメ゗ンフレームソフトウエゕ  反復型開発 1990年代 • 要求の変化が起こる市場 • 反復型開発でリスクを逓減 • ９０年～２０００年前半での分散プラットフォームでの開発  ゕジャ゗ル開発現在 • 要求の変化が非常に大きい市場 • 適応型開発で市場に迅速に反応 • Webゕプリケーション、オープンソースの開発、Jazz Developers Summit 2010 4

米国でのアジャイル普及度 1つ以上のゕジャ゗ルの技法を使っていますか？ 18% of respondents indicated they’re still in the pilot stage 15% of “No” respondents hope to do Agile this year Source: Dr Dobb’s 2008 Agile Adoption Survey Developers Summit 2010 5

本日のアジェンダ  ゕジャ゗ル開発の本質  ゕジャ゗ル開発を企業に導入する際の課題  規模に関係なく適用可能なプラクテゖス  大規模だからこそ考えるプラクテゖス  まとめ Developers Summit 2010 6

アジャイル開発手法の共通点は、確かにある  各ゕジャ゗ル方法論には、確かに違いがあるが基本的なベストプラクテゖスには共通点がある反復＆インクリメンタル＆適応型の開発短いタイムボックス内で動くコード小さな一口単位で開発 Developers Summit 2010 7

アジャイル開発の共通ポイント１：反復＆インクリメンタル＆適応型ウォーターフォール要求(スコープ) 要求分析・設計実装テスト時間 Royce 1970 Developers Summit 2010 8

要求は劣化していく出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 9

アジャイル開発の共通ポイント１：反復＆インクリメンタル＆適応型ウォーターフォールアジャイル要求(スコープ) 要求(スコープ) 要求分析・設計実装テスト時間時間 Royce 1970 Beck 2000 Developers Summit 2010 10

アジャイル開発の共通ポイント１：反復＆インクリメンタル＆適応型ウォーターフォールアジャイル要求(スコープ) 要求(スコープ) 要求ムダに詳細要分析・設計求を作らない重要なものから作る実装システム統合リステストクを初期に削減時間時間早期にリリー Beck 2000 Royce 1970 フィードバックを得ス可能にて学習・改善 Developers Summit 2010 14

アジャイル開発の共通ポイント２：短いタイムボックス内で動くコードをストーリー１ストーリー２構築ストーリー３・・・バックログ評価定義テスト出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 15

アジャイル開発の共通ポイント２：短いタイムボックス内で動くコードを次を取り出しストーリー１ OK ストーリー２構築ストーリー３・・・バックログ評価定義テスト NG すぐに修正タ゗ムボックス出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 16

アジャイル開発の共通ポイント２：短いタイムボックス内で動くコードを次を取り出しストーリー１チームの中で、 OK テストまで全てストーリー２構築ストーリー３行う・・・バックログ評価バックログで優定義テスト先順位を常に決められた期間は NG 管理絶対動かさないすぐに修正受け入れテストタ゗ムボックスをこの段階に出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 17

アジャイルの共通ポイント３：小さな一口単位で開発する  仕事は、ストーリーとタスクに分けるストーリー  ストーリー  「柔軟な」要求の表現  または、ある要求の話し合いの必要性を示したもの  実現すべき機能タスク  タスクタスク  ストーリーを実装するために、メンバーが行うべきタスクこと  ストーリーの粒度は数日、タスクの粒度は一日以内  実施の直前に、この詳細に分解する出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 18

パラダイムシフト：スコープを、固定せずに管理するウォーターフォールゕジャ゗ル要求(スコープ) リソース期日固定される価値重視計画重視見積もられるリソース期日要求(スコープ) 出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 19

なぜ、アジャイルは企業レベルでは使えないと思われるのか？  もともと小規模開発から発達してきたその経緯  確かに、著名なゕジャ゗ルプロセスであるXPは元は10人以下のチーム向き  そもそも、小規模向き、ということで、企業で真剣に考慮されない  ゕジャ゗ルプラクテゖスのうち、実質的に大規模開発に不向きなものがある  例：「同一地点での開発」、「顧客もチームの一部に」  既存の開発スタ゗ルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい  例：既存の縦割り組織形態、官僚的文化、契約体系、既存ゕセット Developers Summit 2010 21

なぜ、アジャイルは企業レベルでは使えないと思われるのか？  もともと小規模開発から発達してきたその経緯・方法論、技術、ツールが進化。大規模適用をサポート・ゕジャ゗ルのメリットを活かせるところは追求すべき  ゕジャ゗ルプラクテゖスのうち、実質的に大規模開発に不向きなものがある  既存の開発スタ゗ルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい Developers Summit 2010 22

なぜ、アジャイルは企業レベルでは使えないと思われるのか？  もともと小規模開発から発達してきたその経緯  ゕジャ゗ルプラクテゖスのうち、実質的に大規模開発に不向きなものがある・多くのプラクテゖスがそのまま大規模開発でも適用できる・不向きなプラクテゖスは工夫が必要！  既存の開発スタ゗ルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい Developers Summit 2010 23

大規模開発に不向きなプラクティス  小チームでの開発  企業レベルで百以上の数となる小チームを、どう組織と適合させるか  顧客をチームの一部に  多くの場合、顧客は離れているか、スキルや時間がない  同一場所での開発  規模が拡大すれば、同じ場所にいることは事実上不可能  ゕーキテクチャーは、自然発現する  規模の大きな開発では、事前にゕーキテクチャーの準備が必要  要求分析と仕様書の欠如  開発者がそのつど要求を引き出す考え方は、大規模開発では心もとない  文化の環境、物理的環境  傍から見たゕジャ゗ルの仕事ぶりは、しばしばプロらしくなく見える出展： Scaling Software Agility Developers Summit 2010 24

なぜ、アジャイルは企業レベルでは使えないと思われるのか？  もともと小規模開発から発達してきたその経緯  ゕジャ゗ルプラクテゖスのうち、実質的に大規模開発に不向きなものがある  既存の開発スタ゗ルに慣れている組織にとっては、大規模であればあるほど「新しいもの」を導入することが難しい・開発者の能力と生産性のために、変化は不可欠企業そのものに内在する課題を乗り越えることが必要！ Developers Summit 2010 25

企業そのものに内在する課題  プロセスとプロジェクトマネジメント組織  プロジェクトマネジメント組織が、自らの権限/権威が少なくなる変化に抵抗する  既存の公式なポリシーと手続き  過去の苦い経験によって追加されてきたガ゗ドラ゗ンは、変更が容易ではない  企業文化  企業は時間をかけて、「ゕジャ゗ルのためにならない」強力な文化を培ってきた  期日も機能も固定した上でなんとかやれ、という依頼  範囲と期日とリソースがあらかじめ決められて開発チームに命令されるならば、ゕジャ゗ル開発は成立しない  開発部門とユーザー・顧客代理チームとの摩擦  開発チームとユーザー部門の間には、相互不信の原因となる苦い経験があることが多い  職制によって組織された人々  組織は、職制（製品マネジメント、ゕーキテクチャー、開発者など）で編成されていることが多い  高度に分散した開発  企業が大きくなるほど、組織は分散化する出展： Scaling Software Agility Developers Summit 2010 26

規模に関係なく適用できるプラクティス  定義・構築・テストのコンポーネント・チーム  2 レベル計画作りと追跡  反復型開発  頻繁な小規模リリース  コンカレントテステゖング  継続的゗ンテグレーション  継続的な考察と適応 Developers Summit 2010 28

事例：Jazzプロジェクトの「チームコンサート」開発  Jazzプロジェクトは、2005年より7カ国以上、約120名体制  Jazzの最初の成果が、「Rationalチームコンサート(RTC)」  ゕジャ゗ルプラクテゖス (Scrum, XP) を利用  「チームコンサート」自身を用いて、Jazz系製品を開発 Winnipeg Lexington Ottawa Saint Nazaire Shanghai Toronto Beaverton Zurich Raleigh Tokyo Bangalore Developers Summit 2010 29

Rationalチームコンサート(RTC)とは？  プロジェクトの透明性を高めるために、Eclipse開発、 CC/CQ開発での経験をベースに、IBM Rationalが一から作り直した製品構成管理ビルド管理ビルド管理構成管理プロセス管理障害管理プロセス管理開発者開発者 Jazz サーバー障害管理チームコンサートを使用することで生産性を高める：・情報の一元化、トレーサビリテゖの自動化、プロセス自動化・コミュニケーション＆透明性を高め、早期にリスク対応がとれる・レポーテゖングのための工数削減・゗ンフラコスト(ハードウェゕ、ソフトウェゕ)、管理コストの削減 Developers Summit 2010 30

定義・構築・テストのコンポーネント・チーム  「定義・構築・テスト」のスキルを有したチームを核として、チーム編成  RTCチームの場合  2段階のチーム構成 (PMC、コンポーネント)  各チームにプロセス（運営）を任せる、統括PMが一人プロセスワークアイテムソース管理 4-10人x 20 PMC 約10人 Web UI 統合テスト Developers Summit 2010

反復型開発、頻繁な小規模リリースリリースウォームアップリリース計画 M1a M1 立ち上げ安定化安定化計画計画開発開発 4週間 4週間マ゗ルストーン Developers Summit 2010 32

反復型開発、頻繁な小規模リリースリリースウォームアップリリース計画 M1a M1 … エンドゲーム修正- 洗練化立ち上げテスト安定化安定化安定化テスト計画計画開発開発開発修正計画 4週間 4週間 4週間マ゗ルストーン Developers Summit 2010 33

反復型開発、頻繁な小規模リリースリリースウォームアップリリース計画 M1a M1 … エンドゲーム修正- 洗練化立ち上げテスト安定化安定化安定化テスト計画計画開発開発開発修正計画 4週間 4週間 4週間要件定義マ゗ルストーン Developers Summit 2010 34

反復型開発、頻繁な小規模リリースリリースウォームアップリリース計画 M1a M1 … エンドゲーム修正- 洗練化立ち上げテスト安定化安定化安定化テスト計画計画開発開発開発修正計画 4週間 4週間 4週間要件定義マ゗ルストーンリリース用のテイテレーション毎の Jazz.netでダウスト、ドキュメンテスト・デモ・ふりかえりンロード可能にト整備35 Developers Summit 2010 35

２レベル計画づくりと追跡  アジャイルでは、粗いリリース計画と、詳細な反復計画を用いて、計画づくりとトラッキングを行う RTCチームの場合テーマ 5-10 リリース計画プランアイテムプランアイテムプランアイテム（PMC) 40-50 ストーリーストーリーストーリー反復計画タスク (チーム毎) タスク Developers Summit 2010 36

２レベル計画づくりと追跡リリースバックログ各自のタスクの状況が一覧できるスプリントバックログ見積もりポイント、優先順位を一元的に管理 Developers Summit 2010

コンカレントテスティング  アジャイルでは、「すべてのコードはテストされたコード」である  RTCチームの場合  反復毎に、各チームレベルで、ユニットテスト、機能テスト、受け入れテストを行う  リリースにむけ、統合テストチームが、並行して、パフォーマンステスト、信頼性テストを行うプロセスワークアイテムソース管理 4-10人x 20 PMC Web UI 約10人統合テスト Developers Summit 2010 38

継続的インテグレーション  正常に動くビルドを少なくとも1 日1 回作り出す  ソース統合、ビルド自動化、テスト自動化が必要  RTCチームの場合  チームコンサートを用いて一元管理、常に動く安定したプログラムを保持  テストコードを含んだ、個人の作業領域での個人ビルド  チーム領域でのビルド  統合領域でのビルド (安定したもの）出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 39

反復ごとの「ふりかえり」の実施  定期的間隔で、チームはより効率を高めるためにどうすべきか考察し、やり方を改善する  RTCチームの場合  反復ごとにチーム毎、PMCレベルで実施  ふりかえり(Retrospective)の結果も、チームコンサートを使って管理 40 Developers Summit 2010 40

本日のアジェンダ  ゕジャ゗ル開発の本質  ゕジャ゗ル開発を企業に導入する際の課題  規模に関係なく適用可能なプ7ラクテゖス  大規模だからこそ考える7プラクテゖス  まとめ Developers Summit 2010 41

大規模だからこそ必要なプラクティス  意図的なゕーキテクチャ  リーン要求開発のスケールゕップ：ビジョン、ロードマップ、ジャスト゗ンタ゗ムの詳細化  ゕジャ゗ルリリーストレ゗ン  高度に分散した開発の管理  顧客とオペレーションへの゗ンパクトの調整  組織を変化させる  ビジネスパフォーマンスを計測する Developers Summit 2010 42

意図的なアーキテクチャ  ゕーキテクチャは出現するのか？ →どれぐらいのゕーキテクチャをチームが必要とするかは、何を作っているのか依存する出展：「ゕジャ゗ル開発の本質とスケールゕップ」 Developers Summit 2010 43

意図的なアーキテクチャ RTCチームの場合製品に対する要件ソフトウェアコンポーネント Developers Summit 2010 44

意図的なアーキテクチャ RTCチームの場合製品に対する要件ソフトウェアコンポーネント開発チーム（スクラム）統合テスト・チームチーム間スクラム（PMC） 4-10人 x 20チーム Developers Summit 2010 45

リーン要求開発  ゕジャ゗ルなチームは、素早いコーデゖングにより、形式的な仕様書を避ける  とはいえ、大規模開発においては、ビジョンは、非機能要求などの共通な要求は前倒しで持っておくべき  また、要求の劣化を避けるために、ジャスト゗ンタ゗ムで要求を詳細化する必要がある 46 Developers Summit 2010 46

リーン要求開発 RTCチームの場合ビジョン（開発構想書）ロードマップリリース1 リリース2 リリースv1.0 リリースv2.0 2009年9月 2009年12月テーマ：快適なバーテーマ：スケーラビ反復#1 反復#2 反復#3 反復#4 ジョン管理リティバージョン管理分散開発での管理 Emailでの通知 RSSでの通知プラットフォームプラットフォーム Windows Linux バックログジャストインタイムで ID ストーリー優先順位見積もりストーリーの詳細化 xxxx xxxx Developers Summit 2010 47

高度に分散した開発の管理  大規模開発では、分散開発にならざるをえない  同じ都市や建物内でも、チームはバラバラ  以下の情報の共有が不可欠  優先度、リゕルタ゗ムの状況、依存関係、阻害要因  ツールの使用と、より組織的なゕプローチへの必要性が高まる  電話会議システム、チャット  共通プロジェクトマネジメント、共有要求、ソースコードマネジメント、統合ビルド環境、変更管理、自動化テストを可能とするツール Developers Summit 2010

高度に分散した開発の管理 RTCチームの場合  一つのチームに属する人も散らばっている Winnipeg Lexington Ottawa Saint Nazaire Shanghai Toronto Beaverton Zurich Tokyo Raleigh Bangalore プロセスワークアイテム PMC ソース管理 Web UI Developers Summit 2010

高度に分散した開発の管理 RTCチームの場合  社内の電話会議システム  各チームは、デ゗リーミーテゖング（電話会議）  各自、昨日やったこと、今日やること、課題の共有  PMCは週２回のスクラムミーテゖング  ツールによるチーム内情報共有  誰が何をやっているか、誰が次に何をやるかをリゕルタ゗ムに把握  常に変化に対応できる体制  RTCを用いて  一元化されたソース管理、作業管理、問題管理  情報を見える化し、情報間のトレーサビリテゖを自動保持  適切なレベルのプロセス管理 Developers Summit 2010 50

アジャイル・リリーストレイン  一般的に、アジャイルチームはより多くの成果を素早く納品可  しかし、大規模では成果納品のコーディネーションが難しい  アジャイル・リリーストレインの概念が登場  リリースを、固定され遅らせることのできないスケジュールと考える  時間通りに次々と発車する電車のように  リリース日、テーマ、品質が固定  上記3つが固定であるならば、可変できるのは機能 Developers Summit 2010 51

アジャイル・リリーストレイン Developers Summit 2010 52

アジャイル・リリーストレインリリースウォームアップリリース計画 M1a M1 … エンドゲーム修正- 洗練化立ち上げテスト安定化安定化安定化テスト計画計画開発開発開発修正計画複数チーム間で同期をとらねばならないもの 4週間 4週間 4週間は必須。それ以外は、マ゗ルストーン優先順位付けしたものから作る。 53 Developers Summit 2010 53

顧客とオペレーションへのインパクトの調整  小規模で頻繁なリリースは、言うは安く行なうは難し  開発チームがそれを実施できても、企業とすればそれで終わらない  他システムとの連携  納品プロセス、保守チーム  営業やマーケテゖングなどの利害関係者  リリースの目標に向かって、より多くのコーデゖネーションとコミュニケーションが必要となる Developers Summit 2010 54

顧客とオペレーションへのインパクトの調整チームコンサート開発チームの場合  Jazz.net で開発の模様を完全に外に公開  ソースコードも、開発タスクの状態も丸見え  タ゗ムリーな情報公開  ユーザーからのフゖードバックを早期に採り入れる  開発者と、ユーザーの距離を縮める Developers Summit 2010 55

組織を変化させる  ボトムゕップゕプローチ  ゕジャ゗ル開発を、企業内の「小さなチーム」に適用しても、それなりの効果がある  トップダウンゕプローチ  ゕジャ゗ルのメリットを最大限に活かすため、全社適用して組織が抱える課題に取り組む  ステップ  ①スポンサー、エヴゔンジェリストを確保  ②組織のゕジリテゖに対する適合性を評価  ③パ゗ロットプロジェクトを実施  ④組織への展開計画の策定  適切なトレーニング  ツール、サポート、コミュニテゖのサポート Developers Summit 2010 56

組織を変化させる  RTCチームの場合  IBM Software Group内で、ゕジャ゗ル推進チーム「 Agile Transformation」を組織化  情報を集約し、HELPデスクの役割を果たす  定期的に、プラクテゖスの浸透度を測定  PM、開発者向けのAgileトレーニングを準備  ゕジャ゗ル開発を支えるツールを提供(RTC) Developers Summit 2010 57

組織を変化させる [非公開] IBMにおけるプラクテゖス浸透度(グラフ) Developers Summit 2010 58

ビジネスパフォーマンスを計測する  開発チームレベルでは、  動くコードの進捗測定が、生産性の指標として最良  他のさまざまな指標は二義的  しかし、企業には他のレベルでの測定に対するニーズ  全社に渡るビジネスパフォーマンスの測定  例：経営者が複数プロジェクトを横串でみて、ポートフォリオとして判断するための指標 Developers Summit 2010 59

ビジネスパフォーマンスを計測する  チームコンサートへの入力等を利用して、上位マネージメントのためのダッシュボードを提供 (Rational Insight) 出展： Scaling Software Agility Developers Summit 2010 60

規模に関係なく適用できるプラクティス  定義・構築・テストのコンポーネント・チーム  2 レベル計画作りと追跡  反復型開発  頻繁な小規模リリース  コンカレントテステゖング  継続的゗ンテグレーション  継続的な考察と適応 Developers Summit 2010 62

大規模だからこそ必要なプラクティス  意図的なゕーキテクチャ  リーン要求開発のスケールゕップ：ビジョン、ロードマップ、ジャスト゗ンタ゗ムの詳細化  ゕジャ゗ルリリーストレ゗ン  高度に分散した開発の管理  顧客とオペレーションへの゗ンパクトの調整  組織を変化させる  ビジネスパフォーマンスを計測する Developers Summit 2010 63

まとめ  ゕジャ゗ルは使える――そして、スケールゕップ可能です！本日の公演内容をもっと詳しく知りたい方のために： http://www.amazon.co.jp/ dp/4798120405/ Developers Summit 2010 64

チームコンサート無料版！  アジャイルなチームのための開発環境である「チームコンサート」のデモブースにも是非お立ち寄りください！  先着で、無料版Express-CのCDが入手できます！  RTC wiki  RTC情報が沢山！  Jazz-jp.net  Express-Cの質問可能！ Developers Summit 2010 65

http://forza.cocolog-nifty.com	287
http://www.slideshare.net	42
http://blog.livedoor.jp	19
http://192.168.80.1	1

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

by 玉川憲 (Ken Tamagawa) - Amazon Web Services

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 349

Statistics