Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
アジャイルジャパン2010 日本アイ・ビー・エム株式会社 ソフトウェア事業 Rational 事業部 Rational テクニカルセールス部長 ソフトウェアライフサイクル・エバンジェリスト 玉川 憲 KenTamagawa
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
IBM ソフトウェアグループでの開発手法の変遷 1980 年代 1990 年代 現在 <ul><li>ウォーターフォール手法 </li></ul><ul><ul><li>メインフレームソフトウエア </li></ul></ul><ul><li>...
事例: Jazz プロジェクトの 「チームコンサート」開発 <ul><li>2005 年より 7 カ国以上、約 120 名体制 </li></ul><ul><li>第一弾の製品 「 Rational チームコンサート (RTC) 」 </li>...
皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
定義・構築・テストのスキルを持った 小規模チームを核にスケールさせる B 機能チーム A 機能チーム X 機能チーム C 機能チーム PMC 約 10 人 4-10 人 x 20 統合テスト
皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
どれくらいのアーキテクチャが 必要か? それは、 何を作っているかに依存する
意図的なアーキテクチャ ソフトウェア アーキテクチャ 製品に対する要件 統合テスト・チーム 開発チーム(スクラム) チーム間 スクラム ( PMC ) アーキテクト
皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
Jazz は、グローバル開発 <ul><li>一つのチームに属する人ですら、 散らばっている </li></ul>Zurich Beaverton Ottawa Saint Nazaire Raleigh Toronto Winnipeg Le...
高度に分散した開発の管理 <ul><li>コミュニケーションのサポート </li></ul><ul><li>電話会議・チャット </li></ul><ul><ul><li>各チームは、デイリーミーティング </li></ul></ul><ul>...
Jazz チームコンサート 設計担当 テスト担当 既存ツール アジャイルチーム 要件担当 実装担当 変更管理 テスト管理 要求管理 構成管理 ビルド管理 障害管理 構成管理 プロセス管理 Jazz Team Server 要求 ( スコープ )...
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
社内 IT 部門における推進体制 <ul><li>Agile の推進コミュニティを発足 </li></ul><ul><li>Agile が適用できるかどうかを判断する 質問票 を用意 </li></ul><ul><li>業務、 PM 、開発者向...
Agile が適用できるかどうかを 判断する質問票を用意 質問内容 ・契約形態 ・要求の変化度合い ・仕様変更を許容するか ・他のアプリとの依存関係 ・ユーザーの巻き込み ・ ToBe モデルの存在 ・ UI ベースでユーザーが評価しやすいか?...
PM のためのプロジェクトガイド ( 立ち上げ、計画、見積もり、ドキュメント ) を用意
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
日本のサービス部門における アジャイル事例 <ul><li>ユーザー企業からの興味が高まっている </li></ul><ul><ul><li>後から変更が発生することを想定した開発プロセス </li></ul></ul>
日本のサービス部門における アジャイル事例 <ul><li>ユーザー企業からの興味が高まっている </li></ul><ul><ul><li>後から変更が発生することを想定した開発プロセス </li></ul></ul><ul><li>特に必要...
IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><...
アジャイルジャパン2010 Q&A
Rational チームコンサート (RTC) とは? <ul><li>プロジェクトの透明性を高めるために、 Eclipse 開発などの経験をベースに、 IBM Rational が一から作り直した製品 </li></ul><ul><li>チー...
チームコンサートを使ってみる! <ul><li>Jazz ポータル </li></ul><ul><ul><li>チームコンサートの Express-C は無償バージョンが DL できます </li></ul></ul><ul><ul><li>h...
アジャイル開発の本質と スケールアップ  変化に強い大規模開発を成功させる 14 のベストプラクティス デスマーチ対策ツール チームコンサート超入門 アジャイルプロジェクト管理 スクラムではじめる最強エンタープライズ開発
さらに詳しく知りたい方は <ul><li>IBM Rational </li></ul><ul><ul><li>http://www-06.ibm.com/software/jp/rational/ </li></ul></ul><ul><li...
Prochain SlideShare
Chargement dans…5
×

大規模アジャイル Ibm

大規模アジャイルのパネルディスカッションの前説で使用した資料

  • Soyez le premier à commenter

大規模アジャイル Ibm

  1. 1. アジャイルジャパン2010 日本アイ・ビー・エム株式会社 ソフトウェア事業 Rational 事業部 Rational テクニカルセールス部長 ソフトウェアライフサイクル・エバンジェリスト 玉川 憲 KenTamagawa
  2. 2. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>
  3. 3. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>横展開済み 展開中 事例化
  4. 4. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>大規模のポイント 推進体制 日本ならではの 難しさ 横展開済み 展開中 事例化
  5. 5. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>大規模のポイント 推進体制 日本ならではの 難しさ 横展開済み 展開中 事例化
  6. 6. IBM ソフトウェアグループでの開発手法の変遷 1980 年代 1990 年代 現在 <ul><li>ウォーターフォール手法 </li></ul><ul><ul><li>メインフレームソフトウエア </li></ul></ul><ul><li>反復型開発手法 </li></ul><ul><ul><li>分散プラットフォームでの開発 </li></ul></ul><ul><li>アジャイル手法 </li></ul><ul><ul><li>Web アプリケーション、 オープンソースの開発、 Jazz </li></ul></ul>
  7. 7. 事例: Jazz プロジェクトの 「チームコンサート」開発 <ul><li>2005 年より 7 カ国以上、約 120 名体制 </li></ul><ul><li>第一弾の製品 「 Rational チームコンサート (RTC) 」 </li></ul><ul><li>アジャイル・プラクティス (Scrum, XP) を利用 </li></ul><ul><li>「チームコンサート」自身を用いて、 Jazz 系製品を開発 </li></ul>Zurich Beaverton Ottawa Saint Nazaire Raleigh Toronto Winnipeg Lexington Bangalore Tokyo Shanghai
  8. 8. 皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
  9. 9. 定義・構築・テストのスキルを持った 小規模チームを核にスケールさせる B 機能チーム A 機能チーム X 機能チーム C 機能チーム PMC 約 10 人 4-10 人 x 20 統合テスト
  10. 10. 皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
  11. 11. どれくらいのアーキテクチャが 必要か? それは、 何を作っているかに依存する
  12. 12. 意図的なアーキテクチャ ソフトウェア アーキテクチャ 製品に対する要件 統合テスト・チーム 開発チーム(スクラム) チーム間 スクラム ( PMC ) アーキテクト
  13. 13. 皆様からの疑問ランキング <ul><li>どうやって大規模化するの? </li></ul><ul><li>アーキテクチャは自然発生するの? </li></ul><ul><li>オフショアじゃ無理でしょ?! </li></ul>
  14. 14. Jazz は、グローバル開発 <ul><li>一つのチームに属する人ですら、 散らばっている </li></ul>Zurich Beaverton Ottawa Saint Nazaire Raleigh Toronto Winnipeg Lexington Bangalore Tokyo Shanghai ワークアイテム プロセス Web UI ソース管理 PMC
  15. 15. 高度に分散した開発の管理 <ul><li>コミュニケーションのサポート </li></ul><ul><li>電話会議・チャット </li></ul><ul><ul><li>各チームは、デイリーミーティング </li></ul></ul><ul><ul><li>PMC は週2回のスクラムミーティング </li></ul></ul><ul><li>チームがコラボレーションする環境 </li></ul><ul><ul><li>誰が何をやっているか、誰が次に何をやるかをリアルタイムに把握 </li></ul></ul><ul><ul><li>一元化されたソース管理、作業管理、ビルド管理、問題管理 </li></ul></ul>
  16. 16. Jazz チームコンサート 設計担当 テスト担当 既存ツール アジャイルチーム 要件担当 実装担当 変更管理 テスト管理 要求管理 構成管理 ビルド管理 障害管理 構成管理 プロセス管理 Jazz Team Server 要求 ( スコープ ) 時間 アジャイル Beck 2000 既存ツール群 要求 分析・設計 実装 テスト 時間 要求 ( スコープ ) ウォーターフォール Royce 1970
  17. 17. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>大規模のポイント 推進体制 日本ならではの 難しさ 横展開済み 展開中 事例化
  18. 18. 社内 IT 部門における推進体制 <ul><li>Agile の推進コミュニティを発足 </li></ul><ul><li>Agile が適用できるかどうかを判断する 質問票 を用意 </li></ul><ul><li>業務、 PM 、開発者向けの Agile トレーニング を準備 </li></ul><ul><li>PM のために、 プロジェクトガイド を用意 </li></ul><ul><li>アジャイル開発を支える ツール を提供 </li></ul><ul><ul><li>スクラムテンプレート、 OpenUP テンプレートなどを準備 </li></ul></ul><ul><ul><li>プロジェクトの作業・進捗をオフショア環境でも見える化 </li></ul></ul>
  19. 19. Agile が適用できるかどうかを 判断する質問票を用意 質問内容 ・契約形態 ・要求の変化度合い ・仕様変更を許容するか ・他のアプリとの依存関係 ・ユーザーの巻き込み ・ ToBe モデルの存在 ・ UI ベースでユーザーが評価しやすいか? ・プログラム言語 ・スキルレベル ・チームサイズ ・クライアントとの関係 ・・・
  20. 20. PM のためのプロジェクトガイド ( 立ち上げ、計画、見積もり、ドキュメント ) を用意
  21. 21. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>大規模のポイント 推進体制 日本ならではの 難しさ 横展開済み 展開中 事例化
  22. 22. 日本のサービス部門における アジャイル事例 <ul><li>ユーザー企業からの興味が高まっている </li></ul><ul><ul><li>後から変更が発生することを想定した開発プロセス </li></ul></ul>
  23. 23. 日本のサービス部門における アジャイル事例 <ul><li>ユーザー企業からの興味が高まっている </li></ul><ul><ul><li>後から変更が発生することを想定した開発プロセス </li></ul></ul><ul><li>特に必要な考慮点 </li></ul><ul><ul><li>縦、横の両方からのコミットが必要 </li></ul></ul><ul><ul><li>利害関係者への逆三角形の周知徹底 </li></ul></ul><ul><ul><li>がちがちの職位・プラミッド構造の緩和 </li></ul></ul><ul><ul><li>契約形態 </li></ul></ul>
  24. 24. IBM におけるアジャイルへの取り組み <ul><li>製品開発部門 </li></ul><ul><ul><li>Agile な開発手法を 標準 として推進 </li></ul></ul><ul><li>社内 IT 部門 </li></ul><ul><ul><li>適用可能プロジェクト には Agile の適用を原則化 </li></ul></ul><ul><li>サービス部門 </li></ul><ul><ul><li>Agile な プロセスを準備 。日本でも事例がではじめている。 </li></ul></ul>大規模のポイント 推進体制 日本ならではの 難しさ 横展開済み 展開中 事例化
  25. 25. アジャイルジャパン2010 Q&A
  26. 26. Rational チームコンサート (RTC) とは? <ul><li>プロジェクトの透明性を高めるために、 Eclipse 開発などの経験をベースに、 IBM Rational が一から作り直した製品 </li></ul><ul><li>チームコンサートを使用することで生産性を高める: </li></ul><ul><ul><li>情報の一元化、トレーサビリティの自動化、プロセス自動化 </li></ul></ul><ul><ul><li>コミュニケーション&透明性を高め、早期にリスク対応がとれる </li></ul></ul><ul><ul><li>レポーティングのための工数削減 </li></ul></ul><ul><ul><li>インフラコスト ( ハードウェア、ソフトウェア ) 、管理コストの削減 </li></ul></ul>ビルド管理 障害管理 構成管理 プロセス管理 開発者 ビルド管理 障害管理 構成管理 プロセス管理 開発者 Jazz サーバー
  27. 27. チームコンサートを使ってみる! <ul><li>Jazz ポータル </li></ul><ul><ul><li>チームコンサートの Express-C は無償バージョンが DL できます </li></ul></ul><ul><ul><li>http://www-06.ibm.com/software/jp/jazz/ </li></ul></ul><ul><li>Jazz & RTC wiki </li></ul><ul><ul><li>チームコンサートの情報が豊富です </li></ul></ul><ul><ul><li>http://www.ibm.com/developerworks/wikis/display/rtcj/ </li></ul></ul><ul><li>Jazz の日本コミュニティ </li></ul><ul><ul><li>チームコンサートの Q&A フォーラムがあります </li></ul></ul><ul><ul><li>http://jazz-jp.net/ </li></ul></ul><ul><li>Jazz の本家 </li></ul><ul><ul><li>http://jazz.net/ </li></ul></ul>
  28. 28. アジャイル開発の本質と スケールアップ 変化に強い大規模開発を成功させる 14 のベストプラクティス デスマーチ対策ツール チームコンサート超入門 アジャイルプロジェクト管理 スクラムではじめる最強エンタープライズ開発
  29. 29. さらに詳しく知りたい方は <ul><li>IBM Rational </li></ul><ul><ul><li>http://www-06.ibm.com/software/jp/rational/ </li></ul></ul><ul><li>ツイッター </li></ul><ul><ul><li>Twitter.com/KenTamagawa </li></ul></ul><ul><li>玉川のブログ - Jazz ブログ http://www.ibm.com/developerworks/blogs/page/jazzydev </li></ul>

×