大規模プロジェクトのユーザーストーリーの管理

Question

多くのサブプロジェクトを持つかなり大きなプロジェクトを開始しています。私たちは現在どのような種類の名前付きプロセスも使用していませんが、私はバックドアによって何らかの種類のアジャイル/スクラムのプロセスを得ることを望んでいます。

私は、ほとんどのプロジェクト全体のために良いバックログを有し、かつ、少なくとも私の頭の中で、いくつかのものは、バックログから取得され、反復のアイデアは、より詳細に見て、開発されているに焦点を当てされる領域合理的な期限まで

私はバックログに入るためにプロジェクトを中断するために人々がどのようなテクニックを使用しているのか、バックログがどのように維持され、注文されたのか疑問に思っています。要素間の関係がどのように維持されているか（つまり、これが可能になる前にこれを行う必要があります。これは今では5つです）

この質問の回答がどのように見えるかわかりません。どのような方法でバックログをオンラインに保つオープンソースプロジェクトがあれば、他の人たちのやり方を見ることができます。

私から+1になるだろう何か他のものは、実際のプロジェクトから、実際のユーザーストーリーの例（話「ユーザーがログオンできる」私のプロジェクトで私の絵の事を助けていないです。

感謝。

Answer 1

私はツールを採用する前に慎重に考えてみることをお勧めします。特に、あなたの足が見つかるにつれて、あなたのプロセスが最初は流動的であるように思えるからです。私の気持ちは、この段階ではツールがあなたを拘束する可能性が高く、good card-wall in physical spaceの代用品ではないということです。私は代わりにあなたの努力を手近にある仕事に集中させ、実際に必要と感じるときにツールをつかむことを提案します。その段階では、要件の明確なアイデアが得られる可能性が高くなります。

私は今やいくつかのアジャイルプロジェクトを実行しており、スプレッドシートよりも複雑なツールや予算が100万ポンドを超えるプロジェクトでは必要としませんでした。主に、ホワイトボードとインデックスカード（ユーザーストーリーごとに1枚）が十分であることがわかります。

あなたのストーリーを特定する際には、ユーザーに理解される言葉で表現するようにしてください。あなたがユーザーに実証できなかった技術的な細部についての記事を書き留めてはいけません。

ストーリーをスケジューリングするときのスキルは、あなたが最初に知っていること（あなたがしたいことではなく、学びたいことを計画する）に優先順位を付けようとすることです。アプリケーションのコア機能を開発し、その後のストーリーを使用して機能（および技術的な複雑さ）をラップします。

パズルの一部を後で残すことができると確信している場合は、その詳細に汗を流さないでください。必要な大きな会話を表す単一のストーリーカードを書いてください後で、より重要なもので乗り越えてください。何が来るのかを感じる必要がある場合は、planning pokerと呼ばれる広帯域デルファイ推定技術を見てください。

マイク・コーンの書籍、特にAgile Estimating and Planningは、この段階で多くのお手伝いをします。

幸運を祈る！

Answer 2

これはあなたが探しているものかどうかは分かりませんが、まだ役立つかもしれません。コードキースのMax Poolは、彼の「アジャイル・ウォール」を説明するビデオを持っています。必ずあなたの質問に関係します：

My Agile Wall (Plus A Few Tricks)

Answer 3

これはいくつかのヒントです： 私たちはRallyDevを使用します。
私たちの要件が住んでいるパッケージのビューを作成しました。 大きな物語はエピソードとしてラベル付けされ、意図したリリースのリリースバックログに配置されます。子供の話が叙事詩に追加されます。私たちは物語を非常にきめ細かく保つことが最良であることを発見しました。大まかな話は現実的に見積もり、実行することを困難にします。一般的にはそう

：

2. 製品の所有者とプロジェクト マネジャー2-4週間の間 反復をキープリリースで

3. を整理がリリース バックログに話を追加

4. 開発チームの見積もり0123開発チームは、 リリースバックログからの反復のため 仕事を選択 meeetingsを計画春のTシャツのサイズ、 ポイントなどをもとに件の物語...
5. 。

これは、我々は過去4ヶ月間行ってきた、それがうまく機能することがわかってきたものです。物語のサイズを細かく細かく保つことは非常に重要です。

いい話をする必要があり、ユーザーストーリーを評価するための投資とスマート頭文字を覚えておいてください： I - 独立 N - 応相談 V - 貴重 E - 見積る S - 小 T - テスト可能

スマート：

S - 特定 M - 測定可能 A - 達成可能 R - 関連 T - 時間箱入り

Answer 4

私はまず、Keep it Simple ..と言うことで、共有スプレッドシートを使ってトラッキング（とバックアップ）をします。バックログを一貫性のある状態に維持することがますます時間がかかるようなスケーリングや同期の問題がある場合は、トレードアップしてください。これにより、支出/再訓練の費用が自動的に検証され、正当化されます。

私はMingle from Thoughtworksについていくつかの良いことを読んだ。

Answer 5

DanielHonigと同様に、私たちはRallyDev（小規模で）も使用しています。少なくとも調査するのに役立つシステムのようです。

また、ユーザーストーリーの開発方法に関する素晴らしい本は、マイク・コーンのUser Stories Appliedです。私は確かにそれを読むことをお勧めしますまだしていない場合。それはあなたの質問の多くに答える必要があります。

Answer 6

はここにあなたにいくつかのアイデア

Help a BA! Managing User Stories ...

Answer 7

これらの応答の多くは、使用するツールについて提案をしているを与えるかもしれ同様の質問に対する私の回答です。しかし、実際には、プロセスを実装するために使用するツールよりもプロセスが重要になります。あなたの喉の下に方法論を詰め込もうとする道具から離れてください。また、新しいツールを使用して古い非アジャイルプロセスを実装するだけでも気をつけてください。ソフトウェアツールを計装悪いプロセスが悪い ソフトウェアツールimplementionになります

1. ：ここでのプロセスのためのツールを決定する際に考慮すべきいくつかの強力な事実です。
2. プロセスは、管理しているグループに基づいて変更されます。 重要なことは人であり、プロセスではありません。 を実装して正常に動作し、プロジェクトが成功するでしょう。各反復トーク後は文書化されたプロセスの純粋な実装と
   • スタート、
   • 、あなたの反復が小さく：

ここでは、言ったことすべてはあなたを助けるためにいくつかのガイドラインがありますあなたのチームと彼らは何を尋ねます 、変更するだろう、意味のある変更を実装します。

大規模な組織の場合は、SCRUMを使用している場合は、カスケードスタンドアップメカニズムを使用してください。スクラムマスターはチームと出会う。その後、Scrum Masterは6〜9のスタンドアップで会い、Scum-Masterのスクラムから次のレベルへのアイテムの報告を担当するSuper-Scrum-MAster ...など

あなたの階層の最高レベルで毎週のスーパー・スクラム・ミーティングで十分であることがわかります。