estimation - 経験がない場合のプログラミングタスクの見積もり方法

Question

経験のないサードパーティ製のコントロールを使用しているプログラミングタスクについて、経営陣が見積もりを求めるのに苦労しています。

彼らが見積もりを欲しがる理由は確かに理解できますが、私が提供する見積もりは、a) 短すぎて見栄えが悪くなってしまうか、b) 長すぎて見栄えが悪くなってしまうのではないかと感じています。

仕事を続けることができるように、経営陣に彼らを追い払うために、どのような見積もりまたは返信ができるでしょうか。

score 93 · Accepted Answer

あなたが与えることができる最善の答えは、より正確な見積もりを与えることができるように、簡単なプロトタイプを作成する時間を求めることです. ツールや問題に関する経験がなければ、どんな見積もりも本質的に意味がありません。

余談ですが、見積もりが長すぎることで問題が発生することはほとんどありません。予期しない問題が発生し、優先度が変更され、要件が「更新」されます。要求したすべての時間を使用しない場合でも、テスト時間が増えるか、「早期」にリリースできます。

私はいつも楽観的すぎる見積もりをしてきましたが、それはあなたの人生に多くのストレスを与える可能性があります。上司に不快な真実を伝える経験や自信がない若いプログラマーの場合は特にそうです。

score 40 · Accepted Answer

秘密を教えてあげる。あなたがその技術の専門家であったとしても、あなたの見積もりは非常に不正確である可能性があります. 本質的に R&D タスクである何かを行うとき、それは野獣の性質です。残念なことに、経営陣はしばしば製造モデルを適用しようとし、正確な見積もりを要求します。私の主張を説明するために、次の 2 つの努力を正確に見積もることの難しさを考えてみてください。

A) 先月大量生産した 2K とまったく同じ 11K の傘をもう 1 つ製造します。B) 新しい種類の傘を設計し、最初の傘を作ります。

ソフトウェア開発はBですが、Aを想定して見積もりを求めています。

あなたができる最善の方法は、タスクを可能な限り最小の部分に分割し (それぞれ 1/2 日以内)、最終的に得られた数を 3 倍にすることです (スポルスキー法)。

また、Steve McConnell は、ソフトウェアエンジニアリングのこの側面に関する本を 1 冊 (おそらく数冊) 出版しています。 http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

score 32 · Accepted Answer

Steve McConnell (およびその他) が円錐形の不確実性について語っています。基本的に、次のような見積もりを提供します。

作業には 3 ～ 9 週間かかりますが、4 週間が最も可能性が高いです。

プロジェクトの進行に合わせて、見積もりを調整できます。より多くの作業を行い、必要な労力をよりよく理解するにつれて、見積もりをより正確にすることができます。

私にとってはうまくいきましたが、プロジェクトの他の利害関係者にプロセスを理解してもらうには、ある程度の努力が必要になる場合があります。

score 13 · Accepted Answer

見積もりと信頼水準の両方を提示することを検討することをお勧めします。つまり、50/50 で 3 ～ 6 か月または 6 ～ 9 か月かかるか、9 か月で完了する確率が 75% で、完了する確率が 90% です。年に行われた。

考慮すべきもう 1 つのことは、「群集の知恵」アプローチを使用することです。25 人から 50 人に、どれくらいの時間がかかると思うかを尋ね、見積もりの平均をとります。Mike Cohn のPlanning Pokerはこれと非常によく似ていると思いますが、1 人の開発者だけで計画を立てるのは困難です。

score 12 · Accepted Answer

見積もりを次のように分類します。

既知の既知の; あなたがする方法を知っていることをするのにどれくらいの時間がかかりますか。この見積もりは、高い信頼度で提供できるはずです。
既知の未知数; やり方がわからないことをするのにどれくらいの時間がかかると思いますか。dacracot のような方法を使用して、この推定値にさまざまなレベルの信頼性を与えることができます。
未知の未知; これがリアルタイムのブラックホールです。これらは、最も不機嫌なときに立ち上がって、あなたのお尻を噛むものです. 予想されるリスクに基づいた正当な理由を付けて、見積もりの範囲を指定します。

途中で見積もりと特定のマイルストーンを調整することを申し出ます。未知の未知は既知の未知になり、経験を積むにつれて既知の未知は既知の既知になり、既知の既知の推定値は現在までの進捗状況に基づいて調整できます。最初の見積もりを行い、約 25% 完了したら再見積もりを行い、次に 50% で再度見積もり、次に 85% で再度見積もりを行うことができます。各マイルストーンで、見積もりはタスクにかかる実際の時間に収束し始めるはずです。

score 8 · Accepted Answer

私は見積もりに明確なラベリングシステムを使用しています... クラス A、クラス B、およびクラス C。

クラス C の見積もりは、彼らが最初に取得するものです。未知数のため、プラスまたはマイナス 50% として公然と述べられています。彼らが私にクラスBを与え続けることを望んでいるなら、研究するためのお金が必要です.

クラス B はプラスマイナス 25% です。時にはこれで十分で、彼らは私に構築するためのお金をくれます。そうでない場合は、お金を減らして研究を増やしてください。

クラス A はプラスマイナス 10% で、最終的には行くか行かないかです。それがうまくいかず、見積もりから大きく外れている場合は、頻繁に、そして早く告白します。

score 8 · Accepted Answer

「これまでに経験のないサードパーティのコントロールを利用している」というフレーズを削除すると、より大きな問題をよりよく説明できると思います.

「アジャイル」が私たちに何かを教えてくれたとすれば、それは、経営陣が継続的にプロジェクトをそのように見積もることを期待している場合です。十分な情報があれば、あなたは FAIL への道を進んでいます。

最大の問題は、自分では制御できない問題であり、まだ特定していない問題です。どれくらいの頻度で振り返って、自分自身にこう言いましたか。 1 週間の休暇と、プロジェクトマネージャーが私を 1 週間必要とすること、妻が妊娠していること、そして ...」.

「重大なリスク要因を特定し、成果物のチェックリストを作成して xx 日でテストすることができます。その時点で、別の増分見積もりを提供します。」

そして、「将来、そのようなタイプの信頼できる見積もりを提供しようとしないことを主張してください。私がしようとしたら、私を解雇します.」

（誇張されていますが、ほんのわずかです。）

score 7 · Accepted Answer

見積もりもしないでください。あなたの見積もりが正しいとは限りません。あくまでも目安です。

代わりに、機能を小さな部分 (たとえば 1 ～ 2 日以内) に分割し、これらの部分を機能する完全でテスト可能な価値のあるコードとして顧客/マネージャーに提供することをお勧めします。そうすれば、彼はあなたの日々の進歩を自分の目で確かめることができます。これはまた、開発がすべての目標に達していなくても、いったん満足したら開発を中止し、それが完了したと見なすことを実際に決定できることを意味します。

このアプローチの詳細については、アジャイルプラクティスの「リリース計画」と「イテレーション計画」を参照してください。

score 6 · Accepted Answer

より長い時間の見積もりを要求したが、時間内にそれを達成した場合は、見積もりを下回って延長を要求するよりもはるかに優れているように見えることに注意してください.

プロトタイプをモックして、所要時間をよりよく把握できるようにします。経営陣に正直になり、学習曲線の予期しない遅延に備えて予算を組むことができます。

編集:より「反復的な」締め切りを取得できるかどうかも確認できます。"Pragmatic Thinking and Learning" の中で、Andy Hunt は、人々はプロジェクトの終わりに近づくとプロジェクトの専門家になり、最初の段階では知識がほとんどないことを強調しています。誰もがプロジェクトについて最も知識がない最初の段階で、すべての設計と時間の見積もりを行うことはあまり意味がありません。締め切りを「反復」し、問題をチャンクで解決すると、より多くの成功を収めることができます。

score 5 · Accepted Answer

正確な見積もりの多くは自己知識です。多くのコードを書いたことがあり、多くの API を学ばなければならなかった場合、次のような疑問を感じ始めます。

新しい API を習得するにはどのくらいの時間がかかりますか?
新しい言語を習得するのにどのくらいかかりますか?
新しいツールセット (コンパイラ/リンカー/IDE) を習得するにはどのくらいの時間がかかりますか?
典型的なタスクを実装するのにどれくらいの時間がかかりますか?
作品のテストにはどれくらいの時間がかかりますか?
作品を展開するのにどのくらいかかりますか?

その全体を通して、次のようなことを理解する必要があります。

作成した典型的なバグの数とその分類方法 (つまり、簡単、難しい、不可能)
いくつの複雑さが導入されるか (つまり、サードパーティの API やバグのある API がないためにリファクタリングが必要になる、機能の誤解のために再設計が必要になる、非標準のツールやビルドプロセスが必要になる)。
中断/外部の問題により失われた時間

これらすべてに基づいて、何かが完了するまでにどれくらいの時間がかかるかの感覚を養い、悲惨なほど不完全な情報に直面しても、自分の仮定 (「API が正常であると仮定して...」) を述べることができるようになります。

score 5 · Accepted Answer

より適切な見積もりを行うために十分な学習に必要な時間を見積もってください。たとえば、「わかりません。これまでにこれを扱ったことはありません。おそらく、何を解決するためにあなたの見積もりをここに挿入する必要があるでしょう。これを使用してプロジェクトを完了するための適切な見積もりを提供する前に、私が知っておく必要があることについて学ぶ必要があります。」

score 3 · Accepted Answer

プログラミングをするとき、私はいつも自分が本当に必要だと思っていたものを取り、それに 3 を掛けて見積もりを出しました。1 週間で仕事ができると思うなら、クライアントに 3 週間かかると言い、本当に 3 週間かかると思うなら、9 週間かかるとクライアントに伝えます。

これを行うことで、私は「約束どおり、期待以上の結果を出す」ように自分自身を設定しました。これをうまく行うことができれば、あなたの人生はより良くなり、クライアントは非常に満足するでしょう.

あなたの場合、見積もりを提供する前に、あなたが何に飛び込んでいるかについて少なくともある程度の理解を得たいと思うでしょう. 見積もりを提供するのにどれくらいの時間がかかるかについての見積もりを提供する必要があるかもしれません. 3 倍すると、クライアントは満足します。

score 3 · Accepted Answer

ある程度の経験があるものに分解してください。それを切り刻むという行為は、あなたが何を知っていて、何を知らないかについてより良い考えを与えてくれます。

断片が十分に小さくなり、単一の定義されたタスクと見なされるようになると、そのうちのいくつかは完全に見積もることができなくなります。それらについては、最初にプロトタイプを作成するか、ピースのサイズに応じて、ある程度の時間をかけてください. 2 ～ 4 週間の作業よりも大きな見積もり不可能な部分があることに気付いた場合は、最初にそれらを切り刻むことに戻ります。

最終的には、いくつかの非常に奇妙な技術的解決策 (うまくいくはずだと思うが、確かなことはわからない) にたどり着き、それがうまくいくと、それをバックアップするために多くの作業を行う必要があります。不足している設計がいくつかあるため、最初のバージョンではよく知られているライブラリまたは非常に単純なアルゴリズムを選択するのが最善です。

タスクを分割できない場合は、十分な経験を持ち、それができる人を雇う必要があります (経験不足は他の面でも悩まされるため)。誰かを雇うことができない場合は、無作為に長い期間 (6 か月から 2 年) 交渉して、乱雑なプロトタイプに直行する必要があります (何が正しいか、何が正しいかを知るのに十分な経験を自分に与えることができるまで)。違う）。しかし、失敗してしまった場合は、自分をからかって、正しい「方法」でやっていると考えることが重要です。試作品は捨てるものでした。プロトタイプのカウントダウンが完了したら、実際にビルドする準備ができていることを願っています。

ポール。

score 3 · Accepted Answer

外部の数字を推測してすぐに評価を開始し、将来の情報が見積もりに影響を与える可能性があることを知らせますが、最新の状態に保つことを忘れないでください。

評価するときは、ウェブ上に公開されたドキュメントまたは毎週の更新のいずれかを通じて、常に情報を提供してください。ただし、更新された「推定終了日」と、延長の理由 (ある場合) を常に含めてください。

ほとんどのマネージャーは、終了日を尋ねることで、実際には「スケジュールを計画する方法を教えてください」、「いつまでもかかるのではなく」と言っていることを理解する必要があります。

1 回か 2 回以上延長することになった場合は、見積もりが苦手な新しい知識に基づいて、スケジュール全体を再評価してください。

score 2 · Accepted Answer

私は自分の仕事で見積もりをかなり扱っていますが、それは本当の挑戦です。私の最大の課題の 1 つは、別の開発者がどの程度のスキルを持っているかを知らずに、別の開発者がタスクを完了するのにかかる時間を見積もることです。

「約束を破り、成果を上げない」方法で最初の成功を収めることができるかもしれませんが、時間の経過とともに、「約束を超えて成果を上げない」という考え方に従う他の人々に負けることに気付くでしょう。いずれにせよ、精度の欠如はあなたを噛むために戻ってきます。精度は経験と密接に結びついており、テクノロジーによって未知数を制限しています。

私が提案することの 1 つは、見積もりがどのような種類の予算に対して機能するかについて、ある程度のアイデアを得ることです。予算が少ない場合は、なじみのないテクノロジーに夢中になるのではなく、知っていることを続けてください。予算がもう少し柔軟であれば、少し実験する余裕があります。

また、ワイルドアスゲス (WAG) しか提供できないタスクがいくつかあることも認識しておいてください。これらについては、見積もりに最小時間を設定し、最大時間がわからないことを明確にする必要があります。多くの場合、この種の見積もりは、管理者が特定の機能/要件を除外するのに十分な理由です。

score 2 · Accepted Answer

RB が言ったことに付け加えると、この状況に陥ったときは、使い慣れたツールでどれくらいの時間がかかるかを見積もり、その見積もりを 2 倍にして学習曲線を構築します。

重要な部分は、見積もりが推測であることを経営陣に伝えることです。彼らがより正確な見積もりを要求したり、彼らがあなたに時間制限を売り込もうとしたりした場合 (スターシップを構築するのに2 日しかかからないことは確かです)エンタープライズ、あなたは良いです）あなたの銃に固執し、あなたの見積もり、またはそれが信頼できないという事実を妥協しないでください.

管理者があなたを無視し、「まあ、2 日以内に完了しなければならない」などのタスクをタイムボックス化した場合は、それが彼らの見積もりであることをもう一度知らせてください。これはあなた自身とまったく同じくらい信頼できます。

これらすべてを書面で書き留めてください。

score 2 · Accepted Answer

これは、プロジェクトマネージャーとプログラマーの両方が持っている可能性がある (そしてもちろんマスターする可能性がある!) 不可欠なスキルです。私は、プロジェクトのタスクをより適切に見積もるのに役立つと期待している、 Estimating Software Development Tasks Made (a little bit) Easyerという記事を見つけました。

score 1 · Accepted Answer

何かにかかる時間を見積もることは、あなたの仕事の一部です。締め切りではなく見積もりであることが理解されている限り、何も心配する必要はありません. コードを書く人ほど見積もりを出すのに適した人はいません。適切な見積もりを提供できない場合は、経営陣にあなたの悪い見積もりに付随するリスクを認識させて、これらの未知のサードパーティコントロールに対してプログラミングのリスクを冒す価値があるかどうかを再検討できるようにする必要があります。

score 1 · Accepted Answer

これは非常によくある状況です: 未知のものに対処する必要性です。これに取り組むための有効な方法は、実際のプログラミングタスク以外に、学習する必要があることを認識することです。管理者はそのことを認識しておく必要があります。

このような状況では、プロジェクトは突然 R&D プロジェクトになり、プログラムを学習して作成しているため、通常よりも長い時間がかかっても見栄えが悪くなります。あなたがどのくらいの速さで学習しているか、または見つけた問題に対処するためにどのようなリソースが必要かはわかりません (スタックオーバーフローは選択肢の 1 つです)。

いつものように見積もりをしてから、1.5 を掛ける (学習が速く、問題を解決するためのリソースにアクセスできる場合) か、平均的な学習者で自分だけに頼っている場合は 2.5 を掛けるべきだと思います。

これが役立つことを願っています！

score 1 · Accepted Answer

上記のすべての回答は、見積もり自体の作成に関するほとんどすべてをカバーしています。

私が強調したいことの 1 つは、あなたの見積もりを追跡することです (ジョエルのような小さな Excel スプレッドシート、または非常に単純な場合はメモ帳のドキュメントでも構いません)。毎日の終わりに、これを現在提供できる最も正確な数値に更新します。 . これを上司に返す必要がない場合でも、これを最新の状態にしておくことで、物事がどのように進んでいるかをよりよく理解できます。さらに重要なことに、作業の進行に伴って見積もりが変化する理由をよく理解できます。 .

これを行うと、この特定のテクノロジーと以前に使用したことのない他のテクノロジーの両方について、将来の見積もりが改善されます. .

score 0 · Accepted Answer

タスクを扱いやすい部分に分割するために最善を尽くしてください。運が良ければ、関連するサードパーティコンポーネントに関連する特定のタスクと、あまり結合されていない (したがって、見積もりが容易な) タスクがあります。経営陣に分割見積もりを渡し、最も不確実な見積もりがどこにあるのかを指摘します。

私は、遊んでプロトタイピングすることを提案した人に完全に同意します。プロトタイピングアクティビティの固定タイムボックスを設定します。(「見積もりのこの部分を改善するには、まず 2 日かかります。」)

score 0 · Accepted Answer

範囲を指定できますか？40～60時間くらい？

タスクが小さければ小さいほど、それはより難しくなります。それらをグループ化できれば、プロジェクトの最後にエラーがバランスする可能性があるため、もう少し「スロップ」ができます。

経験のある分野を見て、ガイドとして使用してください。「前回、データベースを変更する機能を作成する必要があり、X かかりました」. 幸運を。

estimation - 経験がない場合のプログラミングタスクの見積もり方法

22 に答える 22

Related

Reference