Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Agile Estimating And Planning
Ähnlich wie Agile Estimating And Planning (20)
Mehr von Eiwa System Management, Inc.
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
Agile Estimating And Planning
- 1. アジャイルな 見積りと 計画づくり Agile Estimating and Planning 角谷 信太郎 (株)永和システムマネジメント 日本Rubyの会 s-kakutani@esm.co.jp KAKUTANI Shintaro; Nihon Ruby-no-kai; Eiwa System Management,Inc. FAgile2010東京; 2010-03-09(Tue) 2010年3月10日水曜日
- 2. 角谷信太郎 kakutani.com !"!#$"%&'()*+,-./ 2010年3月10日水曜日
- 3. 提 供 情報化 技術を通じて 社 会と 共 生 す る 2010年3月10日水曜日
- 4. 角谷信太郎 ! 受託開発のプログラマ ! 日本Rubyの会理事 ! 技術書の翻訳・監訳 2010年3月10日水曜日
- 7. よろしく お願いします 2010年3月10日水曜日
- 8. 今日のお話 ! 書籍のキーワードについて ! 過去5年以上の私たちの現 場経験をもとに、 ! その有用性と限界、課題に ついてお話しします 2010年3月10日水曜日
- 9. お品書き ! 解読 アジャイル ! アジャイルな 見積りと計画づくり ! 見積り ! 計画づくり 2010年3月10日水曜日
- 10. Agile Software Development http://www.flickr.com/photos/long-mai/3569550298/ 2010年3月10日水曜日
- 11. 再注目される アジャイル ! マネージャ, 経営層に ! かつては現場リーダ,プログラマの祈りだった ! 非ウォーターフォール ! 「ここではないどこか」の総称として ! 事例が積み重なってきた ! 北米の2006年頃の状況に似ている? 2010年3月10日水曜日
- 12. 依然としてよくある誤解 ! ドキュメントを書かない ! 計画をたてない ! 短期開発に向いている ! プラクティス をやる ! 毎回リリースするの? 2010年3月10日水曜日
- 13. 依然としてよくある誤解 ! ドキュメントを書かない ! 計画をたてない ! 短期開発に向いている ! プラクティス をやる ! 毎回リリースするの? 2010年3月10日水曜日
- 16. 「アジャイルプロジェ クトの見積りと計画づ くり」ではなく、見積 りや計画づくりといっ たプロセスをアジャイ ルに進めるための一冊 2010年3月10日水曜日
- 17. “ この本が問いかけているのは「開 発者にとって客は敵なのか味方な のか」という問いだと思う。 id:essa, 「アジャイルな見積りと計画づくり」書評 -- 顧客を黙らせる為の見積りではなく喋らせる為の見積り http://d.hatena.ne.jp/essa/20090607/p2 2010年3月10日水曜日
- 20. “ Expect Unexpected Changes 0123456789:;<=5>?=@ ''12A; 2010年3月10日水曜日
- 21. Agile Software Development http://www.flickr.com/photos/long-mai/3569550298/ 2010年3月10日水曜日
- 22. アジャイルな開発とは ! 変化する環境に、 ! 適応しながら、 ! ビジネス価値のある ! ソフトウェアを ! 提供し続けるための作戦 2010年3月10日水曜日
- 23. Manifesto for Agile Software Development Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 2010年3月10日水曜日
- 27. アジャイル開発手法 ! eXtreme Programming(XP) ! ムーブメントの先駆けにして最強 ! 技術とビジネスのあいだに調和をもたらす ! Scrum ! プロジェクト運営と心構えのフレームワーク ! 北米でアジャイルといえば今はこれ。大流行。 ! Lean ! ソフトウェアを活用したビジネスのムダをなくす 2010年3月10日水曜日
- 28. アジャイル開発手法 ! インクリメンタル ! Incremental ! 漸進的 ! 少しずつ積み重ねていく ! イテレーティブ ! Iterative ! 繰り返し ! 2週間∼1ヶ月単位でのタイムボックス 2010年3月10日水曜日
- 30. 要求 フィードバック TDD 受入 2010年3月10日水曜日
- 31. 要求 フィードバック TDD 受入 2010年3月10日水曜日
- 32. 要求 フィードバック TDD 受入 2010年3月10日水曜日
- 33. 要求 フィードバック TDD 受入 2010年3月10日水曜日
- 35. フィードバック ? 要求 受入 TDD 半年とか1年 2010年3月10日水曜日
- 36. !!! フィードバック 要求 受入 TDD 半年とか1年 2010年3月10日水曜日
- 38. アジャイル開発手法 ! インクリメンタルかつ イテレーティブ ! 少しずつの積み重ねを 繰り返していく ! フィードバック重要 2010年3月10日水曜日
- 39. インクリメンタル開発の流れ タスク リリース計画 完了条件 優先順位づけ 分解 フィードバック バックログ テスト 満足条件 本番環境 受入テスト 検証 テスト駆動開発 ケース デプロイ 実施 受入テスト コード 統合 2週間でnバックログをこなす 2010年3月10日水曜日
- 40. インクリメンタル開発の流れ マイルストーン1 マイルストーン2 リリース1 リリース2 リリース3 リリース4 ... 1 2 3 4 5 6 7 8 9 10 11 ... イテレーション イテレーション イテレーション イテレーション マイルストーン: マイルストーンは契約の単位です。1つのマイルストーンにつき、1回以上リリー スするものとします。 リリース: リリースプランニングを通じて、リリースに含める内容を優先順位にしたがって各イテ レーションに割り当てます。含められる分量は、過去のイテレーション実績をもとに決定します。 イテレーション: 1∼2週間をタイムボックスとして、リリース計画で割り当てられた作業を実施し ます。状況の変化に応じて優先順位の変更に適応します。 2010年3月10日水曜日
- 41. アジャイル開発手法 ! インクリメンタル ! Incremental ! 漸進的 ! 少しずつ積み重ねていく ! イテレーティブ ! Iterative ! 繰り返し ! 2週間∼1ヶ月単位でのタイムボックス 2010年3月10日水曜日
- 42. “ ホモ・サピエンスはパターン認識生物だ、 とパーカーボーイはいう。 それは才能でもあり、罠でもある。 ーーウィリアム・ギブスン『パターン・リコグニション』 2010年3月10日水曜日
- 44. 手法や名前に 惑わされては いけない！！ 2010年3月10日水曜日
- 46. “ プロセスとは、どのような図、 文書、テストを実行すべきかに 関する形式的な一連の規則とい うよりも…実は実行すべきこと や実行すべきときを表すものに すぎないのです。また、頭文字 も必要ありません…適切に機能 すればよいのです。 『Head First ソフトウェア開発』 2010年3月10日水曜日
- 47. “ 自分のチームと自分のプロジェ クトに役立つプロセスを選び… そのプロセスが生み出した成果 物を自分の顧客の要望に合うよ うに調整します。 『Head First ソフトウェア開発』 2010年3月10日水曜日
- 49. アジャイルな見積りと計画づくり ! 見積り(Estimating) ! 計画づくり(Planning) ! アジャイルな(Agile) 2010年3月10日水曜日
- 51. 見積り ! Estimating ! 見積もること ! × 見積(御見積書) ! プロセス = 「過程」 2010年3月10日水曜日
- 53. 計画づくり ! Planning ! 計画を立てること ! × 計画(計画書) ! プロセス = 「過程」 2010年3月10日水曜日
- 54. 見積りと計画づくりの い ず れも が プ ロ セ ス 、 すなわち それ を実 行 す る こ と と 、 そ れを 実 行 す る 主 体 に つ いて の話題である。 2010年3月10日水曜日
- 55. そ して プ ロ セ ス 、 す な わち実行することと、 その実行主体(つまり 人)は既に遍在し実践 され続けている。 2010年3月10日水曜日
- 56. つまり プロセス と はソフトウェアをつ くって い る 活 動 そ の も の、すなわちソフト ウェアづくりである。 2010年3月10日水曜日
- 57. 2010年3月10日水曜日
- 58. 陰 2010年3月10日水曜日 陽
- 60. 2010年3月10日水曜日
- 62. Chapter23: The Timeless way of Programming !"#$%&'()*+,-./0-12 2010年3月10日水曜日
- 63. チームが技術とビジネスの関 心事項の調和を日常的に取れ るようにすることだ。 調和とバランスがXPの目的 である。 ケント・ベック『XPエクストリーム・プログラミング入門』第2版 2010年3月10日水曜日
- 64. ソフトウェアでは、新たな社 会構造を作る機会がある。 ケント・ベック『XPエクストリーム・プログラミング入門』第2版 2010年3月10日水曜日
- 65. チーム間の権力と責任の適切 な共有は、非現実的に思える かもしれない。 ケント・ベック『XPエクストリーム・プログラミング入門』第2版 2010年3月10日水曜日
- 66. バランスには、相互尊重が不 可欠である。絶対的な権力は 存在しない。 ケント・ベック『XPエクストリーム・プログラミング入門』第2版 2010年3月10日水曜日
- 67. 複数レベルの計画づくり 戦略 ポートフォリオ プロダクト リリース イテレーション 今日 2010年3月10日水曜日
- 68. ビジネスモデル突破の難しさ ! 人月 vs. 価値 ! 内製 vs. 発注 ! 準委任 vs. 一括請負 ! 新規開発 vs. 再構築 2010年3月10日水曜日
- 70. 計画の基準: フィーチャ(タスクではない) " フィーチャ(Feature): ソフトウェアの機能、特性や特徴、 性能目標、見た目や使い勝手など、いわゆる「売り文句」 を総称するもの " 要求仕様, 機能要件, 大機能, ユースケースとよく似ている " ユーザに価値を提供するものがフィーチャ " 性能要件やセキュリティといった非機能要件もフィーチャになりうる " フィーチャの 実装 手段はさまざま " ユーザーストーリー, ストーリーカード " Issue Tracking Systemに登録されたチケット " Excelの表 " ユースケース記述の変異したもの 2010年3月10日水曜日
- 73. ユーザーストーリの形式 ! As a/an <type of user>, ! 販売管理部門の担当として、 ! I Want To <some goal> ! 先月の締め日以降の今月の売上金額と数量を見たい ! So That <some reason> ! 経理部門にレポートを提出するために必要だから 2010年3月10日水曜日
- 78. 規模を見積もり、期間は導出する (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 80. Velocity ! 単位期間のあいだにプロ ジェクトが進んだ速度 ! 見積り単位は規模を表現 ! ストーリーポイント ! 理想日 2010年3月10日水曜日
- 82. 見積りの技法 " 見積りの単位 " ストーリーポイント vs. 理想日 " 相対サイズによる見積り " 対比、三角測量、分割 " 見積りのスケール " 1∼10倍の精度 " フィボナッチ数列(1, 2, 3, 5, 8) vs. 公比2の等比数列(1, 2, 4, 8) " 10倍を超える場合は分割するか、13, 20, 40, 100 を使う " テーマ, エピック, ユーザーストーリー " チームで1つの見積り " プランニングポーカー 2010年3月10日水曜日
- 83. プランニングポーカー http://store.mountaingoatsoftware.com/ http://www.planningpoker.com/ 2010年3月10日水曜日
- 88. 最初のベロシティの見積り ! 過去の実績値を使う ! 実際に1イテレーション やってみる ! 予想する ! 想定できる作業時間から積みあげていく 2010年3月10日水曜日
- 91. インクリメンタル開発の流れ マイルストーン1 マイルストーン2 リリース1 リリース2 リリース3 リリース4 ... 1 2 3 4 5 6 7 8 9 10 11 ... イテレーション イテレーション イテレーション イテレーション マイルストーン: マイルストーンは契約の単位です。1つのマイルストーンにつき、1回以上リリー スするものとします。 リリース: リリースプランニングを通じて、リリースに含める内容を優先順位にしたがって各イテ レーションに割り当てます。含められる分量は、過去のイテレーション実績をもとに決定します。 イテレーション: 1∼2週間をタイムボックスとして、リリース計画で割り当てられた作業を実施し ます。状況の変化に応じて優先順位の変更に適応します。 2010年3月10日水曜日
- 92. リリースプランニング (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 93. イテレーションプランニング " ベロシティ駆動イテレーションプランニング (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 94. イテレーションプランニング " コミットメント駆動イテレーションプランニング (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 95. プロジェクトレベルでの 計画づくり http://www.flickr.com/photos/alastairhumphreys/3188288778/ 2010年3月10日水曜日
- 96. プロジェクトのバッファ " 2点見積りによるバッファ " 平均ケース(50%見積り) " 最悪ケース(90%見積り) " 50%と90%の標準偏差の合計値の平方根(二乗和平方根法) " 1点見積りによるバッファ " 50%見積りの合計値 " 不確実性が適切に反映されないおそれ " フィーチャバッファとスケジュールバッファ " 期間全体に対して20%のバッファを用意できるか? 2010年3月10日水曜日
- 97. 二乗和平方根法によるバッファ算出の例 " 17(50%見積りの合計 + 9 (最悪-平均)2.round → 26ポイント (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 98. プロジェクトのモニタリング " バーンダウンチャート " バーンダウン棒グラフ " リリースまでに残っている作業 " 残作業に加えて、スコープの変 の規模を計測する 化もモニタリングする " 完了見込みを一目瞭然にする " 要求の安定性を一目瞭然にする " イテレーション単位で計測する " グラフの読み方やスコープ変化 (日次で計測することも可能) の扱いに習熟が必要 (『アジャイルな見積りと計画づくり』から引用) 2010年3月10日水曜日
- 100. まとめ ! アジャイル はここではないどこかへ行 くための魔法ではない。いまの世界の破 壊者でもない。 ! 自分たちの変化の速度に合わせてボトル ネックを移動させていくしかない ! やらない理由はいくらでもある ! 外部の制約は言い訳にしやすい 2010年3月10日水曜日