Agile Estimating And Planning

アジャイルな
見積りと
計画づくり
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日水曜日

角谷信太郎
kakutani.com
!"!#$"%&'()*+,-./

提供

情報化技術を通じて社会と共生する


角谷信太郎

! 受託開発のプログラマ
! 日本Rubyの会理事
! 技術書の翻訳・監訳


http://www.amazon.co.jp/o/ASIN/4839924023/kakutani-22

よろしく
お願いします

今日のお話
! 書籍のキーワードについて
! 過去5年以上の私たちの現
場経験をもとに、
! その有用性と限界、課題に
ついてお話しします

お品書き
! 解読アジャイル
! アジャイルな
見積りと計画づくり
! 見積り
! 計画づくり

Agile Software
Development

http://www.ﬂickr.com/photos/long-mai/3569550298/

再注目されるアジャイル
! マネージャ, 経営層に
! かつては現場リーダ,プログラマの祈りだった

! 非ウォーターフォール
! 「ここではないどこか」の総称として

! 事例が積み重なってきた
! 北米の2006年頃の状況に似ている?


依然としてよくある誤解
! ドキュメントを書かない
! 計画をたてない
! 短期開発に向いている
! プラクティスをやる
! 毎回リリースするの?

http://gihyo.jp/dev/serial/01/agile

「アジャイルプロジェ
クトの見積りと計画づ
くり」ではなく、見積
りや計画づくりといっ
たプロセスをアジャイ
ルに進めるための一冊

“ この本が問いかけているのは「開
発者にとって客は敵なのか味方な
のか」という問いだと思う。
id:essa, 「アジャイルな見積りと計画づくり」書評 -- 顧客を黙らせる為の見積りではなく喋らせる為の見積り
http://d.hatena.ne.jp/essa/20090607/p2


根源的な態度


“ Expect Unexpected Changes

0123456789:;<=5>?=@
''12A;

アジャイルな開発とは
! 変化する環境に、
! 適応しながら、
! ビジネス価値のある
! ソフトウェアを
! 提供し続けるための作戦

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

http://www.amazon.co.jp/o/ASIN/482228350X/kakutani-22

アジャイル開発手法
! eXtreme Programming(XP)
! ムーブメントの先駆けにして最強
! 技術とビジネスのあいだに調和をもたらす

! Scrum
! プロジェクト運営と心構えのフレームワーク
! 北米でアジャイルといえば今はこれ。大流行。

! Lean
! ソフトウェアを活用したビジネスのムダをなくす

! インクリメンタル
! Incremental
! 漸進的
! 少しずつ積み重ねていく

! イテレーティブ
! Iterative
! 繰り返し
! 2週間∼1ヶ月単位でのタイムボックス

インクリメンタル


要求フィードバック

TDD 受入


イテレーティブ


フィードバック
?
要求受入

TDD
半年とか1年

!!!
フィードバック

要求受入

TDD
半年とか1年

半年とか1年

! インクリメンタルかつ
イテレーティブ
! 少しずつの積み重ねを
繰り返していく
! フィードバック重要

インクリメンタル開発の流れ
タスク
リリース計画完了条件
優先順位づけ
分解

フィードバックバックログテスト
満足条件

本番環境受入テスト
検証テスト駆動開発
ケース
デプロイ
実施
受入テストコード
統合

2週間でnバックログをこなす


インクリメンタル開発の流れ
マイルストーン1 マイルストーン2

リリース1 リリース2 リリース3 リリース4 ...
1 2 3 4 5 6 7 8 9 10 11 ...
イテレーションイテレーションイテレーションイテレーション

マイルストーン: マイルストーンは契約の単位です。1つのマイルストーンにつき、1回以上リリー
スするものとします。

リリース: リリースプランニングを通じて、リリースに含める内容を優先順位にしたがって各イテ
レーションに割り当てます。含められる分量は、過去のイテレーション実績をもとに決定します。
イテレーション: 1∼2週間をタイムボックスとして、リリース計画で割り当てられた作業を実施し
ます。状況の変化に応じて優先順位の変更に適応します。


“ ホモ・サピエンスはパターン認識生物だ、
とパーカーボーイはいう。
それは才能でもあり、罠でもある。
ーーウィリアム・ギブスン『パターン・リコグニション』


http://www.imgspark.com/image/view/all/230089/

手法や名前に
惑わされては
いけない！！

http://www.amazon.co.jp/o/ASIN/487311392X/kakutani-22

“ プロセスとは、どのような図、
文書、テストを実行すべきかに
関する形式的な一連の規則とい
うよりも…実は実行すべきこと
や実行すべきときを表すものに
すぎないのです。また、頭文字
も必要ありません…適切に機能
すればよいのです。
『Head First ソフトウェア開発』

“ 自分のチームと自分のプロジェ
クトに役立つプロセスを選び…
そのプロセスが生み出した成果
物を自分の顧客の要望に合うよ
うに調整します。
『Head First ソフトウェア開発』


アジャイルな見積りと計画づくり

! 見積り(Estimating)
! 計画づくり(Planning)
! アジャイルな(Agile)


見積り

見積り
! Estimating
! 見積もること
! × 見積(御見積書)
! プロセス = 「過程」

計画づくり

計画づくり
! Planning
! 計画を立てること
! × 計画(計画書)
! プロセス = 「過程」

見積りと計画づくりの
いずれもがプロセス、
すなわちそれを実
行することと、それを
実行する主体について
の話題である。

そしてプロセス、すな
わち実行することと、
その実行主体(つまり
人)は既に遍在し実践
され続けている。

つまりプロセスと
はソフトウェアをつ
くっている活動そのも
の、すなわちソフト
ウェアづくりである。

陰
陽

ビジネス
プロセス

第23章

Chapter23:
The Timeless way of
Programming

!"#$%&'()*+,-./0-12


チームが技術とビジネスの関
心事項の調和を日常的に取れ
るようにすることだ。
調和とバランスがXPの目的
である。

ケント・ベック『XPエクストリーム・プログラミング入門』第2版


ソフトウェアでは、新たな社
会構造を作る機会がある。



チーム間の権力と責任の適切
な共有は、非現実的に思える
かもしれない。



バランスには、相互尊重が不
可欠である。絶対的な権力は
存在しない。



複数レベルの計画づくり
戦略
ポートフォリオ
プロダクト
リリース
イテレーション

今日


ビジネスモデル突破の難しさ
! 人月 vs. 価値
! 内製 vs. 発注
! 準委任 vs. 一括請負
! 新規開発 vs. 再構築

計画の基準: フィーチャ(タスクではない)
" フィーチャ(Feature): ソフトウェアの機能、特性や特徴、
性能目標、見た目や使い勝手など、いわゆる「売り文句」
を総称するもの
" 要求仕様, 機能要件, 大機能, ユースケースとよく似ている
" ユーザに価値を提供するものがフィーチャ
" 性能要件やセキュリティといった非機能要件もフィーチャになりうる

" フィーチャの実装手段はさまざま
" ユーザーストーリー, ストーリーカード
" Issue Tracking Systemに登録されたチケット
" Excelの表
" ユースケース記述の変異したもの


ストーリーカード

http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template

ユーザーストーリの形式
! As a/an <type of user>,
! 販売管理部門の担当として、

! I Want To <some goal>
! 先月の締め日以降の今月の売上金額と数量を見たい

! So That <some reason>
! 経理部門にレポートを提出するために必要だから


http://capsctrl.que.jp/kdmsnr/diary/20100225.html#p01

http://agileproductdesign.com/blog/the_new_backlog.html

規模を見積り、
期間は導出する


規模を見積もり、期間は導出する

(『アジャイルな見積りと計画づくり』から引用)

Velocity

http://www.ﬂickr.com/photos/kaidohmaru/453263320/

Velocity
! 単位期間のあいだにプロ
ジェクトが進んだ速度
! 見積り単位は規模を表現
! ストーリーポイント
! 理想日

見積りの技法
" 見積りの単位
" ストーリーポイント vs. 理想日
" 相対サイズによる見積り
" 対比、三角測量、分割

" 見積りのスケール
" 1∼10倍の精度
" フィボナッチ数列(1, 2, 3, 5, 8) vs. 公比2の等比数列(1, 2, 4, 8)
" 10倍を超える場合は分割するか、13, 20, 40, 100 を使う
" テーマ, エピック, ユーザーストーリー

" チームで1つの見積り
" プランニングポーカー


プランニングポーカー

http://store.mountaingoatsoftware.com/ http://www.planningpoker.com/


http://www.pivotaltracker.com/

最初のベロシティの見積り
! 過去の実績値を使う
! 実際に1イテレーション
やってみる
! 予想する
! 想定できる作業時間から積みあげていく


リリースプランニング



イテレーションプランニング
" ベロシティ駆動イテレーションプランニング



イテレーションプランニング
" コミットメント駆動イテレーションプランニング



プロジェクトレベルでの
計画づくり

http://www.ﬂickr.com/photos/alastairhumphreys/3188288778/

プロジェクトのバッファ
" 2点見積りによるバッファ
" 平均ケース(50%見積り)
" 最悪ケース(90%見積り)
" 50%と90%の標準偏差の合計値の平方根(二乗和平方根法)

" 1点見積りによるバッファ
" 50%見積りの合計値
" 不確実性が適切に反映されないおそれ

" フィーチャバッファとスケジュールバッファ
" 期間全体に対して20%のバッファを用意できるか?


二乗和平方根法によるバッファ算出の例

" 17(50%見積りの合計 + 9 (最悪-平均)2.round
→ 26ポイント


プロジェクトのモニタリング
" バーンダウンチャート " バーンダウン棒グラフ
" リリースまでに残っている作業 " 残作業に加えて、スコープの変
の規模を計測する化もモニタリングする
" 完了見込みを一目瞭然にする " 要求の安定性を一目瞭然にする
" イテレーション単位で計測する " グラフの読み方やスコープ変化
(日次で計測することも可能) の扱いに習熟が必要



バーンダウンチャート

まとめ
! アジャイルはここではないどこかへ行
くための魔法ではない。いまの世界の破
壊者でもない。

! 自分たちの変化の速度に合わせてボトル
ネックを移動させていくしかない

! やらない理由はいくらでもある
! 外部の制約は言い訳にしやすい

ご清聴ありがとうございました

なにかご質問は?


Agile Estimating And Planning

More Related Content

Similar to Agile Estimating And Planning

More from Eiwa System Management, Inc.

Agile Estimating And Planning