開発者の1人は、新しい機能の実装や既存の機能の変更について、別の極端な例もあります。「改善方法を知っています！」 開発の1か月後のどこかで、彼が何かを提供しなかった状況が発生する可能性があり、開発を放棄してコードを破棄するか、問題の解決策を早急に探す必要があります。 この場合、ほとんどすべての開発者が顔を保存したいと考えています。 私はプロです！「彼は考えます。「私が自分の間違いを認めるなら、みんなは私がみんなに言うほどクールじゃないと思うでしょう。」 この場合、十分に開発されていないアイデアがプロジェクトに含まれ、チーム全体の問題になります。 また、プロジェクトがより高価になります。 そして、これはすぐに目立つものではなく、因果関係に注意を払う人はほとんどいないため、状況は何度も繰り返すことができます。
上記のすべてのケースはすべてのプロジェクトで非常に一般的ですが、1年以上の期間を持つ長いプロジェクトで特に顕著です。 しかし、同様のケースの可能性を減らす、またはそれらを完全に排除することができるいくつかのテクニックがあります。 これは純粋な理論ではなく、プロジェクトで使用する既製のレシピです。
はじめに
ソフトウェア製品を開発する際には、常にあらゆる範囲のリスクがあり、そのいずれかの開始は、製品の開発時間の増加、したがってプロジェクトのコストの増加につながります。 ただし、その中でも、私の意見では、最も重要な2つを強調する価値があります。これは、バスファクターとアーキテクチャリスクです。 これらの2つのリスクは、プロジェクトの予測可能性に大きく影響します。 また、最初のイベントが発生すると、2番目のイベントが発生する可能性が高くなるので、それらを関連して重要であると誤って区別することはありません。
「バスファクター」のリスクにより、開発者の変更によりプロジェクトに関する重要な情報が失われることを理解しています。 WHOがプロジェクトを行っただけでなく、彼が同時に考えたことも重要です。 通常、単体テストで覆われているコードからも、このソリューションが選択された理由と、他の多くの単純なソリューションがある場合にそれが非常に難しい理由は必ずしも明確ではありません。 このリスクのコストは、ソリューションが適用される前に設計ソリューションのほぼ完全な文書化によって削減されます。 プロジェクトの開発または変更のすべてのタスクを文書化すること。 これにより、プロジェクトのチームの90％を一度に安全に変更できます。 アイデアとその変更に関する基本情報が文書化されているため、後続の開発者は、誤ったオプションをすべての観点から一掃することなく、想定されたシナリオに従うだけでよいため、アーキテクチャに関連するリスクの可能性が低くなります。
アーキテクチャ上のリスクを、不適切に選択されたアーキテクチャ上のソリューション、フレームワーク、またはハードウェアプラットフォームに関連するリスクと呼びます。 多くの場合、プロジェクトアーキテクチャの開発では常に、新しいソリューションが割り当てられたタスクに対応できなかったり、最も不適切な瞬間にポップアップしたりする可能性があります。「ああ、でも考えなかった」。 その後、原則として、問題を回避するための松葉杖とオプションの発明は、実装段階ですでに始まります。 最終的には、製品開発の時間とコストの増加につながる可能性があります。
プロジェクトレシピ
小麦粉のガラス、砂糖のガラスを取ります...ああ、これはレシピではありません。
おいしいプロジェクトを準備し、それが燃えなかった場合、必要なものは次のとおりです。ナレッジベース（wiki）、マーカーボード、ステッカー、およびいくつかの開発者...
リスク自体の検索に取り組む前に、アイデアレベルでいくつかの問題を解決し、アイデア自体の実行可能性を評価することが重要です。
まず、文言によってプロジェクトのあらゆる方向の動きをブロックします。
-その斬新さに驚くべき素晴らしいアイデアはありますか？
-すごい！ あなたの提案をwikiに文書化し、それについて議論します。
もちろん、「イニシアチブは罰せられる」というフレーズがこのケースに出てくる可能性があり、また一方で、エンジニアの分析スキルを高めるタスクである可能性があります。
新しいアイデアが文書化されると、そのカラフルさと明るさが少し失われる可能性があります。これにより、アイデアをより良く考え、さらにアイデアを求めることができます。 時々、この質問に書面で答えた後、システムで何も変更する必要がないか、既存のプロセスを少しひねるだけでよいことがわかります。または、システムはすでにアイデアに示されているものを知っています。
このアプローチには、考慮すべき重要な小さな欠点が1つあります。 優れたアイデアは初心者の開発者（またはコーダー）によって提供されますが、知識ベースのアイデアの文書化には、すでに比較的高度なレベルの分析能力が必要です。 イベントの開発には2つの選択肢があります。一方で、請負業者はタスクを建築家のスキルを開発するためのタスクと見なすことができます。または、余計なことを考えたくない場合は「支払いを受けません」と言えます。 したがって、著者のアイデアを分析したいという欲求の存在に時間をかけすぎて気付かないことが重要です。
アイデアが本当に価値があり、実装が必要な場合は、ステップ2に進みます。
このソリューションの実装は何につながりますか？
プロジェクトの変更は明らかな結果をもたらす可能性があり、あまり明らかではありません。このステップでのタスクは、アイデアの実装のすべての非明白な結果を見つけることです。 System of Constraints Theory（TOC）のすべての結果を明確にするために、Tree of Future Reality（DBR）用のすばらしいツールがあります。 したがって、ボード上に将来の現実の木を描き、結果を見て、望ましくない現象（NLJ）がある場合、そのような現象をブロックするオプション、つまり、システムに対する望ましくない現象の影響をどのように減らすことができるかを探します。 あまりにも多くの望ましくない現象があり、より良い時期までアイデアを延期するのが理にかなっていることがあります。 または、システムのアーキテクチャを変更するためのよりエレガントなオプションがあります。
説明：将来の現実のツリー。これは、システムの変更が実装後のシステムにどのように影響するかを示す因果関係の図です（ 詳細 ）。
望ましくない現象をすべて発見し、プロジェクトへの影響を軽減する方法を見つけましたが、疑問が生じます。
この決定ですべての目標を達成できますか？
この質問に答えるには、既存のDBDを補完するか、目標からすでに構築されている新しいDBDを描画します。 構築されたツリーでは、目標を達成するために明確に見えるはずです。 したがって、ツリーは因果関係であるため、「目標を達成していますか？」または追跡することができます。または、設定した目標の一部が変更の範囲外になります。 目標の一部が私たちの決定によって達成されない場合、または望ましくない現象（SLC）が発生する場合は、オープンSLCがツリーに残らず、設定されたすべての目標が達成されるように、アイデアの改善を検討する必要があります。
この手順の後、原則として、アーキテクチャソリューションの外観は完成しますが、すぐに実装する理由にはなりません。
ソリューションの実装にかかる費用はいくらですか？
プロジェクトを変更すると、費用と時間がかかります。 問題は、私たちが今日投資する準備ができているか、明日まで延期できるかということです。 プロジェクトのスケジュールを変更するには、サードパーティ（顧客、管理者など）との追加の調整が必要になる場合があります。 このフェーズでは、新しいソリューションを少なくともいくつかの許容範囲でタスクに分割して評価する必要があります。 これにより、関係者との話し合いの際に、詳細な実装計画を立てることができ、より具体的にはタイミングとコストについて話し合うことができます。
しかし、私たちは新しいアイデアについてほとんどすべてを見つけ、交渉の主題を準備しました。
代替手段はありますか？
より単純またはより複雑な代替ソリューションが常にありますが、それらはそうです。 また、これらのソリューションにはコストと「利益」の可能性があり、代替ソリューションが当初提案されたものよりも優れていることが判明する場合があります。 しかし、この質問に答えることができるのは、アイデアがナレッジベースに文書化されている場合のみであり、「アイデアがあり、それを実装している」という形式で開発者の頭の中で展開することはありません。 自分で仕事をするよりも、サードパーティの製品や会社を購入する方が簡単かもしれません。
これらの質問に対する回答が、アイデアの有効性、その実現可能性、およびピアと比較した実装の「低コスト」を示している場合、最も重要な質問をします。
ソリューションの実装/実装を妨げるものは何ですか？
この質問に答える際に、私たちは私たちに干渉する可能性のあるアーキテクチャ上のリスクのすべてまたはほとんどを特定します。 最近の議論では、主なリスクは次のとおりでした：
- 目的のパフォーマンスを達成できますか？
- このフレームワークに必要な機能はありますか？
- 私たちのソリューションは、私たちが考案した手段によって実現可能ですか？
さらなる開発は、各リスクの影響をテストするいくつかのプロトタイプを開発することにより、アーキテクチャ上のリスクを減らすことから始まります。 プロトタイプ自体は、ハッカー主導の開発の原則（私はアイデアを持っているのでエンコードします）に従って作成されるため、非常に安価です。 プロジェクトにソリューションを実装するのは非常に高価で時間がかかります。
もちろん、アーキテクチャリスクをチェックする段階では、このリスクまたはそのリスクが機能する問題があるかもしれませんが、代替オプションを検討する「プランB」の作業を直ちに計画し、計画することは理にかなっています。 リスクが機能しなかった場合、幸運です。さもなければ、研究に追加の時間が費やされます。
まとめ
... 40分後、オーブンから取り出し、ケーキの準備ができました。
すべての質問に対する回答が得られ、すべてのリスクが正常に解決され、プロジェクトがより予測可能になり、予期しない逸脱なしに、計画に従ってさらなる開発が行われます。
同僚、プロジェクトをどのように準備していますか？
その他のレシピ