このユーザーストーリーをタスクに分割するにはどうすればよいですか
ユーザーストーリーとタスクを作成する方法を理解しようとしています。小さなユーザーストーリーを作成する必要があり、それらは「水平方向のスライス」ではなく、機能の「垂直方向のスライス」であるべきだと述べた記事を読みました。
ユーザーストーリーがあります：
バイヤーとして、後で買い物できるように、ショッピングカートに商品を追加したいと考えています。
私の理解から、このユーザーストーリーを完成させるためにあなたがしなければならないことがタスクであるはずです。タスクも「水平」ではなく「垂直スライス」として作成する必要がありますか。 「ショッピングカートモデルの作成」のタスクを作成する代わりに、「ショッピングカートサービスを更新して商品を追加できるようにする」というタスクを実行します。
しかし、そのタスクでは、タスクが1つしかありません。それは大きすぎますか、別の方法で分解する必要がありますか？ユーザーストーリーのタスクが1つしかないのは悪いことですか。
はい、ユーザーストーリーは達成したいことを示し、タスクはそれを実現する方法を示します。
この場合、例えば。タスクには、「カートUIボタンにアイテムを追加」、「在庫レベルの確認」、「ユーザーアカウントの取得」、「一時的なカートの更新」、「ユーザーアカウントの最終購入リストの更新」などがあります。
それらの可能性のあるものは別のユーザーストーリーの一部である可能性がありますが、tを超えて少しずつiを点けることについてあまり心配することはありません。
垂直方向の機能について話すときは、ユーザーストーリーonlyについて話しています。
タスクは、開発チームが適切と考えるものに分解され、ストーリーを完成させます。
あなたは一生懸命考えすぎていると思います。私があなたのところに来て、「ウェブサイトのショッピングカートを作ってください」と言ったとしましょう。何に行くの？理論や流行語、ドグマをすべて無視して、キーボードに腰を下ろしたらどうしますか？
タスクは、実行する必要があることの単なるリストです。
- テストを書く
- 「カートに追加」ボタンのグラフィックを取得する
- ...
タスクを「スライス」と考えることはあまりありません。これらは、特定のユーザーストーリーを実装するために必要な作業です。そのため、多くの場合、スキーマの変更、新しいクラスの追加、新しいメソッドの追加、ページの追加、ページのスタイル設定などを行います。通常、機能全体を実装するためのタスクが1つあります。それらをユーザーストーリーの縦または横のスライスと考える場合、それらは間違いなくより水平です。
ユーザーストーリーの垂直方向のスライスを取ることは、チームが大きすぎると結論付けた場合、1つの大きなユーザーストーリーをいくつかの小さなユーザーストーリーに分割するために通常使用されます。ポーカーの計画で無限のストーリーポイントの見積もりを取得した場合。
これがショッピングカートの例に当てはまり、芸術的なライセンスが少しあれば、次のようなさまざまなユーザーストーリーに分類できます。
- バイヤーとして、すべての製品ページにバスケットに追加ボタンが必要です。その機能が実装されたら、クリックして製品をバスケットに追加できます。
- バイヤーとして、バスケットに追加する数量を入力して、デフォルトの1を超える数量を追加できるようにします。
- バイヤーとして、ボタンをクリックしたときにバスケットに大量のアイテムを追加して、後でアイテムを購入できるようにしたいと考えています。
- バイヤーとして、自分がバスケットに何を追加したかを確認画面で確認し、エラーを修正できるようにしたいと考えています。
これらは、システムのすべての層を垂直にスライスしたものであり、それぞれがデータストレージ、ビジネスロジック、ユーザーインターフェイス、および機能の完全なシステムではありませんが、機能するために必要なその他すべてを実装しています。
ただし、これは例外であり、不快に大きいユーザーストーリーを処理するためにのみ使用されます。通常、ユーザーストーリーは扱いやすいサイズであり、それを実装するために実行する手順を説明するタスクに分解できます。
場合によります ：）
この話の内容はわかりませんが、額面では、カートに追加することが唯一のタスクであるように思えます。典型的なブラウジング/ショッピングアプリケーションでは、これはAddToCartボタンであり、適切なボタンクリックロジックがあり、ユーザー/カートIDがすでに存在しています。
ユーザーIDとカートを想定できない場合は、このストーリーの下でそれらをタスクとして分解せず、代わりに新しいストーリーとして分離にすることをお勧めします。
カートの存在と動作（および必要に応じてユーザーID）をタスクの内訳で明らかにするだけでは、ユーザーとのより有益で価値のある会話の機会を逃してしまいます（カートはどのように見えますか？どこに表示されますか？カートからアイテムを削除できますか？）。
私の意見では、それはユーザーストーリーの重みに依存します。ユーザーストーリーがアイテムをカートに追加することだけである場合、最初のタスクはこのアプローチのデザインを取得することです。
その後、設計に従ってタスクを分割する必要があります（ログインしていない場合は、ログインしたシナリオなど）。
あなたが製品の所有者またはビジネスアナリストであると想定してはいけません。タスクは、要件ではなく技術的な詳細に焦点を当てているため、POまたはBAによって通常作成されません。
開発またはQAの役割を持っている場合は、タスクを開発チームがユーザーストーリーを完成させるために必要な作業手順を理解するためのツールと考えてください。正式なタスクは、開発チームがストーリーの作業を開始し、最初のストーリーポイントの見積もりを通過するのに適した方法です。
チームによっては、アジャイル追跡ツールでタスクが存在しないか、非常に細かい場合があります。重要なのはその思考プロセスです。一般的に、チームがどの程度詳細に取得したいかに応じて、タスクのいくつかのカテゴリーを見て、考えます。
調査タスク実装タスクコード品質タスクテストタスク
タスクが受け入れ基準またはチームの完了の定義を満たすのに役立たない場合は、それが本当にストーリーの一部であるかどうかを検討してください。