スクラムチームは、計画会議で開発/インフラストラクチャタスクをどのように考慮しますか？
一見、エンドユーザーの価値を提供しないため、ユーザーストーリーのようには見えません。
ただし、それらをタスクとして特定のユーザーストーリーに添付することも意味がない場合があります。たとえば、タスクが「Bambooのセットアップ」であるとします。チームが手動でビルドおよびデプロイできるため、ユーザーストーリーを完了するためにそのタスクは必要ありません。そのため、ユーザーストーリーを完了するのにこのタスクは必要ないため、ユーザーストーリーに添付しても意味がありません。
したがって、これは、これらのタスクがユーザーストーリーになることを示唆しています。しかし、その後、チームストーリーがそれらを指し示している場合、プロダクトオーナーがバックログに対して速度を知りたいので、これに奇妙な速度が変更されます。
回答:
それらは実際にはユーザーストーリーではありません。それらは利害関係者の物語です。ソフトウェアが実際にユーザーから直接支払われない限り、ストーリーが完全にユーザーの利益のために作成されることはまれです。
いくつか例を挙げます。
ほとんどの技術的なストーリーは実際にビジネス上の利点を提供しますが、ユーザーにとってはめったにありません。別の方法でそれらをフレージングすると役立ちます。私は通常、Chris MattsのFeature Injectionテンプレートを使用します。
In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.
これにより、開発チームを含むあらゆる種類の利害関係者が明示的に認識されます。これで、技術的なストーリーもフレーズでき、ビジネス上の利点を引き出すことができます。
In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.
私はこれについていくつかのブログ記事を書きました：それらはユーザーストーリーではなく、機能注入と技術的なストーリーの処理です。彼らが助けてくれることを願っています。
速度は、（ドラッグではなく）有用な作業を行うチームの能力の尺度です。インフラストラクチャタスクは、間接的にではありますが、長期的にはチームをより効率的にすることにより、エンドユーザーの価値をもたらします。これらのことをユーザーストーリー（この場合はユーザーは開発チーム）として追跡し、適切に優先順位を付けることに問題はありません。顧客とのコミュニケーションが良好なプロダクトオーナーは、成果物を中断することなく、このようなタスクがどこに適合するかを把握できる必要があります。
徐々にそれらを行います。
利害関係者がそれを望んでいないなら、それを話にしないでください。少しずつ注意してください。たとえば、初めて手動で展開するとき。2回目は、少し自動化します。3回目は、もう少し自動化します。最終的に、ビルドは最大の問題ではないため、他のことに集中します。
開発者に焦点を当てたこれらのタスクは、最初はもっと多くありますが、それで問題ありません。速度（ストーリーで測定）が低下します。それは状況の正しい表現です。しかし、あなたは常にいくつかを持っているので、チームがプロセスを改善するために必要なことをする習慣を身に付けることが重要です。
IMHOの理想的なアプローチは、インフラストラクチャの取り組みを、最初に価値があるユーザーストーリーの下のタスクとして配置することです。あなたが言及したように。
例を挙げましょう。手動で構築および展開することは、それが継続的な努力であり、完了の形がないことを意味します。無期限に存在します。
同じことが、以前は手作業で行われていた典型的なアプリケーションの労力の一部を自動化するコードにも言えます。この取り組みをユーザーストーリーの下のタスクとして定義すると、完全が定義されます。その性質上、エンドユーザーにとって価値があります。
確かにアプリケーションを構築してデプロイすることはできますが、それはバックログを介して正式に追跡されない日々のタスクの一部になり、これはすべて意味がなくなります。
ユーザーストーリーは、ユーザーの観点からビジネス価値を定義します。そのため、インフラストラクチャタスクは一般に「無駄」と見なされます。それは彼らが必要ではないという意味ではありません。より多くのインフラストラクチャタスクを実行すると、ビジネス価値が低下することを意味します。そのため、インフラストラクチャのタスクはユーザーストーリーと見なされるべきではなく、ユーザーストーリーに添付されるべきではありません。
計画会議では、チームは次のスプリントでどのようなインフラストラクチャタスクが絶対に必要になるかを考慮する必要があります。これらのインフラストラクチャタスクを念頭に置いてコミットメントが行われます。速度はチームがどれだけのビジネス価値を提供できるかを測定するため、正しい結果であるチームの速度に影響します。
ユーザーストーリーを、エンドユーザーの価値を提供しなければならないとは決して思いませんでした。それは一般的かもしれませんが、ユーザーストーリーの処理方法ではありません。これらのタイプのタスクはスパイクと見なされることもありますが、他のユーザーストーリーと同様にポイントが推定される定期的なユーザーストーリーもあります。
私が見たところから、インフラストラクチャの多くは与えられたものと考えられています。これには次のようなものが含まれます。
私が取り組んできたほとんどの方法論は、あまり注意を払っていません。これらは、Release 0と呼ばれるものを形成します。これらのことは、開発を開始する前に適切な場所にあるべきです。ストーリーの作成を開始すると、これらの変更はプロセスの改善として追跡できます。
開発チームが意見を述べることもありますが、これらの項目のほとんどはプロジェクトサポートチームが処理する必要があります。複数のプロジェクトでこれらのアイテムを標準化すると、組織にとって大きな見返りが得られます。
以下を考慮してください。
既存の製品スイートに主要な機能を追加するスクラムチーム。
開発技術/ツール/ユーティリティをアップグレードして、エンジニアリングのベストプラクティスに基づいて最新の状態を維持する必要があります。
リリースの過程でスプリントの問題を解決できるように、この作業でリリースをフロントロードすることは理にかなっています。
ビジネスはこれらのアイテムから間接的な価値を得るので、透明性のために、これらは製品バックログアイテム（PBI）であることをお勧めします。
チームはこれらのアイテムのサイズを決定し、PBIと同様に扱います。
私にとってこの問題は、他のビジネス中心のPBIの下にタスクとしてこの作業を隠す方法を見つけようとして時間を無駄にしたくないという事実に要約されます。
この種のインフラストラクチャー作業によってPBIのサイズが歪曲されるのは望ましくありません。何が行われているのかを見て、私が何を払っているのかを理解したいです。
また、質の高いソリューションを提供するために必要なインフラストラクチャに投資することで、ビジネスのコミットメントをチームに理解してもらうことも価値があると思います。
XPでは、すべてのツールとインフラストラクチャがセットアップされている「反復ゼロ」を推奨しています。これらのストーリーを書くことはオプションですが、おそらく良い考えです。インフラストラクチャ（インクリメンタルビルド、自動テストおよび展開、通知など）をテストできることは有益です
私たちのチームでは、次のことを行います。
ステップ2が最も重要です。アジャイルプラクティスのように、スクラムではタスクを達成するためにできる限り少ないことを試みます。不必要な仕事をすることにあなたの人生を無駄にしない方法としてそれを考えてください：私の経験は、「クールになる」ものの50％が長い目で見れば放棄され、維持されないことを示しています。