私たちには 2 つの異なるアジャイル チームがあり、それぞれが別々の、しかし関連するアプリケーションに取り組んでいます。
これまで、各チームは独立した方法で作業することができました (個別のコード ベース、永続ストア、スプリント、バックログなど)。最近、製品管理部門は、これらのアプリケーションをさらに緊密に統合することを決定しました。ちなみに、各チーム (QA、開発者、BA で構成される) の規模は、今後 6 ～ 12 か月で増加します。
経営陣は、アジャイル プロセスがうまく機能した (2 つのチームが可能な限り独立して作業している) ため、アジャイル プロセスをほぼそのまま維持することを決定しましたが、アプリケーションを統合する手段として、契約ベースのサービス レイヤーのアイデアを浮かび上がらせました。
各スプリントでは、他のアプリケーションとの統合が必要なストーリーが特定されます。その時点で、追加の「統合」ストーリーが他のチームのバックログに追加されます。その後、そのチームは契約を履行する任務を負います。その間、他のチームは元のストーリー作業を継続し、他のチームが実用的なサービスを作成するまでモック/フェイク サービスを代用できます。
アジャイルは KISS 哲学を説いているため、チームの何人かの人々は、このアプローチの「複雑さ」に異議を唱えています。彼らは、「過去にうまく機能した」より無駄のないシンプルな統合方法論として、ストアド プロシージャの共有を引き続き使用することを提唱しています。
私はさまざまな理由から契約ベースのプログラミングを好みますが、主な理由は、アプリケーションが提供することが期待される動作をコンパイル時に可視化できることです。また、誰がどのコードを所有しているのか、契約を破った場合に誰のコードを壊す可能性があるのかについて、明確な境界線も得られます。ストアド プロシージャはそれを行いません。
私たちはすでにアジャイルから多くの利益を得ているので、この種のアプリの統合/同期に対処するための「アジャイルフレンドリーな」方法がすでにあると思います。コントラクト ベースの SOA レイヤーを作成することは、アジャイルの匂いテストを満たしていますか? 私が考慮していない 3 番目のオプションはありますか?