Contenu connexe Similaire à Agile Estimating And Planning (20) Plus de Eiwa System Management, Inc. (10) Agile Estimating And Planning1. アジャイルな
見積りと
計画づくり
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日水曜日
17. “ この本が問いかけているのは「開
発者にとって客は敵なのか味方な
のか」という問いだと思う。
id:essa, 「アジャイルな見積りと計画づくり」書評 -- 顧客を黙らせる為の見積りではなく喋らせる為の見積り
http://d.hatena.ne.jp/essa/20090607/p2
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日水曜日
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日水曜日
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日水曜日
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日水曜日
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日水曜日