ユーザーストーリーではなくタスクに焦点を合わせたチーム
Webフロントエンド、Javaバックエンド、Javaおよびpythonマイクロサービス、DBなどです。ビジネスバリューを表すユーザーストーリーを行う場合、それは主に2〜5の異なる技術タスクに分解され、複数の人が作業します（残念ながら、私たちは機能を横断するのではなく技術専門分野を持っています）問題は、誰もがタスクのみであり、スプリントの最後に、レイヤー間の統合の欠如という問題に遭遇することが多く、ユーザーストーリーがエンドツーエンドで配信されないか、スプリントレビューのすぐ後に多くのバグが表示されます。
誰かがこの種の問題を抱えていましたか？
良いニュースがあります。部門を超えたチームがあります。スクラムガイドでは、部門横断的なチームを次のように定義しています。
部門を超えたチームは、チームに参加していない他のメンバーに依存することなく、作業を完了するために必要なすべての能力を備えています。
誤解しないでください。重複するスキルセットはチームの開発に間違いなく役立ちますが、始めるために必要なものはあります。あなたのようなチームは、常にビジネス価値を提供します。
あなたが直面しているかもしれない課題の1つは、人々が彼らの仕事を完了することに基づいて彼らの成功を測定しているように見えることです。チームはレビューで完成したユーザーストーリーを共有しますか？彼らは、なぜいくつかのバックログ項目の半分を完了できたが、1つを完了できなかったのかを説明するように求められていますか？
POの使用を見た1つのテクニックは、スプリントに1つのアイテムのみを追加することです。アイテムが完了すると、別のアイテムが追加されます。 POは、開発時間と低速の非効率的な使用について責任を負います。これは、忙しさよりも提供された価値を重視していることを強調しています。
WIP制限は、同じことを再実行するもう1つの構造的な方法です。スプリントの目標もそうです。
チームがリードするのは、実際には成功の様子についての単なる調整にすぎないようです。
ユーザーストーリーがある場合、誰かがそれをつかんで、「私はそのユーザーストーリーを実装して妥当な時間内にそれを配信できる」と言うか、または「そのユーザーストーリーは不快に大きな作業の塊であるため、私はタスクA、B、Cが完了したら、ユーザーストーリーを実装できます。」.
ユーザーストーリーを取得する人は誰でもそれを実装する責任があります。その人はサブタスクを作成する必要があります。そして、それらのサブタスクは、すべてのサブタスクが仕様どおりに実装された状態でユーザーストーリーを実装できるように、十分な精度で記述する必要があります。 （ストーリーポイントは分割する必要があります。3つのサブタスクが必要な場合、元のユーザーストーリーにはかなりの数のストーリーポイントがあることは明らかです）。
サブタスクを実装してからユーザーストーリーの実装に失敗した場合、サブタスクはnotがユーザーストーリーに必要なものを提供しているか、十分に仕様化されていませんでした。ユーザーストーリーではなく、タスク自体に関心を持つ人々が委員会によってサブタスクを設計する場合があります。サブタスクを正しく実行する強い動機を持つ誰かがいて、その人がサブタスクを設計し、それがユーザーストーリー全体の責任者になると、より良い結果が得られます。
そして重要なのは、QAがサブタスクを受け入れるときではなく、ユーザーストーリーの責任者がサブタスクを受け入れるときに、サブタスクが通常どおり「配信済み」としてカウントされることです。