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