アーキテクチャから開発への移行に関してベストプラクティスはありますか？

アーキテクチャから開発にタスクを引き渡すプロセスの改善を検討しています。

スケールの一端では、各開発者が自分のやり方で物事を行っているため、混乱を招くリスクのあるアーキテクチャガイダンスはありません。

すべてが指定されているスケールの反対側では、仕様よりも開発に時間がかかり、非常に退屈な開発タスクが発生するリスクがあります。

誰かがこれらの両極端の間の最適な中間点を見つけましたか？どの成果物を開発に提供しますか？例：モジュール、クラス構造、またはシーケンス図？

まず、別個の「アーキテクチャー」チームのコンセプトそのものが、優れたソフトウェア開発手法に対する侮辱であると述べます。企業環境のアーキテクチャチームは、開発者のプールの中で見つけることができる最悪の象牙の塔の疑似知的雄牛* *アーティストの集大成になる傾向があります。

他の組織は、メリット、知識、スキルに関係なく、建築グループを政治的報酬や最上級メンバーへの高額給与の正当化のように扱います。ほとんどが両方のタイプで構成されています。

すべての開発者は、アーキテクトであることができ、そうである必要があり、企業の高レベルの設計に関与する必要があります。単一のグループがソフトウェア設計のすべての側面を完全に独占的に制御し、設計に貢献しなかった、設計の選択の背後にある理由を理解していない、重大な欠陥を理解している可能性がある開発者に引き渡さなければならないという非常に考えより快適で、実際の実装と既存のコードにより近い設計では、率直に言って、そのコアから完全に欠陥があり、一貫して次の3つのシナリオのいずれかになります。

• 開発者は設計を理解しないか、現在の実装の現実のために設計を完全に拒否し、最終的に独自の文書化されていない設計を決定し、代わりにそれを実装します。状況は、ソフトウェアの実装を反映していない正式な設計ドキュメントです。

• 開発者は、現在の要件やユーザーストーリーの独自の側面を考慮に入れるかどうかに関係なく、盲目的に設計をフォローしているため、バグが多く品質の低い実装になっています。

• 設計ドキュメントを理解し、それらを実装できるインテリジェントな開発者は、設計のディスカッションに参加しないことにすぐに飽きてしまいます。彼らはおそらく政治的または年功序列の問題のために建築グループへの参加から除外されている可能性が高いので、彼らは欲求不満になり、退屈し、緑の牧草地に向かった。これはプロジェクトに悪影響を及ぼし、頭脳流出によりソフトウェア品質の悪さの悪循環が続くことになります。

この問題を軽減する最良の方法は、アーキテクチャグループを変更して、技術リーダーに配置することです。アーキテクチャグループの役割は、多分「技術リーダーのスクラム」になるはずです。彼らが会うことはめったになく、最高レベルの技術的方向の問題だけを話し合うべきです。JavaからScalaへの移行、Oracle for MySQLの放棄、StarUMLからAltova UMLへの切り替えなど、特定のタイプの設計プロセスを強制する一般的なユーティリティライブラリを作成する議論について考えてみてください。

実際のソフトウェア設計と実際のソフトウェア設計は、すべてのソフトウェア開発者が関与するコミュニティプロセスであり、アーキテクチャグループの非常に高いレベルの方向性によって示されます。

情報がアーキテクチャから開発テストおよび操作にどのように流れるかに常に問題がありました。これらの問題に対処する方法は、次のようないくつかの要因に依存します。

• ソフトウェアのサイズ
• 複雑
• 組織の文化
• 信念。

これらの要因の特定の組み合わせについては、新しいデザインの純粋なアジャイルアプローチの部門横断的なチームが適切です。情報は、連携して流れる。分野は彼らが必要とするものを文書化します。

これらの要因の他の組み合わせについては、アーキテクト、テスター、運用エキスパート、およびリード開発者の小さなチームが、アーキテクチャの反復を開始し、アーキテクチャを徐々に構築し、文書化し、アーキテクチャの決定に関するフィードバックを即座に得ることができます。徐々に機能を実装する開発者をチームに追加し、元のコアチームを小さくすることができます。

ほとんどの場合、政府および金融プロジェクトでは、追加のドキュメントを事前に作成する必要があり、選択に実際のフィードバックがなくても長い時間がかかる可能性があります。私の考えでは、これらのプロジェクトの多くが失敗する最大の理由です。それでもこれがあなたの状況である場合、私はドキュメントを要件に合わせて作成し、オプション1または2を使用して実際にソフトウェアをビルドし、ドキュメントを改良/適​​応します。

お役に立てれば。

これはあまり人気がないと思いますが、あなたのコメント

スケールの反対側ですべてが指定されている場合、仕様は開発よりも時間がかかります。そして、あなたは非常に退屈な開発タスクを抱えるリスクがあります。

実際に努力すべきものです。設計と仕様が十分に堅固で、開発タスクが退屈なものである場合、開発コストは下がります。コードを修正するよりも仕様を修正する方がはるかに安価であり、ソフトウェアプロジェクトの最大のコストはビルドではなく、長期的なサポートです。そして、確かな仕様に基づいたサポートコードははるかに安価です。

maple_shaftの回答に完全に同意することはできませんが、コメントに十分なスペースがなかったので、私の全体を語ることはできません。;-)

すべての開発者がアーキテクトになることができ、そうすべきであることに同意しますが、それはすべての開発者が製品またはシステム全体のアーキテクチャーに責任を負うべきであるという意味ではありません。さらに、すべての建築チームに同じ幅広いブラシを塗ることはできないと思います。適切な建築チームが完成すると、製品開発プロセス全体に大きな価値をもたらすことができます。誤解は、設計者はシステム設計のあらゆる側面を指示する必要があるということです。代わりに、上位レベルの設計に焦点を当て、実装の詳細は開発チームに任せる必要があります。ただし、開発者が最初から計画と設計のプロセスに関与してはならないということではありません。

製品が大きく、モジュール化され、最終的にはより複雑になるほど、製品のさまざまな部分がさまざまな開発チームによって処理される可能性が高くなります。このようなチームは、担当するシステムの部分を完全に理解していれば、システム全体を理解する必要はありません。多くの場合、これらの追加のチームは、アーキテクトや他のチームが専門知識を持たない特定のテクノロジー領域でモジュールを開発するという特定の目的のために、下請け業者として引き継がれます。APIの開発には私自身の特定の才能があり、まだ知りません使いやすさの点で完全に混乱することなく、完全に有機的に開発された十分に分解されたAPI、または、APIのさまざまな側面の間に一定のレベルの均一性があることを保証した人物として目立つ必要はありませんでした。私は多くの例と理由を挙げることができますが、このような状況は、多くの人がそうであると考えるかもしれない象牙の塔BSであるとは思いません。残念ながら、特に防衛、医療、金融の分野で、maple_shaftが最も懸念していると思われる種類の、企業のパラノイアが不十分で特定され、管理が不十分な製品開発をもたらす場所がたくさんあります。これらは私が建築家に（一般的に言えば）あまりふさわしくない悪い名前を与えていると私が信じているものです。残念ながら、特に防衛、医療、金融の分野で、maple_shaftが最も懸念していると思われる種類の、企業のパラノイアが不十分で特定され、管理が不十分な製品開発をもたらす場所がたくさんあります。これらは私が建築家に（一般的に言えば）あまりふさわしくない悪い名前を与えると私が信じているものです。残念ながら、特に防衛、医療、金融の分野で、maple_shaftが最も懸念していると思われる種類の、企業のパラノイアが不十分で特定され、管理が不十分な製品開発をもたらす場所がたくさんあります。これらは私が建築家に（一般的に言えば）あまりふさわしくない悪い名前を与えると私が信じているものです。

では、OPが求めていた中間点はどこにあるのでしょうか。答えは、コミュニケーションのチャネルを開くことです。設計者は、境界がどこにあるかを開発チームが確実に理解できるように、設計を十分に詳しく説明した仕様を渡す必要があります。すべてがブラックボックスと見なされる、最も広い意味でのストーリーと機能のシナリオ。次に、アーキテクトは、チームがアーキテクトの時間にアクセスして前提条件を確認し、仕様が広すぎるか不明確であるかについて質問に回答できるようにする必要があります。その後は、個々のチームが他のチームが取り組んでいることを認識し、システムの各部分が他の部分とうまく機能することを保証するために他のチームと連携する相手を知っていることを確認することです。これらのチームは互いに直接会います。システムが最も広いレベルで設計されたら、アーキテクトは、チームがサニティチェックを必要とするときにチームが頼りにする人物であり、製品の「ビジョン」が維持されていることを確認する必要があります。彼らはまた、必要な統合プロセスに参加し、マネージャー、顧客、およびその他の利害関係者からの開発チームに必要な「エアカバー」を提供すると同時に、これらのさまざまな人々が集まってワークアウトできるようにします。彼らは物事がどのように機能すべきか。

私見アーキテクトは何よりもまずファシリテーターとコミュニケーター、そしてデザイナーは第二にすべきです。仕様のレベルについて教えてください。最高のアーキテクトは、チームが望む詳細のレベルについてチームに尋ね、それらの間で機能するバランスを見つけるものだと思います。必要なドキュメントや指示の量に関して、チームごとに要件が異なる場合があります。上級チームは大まかに描かれた図を見つけ、簡単なチャットでうまくいくかもしれませんが、比較的ジュニアの開発者でいっぱいのチームは、それを実行するためにもう少し必要になる場合があります。何よりも、アーキテクトは、各チームから最高の最終結果を得るために、開発者が独自のデザインの才能を発揮するよう奨励する必要があります。

あなたは何かを改善しようと努力しているので、あなたはすでにプロセスの問題を感じています。特定の状況の根本的な原因は次のようになる可能性があります。外部の誰かによって課されたため、開発者はアーキテクチャで自分自身を識別できません。アーキテクチャを開発に引き渡しても、この根本的な原因はほとんど解決されません。

アーキテクチャを開発チームの一部にします。建築家と開発者の間の境界線を引き裂きます。これにより、情報が確実に流れるようになります。開発チームがアーキテクチャの形成に参加する場合、彼らはそれを異星人とは見なしません。アーキテクチャに関する知識をチームに注入します。あなたが言及した混乱を避けるために、企業アーキテクチャの背後にある推進要因を教えてください。あなたが述べた退屈を避けるためにアーキテクチャの決定を行う必要がある場合は、開発者を巻き込んでください。その後、引き継ぎは不要になり、開発チームのアーキテクトとしての役割を果たしました。

今後のチームがコードを保守するためには、できるだけ多くの情報を提供する必要があります。たとえば、シーケンス図がない場合、開発者はコードを1つずつトレースする必要があり、時間を浪費します。

また、新しいチームが無効であると仮定する余地もあります。

一般に、プロジェクトの内容、技術仕様、単体テストケース、シーケンス/クラス図についてのドキュメントが必要です。

クラス図ビューは、モデルだけでなくコードも作成するソリューションであると思います。クラス図は、プロジェクトアーキテクチャの静的なビューを表します。つまり、パッケージ>クラス、インターフェース、列挙型>属性、メソッドなど...>などがあります。よく見ると、UML2メタモデルの構造は、javaまたはdotnetプロジェクトとまったく同じです。

プロジェクトで使用するのは、単一のモデルに保存されるクラス図です。分類子がすでに存在する場合はモデルのビューを生成し、新しい場合はグラフィカルで新しいビューを作成します。CVS内のプロジェクトフォルダーのルートに保存されているため、開発者は図とモデルを見ることができます。私が気に入っているのは、開発者がモデル化できることです。コードレベルで何かが変更された場合、モデル全体がCVSで自動的に更新されるためです。

クラスダイアグラムは非常にシンプルで、リバースエンジニアリングが機能し、コードのグラフィカルビューを作成するため、UMLを理解する必要はありません。シンプルなナビゲーション、高度で詳細なビュー。多くのコメントを常に最新の図に追加して、プロジェクトのCVSに直接表示できます。私のUMLクラス図はマジックになりました:-)