問題タブ [estimation]

私の会社の経営陣は、データ中心の (フォーム入力) Windows アプリ用のスクリーン ポンプ マシン/生産ライン ファクトリーを探しています。そして、私は、技術的要件を考慮して見積もりを自動化するツールを構築するタスクに賛成です。

Web アプリ (ASPNET MVC など) を構築する時間を見積もる式を構築しようとしています。内訳活動リストは一種の標準であるため.

誰かが以前に見積もりを行うためにこのようなツールを構築する必要があったかどうかを知りたかった.

私は現在、新しいプロジェクトを見積もっています。1人の開発者がそれに取り組んでいると仮定した私の高レベルの見積もりは25週間です。

実際には、2人の開発者が並行して作業します。見積もりを減らすのに合理的な要因は何ですか？（私はそれが0.5ではないことを理解しています）

アジャイル開発プロジェクトに取り組んでいる場合、ユーザー ストーリー/ユース ケースなどの時間の見積もりにどのように組み入れますか? プロジェクトで使用されているなじみのないテクノロジーについて、新しい開発者をトレーニングするのにかかる時間?? 他のマネージャーはこれをどのように処理しますか?

もちろん、私の質問は、問題の技術がプロジェクトを成功させるために必要であると考えていることを前提としています...あるいは、技術的負債の一部を返済していると見なすこともできます!

このxckd 漫画に触発されて、ファイルのコピー/移動の見積もりをユーザーに提供するための最良のメカニズムは何だろうか?

xkcd の alt タグは次のようになります。

彼らは「接続が失われた可能性が高い」と言うかもしれませんが、1,163 時間待っていれば最終的に終了するという期待を与えるために単純な時間平均を行う方が楽しいです。

面白いことは無視して、それは本当に Windows で行われていることですか? 他のOSはどうですか？より良い方法はありますか？

プロジェクトのテストに必要なテスターの数を見積もろうとしています。1 つの方法は、必要なスクリプトの数を決定することであり、要件の数と比較してスクリプトの数に経験則があるかどうか疑問に思っていました。2 - 3 と見積もっています。

• 1 晴天型試験用
• 陰性検査の場合は 1
• 1 は、少なくとも 1 つの要件テストを少なくとも 1 つの他の要件テストと組み合わせることを意味します。

しかし、それは私の最初の推測です。いくつかのベスト プラクティスがあれば、私はすべて耳にします。繰り返しますが、これは単体テストやシステム テスト用ではなく、ユーザー受け入れテスト用です。

タスクの所要時間を見積もるために使用する適切な時間の分解能は何ですか?

0.5、1、2、5 日のようなものですか、それとも 0.5、1、2、4 時間のように数時間に減らしてから数日まで続ける必要がありますか?

ラベル テキストの変更はタスクである必要がありますか? ( ETA < 1 分 )

提案？

過去に2週間の反復を計画するとき、私はユーザーストーリーを取り上げました。

• ストーリー：ファイルの名前を変更する

そしてそれをタスクに分割し、それを数時間で見積もった。

• ストーリー：ファイルの名前を変更する
  • タスク：名前変更コマンドの作成（2h）
  • タスク：選択したファイルのリストを維持する（3時間）
  • タスク：F2キーに接続します（1時間）
  • タスク：コンテキストメニューオプションの追加（1時間）

次に、作業するタスクを選択し、その作業に費やした時間を追跡します。次に、別のタスクでこのプロセスを繰り返します。反復の終わりに、各タスクに費やされた時間を調べ、それを見積もりと比較し、この情報を使用して将来の見積もりを改善することができました。

完全にテストによって駆動される場合、事前に明確に定義されている唯一の作業は、開発を開始する受け入れテストであり、大量の作業をカバーするユーザーストーリーでは、受け入れテストの範囲が広すぎて良い見積もりをしてください。

したがって、（以前のように）完了する予定のタスクを推測することはできますが、テストによって小さな垂直スライスで作業するため、それらに費やされる時間を追跡するのははるかに困難です。同時にタスク。

TDDを実行するときに、より詳細な見積もりを行い、時間を正確に追跡するために使用できる手法はありますか？上記のようにユーザーストーリーをタスクに分割することを奨励するTargetProcessを使用しているので、その形式で物事を維持すると便利です。

私はPHP開発者であり、何日も、ましてや何時間も、何かが仕事にかかる時間についてはよくわかりません。私はよく新しいものを書いていて、それを古いレガシーのがらくたとマージしています。上司に、何かが行われる可能性が高い週、そしておそらくその週の半分を伝えることはできますが、世界でどのようにして、何かが行われる日を具体的に知ることができますか？バグやその他の未知のものが頻繁に発生し、時間を浪費することを考えると、それは少し非現実的ではありませんか？私はこれらのものをそんなに最小化することしかできません...

私は次のように言うことを考えています：

「ほら、明日」と言っているのがわかります。明日！」は役に立ちません。私が取り組む多くのことであなたのためにできる最善のことは、与えられた週のどの半分がそれを終える可能性があるかをあなたに伝えることです。与えられた週の金曜日なら、次の週に移ったほうがいい」と語った。

非常に高い要件を持つWebアプリケーションを構築しています。最初にSilverlightとActiveXでビルドし、JavaScriptがそれらの間に違反するようにしたかったのです。その後、xbapの使用を検討し始めました。問題は、xbapが.net 3.0を要求することです。そのような要求を伴うアプリケーションの作成を開始する前に、.netFramework3.0をインストールしているWindowsOSユーザーの数について一般的な理解を深めたいと思いました。誰かアイデアがありますか？そのような見積もりはどこにありますか？ありがとうございました！