d. 薄いエンドツーエンドのアイテムに分割する

薄く「垂直な」エンドツーエンドの要求に分割します。アイテムを内部設計のステップで分割しないでください

開発者は内部設計における論理的アルゴリズムのステップの観点から開発を考えがちだが、このステップごとにアイテムを分割するのはよくない

良くない分割例

1. SWIFT メッセージの種類を特定する

2. メッセージをパースする

3. メッセージに関連する取引をデータベースから取得する

4. ...

なぜアルゴリズムのステップごとの分割が良くないのか？

顧客中心の自動受け入れテストを追加できないから（顧客中心のエンドツーエンドで機能が実装されていないから）

フィードバックが受けられないから（プロダクション環境で利用できない = 利用できる価値がない、欠陥やリスクが隠れている状況だから）

プロダクト全体思考を阻害するから（コンポーネントチームのダイナミクスと問題を招くから）

e.g. PBI を前述の「良くない分割例」のように分割していて、ステップ「メッセージを特定する」が MessageIdentifier コンポーネントに関連付けられている場合に起こること

各ステップに関連するコンポーネントに含まれる顧客要求の「すべて」のバリエーションの「すべて」を定義し、変更する（e.g. 「MessageIdentifier コンポーネントの全ての処理は、全メッセージタイプの特定です。だったら、一度だけ触る方がいい」）

「すべて」はフィードバックを受けるまでわからないはずなのに定義に時間をかけているのがもったいない、という話？🤔

なぜ薄いエンドツーエンドの顧客中心の切り出し方が良いのか？

「購入決済」の全ての可能なバリエーションではないが、非常に細かく、完全な流れだから

インテグレーションできるから

デリバリーできるから

利用できるから

価値を提供できるから

フィードバックを受けられるから（自動受け入れテストの変更が不要だから）