CUSTOMER/SUPPLIER DEVELOPMENT TEAMS (P356〜360) †
要約 †
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS
[文脈の説明]
- P365-1 (Often One subsystem 〜)
- しばしば，あるサブシステムは他に供給される「下流の」コンポーネントであり，その分析やその他の機能は「上流の」コンポーネントにごくわずかなフィードバックしかもたらさず，全ての依存性は一方通行です．
＊＊＊
[問題についての説明]
- P365-2 (Upstream and dwonstream 〜)
- 上流と下流のサブシステムは，自然と二つの BOUNDED CONTEXTS に分割されます．これは特に，二つのコンポーネントの実装に異なったスキルやツールセットを必要とする場合に当てはまります．意思の疎通は単方向なので容易ですが，二つのチームの関係に政治が絡んでくると問題となります．
問題サマリ
- P365-3 (The freewheeling development 〜)
- もし下流のチームが変更に対する拒否権を持ったり，変更要求の手続きがあまりにやっかいであったりすると，上流のチームは自由な開発を束縛されてしまいます．下流のシステムを壊してしまわないかという心配が上流チームを妨げます．一方，下流チームは上流チームの優先度の意のままとなり，無力です．
- P363-4 (Downstream needs things 〜)
- 下流は上流を必要としますが，上流は下流の成果物に責任を負いません．それは，余計な努力を必要とします．チーム間の関係を正式なものにすることで，全員の人生は簡単なものになります．プロセスは，二つのユーザコミュニティのニーズと，下流が必要とされる機能のスケジュールのバランスを取るためにオーガナイズすることができます．
- P364-1 (On an Extream Programming 〜)
- XP では，そのメカニズムがすでに存在します．それは繰り返される計画プロセスです．我々がすべきことは，計画プロセスにおける二つのチームの関係を定めることです．下流のチームの代表は，計画セッションでユーザの代表のように振る舞うことができ，彼らの「顧客」と直接議論することができます．その結果は，下流チームが最も必要なタスクや遅らせてもいいタスクについての合意を含むので，成果を予想する必要がありません．
- P364-2 (If a process other 〜)
- XP 以外のプロセスを使う場合でも，類似した方法が役立つでしょう．
Therefore (そんなわけで):
解決方法サマリ
- P357-3 (Establish a clear 〜)
- 二つのチームの間に明確な顧客／供給者関係を確立してください．計画セッションでは，下流チームに上流チームの顧客の役割を演じさせてください．全員が義務とスケジュールを理解するように，下流の要件について交渉して予算を立ててください．
- P357-4 (Jointly develop automated 〜)
- 期待されるインタフェースを確認するための自動化された受け入れテストを共同で開発してください．継続インテグレーションの一部として，これらのテストを上流チームのテストスイートに加えてください．このテストは，下流への副作用を心配することから上流チームを解放します．
- P357-5 (During the iteration 〜)
- イテレーションの間，下流チームのメンバーは本来の顧客がそうであるように，上流チームの質問に答えたり問題の解決を助ける必要があります．
- P357-6 (Automatingthe acceptance 〜)
- 自動化された受け入れテストはこの顧客関係に不可欠な要素です．どんなに協調的なプロジェクトであっても，テストなしに行われた変更は驚きをもたらします．それは下流チームの作業を崩壊し，上流チームに予定外で緊急の対策を強制します．
- P358-2 (There are two 〜)
- P358-3 (1. The relationship must 〜)
- 1．この関係は，顧客の要求が最優先であることを含めて，顧客と供給者の関係でなくてはなりません．下流チームだけが顧客ではないので，異なる顧客の要求とバランスを取らなければなりませんが，優先度は彼らにあります．この状況は，下流チームがその要求のために上流チームに物乞いをしなければならない，ありがちな関係とは対照的です．
- P358-4 (2. There must be 〜)
- 2．上流チームが下流チームの成果を壊すことを恐れずにコードを変更するため，そして下流チームが上流チームを絶えず監視することなく自身の作業に集中するために，自動化されたテストスイートがなくてはなりません．
- P358-5 (In a relay 〜)
- リレー競争では，前のランナーはずっと後ろを見てチェックすることができません．彼または彼女はバトンを運ぶ人を信頼して正確に受け渡しができなければなりません．でなければ，チームは絶望的にスローダウンします．
結果、実装上の検討事項、サンプル
Example
収益分析対予約
- P358-1 (Back to our trusty 〜)
- 輸送の例に戻りましょう．予約を分析して収入を最大化するために，とても専門的なチームが設立されました．
- P359-1 (To do this 〜)
- この分析のために彼らは彼ら自身の複雑なモデルを使用し，実装には分析モデルを構築するツールとともにデータウェアハウスを使用します．そして予約アプリケーションから多くの情報を必要とします．
- P359-2 (From the start, 〜)
- 彼らが異なった実装ツールを使用することと，最も重要なこととして異なるドメインモデルを使用することから，二つの BOUNDED CONTEXT が存在することは明らかです．これらの関係はどのようなものであるべきでしょうか？
- P359-3 (A SHARED KERNEL 〜)
- 収益分析は予約モデルのサブセットに関心があるので，SHARED KERNEL が理にかなっているように見えるかもしれません．しかし，SHARED KERNEL は異なる実装技術が使われる場合は困難です．彼らは，彼ら自身のために予約 CONTEXT から必要なものを翻訳する方がいいでしょう (もし彼らが SHARED KERNEL を使うことができるなら，翻訳の負担は遙かに軽いものとなります)．
- P359-4 (The Booking application 〜)
- 予約アプリケーションには収益分析への依存はありません．そこで，上流・下流の関係となります．下流には以下のニーズがあります．
- 予約オペレーションでは必要とされない若干のデータ
- データベーススキーマの安定性 (少なくとも信頼できる変更通知) またはエクスポートユーティリティ
- P359-5 (Fortunately, the project 〜)
- 幸い，予約アプリケーション開発チームのプロマネは，収益分析チームを手助けすることを望みました．実行部門は日々の予約状況を収益分析とは別の副社長に報告するので，それは問題になり得ました．しかし，経営上層部は過去の二部門による共同プロジェクトの問題を見てきたことから収益管理に配慮し，両方のチームのプロマネが同一人物にレポートするようにソフトウェア開発プロジェクトを構築しました．
- P360-1 (Therefore, all the 〜)
- そんなわけで (どんなわけで？)，CUSTOMER/SUPPLIER DEVELOPMENT TEAMS を適用する条件が揃いました．
- P360-2 (I've seen this 〜)
- 分析ソフトウェアの開発者と業務ソフトウェアの開発者に顧客／供給関係がある場合，このシナリオが様々な場所で進化するのを見ました．上流チームのメンバーが顧客の役割を果たすとき，物事はほとんどうまくいきます．それは多くの場合非形式的に，いくつかのケースでは二つのプロジェクトのプロマネの個人的関係によって，組織化されました．
- P360-3 (On one XP 〜)
- ある XP プロジェクトでは，この関係が正式なものになるのを見ました．このプロジェクトは小規模の会社で，最も近い共通のボスはチェーン上の遠くにはありませんでした．
＊＊＊
結果として導き出される文脈、次のパターンへの導入
- P360-4 (CUSTOMER/SUPPLIER TEAMS are 〜)
- もし二つのチームが同じマネージャの下で働くなら， CUSTOMER/SUPPLIER TEAMS はより成功し，最終的にゴールを共有します．彼らが異なった企業であっても，それぞれの役割を持ちます．上流チームに動機を与えられない場合，状況はとても異なったものになります．．．
担当者のつぶやき †
みんなの突っ込み †
