web-dev-qa-db-ja.com

スクラムで製品バックログを作成する際のベストプラクティス

私はスクラム、プロジェクト管理全般に不慣れです。特に、すべてのWebアプリにある標準的な機能について、機能またはサブ機能（その機能を作成するためのタスクリストですか）を何と呼ぶか​​を決定するのに問題があります。

だから私は人々が典型的なウェブサイトソフトウェア（ユーザー、プロファイル、管理者、フロントエンド）の製品バックログを作成する方法のベストプラクティスを探しています。

これを例として考えます。

 - feature: home page

 - feature: contact us page

 - feature: admin panel
            - create user
               + create database (tasklist)
               + write stored procedures (tasklist)
            - delete user
            - add content
            - delete content

 - feature: subscribe 
            - create subscribe page

また、粒度が小さすぎるとどうなりますか？

scrumproductbacklog
6
tommy

私たちがしていることは、トップレベルを「ユーザーストーリー」にすることです。各ユーザーストーリーは、機能が完了したときにユーザーが受ける特定の利点を説明する必要があります。各ストーリーは、それ自体で機能の有用な部分を説明する必要があります。例えば、

  • 「ユーザーはWebサイトに移動して、当社に関する基本的な情報を入手できます。」
  • 「ユーザーはWebアプリを使用してサブスクリプションを管理できます。」
  • 「システム管理者は、Webページを使用してユーザーを追加、削除、および編集できます。」
  • 「システム管理者は、Webページを使用してコンテンツを追加および削除できます。」

タスクは、ストーリーが完全であることを確認するために実行する必要があるアクションを記述します。 「ユーザーは私たちの会社に関する基本的な情報を得るためにウェブサイトにナビゲートできる」ので、私は次のようなものを持っているかもしれません：

  • 「ホームページ作成」
  • 「「お問い合わせ」ページを作成し、ホームページからリンクします」
  • 「「オフィスの場所」ページを作成する」
  • 「「採用情報」ページを作成する」
  • 「オフィスの場所とキャリアページにリンクするナビゲーションバーを作成し、将来の機能のためのスペースを設ける」
5
Ethel Evans

難しく考えすぎだよ。たくさん。

スプリントごとに、チームは「このスプリントをどうするのか」という質問に直面します。理想的には、バックログアイテムは1つのスプリントで実際に完了することができるサイズである必要があり、すべてを整理して追跡することは悪夢になるほど小さくない必要があります。優先度の低い非常に大きなアイテムを用意してもかまいません。優先度リストの上部に近づくと、アイテムを小さなアイテムに分割します。

機能、サブ機能、タスク。誰も気にしない？チームが各スプリントの最優先項目を識別してそれらを完了することができる限り、PBはその仕事をしています。

1
Dave

ストーリーをテストする方法の手順が含まれていると、ストーリーの定義が簡単になります。タスクは、そのストーリーを可能にするためにあなたがしなければならないことです。

これをテストする手順は重要です。ストーリーを正直に保ち、実装に行き詰まることなく、私たちが話していることについて期待を設定するのに役立ちます。一般的に、ストーリーは簡単に見積もることができ、短納期で実装できるように、本当に軽くすべきです。

"ユーザーは製品または当社のWebサイトの問題を報告できます"は、 "お問い合わせページに移動してフォームに入力します。受信トレイでお礼のメールを確認してください。 "タスクと要件については多くのことを推測できます（メールアドレスを収集してメールサーバーを設定する必要があります）。見積もりの​​時期です。

0
bryanbcook

私が働いている場所では、ユーザーストーリーの形式は次のようになります。

Xとして、私はZだからYをやりたいです。

X =何らかのアクションを実行したいアクター。 Y =実行するアクション。 Z =代替案を検討できるように、このアクションを希望する理由。

タスクは通常、私が覚えているように、数時間未満で実行できる項目です。一部のページは、既に作成されている他のページと同様の単純なタスクと見なされ、ページの作成とパッケージ化に20分もかからないため、ページの作成の詳細はページの内容などに多少依存します。他の環境への変更を促進するための変更。

私の頭にあるスクラムの一部は、最初のいくつかのスプリントは、チームに有効なものは別のチームに有効である可能性が低いため、チームに有効なものに関して速度とブレークダウンがうまくいくところです。

0
JB King