2

私はまだ2つの方法のどちらかを学び始めていませんが、SOAを実装するためにアジャイル手法を使用している人がいるかどうか疑問に思いました。

ありがとうございました

4

3 に答える 3

6

問題は、SOA とアジャイルは味方なのか敵なのかということです。

要約すると、サービス指向アーキテクチャ (SOA) とアジャイル ソフトウェア開発はどちらも、企業がより柔軟になり、ビジネスと IT をより適切に連携させるのに役立ちます。その結果、多くの人が、SOA とアジャイルが自然に適合するように見えると指摘しています。

SOA は、アジャイル プロセスをサポートするために変更が受け入れられる制御された環境を導入します。この環境では、設計パターン、標準、およびガバナンス手順のアプライアンスを通じて、品質、効率、および生産性が向上します。サービスの再利用性、構成可能性、抽象化などの設計パターンを活用して、柔軟で適応可能なエコシステムを提供します。また、アジャイルな方法により、ライフサイクルをより段階的かつインタラクティブにすることができ、ビジネスは IT から/へのフィードバックをより迅速に取得/提供できるようになります。どちらも、企業が IT に合わせた戦略を設定できるようにするために必要な、ビジネスと IT の継続的なサイクルをサポートします。-- SOA はアジャイルに何をもたらしますか? それともアジャイルから SOA へ？

説明

SOA マニフェスト 2009とアジャイル マニフェスト 2001でわかるように、アジリティ、柔軟性、変化を機会として捉えるなど、多くの共通の価値観があります。クラウド コンピューティング [2008] や Web サービス [2004] などにより、SOA をアジャイルの進化と見なす人もいます。マニフェストを書いたこれらの人々は、ウォーターフォール モデルに不満を持っていました。クライアントは、官僚主義なしに要件を変更することはできず、プロセスの途中で自分が何を望んでいるか、何を必要としているのかを知っていることもありました。この場合、契約はすでに署名されていました。Fred Brooks, Jr. が「[実装] を 1 つ破棄する計画を立てているようです。とにかくそうするつもりです!」.

そこで人々はアジャイルな方法で物事を作り始めました。そしてそれがお客様に幸せをもたらしました。どういうわけか、彼らはソフトウェアに満足し始め、ソフトウェアはこれまで以上に正確になり、小さなバグがあり、要件に従っていました.

分散システムの BOOM! では、私の意見では、Google で始まり、パブリックまたはプライベートの Web サービスや外部 API など、インターネット上で何かを開発し始めた人もいました。SOA の優れたプラクティスはバズワードでした。彼らはマニフェストを書き、主要な建築デザインになりました。

ノート

  1. 滝は悪くも悪くもない！NASA のような一部の人々にとっては、それでも問題なく動作し、仕様が変更されない重要なソフトウェアではうまく機能します。

  2. レイヤーなど、より多くのアーキテクチャ デザイン パターンがあります。知っておくべきことは、このパターンがプロジェクトに適合するかどうかです。多分SOAは適合しないでしょう。

  3. さらに、特効薬はありません！

于 2012-07-23T03:06:11.987 に答える
2

私はSOA実装をフルタイムで使用しており、これに関してある程度の経験があります。

さまざまな方法論を使用して、SOAを組織に実装できます。参加する試みは見たことがなく、1つのプロジェクトでエンタープライズ統合設計全体をSOAに作り直します。むしろ、これは、ビジネス要件が出現または変更されると、段階的に発生します。

多くの場合、SOA実装の各サブプロジェクトはかなり小さく、製品リリースでSCRUMスプリントに分割するには小さすぎることがよくあります。

多くの点で、ウォーターフォール方式は通常、SOAを実装するための概念的に最も簡単な方式です。サービスの仕様は時間の経過とともに変更されますが、ビジネス要件の変更やエンタープライズ情報システムのアップグレード/交換の影響を大きく受けるため、これをたとえば6か月の間隔で計画することはできません。

ただし、設計段階が完了し、仕様+テクノロジパターンが決定されると、設計仕様にかなりの量の変更が加えられる可能性があります。実装フェーズが開始された後のプロジェクトで。私の経験からすると、石をひっくり返し始めると、古くて未知の悪党が這い上がり、変化が必要になるのが普通です。より反復的なアプローチは、通常、厳密なウォーターフォールよりも安価ですが、必ずしもアジャイルアプローチではありません。

方法論を決定するためのもう1つの重要な要素は、プロジェクトの資金調達と設定の方法です。アジャイルアプローチは全体的な結果/現金比率を向上させる可能性がありますが、それは組織がアジャイル手法に対処できる場合に限ります。私が慣れているいくつかのビジネス要件に対してSOAを有効にするために内部請負業者として働いている場合は、プロジェクト計画、コスト見積もり、および責任を伴う厳密なタイムスケジュールが設定される可能性があります。アジャイルアプローチでは、すべてのプロジェクトのスケジュールなどを把握するのはかなり困難です。具体的には、中小規模のSOAプロジェクトの明確なコスト見積もりを提示するのは困難です。

単一の所有者に提供される大規模なSOAプロジェクトの場合、私はSCRUMをうまく使用しており、本当にお勧めします。

于 2012-07-23T13:24:17.470 に答える
2

はい、アジャイル手法を使用して SOA を利用したプロジェクトを実装しています。しかし、アジャイル手法を使用しないことに異論はありません。防衛省や、ハード コントロール SOA が使用されているためにアジャイルが許可されていない高リスク プロジェクトなど、いくつかの特定のプロジェクトで推測します。この項は直交するためです。

于 2012-07-23T09:41:49.457 に答える