web-dev-qa-db-ja.com

プラットフォームごとに分割された場合のPBIの追跡と優先順位付け

次のようなプラットフォームで分割できるPBIまたはユーザーストーリーがあるとします。

「ユーザーとして、ニュースで更新できるようにフィードを読みたい」

ただし、そのユーザーストーリーはiOS、AndroidおよびWeb用であるため、プラットフォームごとに分割してそれぞれに異なるカードを作成するために使用しますが、スプリントが終了すると、3枚のカードのうち2枚だけになります完了したら、メインカードを"Done"(少なくともそう思います)としてマークできず、遅れているように感じます。

分割カードを優先する場合も同様の問題があります。同じメインストーリーからのものであり、各カードで異なる人が作業している場合はほとんど時間の無駄だと感じているため、(私の経験では)優先順位で並べ替えることは不可能です。

このトピックをどのように管理すべきかについて、ご協力いただければ幸いです。メインのユーザーストーリーを削除して、分割されたストーリーで作業する必要がありますか?プラットフォームごとに分割する場合、分割されたユーザーストーリーを優先する必要がありますか?

2
rhdez.g

区別する必要がある2つの状況があります。

  1. ストーリーは(他のいくつかのストーリーと一緒に)1つのスプリントで実行できるほど小さいと推定され、さまざまなプラットフォームに実装するためにさまざまなタスクが作成されました。
    この場合、すべてのプラットフォームで完了していなければ、ストーリーは完了しておらず、そのポイントを主張することはできません。これは、どのストーリーでも発生する可能性のある通常の推定エラーです。

  2. 元の「すべてのプラットフォーム」のストーリーは、一度に完了するには大きすぎると見なされ、作業をより管理しやすくするために分割されました。
    この場合、すべての「プラットフォーム固有」のストーリーが同じスプリントで完了するわけではないのはまったく正常です。それが親の物語を分割することの要点でした。一体、それらすべてが同じスプリントで開始されるように計画されているわけではないかもしれません。
    この場合、「プラットフォーム固有」の各ストーリーは独自に見積もる必要があり、親ストーリーの見積もりを行ったことを忘れてください。 1つのプラットフォームのストーリーが完了すると、それらのポイントが獲得されます。

スプリットストーリーの優先順位付けに関しては、ビジネスにとっての価値に基づいている必要があります。たとえば、ユーザーベースの60%がウェブサイトを介してシステムにアクセスすることがわかっている/推定されている場合、80%がAndroidベースの電話を使用しており、iOSベースの電話を持っているのはほんの一握りのユーザーだけです。ビジネスの観点からは、AndroidとWebバージョンをすぐに(そしておそらくこの順序で)実装することですが、iOSバージョンはバックログをさらに減らすことができます。

最初に認識すべきことは、それはすべてPBIのサイズに関することです。プラットフォーム固有の各変更が小さい場合は、機能のPBIが1つだけで、プラットフォーム固有の各変更を行うタスクがある可能性があります。それは完全に合理的です。

各プラットフォームが独自のPBIに値するように変更がより複雑な場合、「機能」は実際には機能/エピックである必要があります。どちらも本質的に「大きく」曖昧であり、スプリントの一部としてそれらを追跡することはありません。基本的には、プラットフォーム固有のPBIをスプリントに追加するだけです。たぶん、iOSでこのスプリントを実行することしかできず、Android次のスプリントに取り組むことになります。 。それは問題なく、実際には一般的です。そのため、クロスプラットフォームアプリの機能は、一度に1つのプラットフォームにのみ展開され、場合によっては他のプラットフォームに展開されるまでに数か月かかります。これらを機能またはEpicを使用すると、それらが関連していることを確認できますが、その関係に拘束されることはありません。そのため、1つのプラットフォームの提供は、他のプラットフォームの提供に依存します。

0
Chris Pratt

Bart van IngenSchenauの答えは素晴らしかった。私は彼の返答に、本質的に元の物語は大きすぎて物語にはならず、実際には叙事詩または特集であったと述べることによってのみ追加します。つまり、あなたがしていることは、スプリント内で完了することができる「適切なサイズの」ストーリーを作成するために、私たちが「垂直スライス」と呼ぶものとより一致しています。 「私たちはプラットフォームごとに分割して、それぞれに異なるカードを作成していましたが、スプリントが終了し、3枚のカードのうち2枚だけが完了したとき、メインカードを「完了」としてマークすることはできません(少なくともそう思います)そして遅れているような気がします。」

3つのプラットフォームすべてを同時に準備しないと、リリースできないという印象を受けているようです。しかし、なぜですか?バートが言うように、顧客ベースの80%がAndroidを使用していて、それをスプリントで完了することができれば、1回のスプリント後にその新しい機能を顧客の80%にリリースできます。したがって、頻繁にリリースするというアジャイルの原則に沿った方法で行動していることになります。

逆に、大きなストーリーを維持しようとして、すべてが完了するまでリリースされない場合は、リリースを2週間から6週間に延期します。それはアジャイルの原則に反しています。

「ストーリーの分割」についてのあなたの議論は、あなたがあなたの仕事を追跡するために使用しているアプリケーション(Rallyなど)の機能によって動かされているのではないかという印象を受けます。その場合、ツールにネイティブな分割機能を使用している場合は、ツールがプロセスを決定できないように注意してください。覚えておいてください:プロセスとツールを介した個人と相互作用。スクラムマスターが、アジャイルの観点から意味のあることではなく、ツールの機能に基づいて、このようなトピックをどのように処理するかを決定し始めるのを何度も見てきました。

通常は、3つのプラットフォームと、各プラットフォームの個別のストーリーを含むエピックまたは機能の「ニュースフィード」を作成します。ただし、最初にすべてのAndriodを実行する必要があり、これにより多くの「部分的に完全な」機能がバックログに残り、何らかの理由で管理に苦痛が生じる場合は、プラットフォームごとに個別のエピックを作成して、プラットフォームごとにこれらの機能の進捗状況と完了を示します。このようにして、ツールの機能を活用しながら、アジャイルの原則と価値観に一致する方法で作業しています。

0
Curtis Reed