残りの見積もり作業量は少なくなりません
私はソフトウェアプロジェクトの開発者/アーキテクトとして働いています。プロジェクトマネージャーは、アジャイルの原則に従うのではなく、すべての機能リクエストとそれらの推定（残り）作業を記載したExcelシートを用意することにしました。毎週実装する各機能の推定残り時間を更新する必要があります。
問題は次のとおりです。バグと要件の変更が常に発生しているため、残りの作業はマネージャーが期待するほど速く変更されません。たとえば、約2か月前は「残り12日」でしたが、今日はまだ「残り7日」です。 潜在的な顧客とマーケティング部門にこの方法でリリース日を与えることができないため、マネージャーは当然これについて神経質になっています。この問題を解決する最良の方法？ 主な目標は、意味のあるリリース日を提供できるようになることだと思います。どうすればこれを達成できますか？
さて、冒頭での私の提案は、
すべての機能の優先順位を設定します。これはうまくいきませんでした。機能の約70％が優先1になり、他のすべてが優先2になりました。そして、評決は次のとおりです：すべての機能は最初のリリースに含まれている必要があります。
機能の数を減らすか、実装するのが最も難しい機能や不必要に複雑な機能の複雑さを減らします（つまり、ユーザーは機能の仕組みを理解できません）。これも多くはありませんでした。すべての機能をそのまま実装する必要があり、さらに多くの機能が追加されました。
バグ修正と機能変更の見積もりを追加します。これは、この会社の別のプロジェクトで通常行うことです。その結果、残りの作業が、下がるのではなく、数週間で上がる場合があります。これも主要な問題（リリース日？）を解決しません。
私はアイデアが足りなくなっています...マネージャーは、私の見積もりはバグのないコードを書くのに必要な時間を意味すると思ったと言っています...その発言についてのコメントはありません。彼はまた、最初の見積もりにバグ修正の見積もりを含めることを期待していたとも述べた。はい、存在するかどうかさえわからないバグを解決するための取り組みを含めるには...
彼の別の提案は、可能な限りすべてのケースをカバーするようにテストを書くことでした。理にかなっていますが、このような複雑な機能と、このアプリケーションから呼び出す非常に大規模で複雑なバックグラウンドサービスがあると、統合テストですべてのシナリオをカバーするのに永遠に時間がかかります。 100％カバーできるとは思いません。
編集：質問 「いつ完成するか」に答える方法 と 何ができるかプロジェクトの所要時間の見積もりが上手くなりますか？ は似ているように見えるかもしれませんが、私の状況には関係ありません。私はすでに努力の見積もりを出しました。私の質問は、開発の進捗状況、および見積もり/期限の変更に関連しています。
これはソフトウェアプロジェクトであるため、オーバーランしています。
これは少しばかげた答えですが、これは非常に一般的な問題です。あなたは「常に変化する要求の変化」があると言います：それがあなたがオーバーランしている理由です。要件を凍結する必要があります。そうしないと、出荷されません。要件が凍結されている場合のみ、リリース日を発行できます。
マネージャーは、コスト/品質/機能のトレードオフの三角形を認識する必要もあります。何十年もかけてそれを構築する準備ができていなければ、多くの機能を備えた完璧な製品を手に入れることはできません。新興企業や中小企業は、3つの数量すべてを最小限に抑え、「実行可能な最小の製品」を目指す傾向があります。
スプレッドシートをリビジョン管理システムに配置します。バイナリであり、区別できないかどうかは関係ありません。重要なことは、変更を追跡することです。次に、3週間前からスプレッドシートを掘り下げて、3週間の作業を行い、予想所要時間を3週間短縮したことを指摘できますが、今日のスプレッドシートには、さらに4週間の機能が追加されています。
バグ修正自体は通常、仕様の欠陥を示します。あなたはバグを選別し、ユーザーへのリスクを最小限に抑えることに集中します。ソフトウェアが正常に失敗して再試行できる場合に便利ですが、このオプションはセキュリティバグには使用できません。
あなたが経験するものは
機能クリープ
ディルバートのサイトには このトピックに関する素敵なコレクション があります。
さて、最初に私の提案は次のとおりです。1：すべての機能の優先順位を設定します。
私も同じことを提案したでしょう。
これはうまくいきませんでした。機能の約70％が優先1になり、他のすべてが優先2になりました。そして、評決は：すべての機能は最初のリリースに含まれている必要があります。
製品の所有者またはその同等者が弱い人であるか、顧客と利益相反を持っています。あなたの側で利用できるリソースのサイズが適切でない限り、これは最初から起こりません。特に知っていることは、典型的なプロジェクトではフィードバックがあり（そしてそうでなければならない）、その結果、当然の変化があるということです。
それを問題に変えるのは、チームの誰も彼らに伝えるボール（またはおそらく権限）を持っているようには見えないという事実です、これはうまくいかないでしょう。
現在のデータ。プロジェクトのさまざまな段階で機能と推定に関するデータを収集します。 バーンダウンチャート を描きます。いくつかの予測をしてみてください。 Evidence Based Scheduling を使用することもできます。
より小さなリリース1つの大きなリリースではなく、複数の小さなマイルストーンで製品をリリースすることを提案します。各リリースの一部となるものについてコンセンサスを取得するようにしてください。これを達成するために、人々は自分の願いを優先する必要があります。これは双方にとって良いことであることを説明します。
バッキングを取得します。 POまたはそれと同等のものが問題である場合は、必要な権限を持つ社内の他の誰かを見つけて、何らかの支援をしてください。上記の問題を説明し、アイデアをスケッチします。プロジェクトが成功することを望んでいることを明確にしてください。次にアドバイスを求めます。
重要なのは、1日は24時間しかなく、リソースは限られているが、機能の希望はそうではないことを理解してもらうことです。より多くの機能が必要な場合は問題ありませんが、料金を支払う必要があります。主にお金ですが、ある程度は時間もかかります。
最後に、それはチームの努力であり、目標はプロジェクトの成功です。目標は、最終的に責任を解決するためだけに数千ドルを支払うことではありません。それは誰の助けにもなりません。
新しい機能を継続的に追加しているのは、マーケティングではなくプログラムマネージャーであることを少し心配しています。しかし、ある意味では、それはyour問題ではありません。
マネージャーが新しい機能のリクエストを出すときはいつでも、コード化にかかる時間だけでなく、変更によって引き起こされるバグ修正と復帰テストのために寛大なマージンを追加するようにしてください。 Anecdote：数年前、私は当時のプログラムマネージャーから、機能を追加するのにかかる時間を見積もるように定期的に求められました。しばらくしてから、彼は私に与えたすべての見積もりを常に2倍にすることを教えてくれました。私は統合とテストとデバッグにかかる時間ではなく、設計とコーディングにかかる時間のみを検討します。
まだ行っていない場合は、既知のすべてのバグのデータベースを作成します。すべてのバグについて、修正にかかった時間を追跡します。バグの数が時間とともにどのように減少するかを監視します。これらの2ビットの情報から、未解決のバグの数がごくわずかになるまでの期間を把握できるはずです。
バグの数が時間の経過とともに著しく減少していない場合は、バグが多く、出荷する準備が整っていません。
ソフトウェア開発のほとんどの人は遅かれ早かれあなたが説明したようなプロジェクトを経験するでしょう。私があなたに言える良いこと：あなたはたくさん学ぶでしょう。困難な道を進むと、状況が異なって見え、次のプロジェクトはすでに改善されます。
ここで、あなたが今何ができるかについて考えてみましょう。
あなたのプロジェクトマネージャーはビジネスの背景があり、ソフトウェアプロジェクトの経験がないようです。 （これらの人々は、プログラミングは小包をトラックに積み込むなどの同じ種類の作業であると考えるために使用します。）彼と一緒に座って、「バグのないコード」や「100％テストカバレッジ」などはないことを説明してください。また、ソフトウェア開発における見積もりは容易ではないことも説明してください。これは、トラックの作業員とは異なり、これまでに行ったことのないものを見積もる必要があることが多いためです。
機能のクリープを停止する必要があります。そうしないと、準備ができません。複雑な依存関係があるため、新機能を追加するたびに他の機能の開発が遅くなることを説明します（システムに当てはまると思います）
プロジェクトマネージャーは、何がより重要であるかを明確にする必要があります。リリース日または完全な機能セット？業界によっては両方の状況を経験しました。ただし、この決定を行う必要があることを明確にする必要があります。
人々が優先度を与える気がない場合は、自分で優先してください。もちろん、優先度が「製品の所有者」から来る方がはるかに優れていますが、私の経験では、優先度をまったく持たないよりも自分で優先する方が良いです（70％優先度1は「優先度なし」とほとんど同じですまったく」
バグ修正などのために見積もりにバッファを含める必要があります。確かに、どのバグが発生するかはわかりませんが、いくつかのバグが確実に発生することはわかっています。見積もり用のExcelシートには、時間を消費するすべてが含まれていることを確認してください。たとえば、機能の開発（これは既に持っているものです）、会議、バグ修正、テスト、リリース/展開作業、システム管理です。 （必要に応じて）、休日、病気休暇、電話会議、プラス：見積もりエラーのバッファー
ソフトウェアプロジェクト管理に関する本を入手します（たとえば、アジャイルについての何か、または実用的なプログラマーからの「Ship It」が最初に適しています）。これは長期的にはもっと
ある意味では、これは「クライアントの管理」を正しく行わないことの失敗です。あなたは彼らがあなたが無理だと思うことを期待していると言います、そしてそれが問題の核心です。
ほとんどの企業と人々は、彼らがそれから価値を得ていると考えれば、お金を使うことに問題はありません。ほとんどの場合、これは予算によって制限されますが、価値があると考える企業は$ 2,000を費やし、価値がないと考える企業は$ 2を超えます。これは公平であり、それが機能する方法です。
次に、問題を修正するために、いくつかのことを行う必要があります。
まず、自分のホーンを少し吹いてください。あなたが行ったすべての機能クリープをリストし、それを自慢して見せてください。お客様が費やした時間とお金には価値があることを知らせてください。彼らは価値を見ることができる場合、彼らは時間枠で幸せになります。
次に、時間どおりにタスクを完了します。これを怠ったこと。正当な理由があれば心に留めておいてください。しかしそれでも失敗です。水曜日までにウィジェットを作成することになっていた場合は、水曜日までにウィジェットを完成させてください。火曜日にウィジェットを使用した場合、マークが完了します。クライアントが戻ってきて「この機能を実装するのを忘れた」と言ったとき、それを新しいものとして追跡し、新しい日付を付けます。ここで重要なのは、あなたがやろうとしていることを言うとき、あなたがやろうとしていることをやっていることを示すことです。それはすべて知覚ですが、その列に閉じる（または何でも）を入れないことにより、見栄えが悪くなります。
第三に、使用されている単語を変更してみてください。 「問題」と「エラー」を使用してみます。エラーは、エラーコードを生成するものです。そして、あなたがこれらをたくさん持っているなら、あなたは悪いコードを書いています。問題は他のすべてです。これにより、「説明しなかった機能を実装するのを忘れた」ことがバグではなく問題になる可能性があります。それでもそれは重要ですが、悪いコードのようには聞こえません。
主にここにあるのは、知覚の失敗です。あなたは期待を設定することに失敗しました、そして今あなたは戻ってそうする必要があります。これは非常に困難ですが、やりがいがあります。あなたが満たすことができる期待を設定するように注意してください。そして、この長い間、クライアントは彼の期待の一部を変えたくないでしょう。また、プロジェクトの外部の誰かを雇って、コードレビューなどを行うことを検討してください。通常、第三者に状況を確認してもらうと役立ちます。それにはそれ自体に欠点がありますが、良いコードを書いた場合、第三者が同意して述べるようにすれば、クライアントは状況についてより良く感じるのに役立ちます。
私には、プロジェクトを「壁を押し広げる」と表現する好きなマネージャーが1人いました。つまり、ほとんどのプロジェクトでは、壁を押すなど、ほぼ同じ速度で押し進める必要のあるほぼ圧倒的な数のタスクがあります。
しかし、ある時点で、あなたは重大なしきい値に達し、壁がちょっと消えて完了したと言うでしょう。
「収束」と「発散」の意味でも聞いたことがあります。発散とは、プロジェクトの範囲が拡大していることを意味し、収斂とは、範囲が縮小し、狭まっていることを意味します。それはプロジェクトにとって自然なプロセスです。オンラインでそれを説明している文献を見つけることができるかもしれません。
注意すべき点の1つは、収束と発散も個人的な会話スタイルであるということです。会話の中で、より広く考え、関連するアイデアをどんどん取り入れて、答えを見つけるのが嫌いな人もいます。コンバージャーは反対です。アイデアを結び付け、要約し、明確な答えを出すことを好みます。予想するかもしれないが、収束者と発散者はお互いを狂わせることができる。
そのため、プロジェクト定義のどこかに分岐器があり、その分岐器が答えに不満を持っていることに気付くかもしれません。それとは別に、必要な作業を発見するという自然なプロセスがまだ進んでいる可能性があります-クロスオーバーポイントに到達する前に、すべてが完了し始めます。