Agile Estimating And Planning

1,382 views
1,271 views

Published on

FAgileTokyo2010

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,382
On SlideShare
0
From Embeds
0
Number of Embeds
60
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile Estimating And Planning

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

×