プロジェクトの見積もりをどのように管理し、チームの時間を管理しますか
私は次のようなことを考えています：
- プロジェクトに専念する通常の7.5時間の1日のうち6時間、残りは他の仕事/会社関連の活動（会議、電子メール、電話など）に費やす開発者を指定すると、上級開発者は少なくなる可能性があります。
- 見積もりまでの20％の緊急時対応時間を構築します。
厳密な見積もりを作成し、同時に開発者を管理から保護するための最良の方法は何ですか。
補遺：私は現在のクライアントがこれらのタイプの問題を抱えているのを助けるように頼まれました。彼らは本当に貧弱な開発チームであり、すべてのショット、スコープクリープ、重複する環境、気まぐれで優先順位を変更するなどのビジネスを行っています。私は彼らがより良くなるのを助けたいと思っています。
私のペットピーブは恣意的な締め切りです。
プロジェクトの締め切り：問題
プロジェクトの見積もりは、常に暗黙の期限となる日付につながります。その日付が欠落していると、原因に関係なく、そのように完全に特徴付けられていない場合、失敗のように感じることがよくあります。あなたが期待を設定する日付を与えるとき、そしてそれらの期待が満たされないとき、人々がいくらかだまされたり騙されたりするのは当然です。チームの士気はしばしば打撃を受けます。
プロジェクトの締め切り：チーム管理の鈍化とそのコスト
私の経験では、人々はプロジェクト管理を鈍いツールとして使用して、群れの開発者に何に取り組み、どれだけ難しいかを試してもらいたいので、任意の日付を望んでいます。したがって、最良のシナリオは、チームが期限までに作業し、それを早期に完了することです。一般的に得られるのと同じパフォーマンスなし期限。
最悪のシナリオは、プロジェクトが期限を過ぎたことがある人なら誰でも知っているようにです。締め切りに近づくほど、より多くのショートカットが使用されます。コードの品質が低下します。そして一般的に、より多くのモラルが苦しんでいます。コストを見ると、人々に任意の日付まで働かせようとするのはばかげているです。その結果、あなたは悪いコードを作成し、士気を悪化させました。開発者が他の職場を探しているときに、売上高がいくらかあるかもしれません。
繰り返しになりますが、
- 最良のシナリオは、期限なしでチームから得られるのと同じパフォーマンスです。
- 最悪のシナリオは、悪いコード、悪い士気、そしていたるところにある悪い経験です。
期限のないプロジェクト：より良い方法
厳しい締め切りがない限り、私は日付を与えません。リリースは、マーケティングキャンペーン、特定のイベントなどに合わせる必要があります。ただし、問題は、私たち（開発チーム）がどのようにやり取りするかということです。他の人？要求された作業がいつ完了するかをどうやって知るのですか？
頻繁なリリース：垂直スライスと速度
まず、実行されたすべての作業を追跡します。機能やバグ修正ではない作業は行われていません。すべてが垂直スライスとして行われます。したがって、機能が完了すると、リリース可能になります。現在は隔週でリリースしていますが、過去には毎週リリースしています。その結果、誰もが進捗状況や完了した作業を確認できるだけでなく、作業率も把握できます。実際、14週間の平均、標準偏差、中央値とともに、毎週の速度（連続的な毎週のスプリントのアイデアを使用）もあります。
公開優先リスト
次に、公開されている優先リストがあり、最も優先度の高い作業のみに取り組んでいます。私はリストを管理し、さまざまな要因から情報を得て優先順位について電話をかけます。上司に再確認します。
そのため、人々は他の人との関係でそこでの仕事を見ることができ、完全にリリースされると（隔週のリリースで）各作品を見ることができます。これまでのところ、それは機能しているようであり、何よりも任意の日付はありません。
有効なデータがあると仮定すると、以前のパフォーマンスが最良の予測因子です。それでも十分に正確ではない可能性がありますが、正確さを得るためにデータを収集するのが面倒であるほど、データをまったくキャプチャしないリスクがあります。
私見-重要なことに焦点を当てることは、あなたの時間を管理し、期日を迎える最良の方法です。
これは@Jamesの良いスタートですが、管理の中断がすべて便利な1.5時間のブロックで行われるわけではなく、1日を通してスプレーされる傾向があり、回復の通常の時間をはるかに超えて影響を及ぼします。
また、「時間」は、達成度のそれほど意味のある尺度ではありません。モニターをじっと見つめ、昼食を待ってスターバックスを目覚めさせ、一晩中目を覚まし続けたバグに取り組む意欲を持ってもらうのに費やした時間は、スターバックスがマニアックなデバッグをしている間に費やした時間と同じではありません。トリッキーなI/Oブロッキングと競合状態を支援するために4人の友人にIMを送信します。
20％のマージンは単純なエラーや見落としを説明するかもしれませんが、大きな脱落や間違い（およびプラットフォームの「落とし穴」）は説明しません。
最後に、@ Billが示唆したように、 PMサイト がこの質問に適した場所です。
チームの規模に応じて、現実的で達成可能な期限を設定するために使用できるさまざまなプロジェクト管理方法があります。
最も人気のあるアジャイル手法は、SCRUMとエクストリームプログラミング（XP）です。どちらにもベストプラクティスがあり、常識に過ぎない原則を中心に展開しています。
20％は私が過去にも見た数値であり、実際には非常に現実的です。開発者がタスクを頻繁に切り替える必要がない場合は、この数を減らすことができます。
個人的には、SCRUMを採用することで、私のチームは現実的なタイムラインとマイルストーンを確立することができました。また、私たちの目的を会社の他のメンバーに伝えるのにも役立ちます。 （「非技術者」）
補遺はOPとは異なる獣です。今、あなたはソフトウェア開発がどのように機能するかについて経営者を教育する方法、そしてスコープクリープのような失敗のために物事を準備するものとして認識されているものについて話している。これは、チームが見積もりや時間管理を上手に行えるようにすることとはまったく異なります。