問題タブ [estimation]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
12 に答える
5156 参照

project-management - アジャイル環境での大規模プロジェクトの見積もり

私の会社は、最初の大規模な開発プロジェクトの問い合わせを受けたばかりで、アジャイル プロセスを使用したいと考えています。クライアントはアプリケーションのビジョンを持っていますが、要件がほとんどないことを公然と認めており、時間単位で請求する必要があることを認識しています。このため、私は彼にアジャイル アプローチを勧めました。

問題は、彼が予算を立てる人物を望んでいることです。私は、クライアントがその数の予算を立て、要件が変わっても、彼らの頭の中や本の中の数はそうではないので、見積もりをあきらめないように主張する多くの記事を読みました.

契約の価格設定を考慮に入れる方法はいくつかあると読んだことがありますが、そのほとんどすべて (1 つを除く) に事前の数字が組み込まれています。これは、アジャイル開発の原則全体に違反しているように見えます。

そこで私の質問は、あなたがアジャイル開発者である場合、どうすればこのアジャイル開発のキャッチ 22 を回避できるのでしょうか?

0 投票する
22 に答える
19361 参照

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

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

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

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

0 投票する
3 に答える
3129 参照

project-management - アジャイル - タスクの内訳 - 見積もるかどうか?

イテレーションの計画中に、私たちはこの男と同じ立場にいることがよくあります -経験がない場合にプログラミングタスクを見積もる方法

合理的な見積もりを出す前にプロトタイピングを行うことに私は間違いなく同意します。しかし、少しのアーキテクチャと設計が必要な場合にも同じことが当てはまりますが、スプリントの範囲外でこれらすべてを行うのはあまり快適ではありません。

基本的な考え方は、自信を持ってできる限り多くのタスクを特定し、それらを通常と推定することです。不明な領域については、調査と実装という 2 つの「タイプ」のタスクが特定されている必要があります。

調査タスクは、「Control X をデータにバインドする方法を調査する」など、不明な作業の簡単な説明です。これらについては、概算が提示されます。

実装タスクは、おそらく割り当てられたストーリー ポイントに基づいて、機能を実装するのにかかると思われる時間を大まかに推測したものです。

スプリント中に調査タスクが完了すると、開発者は何が起こっているのかをよりよく理解できる段階にあるはずです。その後、「適切な」タスクを識別できます。これは、実装プレースホルダーの代わりになります。さらに、この段階でさらなる調査タスクが特定される可能性があり、サイクルは継続します。

上記の例では、7 時間の調査タスクと推定 14 時間の実装タスクから開始します。最初の調査が完了すると、タスク 1、2、および 3 が特定され、ある程度確実に推定されます。ここで、タスク 3タスク 4 と 5 は後の段階で識別される別の調査タスクです。ご覧のとおり、最初の実装見積もりでは 14 時間以内に機能が配信されましたが、実際には少なくとも 4 + 7 + 3 + 4 + 2 = 20 かかりました。最初の見積もりよりも 3 分の 1 長くなりました。

代替テキスト http://www.duncangunn.me.uk/myweb/images/estimate.png

すべての考えを歓迎します - 私の本能はこれが飛ぶということです - 私は正しいですか、それとも私は間違った兄弟ですか?

乾杯!

0 投票する
2 に答える
67 参照

scheduling - 開発スケジュールの調整

自分の開発時間の見積もりを調整するために使用できる、完成した実際のプロジェクトのタイムスケールを含むオンライン リポジトリはありますか?

0 投票する
8 に答える
290 参照

system - この期待を踏まえて、ソリューションを実装するためにどの言語またはシステムを選択しますか?

システムが処理する必要のある見積もりは次のとおりです。

  • 3000人以上のエンドユーザー
  • 世界中に150以上のオフィス
  • ピーク時に1500人以上の同時ユーザー
  • 10.000以上の毎日の更新
  • 1秒あたり4〜5コミット
  • 1秒あたり50〜70トランザクション(読み取り/検索/更新)

これは社内のみのビジネスアプリケーションであり、世界規模の貨物管理で海運会社を支援することを目的としています。

あなたのテクノロジーの選択は何でしょうか、なぜその選択であり、それを実装するのにおよそどのくらいの時間がかかりますか?ありがとう。

注:私は募集していません。:-)

0 投票する
8 に答える
1047 参照

estimation - プログラミングは本当に難しくて時間がかかることを営業担当者にどのように説明しますか

私は、技術的な観点から要求の範囲を理解するどころか、Excel の使用方法を理解できない営業およびマーケティング タイプと仕事をすることがよくあります。もちろん、それを期待するのは公平ではありませんが、それでも私には問題が残ります.

多くの複雑なプログラミングとある程度の忍耐を必要とするものを求めていることを、マーケティングと販売のタイプに示す最良の方法は何ですか?

問題と解決策の例を教えてください。

このテーマについてのおすすめの本を教えてください。

ありがとう!

0 投票する
6 に答える
621 参照

estimation - 構築するか購入して統合するか - どのように決定しますか?

構築するか購入するかについて多くの質問や議論を見てきましたが、ほとんどの場合、単純にどちらか一方を実行できるという単純なアプローチに固執しています。ほとんどの場合、購入して統合するか、自分で構築する必要があります。いずれにせよ、あなたはいくつかの仕事のために入っています。

次の 30 ~ 60 日間で、私はいくつかの管理プロジェクトを実施して、全員が髪を引きちぎり、殺し合いをしないようにする必要があります。その最大のものは、チケット システム (電子メール、サポート リクエスト、セルフ サービスなど) です。

オプションが不足することはありませんが、最終的には、使用すると決めたものを購入し、すべてのクライアントとそのユーザーを追加して、時間の経過とともに同期を維持する必要があります. また、シングル サインオンを提供し、設計作業を行って、すべてをゼロから構築したように見せる必要があります。

構築すれば、限られた(しかし焦点を絞った)機能セットではありますが、統合の問題点をスキップできます。

このような決定を下す際に、通常何を分析しますか? 非常に特定の仕事をうまくこなす 4 ~ 5 台のシステムと、すべてをこなす 1 つのモノリシック システムのどちらがよいでしょうか?

0 投票する
51 に答える
7487 参照

project-management - プロジェクトの完了予定日を膨らませていますか?

もしそうなら、なぜですか?いくら?

楽観的すぎるので、少し膨らませる傾向があります。

0 投票する
17 に答える
1779 参照

project-management - ソフトウェアの見積もりの​​評価: 非現実的な数値の確かな兆候?

Ashによって投稿された「<a href="https://stackoverflow.com/questions/549597/dealing-with-awful-estimates/553200#553200">ひどい見積もりに対処する」に答えながら、私が学んだいくつかのヒントを共有しました。弱い見積もりを見つけるために個人的に使用します。しかし、私はもっとたくさんあるに違いないと確信しています!

サードパーティ (同僚、ビジネス パートナー、または外部企業) によってまとめられたソフトウェア プロジェクトの見積もりを迅速に評価する必要がある場合、シナリオで使用するヒューリスティックは何ですか?

目の前のタスクに関する詳細な知識がなくても発見できる、弱いソフトウェア推定の明らかな兆候とそれほど明白ではない兆候は何ですか?