XP&Agile2002 2002.09.09 さまざまなアジャイル開発プ ロセスとその適用 山田正樹/メタボリックス [email protected] 2002.09.09 agile • [アジャイル]または[アジル] 1. (動きが)機敏な, はしっこい 2. 頭の回転の速い, 機敏な, 明敏な – • 例えば... 2002.09.09 ©Metabolics, Ltd. 研究社新英和中辞典より ©Metabolics, Ltd. 2 1 XP&Agile2002 2002.09.09 agile • アジル・コンペティション—「速い経 営」が企業を変える – スティーブン・L. ゴールドマン (著), その 他 (1996/04/01) 日本経済新聞社 • アジル生産システム—速い経営・速い 生産 – 野口 恒 (著) (1997/03/01) 生産性出版 2002.09.09 ©Metabolics, Ltd. 3 アジャイル開発プロセス • • • • • • キャッチフレーズにؘえば... 「よいものを手早く無駄なく作る」 「お客さん、喜ぶ。開発者、満」 本当にそんなことが可能だろうか? 具体的にはどんな方法がある? 実際に取り入れるには? 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 4 2 XP&Agile2002 2002.09.09 さまざまなアジャイル開発プ ロセス • • • • • • • • エクストリーム¢プログラミング (XP) スクラム (Scrum) フィーチャ駆動型開発 (FDD) クリスタル (Crystal) 適応的ソフトウェア開発 (ASD) リーン¢ソフトウェア開発 (LSD) エクストリーム¢モデリング (XM) ...... 2002.09.09 ©Metabolics, Ltd. 5 エクストリーム¢プログラミン グ • ... ケント¢ベック氏に任せる • ... 本もいっぱいある 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 6 3 XP&Agile2002 2002.09.09 エクストリーム¢プログラミン グ • 4つの価値 • 12のプラクティス • エンジニアリングにフォーカスした強 い方法論 2002.09.09 ©Metabolics, Ltd. 7 4つの価値 • • • • コミュニケーション 単純さ フィードバック 勇気 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 8 4 XP&Agile2002 2002.09.09 12のプラクティス • ב画ゲーム • いつも二人で • すぐリリース • みんなで共有 • メタファ • 単純さ優先 • いつも統合 • 週40時間労働 • まずテスト • リファクタリング • ش客も一緒 • コーディングӪ準 2002.09.09 ©Metabolics, Ltd. 9 プラクティスを支える多くの アイデア • プロジェクト速度 • ストーリー¢カード • 自動統合スクリプト • 構成管理 • タスク¢カード • コーチ • スパイキング • スタンドアップ¢ミー ティング • インソーシング • xUnit • ファシリティ 2002.09.09 ©Metabolics, Ltd. • CRCカード • ....... ©Metabolics, Ltd. 10 5 XP&Agile2002 2002.09.09 エクストリーム¢プログラミン グ • どんなプロジェクトに向いているか? – テクノロジにフォーカスした、 – 要求や技術の変化の激しい、 – 少人数のチーム。 – システムӪ模の大小は問わない – メンタや経験者の参加を強く勧める – 全員のトレーニング参加を強く勧める 2002.09.09 ©Metabolics, Ltd. 11 エクストリーム¢プログラミン グ • 利点 – よく知られているので導入しやすいかも – 参考になる資料や組織も多い • 日本XPユーザ¢グループ(XPJUG) • http://xp.medinfo.m.ehime-u.ac.jp/ – うまくいけばఫ常に効果/効率はژい – 双方にとってリスクを低減できる 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 12 6 XP&Agile2002 2002.09.09 エクストリーム¢プログラミン グ • 欠点 – 気を抜くと総崩れ – 癖があるので感情的な抵抗があるかも 2002.09.09 ©Metabolics, Ltd. 13 エクストリーム¢プログラミン グ • 何を期待できるか? – ژい品ޑ – 低い開発コスト – 短い開発期間 – 要求や技術の変化への対応 – 人を育てる – 組織に活気をもたらす 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 14 7 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 15 スクラム • Ken Schwaber – http://www.controlchaos.com/ • Jeff Sutherland – http://jeffsutherland.org/scrum/ • “Agile Software Development w/ Scrum” – ഀ訳もまもなく出版予定 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 16 8 XP&Agile2002 2002.09.09 スクラム • 5つの価値 • 5つのプラクティス • マネージメントにフォーカスした強い 方法論 2002.09.09 ©Metabolics, Ltd. 17 5つの価値 • • • • • コミットすること 集中すること オープンであること 敬意を払うこと 勇気を出すこと 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 18 9 XP&Agile2002 2002.09.09 5つのプラクティス • • • • • スクラム¢マスタ スプリント バックログ スクラム¢ミーティング スプリント¢レビュー 2002.09.09 ©Metabolics, Ltd. 19 スクラム プロダクト¢バックログ ビジネス上の要件 スプリントのב画 スプリント¢レビュー デイリー¢スクラム スプリント¢バックログ 2002.09.09 ©Metabolics, Ltd. スプリント(30日間) ©Metabolics, Ltd. 20 10 XP&Agile2002 2002.09.09 スクラム¢チーム • 一つのスクラム¢チームは5~9人 • 各スクラム¢チームにスクラム¢マスタ がいる • 一つのプロジェクトが複数のスクラム¢ チームから構成されていてもよい – その場合にはスクラム¢マスタのスクラム¢ マスタを置く 2002.09.09 ©Metabolics, Ltd. 21 プロダクト¢オーナ • 一つのプロダクトに対して一人のプロ ダクト¢オーナがいる – ش客、ユーザ代表、マネージメントなど – プロダクトに関する決定権を持つ 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 22 11 XP&Agile2002 2002.09.09 プロダクト¢バックログ • プロダクトの開発すべき機能の一覧 – 優先順位が付いている – 開発中に変わってもよい – プロダクト¢オーナがすべて制御する – 関係者全員にオープンにする – バックログ = 仕掛品 2002.09.09 ©Metabolics, Ltd. 23 スプリント • (暦上の)30日間のイテレーション • すべての責任と権限はチームにある – 勝つためなら何をやってもいい • 何をするべきかはチーム外のも指示 できない – 逆にؘえばも指示してくれない • チームは創発的に自己組織化する 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 24 12 XP&Agile2002 2002.09.09 スプリント¢バックログ • スプリントですべきことは最初にスプ リント¢バックログに記述する • スプリントの目的はスプリント¢バック ログを消化すること • スプリント中はチーム¢メンバ以外には 変えられない • プロダクト¢バックログの優先順位のژ いものから 2002.09.09 ©Metabolics, Ltd. 25 スクラム¢マスタ • チームを引っ張る • デイリ¢スクラムを主催する • メンバのあらゆる問題点をあらゆる手 を使ってЖ決する • メンバをチーム外の圧力/障害から守る • ఫ常に重要な役割 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 26 13 XP&Agile2002 2002.09.09 デイリ¢スクラム • • • • • • 毎日決まった時間に決まった場所で 全員参加、刻厳禁、ܚਮ禁止 メンバ以外はいっさいの干渉禁止 テレコンファレンスでもよい だいたい15分程度 問題Ж決のミーティングは別途開催 2002.09.09 ©Metabolics, Ltd. 27 デイリ¢スクラム • スクラム¢マスタがメンバ一人一人に順 に次のޑ問をする – あなたは昨日何をしましたか? – あなたは今日何をしますか? – あなたが今抱えている問題は何ですか? • これだけ 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 28 14 XP&Agile2002 2002.09.09 スプリント • スプリント期間中、 • メンバはバックログを一つずつ消し、 • スクラム¢マスタはみんなの問題をЖ決 し、 – これがスクラム¢マスタの信頼の素 • 他の関係者はじっと黙って30日目を待 つ。 2002.09.09 ©Metabolics, Ltd. 29 スプリント¢レビュー • 30日目にその成果をお披目する • 必ず動作するソフトウェアが必要 – デモンストレーション • 関係者全員が参加 • このレビューを元に次のスプリントの ב画を立てる 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 30 15 XP&Agile2002 2002.09.09 スクラム • 全体としてスプリントを数回~10回程度 繰りೊす • もし無理ならば、チームはスプリント をキャンセルしてやり直すことが可能 • ش客は30日分のリスクを負う 2002.09.09 ©Metabolics, Ltd. 31 スクラム • どんなプロジェクトに向いているか? – 要求や技術の変化が激しいプロダクト。 – チームӪ模やシステムӪ模の大小はあまり 関係ない – メンタリティの強いスクラム¢マスタが必 要 – あまりにش客や組織が強いと難しいかも 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 32 16 XP&Agile2002 2002.09.09 スクラム • 利点 – 多様なプロジェクトで採用可能 • Ӫ模、分野、技術などにあまり依存しない – 比ѕ的導入しやすい – 双方にとって比ѕ的リスクが低い 2002.09.09 ©Metabolics, Ltd. 33 スクラム • 欠点 – スクラム¢マスタがチーム外からの圧力に 屈すると影՝が大きい – 人間的要素が大きい • マニュアル通りやればスクラムになるとは限ら ない 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 34 17 XP&Agile2002 2002.09.09 スクラム • 何を期待できるか? – 要求や技術の変化への対応 – スケジュールの制御 – 人を育てる – 組織を変化させるきっかけになる • ピラミッド型から自律分散型へ 2002.09.09 ©Metabolics, Ltd. 35 XP+Scrum • XPとScrumはフォーカスしている側面 が違う • 両方を組み合わせるとఫ常に強力 • XP@Scrum – http://www.controlchaos.com/xpScrum.htm • Xbreed – http://www.xbreed.net/index.html 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 36 18 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 37 フィーチャ駆動型開発 • Jeff De Luca – http://www.nebulon.com/fdd/ • Peter Coad • “Javaエンタープライズ¢コンポーネン ト” • “A Practical Guide to Feature-driven Development” 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 38 19 XP&Agile2002 2002.09.09 フィーチャ駆動型開発 • 8つのプラクティス • 5つのプロセス • テクノロジとマネジメント両面をサポー トする古典的な繰りೊし型開発の一種 – ただし十分軽量/明確 2002.09.09 ©Metabolics, Ltd. 39 8つのプラクティス • • • • • • • • ドメイン¢オブジェクト¢モデリング フィーチャごとの開発 クラスの個人所有 フィーチャごとのチーム編成 インスペクション 定期的なビルド 構成管理 結果の報告と透明性 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 40 20 XP&Agile2002 2002.09.09 フィーチャ • ユーザ機能ともいう – 実現のための機能ではない – ش客に価値をもたらすもの – できるだけ小さく • 何をやるか明確で(2週間) • ב測可能な大きさ(オーバーヘッド、精度) – “オブジェクトXXXのYYYをZZZする” 2002.09.09 ©Metabolics, Ltd. 41 フィーチャ • フィーチャはかなり小さいので... • 関連したフィーチャをまとめたのが フィーチャ¢セット – “オブジェクトXXXをZZZする” • 中心となるフィーチャ¢セットが主要 フィーチャ¢セット – “XXXマネージャ” 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 42 21 XP&Agile2002 2002.09.09 ドメイン¢モデル • 概念モデルと呼ばれることもある • 問題領域に現れるオブジェクトをモデ リングしたもの • 現実の世界に対応しているので実装な どの変化の影՝を受けにくい • 他のモデルのベースになる • ユーザやش客に理Жしやすい 2002.09.09 ©Metabolics, Ltd. 43 インスペクション • Michael Fagan (IBM, 1976) • 単なるレビューではない • ఫ常に効率がژいので有名 – 生産性向上 30~100% – 開発期間短縮 10~30% – テスト¢コスト/期間の短縮 1/5 ~ 1/10 – 保守費用の低減 全体の10%以下に 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 44 22 XP&Agile2002 2002.09.09 インスペクション • • • • • • 参加者は前もって準備する チェックリスト(1頁以内)に従う ミーティングは最大2時間 ミーティングでは議論はしない ログを取る ちゃんとしたリーダがいる 2002.09.09 ©Metabolics, Ltd. 45 インスペクション • 実はインスペクション自体が一つの方 法論といえるほど強力な手法の一つ • ただしあまり軽量とはؘえない • “ソフトウェア¢インスペクション” (T. Gilb, F. Graham, 1999, 共立出版) • 役に立たないだらだらレビューから見 れば参考になる点が多い 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 46 23 XP&Agile2002 2002.09.09 構成管理 • バージョン+構成の管理 • 「いつでも元に戻れる」が重要 – 自由と勇気を与えてくれる • アジャイルであろうがなかろうが必ࣆ • ツール – CVS (Concurrent Versioning System) – Subversion – ...... 2002.09.09 ©Metabolics, Ltd. 47 5つのプロセス 1. 全体を表すオブジェクト¢モデルの作 成 2. フィーチャ¢リストの作成 3. フィーチャ開発ב画の作成 4. フィーチャごとのध( בDBF) 5. フィーチャごとの構築 (BBF) – 2002.09.09 ©Metabolics, Ltd. 4, 5は合わせて2週間単位の繰りೊし ©Metabolics, Ltd. 48 24 XP&Agile2002 2002.09.09 5つのプロセス 全体を表すオブジェクト¢モデルの作成 フィーチャ¢リストの作成 フィーチャ開発ב画の作成 フィーチャごとのधב フィーチャごとの構築 2002.09.09 ©Metabolics, Ltd. 49 プロセス¢テンプレート • ETVX – Entry 開始条件 – Task 実際の作業 – Verification 作業成果の検証 – eXit 終了条件 • 各プロセスごとにETVXが定義されてい る 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 50 25 XP&Agile2002 2002.09.09 全体を表すオブジェクト¢モデ ルの作成 1. 2. 3. 4. 5. 6. 7. モデリング¢チームの結成 問題領域のウォークスルー ドキュメントੴ査 小グループによるモデリング チーム全体でのモデリング モデルの詳細化 コメントの記述 2002.09.09 ©Metabolics, Ltd. 51 フィーチャ¢リストの作成 1. フィーチャ¢リスト作成チームの結成 2. フィーチャ¢リストの作成 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 52 26 XP&Agile2002 2002.09.09 フィーチャ開発ב画の作成 1. ב画作成チームの結成 2. スケジュールの作成 3. フィーチャ¢セットのチーフ¢プログラ マへの割り当て 4. クラスの開発者への割り当て 2002.09.09 ©Metabolics, Ltd. 53 フィーチャごとのधב 1. 2. 3. 4. 5. 6. 7. フィーチャ¢チームの結成 問題領域のウォークスルー 関連ドキュメントのੴ査 シーケンス図作成 オブジェクト¢モデルの詳細化 クラス¢インタフェースの記述 धבインスペクション 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 54 27 XP&Agile2002 2002.09.09 フィーチャごとの構築 1. 2. 3. 4. クラスの実装 コード¢インスペクション 単体テスト ビルド 2002.09.09 ©Metabolics, Ltd. 55 プロセスごとの時間割当例 プロセス 初期 繰りೊし 全体を表すオブジェクト¢モ デルの作成 10% 4% フィーチャ¢リストの作成 4% 1% フィーチャ開発ב画の作成 2% 2% フィーチャごとのधב/構築 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 77% 56 28 XP&Agile2002 2002.09.09 進捗グラフの例 フィーチャ¢セットの状況 作業中 れ 完了 フィーチャ¢セット名 (フィーチャ数) 完了度 未開始 完了度 完了予定日 2002.09.09 ©Metabolics, Ltd. 57 フィーチャ駆動型開発 • どんなプロジェクトに向いているか? – 中Ӫ模以上のチーム – モデリングの経験がある – 古典的なプロセスを体験している – あまり過激なことはやりたくない 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 58 29 XP&Agile2002 2002.09.09 フィーチャ駆動型開発 • 利点 – 古典的な手法の経験者に受け入れられやす い – ツール化しやすい – モデリングのプロセスとかなり密に結合し ている 2002.09.09 ©Metabolics, Ltd. 59 フィーチャ駆動型開発 • 欠点 – モデリングのプロセスとかなり密に結合し ている – まったくプロセスを持たない組織が一度に 導入するのは難しいかもしれない – 具体的である分、汎用性に欠けるかもしれ ない 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 60 30 XP&Agile2002 2002.09.09 フィーチャ駆動型開発 • 何を期待できるか? – 今まで古典的な手法で古典的なプロダクト を作ってきたソフトウェア組織が、オブジェ クトを使ってプロダクトを作るときのよい ガイドラインになり得る – 組織の性ޑ上中庸を求められる場合には使 いやすく、ほどほどの成果を得られる ©Metabolics, Ltd. 2002.09.09 ©Metabolics, Ltd. 61 2002.09.09 ©Metabolics, Ltd. 62 31 XP&Agile2002 2002.09.09 クリスタル • ...アリスター¢コーバーン氏に聞いてみ よう • マネージメントにフォーカスした弱い 方法論 – FDDと同様古典的な繰りೊし型開発の一種 と考えてもよい – 開発Ӫ模に応じてパラメータ化されている 2002.09.09 ©Metabolics, Ltd. 63 クリスタル • “Agile Software Development” • “Surviving Object-Oriented Project” – ഀ訳を会場で売っているはず... – これらにはあまりクリスタルは出てこない が... 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 64 32 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 65 適応的ソフトウェア開発 • Jim Highsmith – http://www.adaptivesd.com/ • “Adaptice Software Development” • “Agile Software Development Ecosystems” – まもなくഀ訳出版予定 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 66 33 XP&Agile2002 2002.09.09 適応的ソフトウェア開発 • 3つのモデル • 1つの適応的ライフサイクル • 複ܚ適応系(CAS)の理論を応用した、エ ンジニアリングとマネージメントの両 面に渉る大きなフレームワーク 2002.09.09 ©Metabolics, Ltd. 67 3つのモデル • 概念モデル – 理論的背景 • 開発モデル – 適応的ライフサイクル • 管理モデル – リーダーシップ+協ੴ • この三つの絡み合いで成立している 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 68 34 XP&Agile2002 2002.09.09 3つのモデル 秩序の創発 ウォーターフォール ニュートン的世界観 複ܚ適応系 概念 モデル 開発 モデル 管理 モデル 2002.09.09 ©Metabolics, Ltd. 適応的開発 命令と制御 適応的管理 69 概念モデル • 理論的背景で実ॏ的内容はない • 複ܚ適応系(CAS) – ひとはエージェントなり – チームはCASなり 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 70 35 XP&Agile2002 2002.09.09 開発モデル • 適応的開発ライフサイクル – 推測 – 協ੴ – 学習 • 古典的な繰りೊし型ライフサイクル(ב 画 - 構築 - 改訂)とは異なる 2002.09.09 ©Metabolics, Ltd. 71 推測 • 複ܚな系ではב画は役に立たない – 結果が予測不可能なのにב画は無意味 – ב画からのずれこそが進むべき道を示して いる • 推測はミッションとして表す – howではなくwhatを表す – 共有されることが重要 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 72 36 XP&Agile2002 2002.09.09 ミッション • ミッションは以下のドキュメントに表 す – プロジェクト¢ビジョン(憲章) • 2~10頁、キーとなる目的/仕様/位置付けなど – プロジェクト¢データ¢シート • 1頁、管理上必要事項のまとめ – プロダクト仕様アウトライン • 仕様の概要 2002.09.09 ©Metabolics, Ltd. 73 適応的ライフサイクル • 適応的ライフサイクルは – ミッションによって駆動される – コンポーネント¢ベースである – 繰りೊし型である – 時間で区切られている – リスクによって駆動される – 変化に強い 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 74 37 XP&Agile2002 2002.09.09 適応的ライフサイクル 学習のループ プロジェクト 立ち上げ 推測 2002.09.09 適応的 サイクル ב画 並行 並行 コンポーネント コンポーネント 開発 開発 品ޑ レビュー 協ੴ ©Metabolics, Ltd. 最終QA リリース 学習 75 ב画の立て方 1. プロジェクトを立ち上げる 2. プロジェクトのタイムボックスを決め る 3. サイクルの数とそれぞれのタイムボッ クスを決める 4. サイクルごとの目的を文書化する 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 76 38 XP&Agile2002 2002.09.09 ב画の立て方 5. 主要なコンポーネントをサイクルに割 り当てる 6. 技術要素と他のコンポーネントをサイ クルに割り当てる 7. プロジェクト¢タスク¢リストを作る • サイクルごとにレビューと再ב画を行 う 2002.09.09 ©Metabolics, Ltd. 77 協ੴ • が何をやるかは自分たちで決める • 4つの価値 – 互いに信頼し合う – 互いに尊敬の念を持つ – 互いに関わり合う – 一致してコミットメントする 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 78 39 XP&Agile2002 2002.09.09 Joint Application Development • ユーザ参加型の要求定義プロセス – IBM, 1984 • “Joint Application Development”(Wood & Silver, 1995) • これを協ੴのツールとしてプロジェク ト内で利用する 2002.09.09 ©Metabolics, Ltd. 79 学習 • 推測と協ੴの結果との誤差を学習する – トレーニングはスキルの獲得だが、学習は 物事に向かう態度である – 重要なのは何を学んだかではなく、如何に 学んだかである – 重要なのは正確さではなく、適切さである 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 80 40 XP&Agile2002 2002.09.09 学習のためのツール • ش客中心グループ(CFG)¢レビュー • ソフトウェア¢インスペクション • プロジェクト¢ポストモータム 2002.09.09 ©Metabolics, Ltd. 81 CFGレビュー • 開発者とش客の参加するセッション – 成果物をレビューする – 変更要求を文書化する – 参加者はそれぞれ役割を担う – ただしش客側の視点から – 必要ならばش客が開発に参加できるように する 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 82 41 XP&Agile2002 2002.09.09 ソフトウェア¢インスペクショ ン • 前述 2002.09.09 ©Metabolics, Ltd. 83 プロジェクト¢ポストモータム • ポストモータム(検死) – レトロスペクションと呼んでください:-) • うまくいったのは何か? • どんな問題がӭきたか? • もっとよくするためにはどうするとい いか? 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 84 42 XP&Agile2002 2002.09.09 管理モデル • リーダーシップと協ੴ • アカウンタビリティ • 文化を創る – 最適化(CMM L5)ではなく適応が重要 2002.09.09 ©Metabolics, Ltd. 85 管理モデル • ワークフローではなくワークステート で考える – ワークフローはよく定義され、繰りೊされ るタスクには向いている – ソフトウェアではアクティビティ間の依存 関係が明確でない • 例えばコンポーネントの状態として – outline/detail/reviewed/approved 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 86 43 XP&Agile2002 2002.09.09 適応的ソフトウェア開発 • どんなプロジェクトに向いているか – Ӫ模や分野に特に制約はない – ただしチャレンジングである必要がある – 技術や要求の変化が激しい 2002.09.09 ©Metabolics, Ltd. 87 適応的ソフトウェア開発 • 利点と欠点 – 理論的には整然としている – フレームワークはかなり大きい • 影՝も初期投資もかなり大きい可能性がある • 必ずしも軽量とはؘえない – 大Ӫ模なプロジェクトでも適用可能性がژ い – まだよく分かっていない... 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 88 44 XP&Agile2002 2002.09.09 適応的ソフトウェア開発 • 何が期待できるか? – 要求や技術の変化への対応 – 新しいパラダイムの有効性:-) – ...... ©Metabolics, Ltd. 2002.09.09 ©Metabolics, Ltd. 89 2002.09.09 ©Metabolics, Ltd. 90 45 XP&Agile2002 2002.09.09 リーン¢ソフトウェア開発 • Mary Poppendiek – http://www.poppendieck.com/ 2002.09.09 ©Metabolics, Ltd. 91 リーン¢ソフトウェア開発 • 10のルール • 13のツール • 具体的な方法論とؘうよりは、アジャイル開 発プロセスの基本原則や理論的背景を示した もの – ベースになっているのは、トヨタ生産方式(カンバ ン、ムダ取り)など – リーン生産、TQMの原則をソフトウェアに適用 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 92 46 XP&Agile2002 2002.09.09 10のルール • • • • • ムダをなくせ 在庫は最小に 停滞するな 必要になったら取りに行く お客様中心 2002.09.09 ©Metabolics, Ltd. 93 10のルール • • • • • 最初からきちんと 現場に権限を 一カ所だけよくしてもダメ ੴ達は少しずつ やり続ける文化を作る 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 94 47 XP&Agile2002 2002.09.09 ムダをなくせ • ソフトウェア開発におけるムダとは? – 例えば中間成果物(ドキュメント、図、モ デルなど) – これらは本当に最終成果物に価値を付け加 えているか? – もっと効率よく価値を付加できる方法はな いか? 2002.09.09 ©Metabolics, Ltd. 95 在庫は最小に • ソフトウェア開発における在庫とは? – 例えば最終成果物ではないドキュメント – これらに実際どれだけの工数を掛けている か? • 作成、レビュー、変更管理、... – 最大にすべき開発の流れをॱ害していない か? 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 96 48 XP&Agile2002 2002.09.09 停滞するな • ソフトウェア開発における停滞とは? – Work-in-process(WIP, やりかけの仕事) – WIPを減らせば全体のサイクル¢タイムを 減らすことができる – そのためには • small batch - 仕事の単位を小さく • smooth flow - 次の仕事につなげる – いわゆる繰りೊし開発 2002.09.09 ©Metabolics, Ltd. 97 必要になったら取りに行く • ソフトウェア開発における後工程引取 りとは? – 遠い将来に納品されるシステムの要求を予 測しない – 要求やधבを初期の段階で凍結しない – 決断はできるだけ後まで引き延ばす – これによって要求や要求の変更をできるだ け早く製品に反映できる 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 98 49 XP&Agile2002 2002.09.09 お客様中心 • 品ޑとはお客様の満度 • 最初にどれほど要求を詳細に決めて、 決定事項としたところで、必ず変化す る • その変化への対応も品ޑ • 変化を知るには実際に使ってもらうし かない(短いリリース) 2002.09.09 ©Metabolics, Ltd. 99 最初からきちんと • 「まずやってみてダメだったら直す」 はダメ – これは「要求を初期に凍結する」のとは別 • 変更はあり得る、きちんと変更できる ためには – テストをプロセスに組み込みなさい – リファクタリングしなさい 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 100 50 XP&Agile2002 2002.09.09 現場に権限を • 自分たちの問題のЖ決の仕方は自分た ちで決める • 紙やプロセスよりも人や協ੴが重要 • 紙で渡される情報は暗黙知を失いやす い 2002.09.09 ©Metabolics, Ltd. 101 一カ所だけよくしてもダメ • 局所的に生産性を上げても全体の生産 性は上がらない(むしろ落ちる) • 問題は単純な生産性ではなく、全体の 流れとタイミングが重要 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 102 51 XP&Agile2002 2002.09.09 ੴ達は少しずつ • evolutionary procurement(acquisition) – 一度に大量にੴ達するのでなく少しずつ 期にわたってੴ達すること – ムダが生じる – 変化に対応できない 2002.09.09 ©Metabolics, Ltd. 103 やり続ける文化を作る • CMMやISO9000などドキュメント-プロ セスのパラダイムは、固定したプロセ スで間に合う場合には有効 • しかし変化への感受性に欠ける • Plan - Do - Check - Actionサイクルが重要 • さらにプロジェクトをΡえた改善の継 続が必要 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 104 52 XP&Agile2002 2002.09.09 13のツール • 分析のためのツール – バリュー¢ストリーム¢マッピング – 延コスト – リアル¢オプション • 制御のためのツール – 待ち行列理論 – 制御理論 – 複ܚ性理論 2002.09.09 ©Metabolics, Ltd. 105 13のツール • 組織のためのツール – プロフェッショナリズム – 目的 – 契約 • ソフトウェア開発のツール – – – – イテレーション 最終決断時点 集合にもとづく開発 テストの役割 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 106 53 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 107 エクストリーム¢モデリング • http://www.extrememodeling.org/ • 常に検証可能な形でモデリングを行い、 モデルから直接実行可能な製品を生成 する方法論 – eXecutable UML (旧シュレーヤ¢メラー法) – OMG MDA(Model Driven Architecture) – なども含めて考えることができる 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 108 54 XP&Agile2002 2002.09.09 エクストリーム¢モデリング • 今までのモデリングは反アジャイル – いくらモデルを書いても最終的にはほとん ど何ももたらさない(ムダ) • 一ಊではすでに実用化されている – BridgePoint (http://www.projtech.com/) – iUML (http://www.kc.com/) – など 2002.09.09 ©Metabolics, Ltd. 109 エクストリーム¢モデリング • ツールが必ࣆ – 現状はఫ常にژ価で一般的でない • UML2の行方が将来を握っている • ソフトウェア開発に劇的な変化がӭこ るだろうと思われる 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 110 55 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 111 アジャイル開発プロセスをど う適用するか? • 大きく分けて二つの選択肢がある – 既存のアジャイル開発プロセスを導入する – 自分たちのプロセスをベースにアジャイル 化を進める • いずれにしろ以下のステップを踏む必 要がある 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 112 56 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 1. アジャイル開発プロセス適用のスコー プを決める • プロジェクト単位か、ಊ単位か、組織単 位か • 最終的には組織がコミットしなければう まくいかない • が、とりあえずの出発点は小さくてもよ い 2002.09.09 ©Metabolics, Ltd. 113 アジャイル開発プロセス適用 ステップ 2. 自分たちのビジネス¢ゴールを明確に する • • • • 2002.09.09 ©Metabolics, Ltd. 現状では何が問題なのか? 何を目指すのか? なぜアジャイル開発プロセスが必要なの か? できるだけオープンに議論し、できるだ けビジョンを共有する ©Metabolics, Ltd. 114 57 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 3. イントロスペクションを行う • • 何が問題なのか? その理由は何か? • • 変えるためには何が必要か? よかった点は何か? • • もっとよくするためには何ができるか? やってみたいことは何か? 2002.09.09 ©Metabolics, Ltd. 115 アジャイル開発プロセス適用 ステップ 4. 導入方法を決める 1. 既存のアジャイル開発プロセスを導入す る 2. 自分たちのプロセスをベースにアジャイ ル化する 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 116 58 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 5. 導入するプロセスの詳細をੴ査する • • 導入コスト 導入によるインパクト • • 導入によるリスク 期待される効果 • • プロセスの適不適 ...... 2002.09.09 ©Metabolics, Ltd. 117 プロセス¢マトリックス XP Scrum FDD Crystal ASD 効果 ◎ ◎ ○ ○ ? プロジェク 小 トӪ模 - - - 中< インパクト 大 中 小 小 中< コスト 中 小 小 小 中? これはあくまでも例です。自分の状況の中で判断してください 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 118 59 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 6. ઉ加するとよいプラクティスはある か • ほかのアジャイル開発プロセスから • • 自分たちのプロセスのいいところ 組織/プロセス¢パターン 2002.09.09 ©Metabolics, Ltd. 119 組織/プロセス¢パターン • Coplien他多数 – http://www.kamenet.com/jplop/Translation/GDP/patternIndex.htm • “アンチパターン” (1999, ソフトバンク) • G. ワインバーグ – ソフトウェア文化を創るシリーズ他 • “The Manager Pool”(2001, AWL) • 場合によってはCMMだって参考になる • ...... 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 120 60 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 7. トレーニングなどを受ける • • • できれば全員 XPを除けば国内で定期的に行われている トレーニングは少ないだろう • http://www.tech-arts.co.jp/training/index.html • • 日本XPユーザ会など コンサルタント、メンタなどに依頼 少なくともある程度の勉強を 2002.09.09 ©Metabolics, Ltd. 121 アジャイル開発プロセス適用 ステップ 8. 初期プロセスを明確にしてメンバ全員 の同意を得る • • • • プロセスを何らかの形で記述しておく もちろん後で変わっても構わない すぎるのはダメ(1頁が基本) 補助的にSPEMを使ってもいいかも • • 2002.09.09 ©Metabolics, Ltd. Software Process Engineering Metamodel UMLを拡張してプロセスを図示する記法 ©Metabolics, Ltd. 122 61 XP&Agile2002 2002.09.09 アジャイル開発プロセス適用 ステップ 9. Go ! 2002.09.09 ©Metabolics, Ltd. 123 アジャイル開発プロセス適用 ステップ 10. 何らかの客観的な指標を用いて結果を 評価する – 最初のビジネス¢ゴールの達成をבる – – 一つでもいい、簡単でもいい プロセスが備えている指標でも使えれば OK – アジャイルだから測定無しということは ない! 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 124 62 XP&Agile2002 2002.09.09 2002.09.09 ©Metabolics, Ltd. 125 アジャイル¢アライアンス • http://www.agilealliance.org/home – アジャイル開発プロセスの提唱者たちを中 心としたコミュニティ • http://www.agilemanifesto.org/principles.ht ml – 最後に彼らの掲げる原則を... 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 126 63 XP&Agile2002 2002.09.09 我々は価値のあるソフトウェアを できるだけ早い段階から 継続的に引き渡すことによって お客様の満度をژめることを もっとも優先します 2002.09.09 ©Metabolics, Ltd. 127 要件の変更は 例え開発の後期であっても 受け入れます 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 128 64 XP&Agile2002 2002.09.09 アジャイル¢プロセスは 変化を味方につけることによって お客様の競争力を引き上げます 2002.09.09 ©Metabolics, Ltd. 129 動くソフトウェアを 2~3週間から2~3ヶ月という できるだけ短い時間間隔で 繰りೊし引き渡します 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 130 65 XP&Agile2002 2002.09.09 ビジネスをする人と開発者は プロジェクトを通して 日々一緒に働かなければなりません 2002.09.09 ©Metabolics, Ltd. 131 意欲に満ちた人々を集めて プロジェクトを構成します。 ですから彼らが必要とする 環境と支援を与え 仕事が無事終わるまで 彼らを信頼してください 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 132 66 XP&Agile2002 2002.09.09 開発チームに対して あるいは開発チーム内ಊで情報を伝える もっとも効率的で効果的な方法は 面と向かって話をすることです 2002.09.09 ©Metabolics, Ltd. 133 動いているソフトウェアこそが 進捗の最も重要な尺度です 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 134 67 XP&Agile2002 2002.09.09 アジャイル¢プロセスは 持続可能な開発を促進します。 スポンサ、開発者、ユーザは 一定のペースで 永続的に保守 できるようにしなければなりません 2002.09.09 ©Metabolics, Ltd. 135 卓Ρした技術と 優れたधבに対する不断の注意こそが 機敏さをژめます 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 136 68 XP&Agile2002 2002.09.09 単純さ - 作業せずに済む量を 最大限に引き上げる技量 が本ޑです 2002.09.09 ©Metabolics, Ltd. 137 最良の アーキテクチャ、要件、धבは 自己組織的なチームから 生み出されます 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 138 69 XP&Agile2002 2002.09.09 どうしたら チームがもっと効率を ژめることができるかを 定期的に振りೊり、 それに基づいて自分たちのやり方を 最適にੴ整します 2002.09.09 ©Metabolics, Ltd. ©Metabolics, Ltd. 139 70
© Copyright 2026 Paperzz
