問題タブ [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.
project-management - プロジェクト マネージャーは、機能を実装するのにどれくらいの時間がかかるかを尋ねるべきですか?
私たちのプロジェクト マネージャーは通常、クライアントから要求された機能を実装するのに必要な時間を開発者に相談します。これは管理の原則と一致していますか? あなたやあなたのプロジェクトマネージャーは同じことをしていますか?
project-management - 将来の見積もりのために過去のプロジェクト データを記録している人は何人いますか?どのように行っていますか?
プロジェクトに取り組んでいるとき - 私は常に自分のタスクを見積もり、完了するまでにかかる時間を計算します。そのため、最終的に、プロジェクトを終了する必要がある期間を取得します (めったにありません)。
私の質問は、プロジェクト中に見積もりで使用したデータと仮定を記録し、それらを後のプロジェクトまたは同じプロジェクトの詳細な見積もりに使用しますか?
もしそうなら、そのようなデータをどのように記録し、どのように保存しますか?
私はExcelシートを使用しましたが、どういうわけか(それがどのように起こったのか想像できません;))新しい仮定や得られた情報を記入するのを忘れがちです。一方で、プロジェクトの終了後に私の予測を評価するのに、実際には読みにくく、有用ではありません。次のプロジェクトのためにそれから学ぶことです。
algorithm - 軌道方程式、およびそれらを実行するために必要な電力
今日のSO IRCに関する議論により、軌道力学に興味があり、
- 軌道問題を解くために必要な方程式
- 複雑な問題を解決するために必要な計算能力
特に問題は、いつ地球が太陽に突入するかを計算することです (基準のフレームに応じて、その逆も同様です)。
太陽系内のすべての引力を計算する必要があるのではないかと思いますが、どのような種類のコンピューター クラスターが必要なのか、それとも単一のボックスで実行できるのでしょうか?
私はここでナプキンの裏側のテストをした経験がありませんが、おそらくあなたはしますか?
また、元のインスピレーションについて Gortok に感謝します (コメントを参照)。
-アダム
estimation - ソフトウェア開発で 80/20 ルールを回避する方法
私のプロジェクトが何であれ、私は仕事の 80% をかなり早く終わらせているようです。ユーザーと管理者は、物事が予定よりかなり進んでいると考えて興奮していますが、残りの厄介な 20% の作業は、前の 80% の 4 倍の時間がかかるようです。プロジェクトの定期的なチェックインやスタンドアップを行うと、「はい、これまでのところ順調に進んでいますが、まだやらなければならないことがかなり残っています...」と言って、記録が破られたように感じます。
ほとんどの場合、私の見積もりはかなり正確ですが、私は人間です。最後の 20% の作業に実際に 80% の時間がかかっていることをユーザーに納得させるための最善のアプローチは何ですか? IT は簡単で、指を鳴らすだけで魔法が起こると信じているユーザーや管理者が増えているようです...
一般に、私たちはかなり低いレベルであると私が信じているタスクを追跡します。必ずしもラベルやテキストボックスを作成する必要はありませんが、かなり詳細です...また、すべてのタスクの完了までの見積もりを追跡します。これは、プロジェクトの途中にある場合、元の見積もりよりも重要な数値だと思います.
それはユーザーと管理者の認識に帰着すると思います。彼らは見積もりを完全に知っているかもしれませんが、見ているものに対する感情や認識にとらわれ、見積もりの数字は後回しになります。これが、期待を抑えたり管理したりする方法を見つけようとしているものです。
EDIT
これはかなり主観的であるため、コミュニティwikiに変わります。最初からそうすべきだった。
project-management - 誰が高レベルのプロジェクト見積もりを出す必要がありますか?
私は、与えられた作品の見積もりを出すのに最適な人についての議論から来ました。
詳細なレベルでは、私は常に、彼らが完全に理解しているので実際に仕事をしなければならない人から最良の見積もりが得られると言います、そしてこれは彼らに完全な賛同を与えます、しかしより高いレベルの抽象化(すなわちプロジェクト全体のレベルで)よくわかりません。
1985年からのオーストラリアの研究の結果を提供するPeoplewareの第5章を思い出します-私が見つけることができる最良のリンクはここにあります。
ここでのあなたの焦点に特に興味があります-あなたは開発者、アーキテクト、プロジェクトマネージャーなどとして答えていますか?
project-management - 不確実性のない出荷日の見積もりのためのシンプルなツール
私が探しているのは非常に単純です。信頼区間に基づいて推定されるのではなく、計算されたツールが必要です。出荷日は、必要に応じてさらに不確実性を導入することなく、合計推定値と現在の進捗状況を含むタスクのリストを指定します。それを外部で処理します。
平日やユーザー入力の休日などを考慮してほしい。
FogbugzのEvidenceBaseSchedulingがそれに非常に近いことをしていることは知っていますが、統計的側面と関連する信頼区間なしでそれを望んでいます。大幅な簡素化であり、統計的推定がEBSの本質であることは承知していますが、ここでは主観的な議論は求めていません。この単純な情報(おそらく正確な出荷日)にいつでもアクセスできるようにしたいだけです。自分で計算することなく、プロジェクト中の時間。
だから私は3つのものの1つを探しています:1)信頼区間以外に必要な情報を表示するためにFogbugz(6.0)をカスタマイズする方法2)推定の不確実性を0に設定するためにFogbugzをカスタマイズする方法3)別のツール(無料)それは私が正確にやりたいことをします。
編集:「おそらく正確」または「計算された」とは、実際に何が起こるかという意味ではなく、実際に将来を予測しようとしているということです。私は、入力された情報に関して、その明らかな不確実性とともに意味します。その場合、個々のタスクの見積もりは、支出制限または上限としてより多く見られるべきだと思います。私が計算できるようにしたい情報は本当に非常に単純です。すべてが指定どおりに進んだ場合、どこに行くのでしょうか。次に、個々の開発者が適切な見積もりを行う能力など、見積もりがどのように行われたかについての情報を使用して、信頼区間を導き出すことができます。EBSはこれを自動的に行い、間違いなく非常にうまく機能します。それが私がそれを使用する理由です。私が入手したいのは、もう1つの小さな情報です。
estimation - YouTube のようなサイトのクローンを作成するように依頼されました..
私はこれのクローンを作るように頼まれました: http://www.bragster.com/ わかりました、それ自体はクローンではありませんが、低予算で同様の機能を持つサイトです! どのくらい低く尋ねることができますか?10K 未満、おそらく 5K 未満です。
私の質問: 技術に詳しくない友人に、これは不可能であることを最もいい言葉で説明し、rentacoder.com に行かないように説得し、誰かにお金を払ってもらうように説得するにはどうすればよいでしょうか。
このようなことがあなたに起こったことがありますか?どのように対処しましたか?
architecture - 複雑さと難易度の順にランク付けされたソフトウェアシステム
私は職場で、さまざまな人が構築した最大のソフトウェア システムはどれかという議論に参加していました。この場合の最大の問題は、システムの複雑さと実装の難しさの組み合わせです。
経験豊富なプログラマーはプロジェクトの規模を直感的に把握している傾向があるので、たとえそれを書面にしないとしても、SO に質問することにしました。
議論中のシステムは次のとおりです。
- 通信課金システム。4つの主な機能:
- 60 秒ごとにデータベースからコール クレジットが予約されるリアルタイム コール コントロール、
- カスタマイズ可能な通話プラン、最小コストのルーティング、ユーザーあたりのカスタム料金、
- 課金サーバーあたり 1000 の同時通話の容量、
- 365x24x7 と 99.999% の信頼性。
- レース業界向けのコア賭けシステム。4つの主な機能:
- 約をサポートするクライアント/サーバー アプリケーション。1000 のキャッシュ アウトレットと 200 席のコール センター、
- 固定オッズ システムではなく、コミッションを差し引いて勝者間でプールを共有することに基づいてペイアウトが計算されます。
- 約 20 の異なるベット タイプ、最大コンビネーション ベットは最初の 4 位、
- 350x20x7 で 99.9% の信頼性。
- 顧客関係管理システム。4つの主な機能:
- AJAX ユーザー インターフェイス、
- 受信者アドレスに基づいてさまざまなキューに配信する電子メール統合、
- 請求、
- サードパーティの統合が許可された Web サービス API。
欠落している詳細はたくさんありますが、問題の要点は、「大きさ」の降順でシステムをランク付けすることです (定義については上記を参照してください)。スケールは任意ですが、関連性を持たせるために以下のスケールをお勧めします。
- 100 スペースシャトル生命維持装置、
- ?? アプリケーションX
- 1 つの Hello World コンソール。
上記の 3 つのシステムに加えて、人々がスロットインで作業した他の大きなシステムのランキングを見て、展望を示すことに興味があります.
language-agnostic - プログレスバーなどの現実的な時間の見積もり
ソフトウェアで非現実的な見積もりを出すプログレスバーや時間の見積もりが好きではないのは私だけではないことを私は知っています。最良の例は、10秒で0%から90%にジャンプし、最後の10%を完了するのに1時間かかるインストーラーです。
ほとんどの場合、プログラマーはタスクを完了するためのステップを見積もり、現在のステップ/合計ステップをパーセンテージで表示します。各ステップの完了には異なる時間がかかる可能性があるという事実を無視します。たとえば、データベースに行を挿入する場合、挿入時間は挿入された行の数に応じて長くなる可能性があります(簡単な例)。または、ファイルをコピーする時間は、ファイルのサイズだけでなく、ディスクとそれがどれほど断片化されているか。
今日、私は誰かがすでにこれをモデル化しようとしていて、おそらく構成可能なロバスト推定器を備えたライブラリを作成したかどうかを自問しました。外部要因(ネットワーク接続、ユーザーが他のプログラムを実行するなど)がその役割を果たすため、確実な見積もりを出すことは難しいことを私は知っています。
プロファイリングを使用してより適切な推定量を設定するソリューションもあるかもしれません。あるいは、機械学習アプローチを使用することもできます。
この問題の高度な解決策を知っている人はいますか?
これに関連して、プログレスバーの再考という記事が非常に興味深いものであることがわかりました。プログレスバーが時間の認識をどのように変えることができるか、そしてそれらの洞察を使用してより速いように見えるプログレスバーを作成する方法を示しています。
編集:時間の見積もりを手動で調整する方法を考えることができます。「推定ライブラリ」を使用しても、アルゴリズムを微調整する必要があります。しかし、この問題は統計ツールで対処できると思います。もちろん、見積もり担当者はプロセス中にデータを収集して、次のステップのためのより適切な見積もりを作成します。
私が今していることは、前のステップ(タイプごとにグループ化され、ファイルサイズ、トランザクションのサイズなどで正規化されたステップ)でかかった平均時間を取り、この平均を次のステップの見積もりとして取ります(ここでも、さまざまなタイプでカウントし、サイズ)。
今、私は推定量を作成するためのより良い統計ツールがあることを知っています、そして誰かがそれらを問題に適用したかどうか疑問に思います。