13

事前にいくつかのコンテキスト：

200 人以上の開発者企業が、多かれ少なかれ独立したアーキテクチャ チーム/部門を最終的に立ち上げたと想像してみてください。20 以上の「プロジェクト」/本番環境のさまざまなサイズのアプリケーションで構成されるソフトウェア ポートフォリオは、プロジェクトの「アーキテクチャ」も担当するチーム リーダー/テクニカル リーダーによって処理されました。

アーキテクチャを統合および制御し、必要な知識交換に加えて、システム全体で特定の必要な大規模な再作業を可能にする必要性から、同社はアーキテクチャ部門を設立することを決定しました。

  • そのような事業のすべきこととすべきでないことは何ですか?

  • そのような建築チームを構成しているのは誰ですか?

  • 彼らの責任は何ですか？

  • 彼らの範囲外のものは何ですか？

  • 会社にとって有用な移行戦略は何ですか?

  • 誰かが「アーキテクチャ チーム」に言及するたびに、それらの皮肉な表情を防ぐにはどうすればよいでしょうか?

  • あなたの会社は、そのような変化をすでに成功させていますか?
    なぜ失敗したのですか？
    なぜ成功したのですか？

これは、「アーキテクチャとは何か?」(これは非常に密接に関連しています ;) に関する議論であってはなりません。

本当に興味深い点は許容できる/現実的かもしれませんが、そのようなチームをインストールするための摩擦のない方法でさえあるかもしれません。

4

8 に答える 8

7

考慮すべきいくつかの問題を次に示します。

  • アーキテクチャ チームの正確な任務は何ですか?
  • アーキテクチャ チームの成果物は何ですか? フレームワーク、ガイドライン、実装のヘルプ... それとも単なるアーキテクチャの宇宙飛行士ですか?
  • これは今後のアプリケーション専用ですか、それともバックポートですか?
  • バックポートの責任者は誰ですか? （そして、ここでは予算を意味します...）
  • バックポートのテストに割り当てられるリソースはありますか?
  • アーキテクチャ チームには本当の筋力があるのでしょうか、それとも最初のグループが変更を実装するのに 4 か月かかると不満を言うと、経営陣の意思は固まるのでしょうか...
  • 個々のプロジェクト グループとアーキテクチャ チームの間の軋轢にどのように対処しますか (そして、軋轢が発生するでしょうか?)。日和見主義者は、これを絶好のチャンスと捉えて地位を争うだろう...
  • これは主に政治的なゲームになることに注意してください...

友よ、君の前途は険しい…

最初のステップは、アーキテクチャ チームが達成すべきことを明確にすることです。
なぜチームを配置するのですか？
すべてのアプリケーションを統合し、共通のフレームワークを開発しようとしていますか?
このチームの任務とビジョンは何ですか?

このチームのリーダーが誰であろうと、対人スキルを強化する必要があります。スター・ウォーズのテーマソングを口笛で吹いたり、ライトセーバーの音を立てたりできるのは、優秀なコーダーではない
はずです... しかし、彼はおそらく技術的な立場でチームに参加しているはずです.

おそらく、プロジェクトの大部分に精通している人々でチームを構成する必要があります。現在のチームから大量の知識が必要になる可能性があるため、現在のすべてのリードを選択することには慎重です。現実を直視しましょう。アーキテクチャ チームが独自の成果物を考え出す間、これらのチームは生産性を維持する必要があります。

于 2008-09-23T18:59:52.130 に答える
2

アーキテクチャを正しく理解するのは困難です。

「アーキテクト」は物事を成し遂げる力を必要としますが、その力を乱用して会社の残りの部分を完全に疎外しないよう十分に精通している必要があります。

私は、アーキテクチャ チームが導入された 2 つの場所で働いたことがあります。成功した場所では、ヘッドアーキテクトが技術リーダーとして認められ、チームの他のメンバーは優れた執筆力と政治的手腕を備えた比較的小規模な環境でした。誰もが組織の最善の利益のために行動しました。

うまくいかなかった場所では、アーキテクトは組織内の特定の派閥を明確に表しており、場所全体の信頼や尊敬を得ることができませんでした. その結果、アーキテクチャから価値を引き出すよりも、アーキテクチャをバイパスするための言い訳を作ることに多くの時間が費やされました。この場合、欲求不満は受動的/攻撃的およびその他の反社会的行動に変わりました.

スコープ/責任/移行についてあなたが尋ねる他の質問はすべて「場合による」と答えられると思います。会社にも、人にも、お金にも、スケジュールにもよる。

于 2008-09-23T19:47:30.613 に答える
1

興味深い質問です。

まず、この「アーキテクチャ」チームがどのような問題を解決しているのかを明確に把握する必要があります。チームの「使命」を明確に定義できない場合、それは失敗し、大きな爆発でそれを行います。:)

そうは言っても、最初のステップは、解決しようとしている問題を定義することです。あなたはテクノロジーについていくことを試みていますか？プロジェクト間でコードの再利用を取り入れようとしていますか？開発スタッフを最大限に活用しようとしていますか？アーキテクチャチームを実装する理由はいくつかあり、セットアップを考えると、これらのいずれかで十分な場合があります。あなたの質問から、あなたの目標は既存のアプリを作り直すことであるように思われるので、それは良い最初のステップです。

あなたはすでにアプリについての十分な特定の知識を持っているリードのグループを持っているので、それらから始めるのは良い考えでしょう。それらをまとめて、新しいグローバルアーキテクチャがどのように見えるかをハッシュします。また、この時点で会話を促進するためのコンサルタントを雇うこともできます。やり直しの目標を定義し、誰もが同意できる「全体像」を考え出します。

その後、私は少数のリードを取り、それらをアーキテクチャチームに昇格させます（開発者プールからリードを埋め戻します）。その後、彼らはリードと会い、物事がその「全体像」に従って進んでいることを確認します。

私は外部からまったく新しいグループを持ち込むことはしません。それは、決して良くない、望ましくない私たち対彼らのダイナミックを生み出すでしょう。部外者はまた、物事がどのように機能することになっているのか、または論理が意味するように物事が機能しないのかについてもわかりません。:)

于 2008-09-23T19:04:49.810 に答える
1

この文脈での「建築」それ自体は何の意味もありません。それは「横断的なトピックの専門家」を意味します。

「アーキテクチャチーム」があるときはいつでも、多くのプロジェクトにサービスを提供する横断チームがあります。

前の回答で述べたように、あなたはそのような「建築部門」がどのトピックに取り組む必要があるかを知る必要があります。

ここで、いくつかのトピックに基づいたアーキテクチャチームの編成の例を示します。

  • ビジネスおよび機能アーキテクチャチーム：アプリケーションの一貫した地図作成を完了するために、多くのビジネス関連の仕様を作成し、既存のアプリケーションと機能ワークフローの間の整合性をチェックします。
  • アプリケーションアーキテクチャチーム：地図作成を提供するだけでなく、ビジネスおよび機能アーキテクチャチームによって決定された機能仕様をアプリケーションに編成する方法も決定します。
    たとえば、「ポートフォリオプロセス」用の機能モジュールが必要ですが、アプリケーションアーキテクチャチームはそれを「ランチャー」、「ディスパッチャー」、GUIなどに分割することを決定できます。
  • テクニカルアーキテクチャチーム。常に以下で構成されます。
    • 実行アーキテクチャチーム、ビジネス以外のすべての純粋に技術的なトピック（ロギング、KPI、フレームワークなど）
    • 開発アーキテクチャチーム（ツールの評価とサポート、技術調査、バージョンと構成の制御のためのリポジトリ管理）
    • 環境を「実行可能」にするためのOA（オペレーショナルアーキテクチャ）（つまり、ホモロゲーションまたは本番用にシステムを展開するための適切なプロセス、適切なサーバー、および適切なネットワークを知ること）。

バックアップおよびDRP戦略のタスクを使用して、サーバーとネットワークのすべての管理を行うロジスティックチームを追加することをお勧めします。そして、良いケースシステムに基づくサポート戦略。

そして、あなたは行ってもいいです。

ここで、「大規模なやり直し」を開始するときに、機能アーキテクチャには次の両方の一貫性を強制するという使命があることを忘れないでください。

  • 固定された機能境界内にとどまるように再加工されたプロジェクト
  • レガシープロジェクトは、再加工されたプロジェクトに適用されたものと比較して、メンテナンスに反対の選択が含まれないようにします。

このサイズのショップでのリワークは、リワークが最初のリリースを生成するのを待っている間に、レガシープロジェクトに必要な進化を遂げることができることを意味します。（レガシーは、2〜3年間のやり直しの間、ただ待って静止することはできません）

大規模な手直しには、次の3つの主要なマイルストーンが必要です。

  • 1/レガシーとの対話
  • 2/レガシーを完了する
  • 3/レガシーを置き換える

つまり、特定のコンポーネントは事実上3回開発されています。;）

頑張っておやすみなさい。

于 2008-09-23T19:12:20.493 に答える
0

一般に、政治的およびその他の方法で建築グループに関連するインセンティブには十分注意してください。「建築審査委員会」（またはあなたがそれと呼びたいもの）が進歩の障壁になるのは簡単なことではありません。必要なのは、物事を改善するためのゼロのインセンティブと、物事が変化してすぐに改善されない場合の負のインセンティブです。

間違いが起こり、いくつかの「素晴らしい新技術」は中途半端な流行であり、環境の変化と革新であることが判明することを認識してください。これは時折の短期的な激変と失敗した変換をもたらすかもしれませんが、それは停滞よりも優れています。

そして、代替案は必然的に停滞をもたらします。大規模な組織では、マネージャーがチームを十分に信じて、新しいテクノロジーの推奨をトップにまでサポートし、それを証明するケーススタディを提供し、それを根底に戻すために、キャリアが台無しになっているのを目にしました。新しい技術が最終的に承認されたとき（ほぼ1年の政治的争いの後）、CTO（ずっと反対していた）は革新の功績を主張し、マネージャーを裏木部門に移しました。別の事件では、同じ事業分野での成功の例が数多くある新しい技術が提案され、この問題を研究するための委員会が結成されました。5年後、彼らはまだ問題を研究しており、何も行われていません

于 2008-09-23T19:10:17.473 に答える
0

建築だけで人が宇宙飛行士やゾンビになってしまうかもしれません。したがって、それが基本的なプロトタイピングであっても、コーディングを行う必要があることは間違いありません。実際、彼らのプロトタイプの成功は、明確なレビュー要因でなければなりません。

組織内の他の人が学べるように、毎月のプレゼンテーションや自分の仕事を追跡するブログを頻繁に発行する必要があります。

特定のプラットフォーム/ツール/書籍や設計哲学に精通するなど、学術的な目標が必要です。

必要に応じて、既存のプロジェクトで新しいツール/プロジェクト/責任を追求する時間を与える必要があります。

彼らは、重要なモジュールの少なくとも 3 ～ 4 回のコード レビューを行い、コード スタイルのガイドラインを作成する責任があります。

彼らは、少なくとも重要なモジュールの低レベルの設計をレビューする責任があります。

個人またはチームとして、役立つと思われるものを構築するための空き時間を与える必要があります。

彼らは、建築をやめて、罰則なしでその気になれば通常の仕事に戻るという選択肢を持つべきです。

彼らは、組織内で実行されているすべてのプロジェクトで何が起こっているかについての情報を持っている必要があります。他の場所で起こっていることを自分の仲間に知らせることができるように、少なくとも 1 つのプロジェクトを綿密に追跡する必要があります。これは、コード レビューなどを実行するプロジェクトである可能性があります。

彼らは、マネージャーとして非常に技術的な人を持っている必要があります。

アーキテクトは、プロジェクトの 1 つに慣れてきたら、プロジェクトを切り替える必要があります。元のプロジェクトで作業している間は、どのようなプロトタイプを使用することも許可されます。

1 年ごとに少なくとも 1 つの本当の目標 (プロジェクト間のすべての共通点を 1 つのライブラリに統合するなど) がある

時間とトレーニングを投資して、アーキテクトがエゴに縛られず、公正に専門的に行動できるようにします。紛争解決やその他のソフト スキル トレーニング、および技術的な会議やトレーニングの予算も確実に必要です。

于 2008-09-25T10:36:58.500 に答える
0

アーキテクチャ チームには、すべての開発チームの内部の仕組みを把握し、要求やガイドラインにノーと言える十分な年長者が必要だと思います。私は優れた開発者とチームを組んでいますが、十分な権限がなく、さまざまなチームの上位の開発者マネージャーをフォローすることになり、一貫性のないフレームワークを作成しました。

于 2008-09-23T19:15:31.173 に答える
0

ビジネス シナリオ A) および B) に取り組む必要があります。


A)セットアップしない場合、つまり何もしない場合:

B) 次に設定します:
リソースの流用による、短期的な成果物の中断。
複数の製品が短期間で不利になるリスクがあります。
認識された余分なマンパワーのコスト。
製品が運動によって弱体化した場合、誰がフラグを立てますか（パフォーマンスまたは認識された柔軟性の欠如）

次に、製品チームに同じ演習をしてもらい、結果を比較します。


1. アーキテクチャを推進する主要製品を選択し、このプロジェクトにリソースを追加します。
次に、より多くのリソースを追加する準備をし、辛抱強く待ってください。
このルートでリスク分割を行うと、主力製品が収益の 40% のときに機能しました。
2. 社内で行われている最も有望な議論から引き出された小さなチームを立ち上げ、各製品の新しいアーキテクチャを段階的に取り入れます。
このチームの作業を製品の作業に織り込みます。

確認すべきいくつかの質問:
1. ビジネス上のメリットを得るには、どのくらいの期間でアーキテクチャのコンバージェンスを達成する必要がありますか。
2. アーキテクチャ コンバージェンスについてすでに話しているチーム メンバーは誰ですか。また、その重要性を尋ねたり提案したりしていますか。チーム リードの 80% が「後回し」にこの質問をする必要があります。

してはいけないこと
* 外部から専門家を雇う (あなたが今本当に混乱している場合を除きます)
* 数ヶ月後にあきらめます。これは長期的です。
* すべてのプロジェクトを一度に変更します。
* これを実現できる 3 つのコアが得られるまで開始します。
* アーキテクチャ部門が必要以上に大きくなるようにする
* アーキテクチャ部門が製品チームの問題を解決すると認識されるようにする
* どの製品も「新しいアーキテクチャを待っている」ように見えるようにする
* アーキテクチャ部門が「すべてを定義する」ようにするスコープ クリープがある
* すべての製品をアーキテクチャに強制する。適合しないものもある (たとえば、同じ国で開発されていない)

やるべきこと:
* 最初の質問から適切な理由を用意して、上級管理職に賛同してもらい、製品チームに進捗状況を報告するよう依頼する
* 製品とアーキテクチャ マップの整合性を段階的に変更する
* 最も有望な、またはリスクの低い整合性に取り組む最初に製品ライン
* 付加価値を実証できるように指標を設定します (最初の一連の質問の正当性を参照してください)
* すべての製品が収束するかどうかのロードマップを作成します。
* コア アーキテクチャが何を提供し、誰がそのアーティファクトを維持するかを考える
* 製品チームがコアの仕様、コード、およびメンテナンスの観点からコアに貢献できるようにする
* 新しいスターターと既存のチームを対象に、アーキテクチャ チームの作業を使用する方法に関するトレーニングをセットアップします。

于 2008-09-23T20:37:57.513 に答える