問題タブ [time-estimation]

Python zipfile モジュールまたは UNIX コマンド ライン ユーティリティを使用して、必要に応じて ZIP アーカイブを作成する必要があります。

多くの場合、圧縮されるリソースは 1GB を超えており、必ずしも圧縮に適しているとは限りません。

作成時間/サイズを効率的に見積もるにはどうすればよいですか?

線形進行情報を使用して操作 (IE: ファイルのダウンロード) の ETA を計算する最良の方法を探しています。

呼び出される次のメソッドがあるとしましょう。

私にはいくつかのアイデアがあります：

• 一定時間 (過去 10 秒など) の進行状況を計算し、その速度を操作の平均速度として使用します。
• 報告された最後の x 個の進行状況のセットを保持し、各増分の速度を計算し、平均を使用します。

私はスクラムを学び、それで使用するためにAcunoteと呼ばれるツールを試してきました。私の質問は、タスクごとに、そこにある2つのフィールドについてです。それらは「見積もり」と「残り」です。それらにはどのユニットを使用すればよいですか？ストーリーポイントを使用しますか？残りはどうですか？たとえば、10ユニットかかるタスクがあるとします。一日の終わりに残りの部分を、完了するのに必要だと思う「ユニット」の数で埋めますか？

ありがとう！

研究開発業務の時間を見積もる際に留意すべき主なポイントは何ですか。「WPF」テクノロジーを使用して「ABC」タスクを見積もる必要があり、その経験がないとします。そのための研究開発が必要です。

あなたがプロジェクトマネージャーだとします。特定の開発者の特定のタスクの工数を日数で見積もることができます。推定を実行した後、いくつかの最小値と最大値を取得します。

この後、タスクを開発者に委任します。実際には締め切りも設定します。
締め切りを設定するときに、どちらの見積もりを使用するのが良いですか: 最小または最大?

最小見積もりは開発者にストレスを与える可能性があるため、最大見積もりは、タスクをより速く完了できる場合でも、開発者に割り当てられたすべての時間を使用する可能性があります (いわゆる学生症候群)。2つのアプローチの他の長所と短所は?

編集：

ちょっとした説明: 上司に報告するためではなく、タスクを委任するときに部下に締め切りを設定することについて話します。

編集：

もう1つ明確にするために、私は自分の実際の見積もりを念頭に置いて、上司にはわずかに大きい見積もりを提供し、部下にはわずかに小さい見積もりを提供することができます. そして、この質問は次のことに関係しています: 開発者を過小評価して、開発者をより一生懸命働かせるのは良い考えですか?

私は、Joel Spolsky が提案した方法で時間の見積もりについて考えることに慣れています。スケジュールされた項目に 16 時間以上かかる場合は、より小さなタスクに分割する必要があります。現在、私はチームにスクラムを導入し、ストーリー ポイントに基づく見積もりを取り入れています。ストーリー ポイントの適切な単位は、工数ではなく工数であることが理想的だと思います。日を使用した場合、ほとんどの問題の見積もりは 1/2 または 1 になります。

理想的な工数の使用がスクラムの文献で最も頻繁に言及されている理由について何か考えがありますか?

私は実際の人物や経験を探しています。これを主観的にとらえすぎないでください。

他の何かを探しているときに、私は興味深いステートメントに遭遇しました。これは部分的に次のようになっています。

[...]全国平均は1人あたり年間9,000行のコードです。[...]

私はたくさんのコードを書いていますが、フルタイムではありません。過去1年間のプロジェクトを振り返って、（非常に）大まかなカウント（コード行のみをカウントし、コメントや白い行はカウントしない）を行うと、1年間で約19.000になり、プロジェクトになります。その一部を自動化できれば、時間とお金で利益を差し引くことができます。

大規模なプロジェクトの時間節約を見積もるには、平均が必要です。C＃（または他の選択した言語）で、平均して1年に何行のコード行を記述しますか？そして、あなた自身の状況を見て、あなたの手書きのコードは（部分的に）自動化でき、どのような利益が得られると思いますか？

クライアントが 2 週間ごとに新しい機能を要求するフリーランスの Web アプリケーション プロジェクトがあります。今後の機能の要件を予測することはできません。したがって、クライアントが新しい機能を要求すると、次のいずれかが発生する可能性があります。

1. 既存のプラットフォームと互換性があるため、機能を簡単に実装できます

2. プラットフォームの基盤の大部分を書き直さなければならないため、機能を実装するのは困難です

3. クライアントは、既存のプラットフォームに対して実装するにはコストがかかりすぎるため、リクエストを取り下げます

プロジェクトの開始時、約 6 か月間、システムが小さくて機敏だったため、すべての機能要求がカテゴリ 1) に分類されました。しかし、過去 6 か月間、ほとんどの機能の実装はカテゴリ 2 に分類されました)。システムは成熟しているため、新しいモジュールを追加するたびにリファクタリングとテストを行う必要があります。さらに、以前は機能していたものを壊し、修正していることに気づきました (これに対して報酬はありません)。

クライアントは、私が新機能を実装するための時間と費用に不満を表明し始めています. 彼らにとって、機能要求の多くは、6 か月前に要求した機能と同じ規模です。たとえば、クライアントは、「昨年はチケット システムを構築するのに 1 週​​間かかったとしたら、今日イベント登録システムを構築するのに 1 か月かかるのはなぜですか? イベント登録システムはチケット システムよりもはるかに単純です。 1週間しかかかりません！」このシナリオのため、機能要求はすぐにカテゴリ 3 に分類されるのではないかと心配しています)。実際、私はプロジェクトをサポートするために何時間もボランティア活動を行っているため、すでに多くの費用を自分で負担しています。

何かをするのにかかる時間を正直に話すと、クライアントはしばしばショックを受けます。クライアントは常に私の見積もりをプロジェクトの初期の月と比較します。成熟した Web アプリケーションを開発、維持、サポートするために実際にかかる費用に対して、彼らは準備ができていないと思います。

フルタイムの会社で給与を計算していたとき、マネージャーは私の見積もりをより受け入れてくれ、予想外の事態に備えて数字を埋めるように勧めさえしました. クライアントが同じように考えるように調整する方法はありますか?

この Web プロジェクトにあまりコストをかけずに作業を続ける方法について、誰かアドバイスをいただけますか?

追加情報- 私はフルタイムで 1 年しかフリーランスとして働いていません。私はまだハイエンドのクライアントを持っていませんが、ゆっくりとそこに到達しています. 時間が経つにつれて、より質の高いクライアントを獲得しています。

人気のあるもの (paypal など) からあまり人気のないものまで、約 6 つの電子決済ゲートウェイを統合しました。

人気のない電子決済ゲートウェイを統合しようとするたびに、当初の見積もりを超えているようです。

私はまともなプログラマーだと思いますが、私の時間の見積もりにはおそらく作業が必要です。

他のプログラマーは、聞いたことのない電子決済ゲートウェイを統合するときに、多くの「驚き」に遭遇しますか?

どんなアドバイスも役に立ちます。

ありがとう

数ヶ月前、私はプロジェクト管理/時間見積もりソフトウェアを見つけました。これは、難易度（1、2、または3）の観点からタスクを分類し、展開にかかる時間を見積もります。

作業中にシステムが自動適応します。

ソフトウェア名を忘れてしまいました。過去数日間、私はメールを掘り起こし、結果なしでグーグルを検索してきました。

誰かが私の説明でソフトウェア名を固定できますか？

それはhttp://www.fogcreek.comではありません（私はそれが素晴らしいソフトウェアであることがわかりましたが。

前もって感謝します。