7

私たちは現在の仕事でアジャイル開発を試みており、ほとんどの部分で成功しています。主な問題は、プロジェクトの開発者がスプリントの最初に要件を常に待っていて、最後まで物事を取り下げるために急いでいることだと思われます。要件を提供しているビジネスアナリストは、要件を達成するために常にノンストップで作業しています。

編集:追加情報: 私たちは、内部使用のためにCOTSアプリケーションをカスタマイズしています。私たちの「ユーザーストーリー」は、特定のスプリントでカスタマイズするアプリケーションの部分と、内部で統合するシステムで構成されています。さまざまなシステムとの統合は、すぐに作業を開始できるため、通常はかなりうまく機能します。「x画面のカスタマイズ」は、開発者がそれから何もできないため、主な問題領域です。BAから要件を取得するまで待ってから、実際に何かを実行する必要があります。

編集:より多くの洞察/混乱おそらく: これは大幅にカスタマイズされているCOTS製品であるため、問題の一部はカスタマイズされている画面がすでにそこにあることであるかどうか疑問に思います。人々は、ユーザーストーリーは「Xを実行する画面を作成する」の線に沿っているべきだと提案しています。それはすでに行われています。たぶん、これらの要件に対してユーザーストーリーを作成する良い方法はありません...たぶん、これはまったく新しい質問である必要があります。

4

10 に答える 10

9

待ってはいけません。最小限の要件に基づいてプロトタイプを作成し、製品の所有者からできるだけ早くフィードバックを受け取ります。多くの場合、彼らはとにかく彼らが何を望んでいるのかを知りません-あなたが彼らに出発点として具体的な何かを示すことができれば、あなたは有用なフィードバックを得る可能性が高くなります。また、実際の要件をよりよく理解できれば、プロトタイプの開発からすでに多くの洞察を得ることができます。

于 2008-09-23T19:12:43.753 に答える
4

私があなたの状況を正しく理解していれば、遅れているのは BA です。あなたが試すことができる2つのことがあります。

  1. 小さなスプリントまたは小さな要件チャンクを試してください。いずれにせよ、BA の作業はより簡潔で管理しやすいものにする必要があります。

  2. やり直しやバグスカッシュのためにインターレーションを行います。これにより、BA は時代を先取りすることができるようになるはずです。

ただし、BA が要件を追加する前に以前の要件を「野生」で確認する必要があるという問題がある場合は、より大きな問題が発生します。:)

于 2008-09-23T19:14:29.430 に答える
3

以前のポジションでは、企業顧客に 1 週​​間程度先を急ぐように依頼することで、これを管理していました。確かに、これはアジャイルの厳密な解釈の一部から外れていますが、物事は非常に簡単になりました。テストとビジネスの両方を開発から 1 週間か 2 週間休みます。したがって、開発者がイテレーション 2 に取り組んでいる間、テストは IT1 から出てきたものに取り組み、ビジネスは IT3 に取り組んでいます。アクティブな開発が常に優先されたので、ストーリーが特に柔軟な場合 (つまり、ビジネスがイテレーションの途中で修正に多くの時間を費やさなければならなかった場合) は失敗することもありましたが、全体的にはうまく機能しました。

質問者の更新に対応するための更新

それらはストーリーとして自立していないように思えます。BA チームはストーリーの書き方を再評価する必要があるかもしれません。つまり、カスタマイズされた X スクリーンで「物語を語る」ことはできません。理論的には、ストーリーは「ユーザーが画面 X に移動すると、floozit を変更 (および保存) できるはずです」のようなものにする必要があります。

于 2008-09-23T19:13:46.607 に答える
2

BA がスプリントのユーザー ストーリーをタイムリーに提供していないようです。

あなたの言うことから、スプリント計画セッションはないと思います。

スクラムの大きな信条の 1 つは、開発チームがスプリントごとに作業する内容に責任を持つことであることを考えると、これはあまりアジャイルではないように思えます。(-:

短いスプリントがあることは別として。

于 2008-09-23T19:14:28.743 に答える
1

「ユーザー ストーリー」は今後の会話のプレースホルダーなので、顧客の前に出て質問します。それがBAの仕事なら、火をつけてください;-)

于 2008-09-23T19:40:26.013 に答える
1

ユーザー ストーリーが不完全です。「X 画面のカスタマイズ」はタスクであり、要件や完了基準は記述されていません。ユーザー ストーリーは、「ナンシーが在庫内のアイテムに関連する注文書を参照できるようにする」のようなものにする必要があります。次に、それをスプリント中に取り組むことができるタスクに分解します。

BA が実行可能なユーザー ストーリーを作成したら、それを製品バックログに追加し、優先順位を付けて、上位のバックログ項目のスプリントを計画します。BA は、ユーザー ストーリーを開発し、スプリントとは関係なくバックログに追加する必要があるため、ブロックされることはありません。スプリント中、タスクは完了し、ユーザー ストーリーは変わりません。リリース後、顧客はフィードバックを提供し、それはより多くのユーザー ストーリーとして製品バックログに入ります。

于 2008-09-23T19:48:52.497 に答える
1

さて、いくつかのことが役立つかもしれません - SCRUM プロセスには、Pig Role である Product Owner の概念があり、これは顧客を表します。そのため、PLM またはクライアントの主な連絡先を SCRUM の会議に招待できます。これにより、顧客はプロセスに賛同し、目標に向かって「一緒に」作業するようになります。クライアントへの毎週のビルドが役立つ場合があります。したがって、ウィークリー ドロップの基本的な考え方は、顧客に「進捗状況」を示すことです。したがって、数週間進歩が見られない場合、「なぜ?」という疑問が生じるはずです。そして、それが要件の最終化の欠如によるものであることを説明できるはずです。

お役に立てれば

于 2008-09-23T19:16:47.910 に答える
0

簡単。

スクラムの厳格なルールの外側を考えて、無駄のないルーツに戻ってください: http: //availagility.wordpress.com/2008/04/09/a-kanban-system-for-software-development/ http:// leansoftwareengineering.com/2007/10/31/spreadsheet-example-for-a-small-kanban-team/ http://www.infoq.com/articles/hiranabe-lean-agile-kanban

私を信じてください、あなたがその流れを始めたら、あなたは決して振り返ることはありません。

于 2008-09-24T09:56:44.737 に答える
0

上で述べたように、通常、各スプリントの開始時に、既存のバックログに優先順位を付け、現在のスプリントのいくつかのストーリーを選択する必要があります。開発者向けの十分なユーザー ストーリーがない場合は、開発者を別のプロジェクトに移し、プロダクト オーナーにプロジェクトのまともな (= チームを養うのに十分な大きさの) バックログを作成する時間を与える必要があります。

于 2012-04-17T18:45:05.983 に答える
0

これを処理する方法がいくつかあります。

オプション 1、SCRUM の下では、ソフトウェアの機能に対する要求を含むことになっている製品バックログを管理する製品所有者が必要です。機能が「画面 X のカスタマイズ」のような漠然としたもので構成されていて、それをスプリントに追加することにした場合、スプリント タスクは具体的で分解されたタスクである必要があり、それらのタスクの 1 つは「画面の要件を定義する」である必要があります。バツ'。

デイリー SCRUM で、各チーム メンバーに 3 つの質問をしているときに、その画面変更タスクを担当する開発者が「BA からの要件を待っている間ブロックされています」と言うと、スクラム マスターはできることを行います。それを進めるために。

オプション 2 は、私の意見では、アイテムが少なくとも生産的な作業を行うのに十分なほど十分に定義されるまで、アイテムは製品バックログに入らないというものです。要件が変わることは誰もが知っていますが、要点は、最初から十分な数を用意する必要があるということです。

于 2008-09-23T21:34:51.947 に答える