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

Transcript

1. アジャイルな 見積もりと計画づくり 入門
2. 結論 これ読んで
3. こんなことで困ってない? 開発者 • 見積もりがいつの間にかコミットになっていてプレッシャーで夜も眠れない 😵💤 • 順調にだったはずなのに気づいたら間に合いそうにない！胃がキリキリする 🤮 • 周りから信頼されていない感じがしてきた...マネージャーがやたら細かく具体的に確認する ようになってきた 👁 ステークホルダー • 開発者は口では順調だといっているが進捗が見えずに不安... 😰 • 間に合わない！という話が急に出てきた！！もっと早く言ってくれればこんな 謝罪行脚しなくて済んだのに 🏃💢
4. アジャイルな見積もりと計画づくり要点サマリ - 相対見積もりをする - PBI はユーザ価値単位で小さくする - 実績をもとに見通しをたてる
5. 相対見積もりをする 絶対値（この PBI は ** 日、 ** ヶ月で終わる） ではなく 相対値（この PBI はあのPBIより小さい or 大きい） でPBIのサイズを見積もる
6. 相対見積もりをする｜例 ストーリーポイント 1 2 3 5 👕 👕 Tシャツ S M L
7. なぜ相対見積もり？ 人間は絶対見積もりが絶対的に苦手 2匹のキリンの身長が何mか見積もるのは難しいが 親キリンが子キリンの何倍かはパッと見でわかる 相対見積もりなら低コストかつ高精度に見積もれる
8. なぜ相対見積もり？ 絶対見積もりだと開発者は防御的になる - 仮の見積もりとして出した予想日も死ぬ気で守りきると確約した期日も、 同じ数字である以上人間の脳みそには区別つかない - 仮に “ざっくり” 見積もりでも数字はそのうちコミットメントになる - “ざっくり” であることは外縁のステークホルダーには伝わらず、遅れを攻める輩が出てくる - 見積もりに精度を求め始める 限界効用逓減の向こう側にいっても安心のためにコストをかけてしまう → - 暗黙的に見積もりにバッファを積み始める バッファのバッファのバッファなんてのも.... - ステークホルダーと開発者の間に不信感が育っていく ... the 終わりの始まり 精度 コスト ざっくりでい いから（笑） この言葉に警戒しないやつは エンジニアとして赤ちゃんみたいなもん
9. PBI をユーザ価値単位で小さくする ユーザーがサイトに アカウントを登録し、 プロフィールを作成し、 他のユーザーとチャットで きる。 1. （ユーザー登録）ユーザーはメールアドレスとパスワードを使用してアカウント を作成できる。 2. （ユーザー登録）ユーザーは登録後、確認メールを受け取ってアカウントを有 効化できる。 3. （プロフィール作成）ユーザーは名前、プロフィール写真、および自己紹介文を 追加してプロフィールを作成できる。 4. （プロフィール作成）ユーザーはプロフィール情報を編集できる。 5. （チャット機能）ユーザーは他のユーザーを検索してプロフィールを閲覧でき る。 6. （チャット機能）ユーザーは他のユーザーにメッセージを送信できる。 7. （チャット機能）ユーザーは受信したメッセージに返信できる。
10. なぜ PBI を小さくする？ 人間は小さいものは簡単に見積もれるが大きいものを見積もるのは難しい 遠い方は近い方の 何倍離れている？ 遠い方は近い方の 何倍離れている？ 正解：約389倍 正解：約2倍
11. なぜ PBI を小さくする？ 遅延リスクはタスクサイズの比例ではない 人たちが直感で想像する直線的な遅延リスク 10% × 経過日数 実際の遅延リスク 10% ^ 経過日数 プロジェクトが遅延するリスク 10% / 日 として
12. なぜ PBI を小さくする？ 品質が上がる サイズが大きいと全てが高リスク・高コストになる • レビュー・テスト観点で抜け漏れるリスクが増える • 影響が大きいバグが発生する • バグ原因を探す場所が広くなるので修正までのリード タイム長くなる サイズが小さいと全てが低リスク・低コストになる • レビュー・テスト観点で抜け漏れるリスクが減る • 影響が小さいうちにバグを発見できる • バグ原因を探す場所が狭くなるので修正までのリード タイム短くなる A B C D A 👁 👁 👁 👁 B 👁 👁 👁 👁 C 👁 👁 👁 👁 D 👁 👁 👁 👁 A B C D A 👁 👁 B 👁 👁 C D 同時に扱う機能が 2倍になれば テスト観点は2乗になる
13. ステップ・レイヤーで分割 60%できました！ でも本当は？ - 結合できるかわからない - バグがあるかわからない - 本番環境で動くかわからない - デクレがあるかわからない - 仕様がイメージどおりかわからない 本当の進捗がわかる なぜユーザー価値単位？ ユーザー価値で分割 60%できました！ ユーザー価値単位で完了していれば - 結合できること確認済み - バグがないこと確認済み - 本番環境で動くこと確認済み - デクレがないこと確認済み - 仕様がイメージどおりか確認できる 仕様検討 デザイン バックエンド フロントエンド テスト 仕様検討 デザイン バックエンド フロントエンド テスト 60% 60%
14. ステップ・レイヤーで分割 外部から見ると - 目に見えないから不安 - イメージと合ってるか不安 - リリース後のクソデカインシデントが不安 開発者じゃなくても進捗が信頼できる なぜユーザー価値単位？ ユーザー価値で分割 外部から見ると - 動いているところを目で見れる - 触ってイメージと合ってるか確認できる - 本番環境で問題なく動いていることをスモールステッ プで確認できる 仕様検討 デザイン バックエンド フロントエンド テスト 仕様検討 デザイン バックエンド フロントエンド テスト 60%でき ました！ ??? 60%でき ました！ 👍👍👍
15. ステップ・レイヤーで分割 期限までに全部終わらない！ • どの機能まで頑張る？ • 仕様どうするの？デザインは？それで成り立つ？？ • インフラの設計はどうする？ DBは？バックエンド？フ ロントエンドは？ • 品質保証は何をいつまでに誰が確認する？ 実進捗に合わせた計画変更が容易 なぜユーザー価値単位？ ユーザー価値で分割 期限までに全部終わらない！ • 期限内につめこみたい機能を優先度順に入れ替えま しょ 仕様検討 デザイン バックエンド フロントエンド テスト 仕様検討 デザイン バックエンド フロントエンド テスト
16. 実績をもとに見通しをたてる 2ポイント 1ポイント 1ポイント 1ポイント 1ポイント 3ポイント 今回俺達は 4ポイント 消化できた 俺達は 4ポイント 消化できる 能力が 有りそうだ 2ポイント 1ポイント 1ポイント 1ポイント 1ポイント 3ポイント 今回俺達は 4ポイント 消化できた 次も ここまでは できるだろう 2ポイント 1ポイント 1ポイント 1ポイント 1ポイント 3ポイント 今回俺達は 4ポイント 消化できた 次も ここまでは できるだろう ここまでに この機能 リリースしたいわー 一定期間内に完了した PBIから 消化スピードがわかる → ベロシティ 消化スピードから 一定期間×任意の回数繰り返した時点 でどこまで終わりそうかわかる 任意のタイミングで終わらせたい順に PBIを並び替えて調整できる
17. なぜ実績をもとにする、のか？ ソフトウェア開発は本質的に複雑である 目的地（欲しい機能）はわかっても、 そこまでの道の状態（コンクリ？あぜ道？山道？）も 移動手段（徒歩？自転車？スケボー？）も事前にはわからない 自分たちが目標に向かってどんな道をどのように進んでいるのかを やりながら学ぶ必要がある
18. なぜ実績をもとにする、のか？ 相対見積もり & ベロシティの組み合わせは、タスクのサイズと消化速度を分けて 考える タスクのサイズは不変だが速度は組織やチームや人のスキルや状態によって変 わる 相対見積もり & ベロシティの組み合わせなら、自分たちの実態に合わせて計画 を調整できる
19. アジャイルな見積もりと計画づくり要点おさらい - 相対見積もりをする - PBI はユーザ価値単位で小さくする - 実績をもとに見通しをたてる
20. なぜうまくいくのかおさらい - 相対見積もりをする - 人間の脳みそは相対的に見積もるのが得意 - 絶対値は防御的反応を引き出す - PBI はユーザ価値単位で小さくする - 遅延リスクが減らせる - 品質が上がる - 本当の進捗が開発者にもステークホルダーにもわかる - 柔軟なプロジェクトマネジメントができる - 実績をもとに見通しをたてる - 想像ベースではなく実績ベースなので信頼できる - タスクサイズと速度が分かれているので、不変条件と変動条件が明確で調整観点がシンプルになる
21. 「地図が地形と一致しない場合、常に地形の方が正しい」
22. 付録｜PBI分割の切り口 - データ境界に沿って分割する - 操作の境界で分割する - 横断的な関心事を分離する - パフォーマンス制約を分割する - 優先度に沿って分割する