タグ付けされた質問 「estimation」

プログラマとして、私たちは常に「どれくらいかかるか」と尋ねられていますか？ そして、ご存知のように、状況はほとんど常に次のようなものです。 要件は不明です。すべての影響を詳細に分析した人はいません。 この新機能はおそらく、コード内で行ったいくつかの仮定を破り、リファクタリングする必要のあるすべてのことをすぐに考え始めるでしょう。 過去の課題から他にやることがあり、その他の作業を考慮に入れた見積もりを考え出す必要があります。 「完了」の定義はおそらく不明です。いつ実行されるのでしょうか。コーディングを終えたときのように「完了」、または「ユーザーが使用中」のように「完了」 あなたがこれらすべてのことをどれほど意識していても、「プログラマーのプライド」によって、本来考えていたよりも短い時間が与えられたり受け入れられたりすることがあります。締め切りと経営陣の期待のプレッシャーを感じるときは特に。 これらの多くは、組織的または文化的な問題であり、単純で簡単に解決することはできませんが、実際には、見積もりを求められており、合理的な答えを期待しています。それはあなたの仕事の一部です。単純に言うことはできません：私は知りません。 その結果、私はいつも私が後で達成できないことに気づくと見積もりを出すことになります。それは何度も起こりました、そして、私はいつもそれが再び起こらないことを常に約束します。しかし、そうです。 見積もりを決定して配信するためのあなたの個人的なプロセスは何ですか？どんなテクニックが便利だと思いましたか？

652 project-management  development-process  estimation  time-management 

アジャイル手法（SCRUMなど）では、ユーザーストーリーに必要な複雑さ/労力はストーリーポイントで測定されます。ストーリーポイントは、チームが反復で取得できるユーザーストーリーの数を計算するために使用されます。 推定工数のように、具体的な測定値を使用できる抽象的な概念（ストーリーポイント）を導入する利点は何ですか？推定工数を使用して、速度を計算したり、反復のカバレッジを推定したりすることもできます。 対照的に、ストーリーポイントは使用するのが難しく（概念が抽象的であるため）、関係者に説明するのも困難です。どのような利点がありますか？

132 agile  scrum  estimation  user-story 

リリース日が技術的なものに基づいて設定されているのではなく、営業担当者がそれまでに顧客にコミットしているため、繰り返し立ち往生しているようです。他の会社で開発中の友人との議論に基づいて、同じことが起こるようです。 「ここがコミットされた機能セットであり、ここがコミットされたリリース日です」と主張するのは困難です。なぜなら、この時点でそれに乗っているお金があり、それがすべてに勝るからです。 一般的に、これを後押しする方法はありますか？ このリリースではない場合、将来的にはどうですか？私が抱えている問題は、私がそうする一つの方法を見る唯一の方法であり、それはできる限り最善を尽くすことですが、いわば「現状のまま」ソフトウェアをリリースすることです。 私の名前が付けられているので、バグの多いソフトウェアをリリースしたくありませんが、一度に数か月間80時間週を実行するだけで、任意に設定されたリリース日を証明するだけです。 編集：記録のために、私は今80時間の週をやっていない、ちょうどそれはリリース日までに予想される機能セットをカバーするために必要なものとして思い浮かぶ。

120 communication  estimation  release-management 

以前の雇用では、プロジェクトマネージャー（PM）は、私のプロジェクトのコードの納期に満足していませんでした。プロジェクトリーダーから、PMはタスクと納期に与えた時間の見積もりをロックインする契約に署名することを検討していると言われました。 プロジェクトの状況は、新しいテクノロジー、コードベース、コーディング標準、および非常に変更しやすい要件を扱っていたということでした。私は新しいことを学び、変化し続ける要件にできる限りそれらを適用していました。反復全体の要件は2〜3倍に増加し、完了までの見積もりは約5〜8倍に増加しました。変更されなかったのは、見積もりと納期のみでした。 はい、私はほとんどの締め切りを逃してしまいました。そして、私は開発チーム全体の誰もそれを知らないので、本当に助けてくれないいくつかの非常に新しい技術に取り組んでいました。少なくとも簡単ではありません。 そのとき、私は、PMが彼の数字を加算することを望んでいたように思えたので、私は常に作業コードを時間通りに配信することを「保証」する契約に署名することを望みました。期限内に納品できなかった場合、PMは署名済みの契約でそれを使用できると思います。 次に起こったことは、他のプロジェクトマネージャーやプロジェクトリーダーが私を弁護し、それを起こさせなかったことだと思います。 私の質問は、これはマネージャーについて赤旗を上げるべきですか？マネージャが契約書に署名してソフトウェア開発者の時間の見積もりを確定するのは一般的な慣行ですか？またはこの場合、試してみてください。 私はフルタイムの従業員であり、独立したコンサルタントではないことに注意してください。 更新：毎週新しい見積もりを行ったことを付け加えたいと思いますが、元の見積もりと納期はPMが修正したものだったようです。

113 project-management  contract  estimation 

最近、非常に古いモノリシックアプリケーションをマイクロサービスベースのアーキテクチャに移行するプロジェクトに取り組み始めました。 レガシコードベースは非常に乱雑（「スパゲッティコード」）であり、見かけ上単純な関数（例：「multiplyValueByTen」と呼ばれる）はしばしば「3つの異なるスキーマにまたがる10個のテーブルを含む数千行の検証コード」として現れます。 今、私の上司は、新しいアーキテクチャで機能Xを作成するのにどれくらいの時間がかかるかを（正しく）尋ねています。しかし、現実的な見積もりを思い付くのは困難です。多くの場合、上記の理由によりタスクを非常に過小評価しており、時間内に終わらないので困惑しています。 賢明なことは、実際にコードに入り、すべてのブランチと他の関数の呼び出しに注意して、時間コストを推定するように見えるかもしれません。しかし、古いコードを文書化することと、実際に新しいバージョンを書き留めることの間には、ごくわずかな違いがあります。 このようなシナリオにどのようにアプローチすればよいですか？ レガシーコードのリファクタリングの仕組みを完全に理解していますが、私の質問は「リファクタリング/リライトの方法」ではありません。しかし、「パートXのリファクタリング/リライトにどれくらい時間がかかるか」に対する現実的な答えを与えることについては。

86 estimation  legacy-code 

ソフトウェア開発の最も基本的で広く受け入れられている原則の1つはDRYです（繰り返してはいけません）。また、ほとんどのソフトウェアプロジェクトには何らかの管理が必要であることも明らかです。 では、管理が簡単なタスク（見積もり、スケジュール、制御）は何ですか？正しい反復タスク、DRYに従って回避すべきタスク。 そのため、プロジェクト管理の観点からは、既存のコードを100回コピーしてタスクを解決し、必要に応じて各コピーに若干の修正を加えることは素晴らしいことです。常に、あなたが行った仕事の量と残っている量を正確に知っています。すべてのマネージャーはあなたを愛します。 代わりに、DRYの原則を適用して、重複するコードを多かれ少なかれ除去する抽象化を見つけようとすると、状況は異なります。通常、多くの可能性があります、あなたは決定を下し、研究を行い、創造的でなければなりません。短い時間でより良いソリューションを思いつくかもしれませんが、失敗することもあります。ほとんどの場合、どれだけの作業が残っているかを実際に言うことはできません。あなたはプロジェクトマネージャーにとって最悪の悪夢です。 もちろん大げさですが、明らかにジレンマがあります。私の質問は次のとおりです。開発者がDRYをやりすぎているかどうかを判断する基準は何ですか？どうすれば良い妥協点を見つけることができますか？または、妥協を見つけるだけでなく、このジレンマを完全に克服する方法はありますか？ 注：この質問は、前の質問「ソフトウェア開発における日常作業の量と推定への影響」と同じ考えに基づいていますが、それが私のポイントをより明確にするので、繰り返して申し訳ありません:)。

83 design  project-management  estimation  technical-debt 

私が取り組んだ最近のプロジェクトは、建築家によってひどく過小評価されていることが証明されました。推定値は少なくとも500％外れていました。 残念ながら、見積もりが顧客とサインオフされた後、私はプロジェクトに参加しました。シニア開発者として、私はすぐに機能および技術仕様に気付きました。いくつかの大きなギャップと不確実性が含まれていました。 その結果、私はビジネスおよび技術ディレクターと緊急事態会議を呼び出して彼らに現実を知らせることを強いられたと感じました。何よりもまず、開発者として、私はこれが非常にストレスの多い困難な状況であることに気付きました。「ビジネス」は、ITが無能であり、メッセンジャーであると非難し、私はいくつかの「弾丸」を受け取りました。 顧客はアカウントをキャンセルすると脅しましたが、現在までプロジェクトは未完成であり、私はそれとは直接関係していません。 建築家は社会的にはナイスガイでしたが、このエピソードに基づいて、単に無能であるか、彼の推定に影響を与える大きな販売/ビジネスのプレッシャーがありました。 それでは、プログラマーとして、この種の状況についてのあなたの経験はどのようなもので、どのように対処することを勧めますか？

63 architecture  project-management  estimation 

ほとんどすべての開発者は、次のようなビジネス側からの質問に答える必要があります。 なぜ、この簡単な問い合わせフォームを追加するのに2日かかるのでしょうか？ 開発者がこのタスクを見積もるとき、彼らはそれをステップに分割するかもしれません： データベースにいくつかの変更を加える DBの変更を最適化して速度を向上させる フロントエンドHTMLを追加 サーバー側のコードを書く 検証を追加 クライアント側のJavaScriptを追加 単体テストを使用する SEOセットアップが機能していることを確認してください 確認メールを実装する コードをリファクタリングして最適化して速度を向上させる ... これらは、基本的にタスク全体をHTMLをまとめてデータを保存するためのテーブルを作成するものと見なしている、技術に詳しくない人に説明するのは難しいかもしれません。彼らにとっては、最大で2時間です。 では、なぜ推定値が開発者以外にとって高いのかを説明するより良い方法はありますか？

60 communication  estimation 

経験豊富な開発者は、コードが解決しているパターンと問題が十分に理解されている場合にコードの実装にかかる時間を推定することは比較的可能ですが、最終目標が十分に理解されているときに、どのように適切な推定を行うことができますか？実装は95％の理論的/問題解決であり、実装の量は非常に少ないですか？ 私の仕事は、明確に定義された目標を達成するためのタスクで構成されることがよくありますが、その目標を達成する方法を見つける必要があり、ソリューションを理解するまで、どのような障壁が存在するかは明確ではありません。具体的には、コード生成ツールまたは自動化されたコード操作ツールに頻繁に取り組んでいます。ソリューションが完全に解決され、ツールが完成すると、実際の変更の95％がすぐに直接実行されます。ただし、生成ツールまたは分析ツールで予期しないエッジケースを処理するために、さらにいくつの問題を解決する必要があるかを見積もる方法はありません。 計画の目的のために、私の会社はそれがどれくらいの時間がかかるかについてのより良いアイデアを望んでいますが、ソリューションの各ステップを解決することを通して作業中にいくつの追加の問題が出てくるかわかりません。どのようにすればより良い見積もりを出すことができるのか分かりません。

56 estimation  automation 

私たちはスクラムを使用していますが、時折、それが計画されたスプリントでユーザーストーリーを完了できないことがあります。とにかく真のスクラムスタイルでソフトウェアを出荷し、次のスプリントプランニングセッション中に次のスプリントにユーザーストーリーを含めることを検討します。私たちが引き継いでいるユーザーストーリーが部分的に完了している場合、次のスプリントプランニングセッションでどのように正しく見積もることができますか？私達は考慮しました： a）ストーリーポイントの数を減らして、ユーザーストーリーを完了するために残っている作業のみを反映するようにします。残念ながら、これは製品バックログの報告を台無しにします。 b）部分的に完了したユーザーストーリーを閉じて、新しいストーリーを作成して、ストーリーポイントの少ない残りの機能を実装します。これは、そのスプリントで完了しなかったものを遡及的に見る能力に影響し、少し時間がかかるようです。 c）aまたはbのいずれにも煩わされず、スプリントプランニング中に「ユーザーストーリーはXストーリーポイントかもしれませんが、95％が終了していることを知っているので、それが収まると確信しています。」

50 agile  scrum  estimation  planning 

私は見積もりを吸います。誰かが私に何か時間がかかるかと尋ねると、私は完全に調子が悪くなるので、推測する勇気さえありません。通常、私はあまりにも楽観的であり、おそらく私の推測にいくつかの大きなX因子を掛けるべきです... より良い見積もりをする方法を学ぶにはどうすればよいですか？私の大学では教えられていませんし、すべての労働の期限がありますが、私は何かが実際にどれくらいかかるかについて決して考えません。どっちがいい？みんなのために（特に私のもの）。

42 project-management  estimation 

私はジュニア開発者であり、より大きなソフトウェアプロジェクトを完了するのにどれくらいの時間がかかるかを見積もることは難しいと感じています。一般にアーキテクチャを構築する方法は知っていますが、どの詳細を実行し、どの問題を解決する必要があるかを知るのは困難です。だから、どのプロジェクトを解決する必要があるのか​​、そしてそれらを解決するのにどのくらいの時間がかかるのかわからないので、より大きなプロジェクトを完了するのにどれくらいの時間がかかるかを見積もることは難しい。 ソフトウェア開発者ではない人にこれをどのように説明できますか？

37 project-management  estimation  project 

ここでストーリーポイントをアジャイル開発に使用し始めていますが、説明するのが難しく、またそれらが何であるかについての明確な答えも見つけることができません。私ができる最善のことは、他のサイト（http://blog.mountaingoatsoftware.com/tag/story-pointsなど）をポイントし、それらが何であるかについて漠然とした一般化を与えることです。私は、他の人が使用するのに役立ついくつかの使用例を含む良い説明を探しています。ストーリーポイントを説明するのに役立つリソースはありますか？

36 agile  estimation  planning 

私の質問をする前に、状況を説明しなければなりません。 私は会社でジュニアソフトウェアエンジニアとして働いています。私の開発を終えてコミットしたいとき、先輩の一人はいつも私を止めます。 彼はいつも彼がそれをレビューするのを待って欲しい。通常、彼はいくつかのバグを見つけて、いくつかの最適化を行うため、これは問題ありません。 ただし、期限までにコードをコミットする必要があります。終わったら彼に電話して、終わったと言います。彼は通常遅れる。私のコードも遅れています。 私の質問は、どうすればいいですか？レビューを待つ必要がありますか？ 編集：質問への追加。もう1つ問題があります。 コーディングするときは自由になりたいです。開発の自由に対する信頼をどのようにして得ることができますか？ いくつかの説明： これについて彼と話しました。しかし、それは助けにはなりませんでした。既に課題追跡を使用していますが、レビューのタスクはありません。開発タスクとテストタスクのみがあります。

32 teamwork  code-reviews  estimation  project-planning 

私はこの業界に1年しかいませんでしたが、特定のタスクを見積もるのに問題がありました。これを閉じる前に、はい、私はすでにこれを読みました：見積もりを求められたときにどのように対応しますか？それは私が抱えている問題とほぼ同じです。しかし、より具体的な経験の尺度、定量化可能な、またはおそらく他のプログラマーの平均的なパフォーマンスを探しています。回答の範囲は数週間で、1日程度に割り当てられたタスクのレベルに関する回答を探していました。（これにはQAやドキュメントの送信は含まれず、TDDを使用した場合のテストの作成からテストの送信前のページの作成までの実際の開発時間のみが含まれます） 現在の現在のレートは次のとおりです（ASP.NET Webフォームで）。 現在、1日（8時間）の時間を与えられている場合、既に構築されたアーキテクチャ上に、グリッドリスト（複雑なロジックはなく、作成と読み取りのみ）を含む単純なデータ入力ページを開発できます。 複雑な機能を追加し、ページを更新および削除すると、1日がタスクに追加されます。 ページをゼロから開始する必要がある場合（ソリューションなし、既存のWebサイトなし）、1日かかります。 （常にではありません）しかし、何か新しいことに遭遇したり、まだ行っていない場合は、丸一日かかります。 予想よりも長い見積りをするたびに、他の人よりもかなり遅れていると他の人が思うと感じます。1ページだけでも1日もかからないはずだという期待があったので、心配しています。はい、間違いなく改善の余地があります。常にあります。学ぶべきことがたくさんあります。しかし、私の現在のレートが遅すぎるのか、ただ平均なのか、それとも業界で1年以内の誰かの平均なのかを知りたいです。

31 coding-standards  time-management  estimation