見積もりをがんばらない - forest book

スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この

[shields-pikes]

システム開発の工数見積もり作成を自動化するプロンプトをChatGPTで作ってる。まだ、叩き台にしかならないけど、ブラッシュアップしていけば精度を上げられるし、ほぼ自動化できそう。集中できる時間が足りない……。

[qaliinfo20]

最初にいいかげんに見積った結果を補正せず、つぎつぎに仕様漏れが見つかり、エンジニアに押し付ける組織でなければいいと思うが‥

[nerikara4chimi]

“TL/DR (要約)”本筋と関係ないのだがこのように書くなら最初から「要約」って書けばよくない？と思ってしまった

[softstone]

見積もりのブレは見積もった人の性格に大きく依存しているので誰がどう見積もってどれだけ外れたかのデータ蓄積から機械的に補正できると、JoelOnSoftwareかFogBugzのドキュかで読んで感心した覚えがある。１０年以上前。

[youichirou]

客に出す金額見積もりとプロジェクト進行の作業見積もりをいっしょくたに「見積もり」と書くとややこしい。

[toro-chan]

なぜ見積もりをするかといえば、実際にはビジネス上の約束をするためでは。技術的にって言われるけど、あまり信じてない。要件が増えたり、細かいことは常に増える。

[nemoba]

この記事って、タイムボックス重視のイテレティブな開発か、スプリント内でも成果を重視する開発か、って話なだけで、見積もりの話は普通の話だけに見えるが。なぜか見積もりのコメントが多くてビビる

[tockri]

Backlogのバーンダウンチャートをアジャイルで活用できるように、Chrome拡張を作って使い方も解説してるのでよければどうぞ。 https://zenn.dev/tockri/books/0f58fd333704e0/viewer/planning

[n_vermillion]

ソフト系の見積りはどうしても水物…。精度が高くなるものがあれが良いが、最終的には単価×時間が最強になってしまう…。

[ed_v3]

なぜ1年半前の記事が今頃…

[yarumato]

“熟達者は不確実性の高いものから取り掛かる→全体像が見えるのが早い→精度の高い見積もりに補正。　経験が少ない人は後半に不確実性の高いものに取り掛かるため、後半に見積もりのズレ幅が大きくなる”

[fujii_yuji]

補正を繰り返しやっていくと間違っても良くなるし、間違いも減るって話でいいんだと思うんだけど、なかなかそれが難しい状況も多いよねと。

[iichikoikoi]

“経験が少ない人はわかる範囲から作業を進め、後半になってから不確実性の高いものに取り掛かるため、作業の後半になっても見積もりのズレ幅が大きくなってしまう場合があります。”これ強制するマネージャー多い。

[tkysktmt]

“まとめると言いたいことはこうです。 見積もりは外れるので常に補正していく ”