垂直的なユーザーストーリーの短所

アジャイルアプローチはに仕事を構築することである垂直ユーザーストーリーと焦点を当てたが、完全にからのアプリケーションの一部を機能実現エンドツーエンド。これはソフトウェアを構築するための新しいアプローチなので、なぜこれが横長のストーリーよりも優れているかについて多くの文献を読みましたが、このアプローチの欠点についてはあまり知りません。

私はすでにアジャイルクールエイドを飲みましたが、ケーキを垂直にスライスすることは水平なスライスよりもはるかに優れていることに同意します。ここに私が思いつくかもしれない欠点の短いリストがあります：

• 開発者はストーリーの開発に必要なすべてのテクノロジー（UI +サービスレイヤー+データアクセス+ネットワーキングなど）を理解する必要があるため、最初は機能の実装に時間がかかる場合があります。
• 全体的なアーキテクチャ設計（アプリケーションのバックボーンをクレーティングする）はこのマントラに実際には適合しません（ただし、全体的なアーキテクチャを開発/変更することはユーザーストーリーの一部であると主張する人もいます）

ユーザーストーリーを垂直にスライスすることのその他の欠点は何ですか？

注：この質問をする理由は、チームに「垂直方向」のストーリーを書き始めるよう説得しようとするためであり、可能なトレードオフを事前に提示して、彼らが勝つことができるようにしたいのです。彼らが欠点に直面しているとき、アプローチを失敗とは考えないでください。

長期的な不利な点は知りません。短期的には、この種の開発に不慣れなチームにとっての主な欠点は、ある程度の慣れと学習が必要になることです。

垂直方向に作業するための最も効率的な方法は、フルスタックの開発者を用意することです。このようにして、ストーリーは通常1人（または複数、ただしパイプラインタスクなし）で実行できます。明らかに、これには開発者がスタック全体で垂直に作業する必要があります（Webアプリケーションの場合はhtmlからデータベースへ）。

チームがバーティカルストーリーの作業に慣れていない場合、チームは反対のことを行う可能性が非常に高くなります。各人は、アプリケーションの1つの層/層の知識しか持っていません。バーティカルストーリーを導入すると、チームはそれらをレイヤーに対応するタスクに分割し、タスクを別の人に分配することが期待できます。これは非常に非効率的です。

これに関して私が与えることができる最善のアプローチは、長期的な目標が完全に異なることを明確にしながら、最初にこのパイプライン処理を許容することです。信頼を築き、最終的に人々が完全に独立することを可能にするために、層のペアのチームメンバーにプログラムをペアにさせます。

このアプローチが技術的負債をもたらすという他の答えには同意しません。それは可能ですが、他のアプローチも同様です。

私はこの正確な質問についてたくさん考えてきました。

個人の責任によるスライスとチームの責任によるスライスを区別することが重要だと思います。この答えは主にスライスチームに焦点を当てます。

背景について：私は、フルスタック開発者、シングルティア開発者、垂直（フルスタック）チーム、水平（シングルティア）チーム、および斜めのチームと一緒にプロジェクトに携わってきました。対角線のチームとは、ストーリーに必要なすべての層を含むが、必ずしもシステムのすべての層を含む必要はなく、場合によっては同じ層に焦点を当てた複数の開発者も含むことを意味します。言い換えれば、精神的には垂直ですが、外観や実装の詳細はやや水平です。

最近、私は水平チームから対角線（ほぼ垂直）チームに移行したグループで働いています。同じグループの人々が2つの異なる方法で連携するのを見るのは、特に教育的でした。これにより、いくつかの利点と欠点が明確になります。

これまでの私の意見を以下の要約比較でまとめます。

水平チーム

利点：

• 懸念と疎結合の層の適切な分離を促進します
• はるかに簡単なワークロード分散管理
• 専門の技術リードが管理しやすい
• 階層内コラボレーション、ベストプラクティス、プライド、卓越性の文化を育む
• 自然/緊急のコミュニケーションパターンに合わせる

短所：

• 層の分離につながり、層間の通信を妨げる可能性がある
• 軽減されない場合は、層の「バブル」カルチャを有効にします
• ジェネラリストのリーダーシップを活用するのが難しい
• ジェネラリストを妨げる

垂直/対角チーム

利点：

• 1つのチーム内のユーザーストーリーのすべての部分（「ワンストップショップ」）
• 具体的には、単一のスプリントでn層のストーリーを提供するのを支援します（本当に必要ですか？）
• 階層間のコラボレーションとジェネラリストスキルの成長を促進します
• ジェネラリストをサポート

短所：

• はるかに難しいワークロード分散管理
• 懸念事項と密接に結合された階層の分離が不十分
• 層内のコミュニケーションを削減することによって専門化を妨げます。水平/専門家の行動を軽減することなく、この構造から卓越性の文化がどのように生まれるかを確認することは困難です

チームのメンバーシップが万能なソリューションを持っているとは思いません。ただし、垂直化チームは、一般化を必要とする組織に適しています。エンジニアがジェネラリストであり、フルスタックで作業するのが好きな場合、それは垂直チームを検討するかなり良い理由です。水平方向のチームは、スペシャリストを必要とする組織に適しています。エンジニアがスペシャリストである場合、それは水平的なチームを検討するかなり良い理由です。

他の人が述べたように、他の方向をスライスする二次構造/動作は、いずれかのシステムの欠点を軽減するのに役立ちます。興味深い緩和要因の1つは、スプリント期間です。スプリントが短いと、水平チームの短所の一部が許容できるようになります。今週バックエンドを構築し、来週フロントエンドを構築できるとしたら、それで十分な速度でしょうか？

これらの提案された原則のいくつかを実際の問題に適用するには...私が取り組んできた非常に実際のSaaS開発チームにとって水平スライスは非常にうまく機能し、すべての層で非常に困難な技術的問題を解決しました（私の意見では、専門性が非常に重要である場合）、配信の頻度（および高い粒度/頻度での信頼性）がビジネスの成功に不可欠である場合。この結論は、非常に特定の実際のチームに対するものであり、水平スライシングの優位性に関する一般的な記述ではないことに注意してください。

注意点の1つ：私は、いくつかのまれな例外的なジェネラリストを知っていたとしても、現代のソフトウェア開発の世界では、個人のジェネラリスト能力の主張を信じることに対して、大きな証拠はありません。特に、各層が複雑になり、代替言語/プラットフォーム/フレームワーク/デプロイメントが急増し、それぞれが異なるニーズに対応するようになるにつれて、一般性は確かに高い（垂直？）順序であると感じています。特に最近では、すべての取引のジャックは非常に簡単にどれのマスターにもなり得ません。また、事例によっては、ほとんどの人がかなり専門になりたいと思っていますが、いくつか例外はあります。

私が発見した大きな欠点は、統一されたアーキテクチャーのアプローチに従ってチームがアプリケーションを構築することが困難になることです。

プロジェクトの初期段階では、全員がレイヤーを個別に記述します。ストーリー（および関連するレイヤー）は機能しますが、スプリント終了時に提供された製品を振り返ると、各開発者のアーキテクチャのアイデアのわずかな違いを簡単に確認できます。

この種のことは避けられませんが、ブロッカーではありません。私はこれを2つの方法で戦おうとしました：

1. 各ストーリーを実装する前に、チームと設計に関する長い議論を行う
   • これはすぐに疲れます。多くの場合、誰もが情報に基づいた決定を下すのは時期尚早であり、間違いなくとにかく変更しなければならないことについて議論することになります。
2. 技術的な負債が増えることを念頭に置いて、比較的孤立して開発を進めてください。
   • ここで重要なのは、技術（建築）債務を問題として記録することです。これは返済が必要なものです。
   • 数回のスプリントの後、一貫性のある統一されたアーキテクチャを決定する方が簡単になります。これは、技術的な負債の一部を返済するために強化スプリントを要求する必要がある場合です（既存のコードをリファクタリングします）。または、プロジェクトの次の反復で少しずつ払い戻すこともできます。

それ以外に私が考えることができる他の唯一の問題は、通常、プロジェクトの最初に追加する定型コードがたくさんあることです。垂直スライスストーリーを書くことは、この前提条件のボイラープレートにより、最初の数ストーリーのチームの速度が人為的に低くなることを意味します...しかし、これが最初の2、3のスプリントのみに影響を与えるはずであることに誰もが気づいている限り、すべてが問題ありません。

欠点もわかりませんが、縦のストーリーはうまく実装できません。

私がキャリアを始めたとき、私はXPをやりたいと思っていたチームに参加しましたが、経験はありませんでした。垂直方向のユーザーストーリーを使用するときに、多くの誤りを犯しました。

水平方向の作業を行っているときに遭遇した問題の1つは、機能がレイヤー間でうまく統合されないことでした。APIは、仕様、不足している機能、およびその他の多くの問題に一致しないことがよくありました。多くの場合、の開発者が別の場所に移動したため、それらを待つか、自分で行う必要があります。

垂直ストーリーを実行するように切り替えることで、これらの問題が解決され、統合するための手直しの無駄が減りました/なくなりました。

この作業方法をサポートするXPプラクティスは多数あります。誰もがあらゆる分野で作業できる必要があり、誰もが見つけたバグを修正することが期待されています（集団的コードの所有権）。

バーティカルストーリーに変更を加える場合、慣れていない領域で作業するのは難しい場合があります。ペアプログラミングは、チーム内でペアを組んでいる人を確実につかむことができない場合に役立ちます。ペアプログラミングは、新しいコードベースを使いこなす最も速い方法であることがわかりました。

私たちが見つけたレイヤーに対する強力な所有者がいないと、重複が発生していることがわかりました。これは大きな問題ではありませんでしたが、（サポートする適切なテストを使用して）無慈悲にリファクタリングを確実に実行する必要がありました。

いくつかの問題について触れましたが、バーティカルユーザーストーリーが原因だったとは思いません。実際、それは問題をより明白にしました。切り替え後、チームやアプリケーションレイヤー全体で問題が難読化されることはなくなりました。