叙事詩は死んでいます。代わりにすべきことは次のとおりです。

まだ死亡宣告されていないものは何ですか?テスト駆動開発は何年も前に埋葬されました。それでも、それは広がり続けています。もちろん、アジャイルも死んでいます。しかし、従来の企業でさえスクラムと接触します。死者は生き続けますが、何か死んだと宣言することは、きびきびとした見出しにとって常に良いことです。その意味で、アジャイルプラクティスとして叙事詩を破壊する方法を目撃してください。

叙事詩とは何ですか?

用語はあいまいです。これには利点があります。叙事詩は、仕様よりもコミュニケーションのためのものです。あいまいさはそれらを用途の広いものにします。しかし、誤解を招く恐れがあります。私はマイク・コーンの定義に固執します:

スクラムエピックは大規模なユーザーストーリーです。(ソース)

私はこのような用語を使用します。エピックは、スクラムスプリントに実装するには大きすぎるストーリーです。したがって、製品バックログの上部にある項目は叙事詩ではなく、小さな物語です。バックログには、通常、叙事詩があります。時間が経つにつれて、叙事詩はスプリントに引き込むことができるストーリーに「スライス」されます。

それは私が私のトレーニングコースで何年も教えてきたものです。それは一般的なコンセンサスのようです。一見直感的。なぜそれが実用的でないのかを説明するためにここにいます。

叙事詩に対処するための3つの非現実的な方法

これまでのところ、企業が叙事詩を扱う3つの方法に出くわしました。それらのどれも実用的ではありません。それらを呼びましょう:

解散

リンク

1.解散

溶解の原理は単純です。叙事詩は完全にその構成要素、個々の小さな物語に分解されます。

たとえば、オンラインフライトポータルの壮大な「ブックフライト」は、個々のプロセスステップに分解できます。つまり、「ログイン」、「フライトの検索」などです。すべてのプロセスステップがストーリーになります。チームはストーリーを見積もります。それが大きすぎる限り、チームはそれをスライスし続けます。すべてのストーリーがスプリントに収まるほど小さくなると、チームはエピックを削除し、ストーリーの開発を開始します。

私を悩ませているのは、完全性の根底にある考えです。解散は、トピックが所定の範囲で完了することができることを示唆しています。

ただし、開発中にストーリーの変更が可能な場合、すべてのストーリーを事前に定義することはできません。

スクラムガイドによると:

製品のバックログが完全になることはありません。[…]要件の変更が止まることはありません。

固定スコープを提供する必要がある場合は、ふりをやめてください。叙事詩を忘れて、詳細な要件を前もって説明してください。その場合、アジャイルであると主張しないでください。

2.リンク

叙事詩を完全に解消しない場合は、リンクを使用するのが理にかなっています。叙事詩は未処理のまま残っています。新しい小さな物語を、それらが由来する叙事詩にリンクします。

リスクは、時間の経過とともに叙事詩の量が増えることです。バックログは肥大化します。それはあなたがもう必要としない叙事詩を含んでいます。利害関係者はもう会社にいません。または、トピックはもはや関連性がありません。

もちろん、バックログは時々クリーンアップできます。これは付加価値のない仕事だと思います。そして、後で説明するように、それを回避することができます。

3.木

別の方法は、叙事詩や物語を木として描写することです。

あなたは叙事詩によって小さな物語をグループ化します。悪くないアイデア。しかし、失うのはバックログの順序付きリストです。では、どのように実装順序を決定しますか?

もちろん、両方のビューをサポートするデジタルツールを使用できます。リスク:ツールに多くの時間と労力を費やします。意見は何ですか?属性は何ですか?基礎となるデータモデルは何ですか?興味深い質問。しかし、アジャイルアプローチでは、優先度を高くするべきではありません。

要約すると、グループ化のアイデアは良いです。しかし、それを行うには時間がかかります。

叙事詩の代替

長い間、代替手段がありました。それは、私が上でリンクしたマイク・コーンによる同じブログ投稿でも言及されています。

私はテーマについて話している

テーマは、ストーリーの追加属性と考えることができます。通常、いくつかのストーリーは同じテーマを共有しています。ストーリー「検索フライト」には、「ブックフライト」というテーマがあります。バックログのスニペットは次のようになります。

テーマは、個別のバックログ要素として管理されません。これにより、リンクの章で説明されているクリーンアップ作業が不要になります。それは良い。

しかし、あなたが失うのは、大きな叙事詩からスプリントで実装できるストーリーへと徐々に洗練されるプロセスです。それは良くないね。

幸いなことに、バックログの外でこの改良を行うことを可能にするプラクティスがあります。テーマを特定する1つの方法は、ユースケース図です。

このような図の良いところは、高度な抽象化とグラフィック表現により、「全体像」を示していることです。そのため、バックログは不適切です。

ユースケース名は、後でバックログのテーマになります。しかし、ユースケースからストーリーにどのように到達しますか?これには、JeffPattonのストーリーマッピングが適しています。

サンプルマップの上の2行は、「フライトの予約」と「プロファイルの管理」のユースケースとそれらの基本的なフローを示しています。個々のステップの下で、チームは代替案をハングアップします:他のプロセス、エラーなど。これらの黄色いメモはユーザータスクと呼ばれます。

バックログの詳細化では、チームはユーザータスクからストーリーを導き出します。タスクはストーリーのタイトルとして使用できます。チームは、受け入れ基準などの詳細をストーリーに追加します。

結果

この代替アプローチを適用すると、結果が生じます。たとえば、製品バックログには、次の1〜2スプリントのストーリーのみが含まれます。つまり、おそらく10〜20話です。

受け入れ基準のさらなる優先順位付け、見積もり、および詳細化などのすべてのアクティビティは、これらのストーリーでのみ行われます。10番目のアジャイル原則が言うように:

シンプルさ—行われていない作業の量を最大化する技術—は不可欠です。

経営陣が開発の進捗状況について洞察を得たい場合、これは3つのレベルで可能です。

  • ユースケース図またはテーマは、管理の長期的な視点を提供します。1年間、またはそれ以上。ただし、詳細を指定するのには適していません。
  • ストーリーマップは、リリース計画の基礎を形成します。リリースに関心のある利害関係者は、チームメンバーと一緒にストーリーマップを作成します。(新しい発見により、開発中にスコープが変更される場合があります。)
  • 開発中に深い洞察を持ち、詳細に影響を与えたい人は、スプリントレビューバックログの詳細化に参加します。

低高度でのみ、詳細が表示されます。そして、製品バックログは基本的に買い物リストのようなものです。1年で買いたいものを書き留めていただけませんか?

最後になりましたが、叙事詩の死は、消費主義の死を告げるものです。何かが必要な場合は、チームに同意し、緊密に協力する必要があります。

事後分析

同僚との話し合いの中で、彼らは叙事詩が解散した後でも、小さな物語を追加することができると指摘しました。そうです、そして私にとってそれは許容できる解決策です。ただし、この場合に失われるのは、ユースケース図に示した「全体像」です。

最終的に、ユーザーに対する製品の適合性がその成功を決定します。それがどのように作られたかではありません。これは、叙事詩を含むすべての開発慣行に適用されます。

多分あなたは叙事詩に対処するための賢明な方法を思いついたのですか?

私のオンラインコースにアクセスして、製品バックログを効果的に管理する方法を学びましょう。この記事はドイツ語でHOODブログに最初に掲載されました。