私は新しいソフトウェアアーキテクト/リーダーであり、ソフトウェア開発者のチームのためのソフトウェア設計を考え出します。要件仕様、インターフェイスヘッダーファイル、Visioソフトウェアの設計ドキュメント、ビルドプランなどを考えています。
私の質問は、この期間中にチームの他のメンバーは何をするのかということです。私は確かに彼らをデザインに携わっていますが、チーム全体が私がいつもやっていることに積極的に取り組んでいる必要はありません。
新しいソフトウェアアーキテクトのための良い本はありますか？
11 に答える
2
役に立たないことをやめて、コーディングを始めましょう! ;)
于 2009-04-03T19:13:50.443 に答える
1
進行中の別のプロジェクトと重ならない場合は、彼らを自分のやっていることに巻き込んでもらうのは素晴らしいことですが、彼らにプロトタイプを作成してもらい、代替技術 (API、フレームワーク、ライブラリなど) の長所と短所を提示してもらうことで、プロジェクトをさらに推し進めることができます。 .) プロジェクトで使用できます。
于 2009-04-03T19:14:38.913 に答える
1
他の人が言ったように、通常、プロジェクトの最初の部分と最初のイテレーションの間にランプアップ期間が必要です。これを繰り返し構築するつもりですよね？要件の調査、基本的なデータ モデルの導入、フレームワークの特定と設定、ビルドおよびテストツールをセットアップします。通常、一部のコーディング作業は設計段階で行われます: UI モックアップ、技術的にデリケートな領域の事前プロトタイプ(どんなリスクでも、探索的コーディングによって軽減する必要があります。新しいテクノロジー、統合システムへの文書化されていないインターフェース、または不安定な要件など）。
しかし、設計段階のコーダーは、彼らの賛同を得て、最初の反復中にチームの残りの部分を訓練するのを助けるために、設計を手伝うべきです。この段階での役割は、主要な非機能要件(たとえば、既知であり、優先順位が付けられていること、設計によって満たされていること、およびテスト可能であること) を確認することです。また、必要なイテレーションと人員配置レベルを概説するために、プロジェクト リーダーまたは人員配置と資金調達の責任者と協力する必要があります。ソリューションを反復的に構築できることを確認し、最初の反復では基本的な構造のみを実装して、信頼を築き、リスクを排除することを目指します。(場合によっては、主要なリスクを 2 回目のイテレーションに移し、最初のイテレーションを自信とチーム構築に集中させることができます。)
そしてもちろん、すべての詳細を設計していないことを確認してください。次のイテレーションですべての設計成果物を使用できるようにする必要があります (必要に応じて後で詳しく説明します)。設計上の決定は変更に費用がかかるため、延期するようにしてください。ただし、一部はソリューション全体 (たとえば、データ モデルやセキュリティへのアプローチ) に影響を与えるため、少なくとも事前に概要を説明する必要があります。これは滝ではありません。これは、目を閉じて実行可能なアーキテクチャが魔法によって出現することを望んでいるだけではありません。
しかし、設計は反復を通じて進行します。進行するにつれてそれを行うことが少なくなり、ソリューションへの影響が少なくなります（運が悪く、費用がかかる場合を除きます）。
于 2009-04-03T20:29:17.500 に答える
0
一般的な設計を行う場合、プログラマーに概念実証を作成してもらうと非常に便利です。特に、システムの一部で、計画どおりに機能しない場合にストッパーが表示される可能性がある場合は、代替案を考えて設計を調整できるようにします。
これは、完全に特定の方向に進む前に、適切な設計上の決定を下すのに役立ちます。
設計を行ってから、次に進んでコーディングを開始するだけで、プロジェクトを台無しにする確実な方法です。コーディングの途中までは、設計が実行可能ではない（または単純にうまくいかない）ことに気付くことはありません。それまでに、根本的な変更を行うには遅すぎます。
設計中に存在しない問題を軽減するために時間を浪費し、実装中に予期しない問題に遭遇します。
于 2009-04-03T20:17:28.263 に答える
0
チームに取り組むべきプロジェクトが他にない場合は、チームの経験豊富なプログラマーにプロトタイプを作成してもらい、クライアントのニーズに応じて要件ドキュメントを作成できるようにします。
また、チームで使用されているテクノロジーに慣れていないプログラマーは、この時間を利用して、チームがプロジェクトを開発しようとしているテクノロジーに慣れることができます。
于 2009-04-03T19:24:19.200 に答える
0
今では遅すぎますが、現在のプロジェクトが終了する前にアーキテクトを引っ越すことをお勧めします。彼を 25% 程度解放してから、開始の 1 ～ 2 か月前に新しいプロジェクトで 75 ～ 100% まで作業を進めます (分析と顧客とのやり取りの量によっては、それ以上になることもあります)。
些細なプロジェクト (2 人年としましょう) では必要ないかもしれませんが、それよりも大きなものは、全員が参加する前に少なくとも誰かが分析を正しく行わないと混乱に陥る可能性があります。
于 2009-04-03T19:38:10.993 に答える
0
建築家 != デザイナー
すべての開発者が設計を支援できる可能性があります。それらをしましょう。アーキテクトは「一匹狼」である必要はなく、自分ですべてを行います。ガイドライン、原則、足場をレイアウトし、大まかに配線し、開発者に詳細を具体化させます。それが Visio の図を描くか、プロトタイプを作成して未知のものやリスクを軽減するかです。
アジャイル/XP に移行し、ウォーターフォール方式から離れれば、チームはさらに多くの助けを得るでしょう。
于 2009-04-03T19:50:44.660 に答える