13

私たちは、多くのサブプロジェクトを含むかなり大きなプロジェクトを開始したばかりです。現在、名前付きプロセスは使用していませんが、バックドアから何らかのアジャイル/スクラムのようなプロセスを取り入れたいと考えています。

私が最も力を入れている分野は、プロジェクト全体の良好なバックログを持つことであり、少なくとも私の頭の中では、バックログからいくつかのものを取り出し、より詳細に検討し、合理的な期限まで開発する反復のアイデアです。 .

プロジェクトを分割してバックログに入れるために人々がどのような手法を使用しているのか、そしてバックログが作成されたら、それがどのように維持および順序付けされるのか疑問に思います。また、要素間の関係をどのように維持するか (つまり、これを行う前にこれを行う必要がある、またはこれが 1 つのストーリーであった場合は 5 つになる)

この質問に対する答えがどのように見えるかはわかりません。最も役立つのは、何らかの方法でバックログをオンラインに保持しているオープンソース プロジェクトがあれば、他の人がどのようにそれを行っているかを確認できることです。

私から+1を得る他の何かは、実際のプロジェクトからの実際のユーザーストーリーの例です（「ユーザーがログオンできる」というストーリーは、私のプロジェクトで物事を想像するのに役立ちません.

ありがとう。

4

7 に答える 7

9

ツールを採用する前に慎重に検討することをお勧めします。特に、足を見つけたときに最初はプロセスが流動的である可能性が高いように思われるためです。私の感じでは、ツールはこの段階であなたを可能にするよりもあなたを制約する可能性が高く、あなたはそれが物理的な空間で良いカードの壁に代わるものではないことに気付くでしょう。代わりに、目前のタスクに集中して、本当に必要だと感じたときにツールを入手することをお勧めします。その段階までに、要件を明確に把握できる可能性が高くなります。

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

ストーリーを特定するときは、常にユーザーにとって意味のある言葉で表現するようにしてください。表面化された機能の一部（おそらく小さな部分）です。ユーザーに示すことができなかった技術的な詳細についての記事を書くことに自分自身を陥らせないでください。

ストーリーをスケジュールするときのスキルは、最初に最も知らないことを優先すること（やりたいことではなく、学びたいことを計画すること）を試みると同時に、コア機能を開発できるストーリーから始めることです。後続のストーリーを使用して、機能（および技術的な複雑さ）をラップします。

パズルの一部を後で残すことができると確信している場合は、その詳細に汗を流さないでください。後で必要になる大きな会話を表す1枚のストーリーカードを書いて、より重要なもので。今後のサイズを把握する必要がある場合は、プランニングポーカーと呼ばれるワイドバンドデルファイ推定手法をご覧ください。

Mike Cohnの本、特にアジャイルな見積りと計画は、この段階で大いに役立ち、作業に役立ついくつかのテクニックを提供します。

幸運を！

于 2008-09-23T11:07:13.127 に答える
4

DanielHonig のように、RallyDev も (小規模で) 使用しており、少なくとも調査するのに役立つシステムのように思えます。

また、開発のユーザー ストーリー手法に関する優れた本は、Mike Cohn によるUser Stories Appliedです。まだ読んでいない場合は、必ず読むことをお勧めします。それはあなたの多くの質問に答えるはずです。

于 2008-09-23T02:01:27.680 に答える
2

ここにいくつかのヒントがあります: RallyDev を使用します。
要件が含まれるパッケージのビューを作成しました。大きなストーリーはエピックとしてラベル付けされ、対象となるリリースのリリース バックログに配置されます。エピックに子ストーリーが追加されます。ストーリーを非常にきめ細かく保つことが最善であることがわかりました。粗粒度のストーリーでは、ストーリーを現実的に見積もって実行することが難しくなります。

したがって、一般的に：

  1. リリースごとに整理する

  2. 反復を 2 ～ 4 週間に保つ

  3. プロダクト オーナーとプロジェクト マネージャーがリリース バックログにストーリーを追加する

  4. 開発チームは、Tシャツのサイズ、ポイントなどに基づいてストーリーを見積もります.
  5. 春の計画会議で、開発チームはリリース バックログからイテレーションの作業を選択します。

これは、私たちが過去 4 か月間行ってきたことであり、うまく機能することがわかりました。ストーリーのサイズを小さく細かく保つことが非常に重要です。

ユーザー ストーリーを評価するための Invest と Smart の頭字語を思い出してください。良いストーリーは次のようになります。

頭いい：

S - 具体的 M - 測定可能 A - 達成可能 R - 関連 T - タイムボックス

于 2008-09-23T01:05:55.537 に答える
2

これがあなたが探しているものかどうかはわかりませんが、それでも役立つかもしれません。Codesqueeze の Max Pool は、彼の「アジャイル ウォール」を説明するビデオを公開しています。必ずしもあなたの質問に関係があるとは限りませんが、彼のプロセスを見るのはクールです。

私のアジャイルの壁 (プラスいくつかのトリック)

于 2008-09-22T23:40:34.727 に答える
1

まず、Keep it Simple ..追跡（およびバックアップ）付きの共有スプレッドシートを使用します。バックログを一貫した状態に維持するのにますます時間がかかるようなスケーリングまたは同期の問題が発生した場合は、トレードアップしてください。これにより、支出/再トレーニングのコストが自動的に検証され、正当化されます。

私はThoughtworksからMingleについていくつかの良いことを読みました。

于 2008-09-23T01:47:17.713 に答える
1

これらの回答の多くは、使用するツールに関する提案でした。ただし、実際には、プロセスは、プロセスの実装に使用するツールよりもはるかに重要になります。方法論を喉に詰め込もうとするツールには近づかないでください。ただし、新しいツールを使用して古い非アジャイルプロセスを単純に実装することにも注意してください。プロセスのツールを決定する際に考慮すべきいくつかの強力な事実を次に示します。

  1. ソフトウェアツールを使用した不適切なプロセスは、不適切なソフトウェアツールの実装につながります。
  2. プロセスは、管理しているグループに基づいて変更されます。重要なのはプロセスではなく、人です。彼らがうまく機能できる何かを実装すれば、あなたのプロジェクトは成功するでしょう。

そうは言っても、ここにあなたを助けるためのいくつかのガイドラインがあります：

  • 文書化されたプロセスの純粋な実装から始めます。
  • 反復を小さくし、
  • 各反復がチームと話し合い、チームが何を変更するかを尋ねた後、意味のある変更を実装します。

大規模な組織では、SCRUMを使用している場合は、カスケードスタンドアップメカニズムを使用します。スクラムマスターは彼らのチームと会います。次に、スクラムマスターは6〜9のスタンドアップで会合し、スーパースクラムマスターがスカムマスターのスクラムから次のレベルへのアイテムの報告を担当します...など。

階層の最上位レベルでは、毎週スーパースクラムミーティングを開催するだけで十分な場合があります。

于 2011-09-20T02:53:28.507 に答える
1

これは、いくつかのアイデアを提供する可能性のある同様の質問に対する私の回答です

BAを助けて！ユーザー ストーリーの管理 ...

于 2011-02-03T16:08:27.827 に答える