開発プロセスから管理を排除する方法

私はソフトウェア開発チームのソフトウェアエンジニアです。過去3年間、社内顧客のために新製品を開発しました。この製品が完成したら、既存の製品の主要な新機能に取り組みます。特定の機能について、製品管理者は開発に150時間かかると推測しています。プロジェクトマネージャーと一緒に非常に詳細な計画を作成し、300時間の努力をしています。昨日私たちはこれについて議論し、彼らは私たちが物事を著しく過大評価していると考えています。

私たちの計画では、ユニットテストを書く時間を見積もっていましたが、彼らのアイデアは時間を節約するためにそれらをダンプすることです。まだ決定は下されていません。必要に応じて、この計画と単体テストを擁護します。しかし、ここで私が本当に嫌いなのは、経営陣が開発プロセスに干渉しているということです。開発プロセスからそれらを締め出すにはどうすればよいですか？また、ユニットテストを適切な状態に保つために、どのような引数を使用できますか（品質と長期的な時間の節約に加えて）。

ちなみに、当社には3つのエンジニアリングチームがあり、私が所属するチームはソフトウェアを予定通りに提供しています（10％のマージンを与えるか、またはマージンを取ります）。主に計画の過小評価が原因で、他のチームは常に遅れて配信します。彼らはコーディングのみを計画し、その周辺の管理、テスト、および取り扱いは計画していません。

まず、あなたの立場に完全に同情します。ビジネスのさまざまな部分の間で理解不足やコミュニケーションの崩壊があると、イライラすることがあります。そうは言っても、それらを締め出そうとは思わない。代わりに、なぜこれが良いアイデアであるかについての数字を見せるべきです。単体テストに正当化する価値があるという事実はありますか？持っていない場合は、それらの数字を収集するか、主張を裏付けるためにいくつかの調査を示す必要があります。

私は自分で同様のシナリオに対処しなければならず、この質問に同様のトピックで答えました。また、ここでどのように対処したかについてもブログしました。

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

リンクを追いかける気にならない場合は、関連する質問から要約を繰り返します。

要約すると、プロジェクトの推定時間と実際の時間を比較してから、欠陥率を他のチームの欠陥率と比較しました。私たちの場合、これらの数値は好意的に比較され、それ以上の懸念はありませんでした。

この経験に基づく私の結論は次のとおりです。

...何かをするためのあなたのアプローチが実用的で実用的であると誰にも納得させる最良の方法は、それをして、他のアプローチと比較することです。人々はドグマを気にしない、またはあなたが何かが最良の方法であるべきだと思う理由。人々に数字を見せ、アプローチの有効性を測定することによってのみ、あなたの実践が効果的であることを本当に示すことができます。

管理チームが単体テストに150時間を追加することに投資することに同意しない場合は、おそらく製品の1つの小さな領域に投資するよう説得することができます（または、データを提供するために時間を浪費することに同意することもできます） ）。製品のある領域で単体テストを行い、製品のその領域の欠陥率と、製品の他の領域の欠陥率と比較してそれらの欠陥を見つけて修正するコストに関するデータを収集します。ケースをバックアップするためにいくつかのデータを収集し、これが次のプロジェクトの問題ではないことを願っています。

使用する方法に関係なく、従うべき最大のルールは、

1. 開発者には、自分の作業を見積もる権利が必要です。
2. 利害関係者には、その作業の中で優先順位を付ける権利が必要です。

見積もりと優先順位付けは、両方の当事者がそれぞれの責任を受け入れると非常にうまく機能する2つの力です。ですから、議論する時間を無駄にする代わりに、これに同意し、両当事者が能力を最大限に発揮して作業を行うことを尊重してください。

あなたはユニットテストが時間を節約することを指摘するかもしれないので、それらを落とすと推定は500時間になります。

技術的な負債と単体テストの価値について説明する

技術的負債に関するいくつかの素晴らしいアイデアからこの投稿を見てください。その投稿をフォローすると、次のpdfにアクセスできます。

ユニットテストの価値に関するこの投稿が好きです（おそらくもっと見つけられるでしょう）

希望は、開発プロセスからそれらを取得するのではなく、適切な方法で関与しコミットすることです。

私見では、元の計画を書き留め、技術的な負債と単体テストの価値を説明する第1章と第2章（付録ではありません）を追加する必要があります。選択肢を提供します。

• すべての変更（開発段階およびメンテナンス中）に平均でかかる時間（150全体ではなく、ばかげているように思えます）：
  • 小さな4時間
  • 中16時間
  • 大40時間
• すべての変更（開発段階およびメンテナンス中）に平均でかかる推定時間：
  • 小さな2時間
  • 中8時間
  • 長い20時間

（時間は単なる目安です。適切な見積もりをするための十分な準備ができています。）

予算内での納期厳守のために実績を含めることを忘れないでください。

それを書き留めて、彼らと議論してください。現時点では実際に必要のない機能や、期限内に納品するために必要な技術的負債について、貴重な点があるかもしれません。これらが意識的な選択であることを確認してください。

これが助けて、幸運を願っています。

まず、「ユニットテストの書き込み」を、見積もり、スケジュール、および場合によっては切り捨てられる個別のタスクとして分割しないでください。見積もりは、機能レベル「XYZの実装-18時間」で行う必要があります。これらの18時間には、「単体テストの書き込み」を含む、その機能を「完了」するためにプロセスで必要なものがすべて含まれている必要があります。

これは、非技術的な開発を「開発プロセスから外す」ための良い方法です。開発プロセスをタスクリストやプロジェクトスケジュールに含めないでください。

第二に、あなたのチームはすでに彼らに良い製品を時間通りに提供しているように思えますが、他のチームはそうではありません。たぶん、この管理グループは、これらのチームをマイクロ管理する必要があることに慣れています。あなたの強みを生かしてください-毎週または隔週で動作する機能を備えたアップデートを見せることを提案すれば、彼らは「開発プロセス」について背を向けます。

私はかつて非常に良い状態のコードベースで作業していた状況にありました。非常に短い時間枠でやりがいのある新機能が必要でしたが、私はその機能を非常に短い時間で提供することができました。その時点で、コードベースははるかに悪い状態でした。そのため、機能は提供されましたが、私の作業は完了していません。すべてを同じように良好な状態に戻す必要がありました。

私はマネージャーにこのように2段階上に説明しました：それはあなたの家で塗装の仕事をするようなものです。すべてのツールがそれらの属する場所にあり、良好な状態にあり、すべてのブラシがきれいになっている場合など、ペイント作業を非常に迅速に行うことができます。しかし、その後、すべてのツールを正常に戻すために時間を費やす必要があります。そうしないと、次のペイント作業に時間がかかります。実際、ツールがどこにあるか覚えておらず、ペイントブラシを回収することはできません。また、すぐにクリーンアップジョブを実行したかのように、余分な時間と費用がかかります。

プログラミングの仕事でも同じです。クリーンアップすることで、コードベースを、次に必要になったときに非常に迅速に何かを配信できる状態にします。そうでない場合、次回はさらに時間がかかります。

彼らはあなたの賃金を払って彼らがあなたの製品を使用することになるので、彼らをあなたのプロセスから完全に締め出すことはできません（直接でなければ、おそらくあなたの会社の誰かがエンドユーザーです）。

開発者を過大評価していると非難するマネージャーは私の経験では非常に一般的なシナリオであり、それに対処しないと、上司が彼らを半分にすることを知っているため、次の見積もりが2倍になるかなり愚かな競争につながる可能性がありますそれらは四等分されるので、四倍などになります。可能であれば、この悪循環を避ける必要があります。

期限に「ドロップデッド」の理由がないと仮定すると、2つのことを提案します。

1. 高品質の仕事に対する現在のアプローチにこだわって、150時間でできることの詳細な計画を提供します。この期間内に配信できるものを正確に列挙します。KeesDijkからの回答には、きめ細かいレベルでの計画に関するいくつかの非常に良いリンクがあります。
2. 同じスタイルで詳細な計画を立てて、すべての機能を網羅し、300時間かかる方法（または数値がどうであれ）を示します。

その後、仕事に取り掛かり、進捗状況を定期的に報告し、可能であれば定期的に成果物を用意します。これにより、経営者はあなたの推定スキルと提供能力に自信を持つことができます。

見積もりの​​根拠について質問してください。矛盾を議論するだけです。単体テストをダンプすることは誤った経済です。単体テストを書くのに費やさないのは、後でデバッガーで（そしてより長く）費やします。基本的に、完了した作業のテストを計画しているという事実を文書化しました。彼らはまったくテストしないように言っています。プロジェクトの開発時に単体テストまたはアドホックテストを使用してテストする場合でも、その時間を考慮する必要があります。ユニットテストに割り当てた時間を削除すると、アドホックテストに割り当てられた時間も削除されます。

結論：あなたの推定であなたの銃に固執します。あなたの実績は、あなたが話していることを知っていることを示しており、あなたの推定の根拠（仮定、期待、過去のパフォーマンスなど）に関して合理的な答えを与えることができます。経営陣は、合理的な見積もりを作成するために必要な可視性を持っていないようです。彼らは会議を中断せずに8時間を想定していますか？彼らはシステムテストの予算を見積もっていますか？あなたの実績を考慮して、彼らはどのようにしてあなたの半分の数を思いついたのですか？

私はそれが300時間かかると推定します、そして、彼らが予算150に彼らにオプションを与えるならば、それはバグのある急ぎの仕事または配達されるのが遅いです。プロジェクトが完了し、予測どおりになったら、要求したことを伝えることができます。

ウォーリーは何をしますか？

経営者があなたに求めることを解釈する方法は複数あります。1つは、彼らがあなたに時間通りに配達してほしくないということです。

ばかみたい？はい、しかしあなたが過大評価していないことを他にどのように知ることができますか？あなたの期限（たるみ必要であれば）を満たしていない、あなたがスリップし、誤って見てください時間に何かを提供しなければならない、本当にそれは公園を散歩したという印象を与えないために疲れました。

あなたは漬物の中にいます。あなたが銃に固執し、単体テストに固執し、300時間を主張したい場合は、敵を作ります。

150時間に短縮し、ユニットテストをチャックすると、バグのある製品をより迅速に提供できますが、メンテナンス費用が高くなり、悲しみの原因になります。

どちらにしても、負けです。

またはそうそう。

ほら、あなたは大学で科学実験室を運営していない。企業のエコシステム内の顧客にサービスを提供する企業のビジネスユニットにビジネスサービスを提供しています。あなたの会社は、より速くより良いサービスを顧客に提供し始めるためにあなたの製品を必要とし、したがって必要な収益を上げるかもしれません。

必要なのはROI分析であり、その分析を行うためのすべてのデータを持っているわけではありません。コストの一部のみがあり（全員の給与計算番号がわからない）、収益の部分、特に収益の予測はありません。

信じられないかもしれませんが、経営陣はROIの予測に精通しており（ビジネススクールで彼らが教えていることです）、複数のROI予測を実行して「 ITの管理者が不満を言うソフトウェアのメンテナンスに3倍の料金を支払うことで」

したがって、ジョイントを実行する場合は、独自の会社を設立してください。わかります、それほど簡単ではありません。

言い換えれば、あなたが言われたことをしなさい。経営陣が何をしているのかを知っていれば、あなたは先に出ます。そうでない場合は、ユニットテストの有無にかかわらず、あなたは失業しています。

あなたが尋ねるROIは何ですか？投資収益率。しかし、それは悪い名前です。タイミングが投資のすべてであるため、タイムリー投資収益率（ROTI）である必要があります。