問題タブ [user-stories]

I've been applying agile for a few months now on my project. However we are seeing a steady problem with our iteration burndowns. We aren't hitting zero each iteration.

The tasks remaining are QA tasks. Things like writing tests, testing, etc.

Now, there is some organizational resistance to the "cross-functional team" idea of agile. Dev's develop for single projects but Testers are shared for multiple projects. Which is quite contrary to the agile idea of Dev's and QA working together.

The fact that my tester's time is split across so many other projects is the cause of our slowdowns. The developers are testing to pick up as much slack as they can, but some tasks are still not getting done.

From what I see, I can do two things:

1. Persuade the organization to move towards "each project having a dedicated QA person"
2. Change my definition of "Done" to not include QA/Testing work. Things would still be unit tested though.

I'd much rather avoid doing #2, since I value the testing collaboration we're doing.

What advice do you have for my predicament?

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

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

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

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

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

ありがとう。

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

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

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

誰かがアジャイルを行おうとしている場合、私はこれに JIRA / Greenhopper を使用する方法を見つけようとしています。私たちはグローバルな開発チームであるため、ここでは分散型の性質が非常に重要です。

当初はスクラムワークスを使用していましたが、チームは、JIRA とスクラムワークスに常に重複した情報があり、冗長であると考えていると不満を漏らしていました。

私たちは Greenhopper を手に入れ、それで問題が解決すると考えましたが、これに関して私が抱えている問題は次のとおりです。

1. JIRA にユーザー ストーリーの概念がない
2. Greenhopper も、ユーザー ストーリー レベルでの集計なしで「タスク」に焦点を当てています。

JIRA でこれを成功させた人はいますか、それともスクラムワークなどの他のツールに戻って、サポート チームが提起したバグに JIRA を使用することを検討する必要があります。

私は友人のビジネス用に小さなアプリを書いています。この機会に、今年の初めに行ったアジャイル プロジェクト管理トレーニングを復習しようと思いました。

私 (そして私の現在の組織だと思います!) は、次のような形をとるユーザー ストーリーの形式で要件を収集することに常に苦労してきました。

[ユーザータイプ] として [機能] が欲しい [なんらかのメリット]

私はいつも最初と最後を見逃して、機能をそのままにしておくように誘惑されます-しかし、これは古い方法で収集する要件になります!

しかし、「私はアジャイルをやっている」と言えるように、単に適合させたいわけではありません....たとえば、ユーザーにアイテムのリストを提示する必要があることがわかっている場合、その理由は自明ですね。

例えば

【店長】として【在庫一覧が見たい】のですが・・・？

[so that] 句を省略するのは通常の慣例ですか?

ユーザー ストーリーの実装に必要な時間をどのように見積もっていますか? それがどれくらいの時間がかかるかを知る前に行ったことがある場合。しかし、それがあなたにとってまったく新しいものである場合はどうでしょうか? 「サプライズ」のためにどれくらいの時間を確保していますか?

スクラムでチャートをバーンダウンするには、いくつかの方法があります。

一部の人々は、スクラムのバーンダウン チャートとして残された未完成のストーリーのストーリー ポイントを使用することを提案しています。

長所: 終了したストーリーのみがチャートを下げる

反対: チャートは最初は下がらず、その後急速に下降します

残りのタスク数を使用することを提案する人もいます

長所: チャートが下に移動し、フィニッシュ ラインの上にあるかどうかを確認できます

コントラ: 下に移動して、最後に 10 個のタスク (ハード タスク) が残っていると言うことができますが、まだ 1 つのストーリーは完了していません。完成したストーリーのみが製品所有者にとって良いものであるため、失敗しました。

未完のストーリーのポイントと未完のタスクチャートの両方を持つことが解決策ですか?

ユースケースは単なる複数のユーザーストーリーですか？

ユースケースよりもユーザーストーリーを使用することの利点は何ですか..およびその逆...どちらか一方を使用する場合...すべてのアジャイル手法はユーザーストーリーを使用しますか？

開発にスクラム プロセスを使用し始めています。現在、すばらしいユーザー ストーリーの山があります。ユーザー ストーリーが完成し、テストされ、展開されたら、それを使って他に何かすることはありますか? 今使っているインデックスカードは小さいので、ゴミ箱に捨てるだけでいいと思います。

それらを保持している場合、後でそれらをどうしますか?

3M 付箋で手動で作成する代わりに、アジャイル ユーザー ストーリーを作成するために使用できるソフトウェアを知っている人はいますか? 私はもっ​​と環境にやさしく、ユーザー ストーリーを収集し、クライアントに渡す素敵なドキュメントを作成するために使用できる優れたアプリケーションになろうとしています。

ありがとう！