垂直的なユーザーストーリーの短所
アジャイルアプローチは、作業を垂直ユーザーストーリーに構造化し、end-to-endからアプリケーションの集中的であるが完全に機能する部分を提供します。これはソフトウェアを構築するための新しいアプローチであるため、なぜこれが横長のストーリーよりも優れているかについて多くの文献を読みましたが、このアプローチの欠点についてはあまり知りません。
私はすでにアジャイルクールエイドを飲みましたが、ケーキを垂直方向にスライスすることは水平方向のスライスよりもはるかに有利であることにも同意します。ここに私が思いつくかもしれない欠点の短いリストがあります：
- 開発者はストーリーの開発に必要なすべてのテクノロジー（UI +サービスレイヤー+データアクセス+ネットワーキングなど）を理解する必要があるため、最初は機能の実装に時間がかかる場合があります。
- 全体的なアーキテクチャ設計（アプリケーションのバックボーンをクレーティングする）はこのマントラに実際には適合しません（ただし、全体的なアーキテクチャを開発/変更することはユーザーストーリーの一部であると主張する人もいます）
ユーザーストーリーを垂直方向にスライスすることのその他の欠点は何ですか？
注：私がこの質問をするのは、チームに「垂直方向」のストーリーを書き始めるよう説得しようとし、可能性を引き出したいと思っているからです。事前にトレードオフを行うことで、欠点に直面してもアプローチを失敗とは見なしません。
私はこの正確な質問についてたくさん考えてきました。
個人の責任によるスライスとチームの責任によるスライスを区別することが重要だと思います。この答えは主にスライスチームに焦点を当てます。
背景について：私は、フルスタック開発者、シングルティア開発者、垂直（フルスタック）チーム、水平（シングルティア）チーム、および斜めのチームと一緒にプロジェクトに携わってきました。対角線のチームとは、ストーリーに必要なすべての層を含むが、システム内のすべての層を含む必要はないことを意味し、場合によっては、同じ層に焦点を当てた複数の開発者を含むこともあります。言い換えれば、精神的には垂直ですが、外観や実装の詳細はやや水平です。
最近、私は水平チームから対角（ほぼ垂直）チームに移行したグループで働いています。同じグループの人々が2つの異なる方法で連携するのを見るのは特に教育的でした。これにより、いくつかの利点と欠点が明確になります。
これまでの私の意見を以下の要約比較でまとめます。
水平チーム
利点：
- 懸念と疎結合の層の適切な分離を促進します
- はるかに簡単なワークロード分散管理
- 専門の技術リードが管理しやすい
- 階層内コラボレーション、ベストプラクティス、プライド、卓越性の文化を育む
- 自然/緊急のコミュニケーションパターンに合わせる
短所：
- 層の分離につながり、層間の通信を妨げる可能性がある
- 軽減されない場合は、層の「バブル」カルチャを有効にします
- ジェネラリストのリーダーシップを活用するのが難しい
- ジェネラリストを妨げる
垂直/対角チーム
利点：
- 1つのチーム内のユーザーストーリーのすべての部分（「ワンストップショップ」）
- 特に、単一のスプリントでn層のストーリーを提供するのに役立ちます（ただし、本当に必要ですか？）
- 階層間のコラボレーションとジェネラリストスキルの成長を促進します
- ジェネラリストをサポート
短所：
- はるかに難しいワークロード分散管理
- 懸念事項の分離と密結合層を可能にします
- 層内のコミュニケーションを削減することにより、専門化を妨げます。水平/専門家の行動を軽減することなく、この構造から卓越性の文化がどのように発生するかを確認することは困難です
チームのメンバーシップが万能なソリューションを持っているとは思いません。ただし、一般化を必要とする組織にとっては、垂直チームの方が適していることは非常に簡単に思えます。エンジニアがジェネラリストであり、フルスタックで作業するのが好きな場合、それは垂直チームを検討するかなり良い理由です。水平方向のチームは、スペシャリストを必要とする組織に適しています。エンジニアがスペシャリストである場合、それは水平的なチームを検討するかなり良い理由です。
他の人が述べたように、他の方向をスライスする二次構造/動作は、いずれかのシステムの欠点を軽減するのに役立ちます。 1つの興味深い緩和要因は、スプリント期間です。スプリントが短いと、水平チームの短所の一部が許容できるようになります。今週バックエンドを構築でき、来週フロントエンドを構築できるとしたら、それで十分な速度でしょうか？
これらの提案された原則のいくつかを現実世界の問題に適用するには...水平スライスは、非常に現実的なSaaS開発チームが配信の頻度（および高い粒度/頻度での信頼性）がビジネスの成功に不可欠であるすべての層（専門化が私の意見では非常に重要である）で非常に困難な技術的問題を解決します。この結論は非常に特定の-水平スライシングの優位性に関する一般的な声明ではなく、世界のチーム。
注意点の1つ：現代のソフトウェア開発の世界では、かなりの証拠がない個人がジェネラリストの能力を主張していると信じる傾向があるのですが、まれに例外的なジェネラリストをいくつか知っています。特に、各層が複雑になり、代替言語/プラットフォーム/フレームワーク/デプロイメントが急増し、それぞれが異なるニーズに対応するようになるにつれて、一般性は確かに高い（垂直？）順序であると感じています。特に最近では、すべての取引のジャックはどれも簡単にマスターになることはできません。また、事例によっては、ほとんどの人がかなり専門になりたいと思っていますが、いくつか例外があります。
長期的な不利な点は知りません。短期的には、この種の開発に不慣れなチームにとっての主な欠点は、ある程度の慣れと学習が必要になることです。
垂直方向に作業する最も効率的な方法は、フルスタックの開発者を用意することです。このようにして、ストーリーは通常、1人（または1人以上パイプラインタスクなし）で実行できます。明らかにこれには、開発者がスタック全体で垂直に作業する必要があります（Webアプリケーションの場合はhtmlからデータベースへ）。
チームがバーティカルストーリーの作業に慣れていない場合、チームは逆のことを行う可能性が非常に高くなります。各人は、アプリケーションの1つの層/層の知識しか持っていません。垂直的なストーリーを紹介する場合、チームがそれらをレイヤーに対応するタスクに分割し、タスクをさまざまな人々に分配することを期待できます。これは非常に非効率的です。
これに関して私が与えることができる最善のアプローチは、長期的な目標が完全に異なることを明確にしながら、最初はこのパイプライン処理を許容することです。信頼を築き、最終的に人々が完全に独立することを可能にするために、レイヤーペアプログラム全体のチームメンバーがいる。
このアプローチが技術的負債をもたらすという他の答えには同意しません。それは可能ですが、他のアプローチも同様です。
私が見つけた大きな欠点は、統一されたアーキテクチャーのアプローチに従ってチームがアプリケーションを構築することが困難になることです。
プロジェクトの初期段階では、全員がレイヤーを個別に作成します。ストーリー（および関連するレイヤー）は機能しますが、スプリント終了時に提供された製品を振り返ると、各開発者のアーキテクチャのアイデアのわずかな違いを簡単に確認できます。
この種のことは避けられませんが、ブロッカーではありません。私はこれを2つの方法で戦おうとしました：
- 各ストーリーを実装する前に、チームと設計に関する長い議論を行います
- これはすぐに疲れます。多くの場合、十分な情報に基づいた決定を下すのは時期尚早であり、その後、間違いなくとにかく変更する必要のあることについて議論することになります。
- 蓄積していくことを念頭に置いて、相対的に孤立して開発を進めてください技術的負債。
- ここで重要なのは、技術（建築）債務を問題として記録することです。これは返済が必要なものです。
- 数回のスプリントの後、一貫性のある統一されたアーキテクチャを決定するのが簡単になります。これは、技術的な負債の一部を返済するために強化スプリントを要求する必要がある場合です（既存のコードをリファクタリングします）。または、プロジェクトの次の反復で少しずつ払い戻すこともできます。
それ以外に私が考えることができる他の唯一の問題は、通常、プロジェクトの最初に追加する定型コードがたくさんあるということです。垂直スライスストーリーを書くことは、この前提条件のボイラープレートのために、最初のいくつかのストーリーでのチームの速度が人為的に低くなることを意味します...
欠点もわかりませんが、縦のストーリーはうまく実装できません。
キャリアを始めたとき、XPをやりたいと思っていたチームに参加しましたが、経験がありませんでした。垂直的なユーザーストーリーを使用するときに、いくつかのミスをしました。
水平方向の作業を行っているときに遭遇した問題の1つは、機能がレイヤー間でうまく統合されないことでした。 APIは、仕様、不足している機能、およびその他の多数の問題に一致しないことがよくありました。多くの場合、の開発者が別の場所に移動したため、それらを待つか、自分で行う必要があります。
バーティカルストーリーの実行に切り替えることで、これらの問題が解決され、統合するための手直しの無駄が減りました。
この作業方法をサポートするXPプラクティスは多数あります。誰でも任意の領域で作業できる必要があり、誰もが見つけたバグを修正することが期待されます（ 集合コード所有権 ）。
バーティカルストーリーに変更を加える場合、慣れていない領域で作業するのは難しい場合があります。 ペアプログラミング 自信がない場合は、チーム内でペアを組んでいる人を確実につかむことができます。ペアプログラミングは、新しいコードベースを使いこなすための最速の方法であることがわかりました。
私たちが見つけたレイヤーに対する強力な所有者がいないと、重複が生じていることがわかりました。これは大きな問題ではありませんでしたが、 Mercilessly Refactorless （適切なテストをサポートして）を確実に実行する必要がありました。
いくつかの問題について触れましたが、垂直ユーザーストーリーが原因だったとは思いません。実際、それは問題をより明白にしました。切り替え後、チームやアプリケーションレイヤー全体で問題が難読化されなくなりました。