アジャイルの進捗管理

従来のPMO支援はアジャイルにFITしていない。
そのため、アジャイルでプロジェクト管理するためのノウハウを記載

Transcript

1. アジャイル開発の進め方 佐藤匠太郎
2. -2- 自己紹介 名前：佐藤 匠太郎 年齢：33歳(いわゆるマー君世代) 家族：妻、子供(3月で2歳！) 住まい：東京都中野区 出身：神奈川県川崎市 趣味：野球 (スワローズファン) Other：グロービス経営大学院を2022年3月卒業予定 職歴： 楽天→通販会社→フリーランス→法人化 できること： PM・PMO、業務コンサル、要件定義・システム設計 etc 関わってきたサービスやシステム：？？
3. -3- アジャイル開発ソフトウェア開発宣言より 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 https://agilemanifesto.org/iso/ja/manifesto.htmlより
4. -4- アジャイル開発では一般的なPMOの仕事は好まれない。何かしら支援内容を工夫しなければいけない。 アジャイル開発ソフトウェア開発宣言より 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 従来のPMOの仕事・・・ https://agilemanifesto.org/iso/ja/manifesto.htmlより
5. 一般的に言われていること・・・ 不確実性への対応がしやすい 不確実性とは？ 英語ではUncertaintyを訳す(リスクではない)。「不完全な状態」のこと指します。 ※私の理解は不確実性は「先が見えない状態」と捉えています。 先が見えない状態で今ある情報やファクトを作りながら、進まなければいけない状態を不確実性が高い状 態だと考えます。 -5- アジャイル開発の特徴は？
6. • 1981年にバリー・ベームが発表した図でそ の後不確実性コーンと名付けられた。 • プロジェクトが進むに連れて見積もりは正確 になっていくという考え方。 • プロジェクトマネジメント協会(PMI)も同様 の見解を示している。 -6- 不確実性への対応は1980年代からプロジェクトマネジメントとして認識されていた。 不確実性コーン 書籍：アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法より 今はもう少し幅が大きそう
7. -7- アジャイル開発の見積について知ることで進捗管理の理解度を深めよう。 (アジャイル開発でも計画はやらなければいけません) アジャイル開発の進捗管理をやる前に知っておきたいこと スケジュールを管理するためにはスケジュール を作るまでの過程を分かっていた方が理解度 が高まる。 出典：https://products.sint.co.jp/obpm/blog/serial2
8. -8- アジャイル開発の見積もり https://www.amazon.co.jp/dp/4839924023
9. 本の中で計画作りの目的は以下の通りとしている。 • リスクを軽減する • 不確実性を減らす • 意思決定を支援する • 信頼を確立する • 情報を伝達する → 詳細は本に記載されています！ -9- ちなみに見積と計画を作る目的は？
10. • 機能ではなくストーリーで見積をする → 機能で見積をすると開発者視点での見積となってしまう。アジャイル開発ではユーザー視点で見積 を行うためにストーリーという単位で開発物を洗い出す。 -10- アジャイル開発の見積で大事なこと① 機能での見積 ストーリーでの見積 明細 工数 入力画面 XX人日 検索結果画面 XX人日 検索API XX人日 明細 工数 ユーザーが商品を検索 できる。 5pt ユーザーがタグ検索で きる 1pt 担当者がタグを設定で きる 8pt 感覚的にはユースケースを洗い出してくイ メージに近いです Tips:非機能要件をどこに含めるか？ アジャイル開発では非機能要件をストーリー内に含めることが多いです。例えば、検索機 能を作るときにレスポンスが遅いというのはユーザー視点に欠けます。そのため、当たり 前品質に関する非機能要件はストーリーに含めて見積をします。 ※分離しても意味がない。
11. -11- アジャイル開発の見積で大事なこと② 0% 工数+X% ≒完了時期も +〇〇日 工数-X% ≒完了時期も- 〇〇日 見立てと実績の乖離 率 見積時 作業開始時 作業中 作業完了時 時間 • 見積をコミットメントとしない。 → アジャイルでは「見積は見積もった時間内に完了する確率」と定義しています。 → 見積通りに終わる確率はXX%で、見積にコミットすることがゴールではないという考え方。 なので、開発の完了時期を3月-4月などと期 間で報告するようにしています。
12. 1. ストーリーの洗い出し 2. 規模の見積もり 3. 期間への変換 4. スケジュール -12- ソフトウェアプロジェクトの見積プロセス この資料では2-4について説明をします
13. • ストーリーごとにポイントを割り振る • ポイントは「相対」の考え方で割り振る • ポイントはフィボナッチ数列で割り振るのが一般的。 -13- 規模の見積
14. • ストーリーごとにptを割り振る。 • PTは「相対指標」でこの時点ではA>Bを表現する値にしか過ぎない。(工数やスケジュールへ落とし込 むのはまだしない) • ただし、このときに過去の実績からptを割り振れると後続の工数・スケジュールの見積の精度がすごい 上がる。 -14- 規模の見積 ストーリー 工数 ユーザーが商品を検索 できる。 5pt ユーザーがタグ検索で きる 1pt 担当者がタグを設定で きる 8pt まだ、この時点ではポイントの意味は大きくない。 AよりBの方が開発時間かかるよねくらいのイメージでもOK。 --------- 過去の開発実績があればそれをもとにptを割り振る形の方が良い。 (過去の開発実績と比較して相対評価する) →これを続けていくとpt見積の精度が上がっていく。
15. • フィボナッチ数とは「どの数字も前２つの数字を足した数字」 詳細：https://forest-clinic.jp/knowledge/etc/post-605.html • 見積もりの前提として、「複雑度が増すほど、開発工数は指数関数的に増す」という思想 • この前提を使って見積もりをするときに、いい感じに使えそうな数列がフィボナッチ数だった。 -15- なぜフィボナッチ数でポイント見積？ フィボナッチ数：１、１、２、３、５、８、１３、２１、３４、５５、８９、１４４、２３３、３７７… グラフにすると・・・↓↓ この数を使ってストーリーにポイントを割り振っていく
16. -16- 大きいストーリーポイントのストーリーは開発工数も大きければ、変動性も高いことが多い。 →このようなストーリーはストーリーを分割する。 →分割のタイミングは「分割できる材料が揃ったとき」でOK →ただ、分割を早めにしないと後続のスケジュールに影響が出るので早めに対応し、変動性を抑えたい。 ストーリーポイントが大きいストーリーの対応 ストーリーA：13pt ストーリー B：8pt ストーリー C：5pt
17. 分割の仕方はやりやすい・わかりやすい方法 かつ 「MECE(漏れなく、ダブリなく)」であればなんでもOK。 -17- ストーリーの分割例 例2.システムごとに分割 ユーザーが商品検 索できる 検索API 検索画面 例1.ストーリーごとに分割 ユーザーが商品検 索できる ユーザーが検索で きる ユーザーが検索結 果を参照できる 例3. 画面ごとに分割 ストーリーで分割するのが教科書的だが、システムごとに分割した方がわかりやすいことが多い。 ユーザーが商品検 索できる 入力画面 検索結果表示画 面
18. -18- 期間への変換 本に直接的に書いてな い内容で佐藤がよくやる やり方です ①初回見積もり そのチームの過去のpt消化実績より算 出する。 • 過去、開発チームは実績1spritで 20pt消化する → 100/20=5sprint後に開発が終わる。 ②初動実績見 積 数sprint実行した結果、1sprint = 10ptの 消化だった。(初動の結果確認) → 現在の前提で進める完了見込みは 10sprint後となる → この事実からQCDのトレードオフを 検討する。 例：見積もった結果、100ptの見積となった。1sprintは1 週間とする。 新チーム、新システムの開発の場合初回見積の精度は 結構低いので②の見積を重視することになります。 0% 見積時 作業開 始時 作業中 作業完 了時 ①初回見積もり ②初動実績見 積
19. -19- 隠れた前提がいくつか・・・ 本に直接的に書いてな い内容で佐藤がよくやる やり方です ①初回見積もり そのチームの過去のpt消化実績より算 出する。 • 過去、開発チームは実績1spritで 20pt消化する → 100/20=5sprint後に開発が終わる。 ②初動実績見 積 数sprint実行した結果、1sprint = 10ptの 消化だった。(初動の結果確認) → 現在の前提で進める完了見込みは 10sprint後となる → この事実からQCDのトレードオフを 検討する。 例：見積もった結果、100ptの見積となった。1sprintは1 週間とする。 Sprint毎の消化ポイントは「人」ベースではなく「チーム」で算 出。つまり、2人→4人になったとしても生産量は2倍にならな い！ この結果は全員必ず受け入れる必要がある。 ・①初回見積と②初動実績見積の乖離は発生する ・信頼度が高いのは②初動実績見積 ということを受け入れて、起動修正する。
20. 「この機能改修して」と依頼があったとき、3日で出来ますと回答するときの例 -20- 現場のエンジニアに見積もりをお願いするときは「理想」で会話をすることをルールとすると会話がスムーズ。 「理想」から「現実」に変換するのはあとでやる。 【tips】顧客から「何日でできますか？」と聞かれた時にはどうすればいいか？ 24h 理想 18h 現実 2h 4h 開発に 使える時間 開発に 使える時間 他の調査 日報 現場との会話は理想で会話 この変換作業と各部署への伝達はPMOの仕事 ポイントして捉えるのが良いかもしれない。
21. -21- 見積結果を元にスケジュール計画を立てます。 といっても、ここまでやれば管理ツールに各値入れたら、バーンダウンでの進捗管理ができるようになります。 スケジュールに落とす JIRA Pivotal tracker Backlog
22. -22- まず、進捗管理の基本をおさらい。 実際に進捗管理してみよう タスク量 期限 見積 現在 計画線 差分をウォッチ 実績線 時間 見積もり
23. -23- アジャイル開発では見積は可変として捉えます。(なぜなら、不確実性への対応のため) JIRAのバーンダウンをよくみると・・・ タスク量増えてる！ ※勘違いしないための補足。 アジャイルだからといって、計画時にタスクの全量洗 い出しや見積を「やらない」というのは間違いです。 今ある情報、ファクトを元にその時点でベストな全量 洗い出しや見積はやります。 その結果、見積の精度の甘いストーリーなどが出てく るがそれは後で再見積するなどの対応をし、プロジェ クトの進行と共に不確実性を下げていく。
24. -24- アジャイル開発における進捗管理は「Sprintあたりのタスク消化量(傾き)」と「見積タスク」の ２つの変数を追いかける必要がある。 アジャイル開発における進捗管理のポイント その１ タスク量 期限 初回 見積 現在 計画線 差分をウォッチ 実績線 時間 仕様 追加 仕様 追加 0% 見積時 作業開 始時 作業中 作業完 了時 直近の実績を元 にした見積の精度 が高い
25. -25- 進捗管理のグラフを構成する要素は 「ストーリーポイント(タスク量)、スプリント(時間)、ベロシティ(単位あたり作業予定量)」の３つ。 進捗管理のグラフをアジャイルの単語に置き換えると？ 総ストーリー ポイント 初回 見積 ベロシティ (1sprintあたりの 予定消化pt) 実績線 時間 仕様 追加 仕様 追加 Sprint1 Sprint2 総ストーリー ポイント ベロシティ スプリント 各ストーリーにつけたスプリン トポイントの合計値 工程の反復単位(通例は1週間 or 2週間) ベロシティとはスクラムチーム がスプリント中に完了する平均 作業量をストーリーポイント(時 間で見積をした場合には時間単 位で算出でも可)
26. -26- 簡単に言えば、前ページのグラフをひっくり返したものです バーンダウンチャートとは何なのか？ 総ストーリー ポイント 初回 見積 ベロシティ (1sprintあたりの 予定消化pt) 実績線 時間 仕様 追加 仕様 追加 Sprint1 Sprint2 出典： https://ja.confluence.atlassian.com/jirasoftwareserver087/burnup- chart-998873619.html ちなみにバーンアップチ ャートで管理する場合 もあります
27. -27- 開発開始直後に開発チームのスプリント毎の消化pt測定。 これまでの実績を受け入れた上で、その後の実績線とタスクの変化量がどのように推移するか推定する。 →不確実性を抑えた計画のupdateが可能になる。 アジャイル開発における進捗管理のポイント その2 タスク量 期限 初回 見積 2-3Sprintくらい 計画線 時間 仕様 追加 今後どうなる？ 0 % 見積 時 作業 開始 時 作業 中 作業 完了 時 直近の実績を元 にした見積の精度 が高い 重要なファクト 今後どうなる？
28. • アジャイル開発では不確実性への対応が重要視されている。当然、アジャイルの計画も不確実性が考 慮されたものになる。 • 「計画」＜「実績」 • アジャイルの進捗管理で使うパラメータは「総ストーリーポイント」「スプリント」「ベロシティ」 • アジャイルで進捗管理する指標は「総ストーリーポイントの変移」と「Sprintあたりのタスクの消化量 (傾き)」 -28- ここまでのまとめ
29. -29- 応用編
30. -30- バーンダウンクイズ！！
31. -31- ツールで進捗は簡単に出せる時代。 出力されたレポートから何が言えるかを考えられるとPM(PMO)としての実力が上がる。 応用編の目的 期限 初回 見積 2-3Sprintくらい 時間 仕様 追加 ？？ ？？ 1.ここから何が言え るのか？ 2.今後どうなること が予想できるか？
32. -32- ロジカルシンキングでは「why」と「So what」が重要。 So What思考ができると「そこから何が言えるか」などの抽象思考が身につく。 Why と So What 大谷翔平は 世界一の野球選手 投手として9勝を挙げた ホームランを46本打った 盗塁を26回成功した Why So What
33. -33- Why思考 大谷翔平は 世界一の野球選手 XXXX XXXX XXXX Why 大谷翔平は世界一の野球選手である。な ぜならば・・・
34. -34- Why思考 大谷翔平は世界一の野球選手である。な ぜならば・・・ ホームランを46本打ち、投手として9勝 挙げ、盗塁を26回したから 大谷翔平は 世界一の野球選手 投手として9勝を挙げた ホームランを46本打った 盗塁を26回成功した Why
35. -35- So What思考 大谷翔平はXXXXX 投手として9勝を挙げた ホームランを46本打った 盗塁を26回成功した So What So What思考 大谷翔平はホームランを46本打ち、投手 として9勝、盗塁を26回した。
36. -36- So What思考 大谷翔平は 世界一の野球選手 投手として9勝を挙げた ホームランを46本打った 盗塁を26回成功した So What So What思考 大谷翔平はホームランを46本打ち、投手 として9勝、盗塁を26回した。 ゆえに、大谷翔平は世界一の野球選手と 言える。
37. -37- 役職が上がるに連れて、求められる概念化の能力が求められる。 PMもこのコンセプチュアルスキルが求められている。 【tips】カッツの3能力 参照：https://liberal-arts- guide.com/katz-model/ チームリーダー PM/部長 役員
38. -38- 第1問
39. -39- 第1問 期限 初回 見積 2-3Sprintく らい 時間 進捗＆見積 • 3Sprint目までは当初計画したベロシティ通りにタスクを消化 • 初回見積から見積のupdateはしていない • 各ストーリーポイントの見積はチームリーダーが担当。 チーム • 報告者は新任のチームリーダー、PMとの信頼関係はまだなし • チームは今回の開発が初対面のメンバーばかり • 開発システムに精通しているメンバーは1人 • エンジニアのスキルは高い ルール • このプロジェクトのルールとして8pt以上の見積は良きタイミ ング分割することをルールとしている 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？
40. -40- 定性情報と定量データの整合性が取れていないときは要注意。 第1問で発生したこと＆学び① 期限 初回 見積 2-3Sprintく らい 時間 • ポイント消化を意識しすぎたため、課題の解決を後回し。結果、後続スプリントで消化できるタスクが減 ってしまい、開発をSTOP。 • 定性情報を見ると最初はうまく機能しない(つまり、計画したベロシティに届かない可能性が高い)に見え るが、なぜかオンスケの報告。なにかあるのでは・・・と疑えるかがポイント 進捗＆見積 • 3Sprint目までは当初計画したベロシティ通りにタスクを消化 • 初回見積から見積のupdateはしていない • 各ストーリーポイントの見積はチームリーダーが担当。 チーム • 報告者は新任のチームリーダー、PMとの信頼関係はまだなし • チームは今回の開発が初対面のメンバーばかり • 開発システムに精通しているメンバーは1人 • エンジニアのスキルは高い ルール • このプロジェクトのルールとして8pt以上の見積は良きタイミ ング分割することをルールとしている 最初うまく機能し なさそう(仮説)
41. -41- 定量データだけを見て、何が言えるか考えても価値のある「So what」はあまり出てこない。 第1問で発生したこと＆学び② 期限 初回 見積 2-3Sprintく らい 時間 オンスケです！ としか言えない
42. -42- 定性情報からどんな実績線を描いていくかイメージを持つと不整合に気づきやすい。 第1問で発生したこと＆学び③ 進捗 • 3Sprint目までは当初計画したベロシティ通りにタスク を消化(オンスケ) • 初回見積から見積のupdateはしていない • 各ストーリーポイントの見積はチームリーダーが担当。 チーム • 報告者は新任のチームリーダー、PMとの信頼関係は まだなし • チームは今回の開発が初対面のメンバーばかり • 開発システムに精通しているメンバーは1人 ルール • このプロジェクトのルールとして8pt以上の見積は良 きタイミング分割することをルールとしている 期限 初回 見積 2-3Sprintく らい 時間 リリース前になったら 作業慣れして生産性 あがるかな、いや無理 かも・・・ 最初うまく機能しなさ そうだな(仮説)
43. -43- 第2問
44. -44- 第2問 期限 初回 見積 1Sprintくら い 時間 進捗＆見積 • ベロシティは1sprintあたり25pt。 • 1stスプリントの消化ptはたった5pt。 • 初回見積から見積のupdateはしていない • 各見積は3pt×5ストーリー、5pt×5ストーリー、8pt×5 ストーリー(合計80pt) • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 報告 • チームリーダーは信頼がおけるメンバーで、メンバー いわく「開発はうまくいっている」という報告。 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？
45. -45- なぜ、このようなことが発生したのか？ 第2問・結果どうなった？ 期限 初回 見積 1Sprintくら い 時間 進捗＆見積 • ベロシティは1sprintあたり25pt。 • 1stスプリントの消化ptはたった8pt。 • 初回見積から見積のupdateはしていない • 各見積は3pt×5ストーリー、5pt×5ストーリー、8pt×5 ストーリー(合計80pt) • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 報告 • チームリーダーは信頼がおけるメンバーで、メンバー いわく「開発はうまくいっている」という報告。 進捗はすぐにオンスケに戻り、 期限より若干早く作業が終 了。
46. -46- 実態として、1sprintの箱の中で計画通りベロシティを消化するのは難しい。 第2問 なぜこうなった？ Aさん Bさん Cさん Dさん Eさん • ベロシティは1sprintあたり25pt。 • 1stスプリントの消化ptはたった8pt。 • 初回見積から見積のupdateはしてい ない • 各見積は3pt×5ストーリー、5pt×5ス トーリー、8pt×5ストーリー(合計80pt) ストーリー①：3pt ストーリー②： 8pt ストーリー③： 8pt Sprint1 Sprint2 ストーリー④： 5pt ストーリー④： コードレビュー ストーリー④： レビュー対応 ストーリー⑤： 5pt ポイント 消化 ポイント 消化 ポイント 消化 ポイント 消化 Sprint内でタスクを終えるのが 原則だが、実態こうなってい た。。。 開発以外の作業のリードタイム も存在 25pt÷5 1人あたり5pt消化 ストーリー⑥：3pt ポイント 消化 ポイント 消化 他にも同様の事例として • 仕掛り中だったが作業がSTOP。別 の作業を進めた。 • 開発容易性の観点から2つのストーリ ーを同時開発した etc
47. -47- スプリントの箱の中にきれいにストーリーを収めるのは難しい → この課題に対しての最適解は今のことろわからないです。。。 第2問 課題への対応 すなわち、ストーリーが複数ス プリントにまたがることを許容 • Sprintの期間を長くする(書籍内では2週間以上 を推奨。1週間は辛い) • 複数Sprintにまたがる作業(=2週間以上かかる 作業)はストーリー分割する (2週間以上かかる作業を現場の担当者に丸投げ することがリスクでもある) • レビューの時間が長くなることでポイント消化が遅れ ることは許容せざるを得ない • 不確実性として許容する(Sprintが進むにつれて、 Sprint毎の消化ptは安定してくる) • (やったことないけど)Sprint毎の消化ポイントの移 動平均(感覚的には過去2-3Sprintの平均)を管 理する。 原則に合わせるとしたら・・・ 実態に合わせるとしたら。。。 前提：アジャイル開発ではスプリント内でタスクを終えることが原則 必要以上に作業分割すると生産 性が下がるので要注意
48. -48- 第3問
49. -49- 第3問 期限 初回 見積 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 1stスプリントの消化ptはたった5pt。 • 3rdスプリント以降はベロシティ持ち直し20pt。 • 初回見積から見積のupdateはしていない • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 現場からの報告 • ベロシティは20ptに持ち直したのでオンスケです。 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？ まず、グラフは見ずに考えてみましょう。
50. -50- 第3問 期限 初回 見積 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 1stスプリントの消化ptはたった5pt。 • 3rdスプリント以降はベロシティ持ち直し20pt。 • 初回見積から見積のupdateはしていない • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 現場からの報告 • ベロシティは20ptに持ち直したのでオンスケです。 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？ 3rdSprint
51. -51- 第3問 期限 初回 見積 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 1stスプリントの消化ptはたった5pt。 • 3rdスプリント以降はベロシティ持ち直し20pt。 • 初回見積から見積のupdateはしていない • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 現場からの報告 • ベロシティは20ptに持ち直したのでオンスケです。 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？ 3rdSprint 遅延状態でベロシティを元に 戻しても、遅延の状態は解 消されてない
52. -52- ベロシティだけ見ても、遅れているのかオンスケかどうかは判断できない。 第3問・ラーニングポイント 期限 初回 見積 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 1stスプリントの消化ptはたった5pt。 • 3rdスプリント以降はベロシティ持ち直し20pt。 • 初回見積から見積のupdateはしていない • 見積もりをしたメンバーは開発するシステムの知見が あるメンバー。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バー。開発するシステムの知見も持っている。 現場からの報告 • ベロシティは20ptに持ち直したのでオンスケです。 遅延状態でベロシティを元に 戻しても、遅延の状態は解 消されてない なぜ、こんな当たり前のことを？ チームの短期目標が「ベロシティ」に なると計画と実績の乖離が見えなく なってくる
53. -53- 第4問
54. -54- 第4問 期限 初回 見積 3Sprint 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 初回スプリントでは10pt消化たっだが、回復。 • 初回見積は過去の開発実績から算出。 • 見積は毎スプリント毎に実施しているが見積は増え続 けている。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バーで既存システムを開発している • 構築するシステムは新規構築のシステム 報告 • チームリーダーは「このままでは開発が終わらなそ う」と報告 1.ここから何が言えるのか？ 2.今後どうなることが予想できるか？ 2回目 見積 3回目 見積
55. -55- 見積はどんどん増えていきそうなことは明らか。 【追加設問】チームリーダーに１つ質問できるとしたら何を質問しますか？ 第4問・発生したこと 期限 初回 見積 3Sprint 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 初回スプリントでは10pt消化たっだが、回復。 • 初回見積は過去の開発実績から算出。 • 見積は毎スプリント毎に実施しているが見積は増え続 けている。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バーで既存システムを開発している • 構築するシステムは新規構築のシステム 報告 • チームリーダーは「このままでは開発が終わらなそ う」と報告 2回目 見積 3回目 見積
56. -56- どんなことが考えられるかロジックを作り、質問を考えよう 開発が終わらなそ う 開発スピード 問題なさそう 見積の問題？ 追加のタスクが発 生しているのか？ 営業サイドからの要 望 開発チームでの追 加タスク 今あるタスクの見積 が甘かったのか？ 見積の手法は？ XXX 質問例① 追加のタスクが発生しているの か？今あるタスクの見積が甘く、 追加タスクのストーリーポイント が大きく、Totalの見積が飛躍 的に増えているのか？ 質問例② 営業サイドからの要望が多いの か、開発側で追加タスクが多く 発生しているのか？
57. -57- 見積のやり方・進め方を知っておくことで見積の信頼度(不確実性)を抑えておくことも重要です。 第4問・ラーニングポイント① 期限 初回 見積 3Sprint 時間 進捗＆見積 • ベロシティは1sprintあたり20pt。 • 初回スプリントでは10pt消化たっだが、回復。 • 初回見積は過去の開発実績から算出。 • 見積は毎スプリント毎に実施しているが見積は増え続 けている。 チーム • チームのメンバーはエンジニアリーダー(1人)+エンジ ニア(4人) (つまり合計5人) • チームのメンバーは2年ほど一緒に仕事しているメン バーで既存システムを開発している • 構築するシステムは新規構築のシステム 報告 • チームリーダーは「このままでは開発が終わらなそ う」と報告 2回目 見積 3回目 見積 新規構築するシステムに 対して、過去の実績を元 にした見積の精度は低い のでは・・・？？
58. -58- 素早く、早く問題の原因にたどり着ければ打ち手の精度上がり、 対応に与えられた時間を長く確保することができる。 第4問・ラーニングポイント② 開発が終わらなそ う 開発スピード 問題なさそう 見積の問題？ 追加のタスクが発 生しているのか？ 営業サイドからの要 望 開発チームでの追 加タスク 今あるタスクの見積 が甘かったのか？ 見積の手法は？ 見積の精度が低か った 本ケースの場合はこちらが 原因。ここに早く、確実に たどりつきたい
59. -59- イシューからはじめよはおすすめです。
60. -60- 【参考】よくある見積変移(100点ではないけど、合格点(?)のプロジェクト) 時間(Sprint) Total作業見積 初回見積 開発中の見積 フェーズや開発内容によるが、、、 大体20%の乖離収まれば good(実際、工数バッファ20% 取ることが多い) 工程が半分くらい進むと 見積は収束してくる 初期段階で見積が早い スピードで膨らんでいく
61. -61- 【参考】よくある見積変移(悪いプロジェクト≒炎上するプロジェクト) 時間(Sprint) Total作業見積 初回見積 見積が増えない 締め切り前になってどんど んタスクが増えていく