ソフトウェア開発-非線形プロセス
ソフトウェア開発は非線形プロセスです。 5人の開発者がプロジェクトに割り当てられ、5か月（25人/月）で製品を開発する必要がある場合、25人の開発者が1か月（同じ25人/月）で同じ作業を行うことはできません。
ブルックスは、彼の著書「Mythical Man-Month：Mythical Man-Month」ですばらしい表現をしています：9人の女性が1か月で赤ちゃんを産むことはできません。 これにより、開発時間を短縮できる特定の制限があることを示唆しています。 Steve McConnellは、このしきい値は元の推定値の25％として定義されていると主張しています。
そして、はい、ほとんどの場合、10の開発者も2.5か月で最初の作業を行うことができません。5か月続くプロジェクトで10人の開発者が共同で行動すると、デッドロックまたはその他の通信の問題が発生する可能性が高いためです。
プロジェクト評価と価格エラー
「エラー価格」を説明するために、不確実性コーンがよく使用されます-水平軸に時間を示すグラフ、および垂直軸に-複雑性を評価するときに定められるエラーの値。 時間の経過とともに、評価対象のプロジェクト、正確にどのような条件下で実行する必要があるかについてのデータがますます多くなるにつれて、エラーの「広がり」はますます少なくなります。
再評価と過小評価の場合、エラーの価格はどのように上昇しますか？ エラーの価格を再評価すると直線的に増加し、エラーの価格を過小評価すると指数関数的に増加することがわかります。
最初のケースでは、線形成長はパーキンソンの法則によって説明されます。この法則では、仕事は割り当てられた時間を埋めます。 また、この法律は「学生症候群」と呼ばれます-コースを完了するためにどれだけ時間が与えられても、それは合格する前の最終日まで行われます。
プロジェクト評価のテーマを続けて、さまざまなアプローチを見てみましょう。
シンプルなアプローチ。 時間数を取り、1時間ごとのレートを掛け、20〜30％（リスク）を加算します：（N * hourly_rate）* [1,2-1,3] = project_cost
20-30％-統計によると、プロジェクトの過小評価の平均値。 その後、この値は10％（つまり、優秀なチームを持っていることを意味します）、場合によっては50％（まあ、通常も）、さらに多くの場合があります。
全体的な理由は、人々は楽観主義者だからです。 また、楽観的な推定値も提供します。 したがって、楽観的と悲観的の2つの評価を提供することが望ましいです（秘密をお伝えします-悲観的も顧客に表示できます。それらのほとんどは正常に反応します）。
より複雑なアプローチ：
どこで：
- C bc （プロジェクトコスト-楽観的見積もり）
- C wc （プロジェクトコスト-悲観的評価）
- P bc （楽観的なシナリオの確率）
- P wc （悲観的なシナリオの確率）
最終的な見積もりは5850万ドルで、これは4750万ドル（約23％のエラー）に相当する「平均」値よりもはるかに高く、ほとんどのマネージャーが妥協案として選択する可能性が高いです。 したがって、平均で20〜30％を「通常の」評価に追加する必要があることをもう1つ確認します。
さて、「平均」値について話しているので、過半数が下した決定は、限られた数の人が下した決定よりも常に悪いことを付け加えなければなりません。 大企業での重要な決定は、すべての従業員の一般的な投票ではなく、取締役会によって行われるのはこのためです。 そして、それが、すべてのチームメンバーが下した決定が、たとえばチームリーダーと連携してプロジェクトマネージャーが下した決定よりも悪い可能性が高い理由です。
技術的負債
顧客と請負業者が、完全ではないにしても迅速な技術的ソリューションのすべての利点を明確に理解し、後で支払う必要がある意識的な妥協ソリューション。 この用語はワードカニンガムによって造られました。
技術的負債の一般的な原因：
- すべての必要な変更が行われる前にビジネスが何かをリリースすることを要求するビジネスの圧力は、これらの不完全な変更を含む技術的な負債を蓄積します。
- プロセスの欠如またはビジネスが技術的負債について何の考えも持たず、結果を考慮せずに意思決定を行う場合の理解。
- 疎結合コンポーネントが作成されていないため、コンポーネントがモジュラープログラミングに基づいていない場合、ソフトウェアは変化するビジネスニーズに適応するほど柔軟ではありません。
- テストの欠如-バグを修正するための迅速な開発と危険な修正（「クランチ」）を奨励します。
- 必要なサポートドキュメントなしでコードが生成された場合のドキュメントの不足。 裏付け文書を作成するために必要な作業も、支払わなければならない負債です。
- 知識ベースが組織全体に分散されておらず、ビジネスパフォーマンスが低下している場合、または若い開発者がメンターによって適切にトレーニングされていない場合の相互作用の欠如。
- 2つ以上のブランチで同時に並行開発を行うと、技術的な負債が蓄積する可能性があり、最終的には変更をマージするために補充する必要があります。 単独で行われる変更が多いほど、総負債は大きくなります。
- リファクタリングの遅延-プロジェクト要件の作成中に、コードの一部が面倒になり、将来の要件をサポートするために再設計する必要があることが明らかになる場合があります。 より長いリファクタリングが遅延し、プロジェクトの現在の状態を使用するコードが記述されるほど、後続のリファクタリング時に支払う必要のある負債が増えます。
- 開発者が高品質のコードの書き方を知らない場合の知識不足。
ほとんどの場合、プロジェクトの期限の混乱、追加の従業員の雇用、または時間外労働の形で、技術的負債は償却されます。
パレート原理（原理20/80）
経済学者で社会学者のウィルフレード・パレートにちなんで命名された経験則は、最も一般的な形で「努力の20％が結果の80％を与え、残りの80％が結果の20％のみを与える」と定式化されています。 数字の20と80は条件付きであることを理解する必要があります（たとえば、Google、Apple、Microsoftはアプリケーションストアで30 x 70の分布を好む）が、これは一般的な意味を変えません。
パレートの原則は、生活のさまざまな分野に適用できるよく知られたルールですが、ITにおいては、この原則はすべての栄光に現れています。
パレート法の最も重要な結果：
- 重要な要因はほとんどなく、重要な結果につながるのは孤立したアクションのみです。
- ほとんどの努力は、望ましい結果を生み出しません。
- 私たちが見ているものは常に真実ではありません-常に隠された要因があります。
- 結果として受け取ることを期待するものは、原則として、受け取るものとは異なります（隠れた力は常に行動します）。
- 通常、何が起こっているのかを理解するのは難しすぎて退屈であり、多くの場合それは不要です-あなたのアイデアが機能しているかどうかを知り、それが機能するように変更し、アイデアが停止するまで状況を維持する必要があります働く。
- 最も成功したイベントは、少数の非常に生産的な力の作用によるものです。 ほとんどのトラブルは、少数の非常に破壊的な力の作用によるものです。
- グループまたは個人のほとんどのアクションは時間の無駄です。 望みの結果を達成するために、彼らは何も現実のものを与えません。
また、パレート効率を忘れてはなりません。システムを特徴づける特定の各指標の値を、他の指標を悪化させずに改善できないようなシステムの状態です。
簡略化された形式-三角形のルール：迅速、効率的、安価-任意の2点を選択します。
1％ルール
コンテンツ作成におけるインターネット視聴者の不均等な参加を記述するルール。 一般に、圧倒的多数のユーザーはインターネット資料のみを閲覧し、ディスカッション（フォーラム、オンラインコミュニティなど）には積極的に参加していないと言われています。
より一般的には、新しいアイデアを生み出したり、積極性を示したりする従業員の数を表します。
例を考えてみましょう。 あなたは30人が参加した特定のイベントを開催しました。 イベント後にアンケートを実施してフィードバックを受け取りたい。 それは理にかなっていますか？ ある種の合成条件を考え出そうとしない場合、0.3人が回答するので、このようなアンケートには意味がありません。 1人の人が答えても（3％に相当し、それ自体が優れたオプションです）、1人の答えがあなたに合っているとは思えません。 建物の出口で人々の意見を聞くのは簡単です:-)
ピーター原則
ピーターの原則は次のとおりです。階層システムでは、各個人が自分の無能のレベルにまで上昇する傾向があります。
機能：
- それは一般的な観察の特別なケースです。うまく機能するものやアイデアは、災害を引き起こすまで、ますます困難な状況で使用されます。
- ピーターの原則によれば、階層システムで働く人は、自分の職務に対処できない場所、つまり無能になるまで昇進します。 このレベルは、この従業員の無能のレベルと呼ばれます。
- どのレベルで従業員が無能のレベルに達するかを事前に決定する方法はありません。
このため、37signalsは従業員の昇進を拒否し、職務の一環として従業員にスキルと知識（したがって、支払い）を向上させることを拒否しました。
37signalsの従業員数が25を超えると、奇妙なことが起こりました。 従業員が彼女を残しました。 彼女は昇給を望んでいましたが、会社のフラットな構造はマネージャーの存在を意味しませんでした。 その後、Jason Friedがコラムを書き、この特定の組織構造を維持することがなぜ彼らにとって重要なのかを説明しました。 彼によると、通常、企業は従業員に「垂直的」な野心、つまりキャリアのはしごを上げたいという願望を抱く傾向があります。 そして、37signalsでは、彼らは「水平」な野望に近い人々、つまり、あなたが何よりも愛するものにおいてより専門的になる必要性を受け入れようとします。 村
このトピックをさらに深く理解するには、「Rework and Remote」をお勧めします。
ハンロンかみそり
不快な出来事の原因における人為的エラーの可能性のある役割についての声明は、次のように書かれています。
ハンロンのカミソリは私の好きな原則の一つです。 ほとんどの場合、すべての横棒は「予期しない力の行動」、「陰謀論」を押し出そうとしていますが、従業員の通常の愚かさによって簡単に説明されます。
このトピックを続けると、マーフィーの法則を想起する必要があります。これは、次のように定式化された哲学的原則です。何らかのトラブルが発生する可能性がある場合、間違いなく発生します。 そのような卑劣な法則。
正式な形式では：
任意のnにはmがあり、m <nであるため、nがこれらの特定の条件下でマーフィーの法則を満たすのに十分な大きさである場合、m個のテストで少なくとも1つが望ましくない結果を出すのに十分です。
ソフトウェア開発におけるマーフィーの法則の結果：追加のチェック、追加レベルの抽象化と分離、および「ベストプラクティス」として知られているその他の技術、「愚か者に対する保護」を実装する必要があります。
最後に、もう1つの効果である「督促-クルーガー」効果について説明します。 これはメタ認知のゆがみであり、低いレベルの資格を持つ人々が誤った結論を下し、失敗した決定をし、同時に低いレベルの資格のために彼らの間違いを認識することができないという事実から成ります。 これは、自分の能力を過大評価することにつながりますが、逆に、真に高度な資格を持つ人々は、逆に能力を過小評価する傾向があり、他の有能な人を考えると、自信が不十分です。 したがって、能力の低い人は一般に、能力のある人の特性よりも自分の能力について高い意見を持っています。
そして、人々は自信を持って無礼に話す人をより多く信じる傾向があるので、静かに、そして緊張せずに言った真実は聞かれないかもしれません。 したがって、次回より有能であるが勇気のない従業員の話を聞くには、すべての評価と決定を従業員の発言と相関させることが非常に重要です。
説明されている原則と法律を理解することで、ソフトウェアをより効率的に開発し、常に時間と予算内で完成させることができることを願っています！