テクニカルデットストーリーを書くための推奨フォーマットはありますか？
私たちのチームは、Angularの新しいバージョンへのアップグレードの一部として、コンポーネントとUIをカバーする一連のストーリーを洗練し始めています。これらのコンポーネントは、既存のアプリケーションで画面を再作成するために使用されます。この仕事は技術的な借金を考えています。
テクニカルデットストーリーを作成するための推奨フォーマットはありますか？
より直接的に顧客に焦点を当てた標準的なストーリーには、「現状として...できる...として」とガーキンの「指定>いつ>その後」の受け入れ基準を使用します。
これらの技術債務の話に使用する必要がある同様のものはありますか？それとも、技術的な要件のみをリストする必要がありますか？
あなたが遭遇しているロードブロッキングは仕様によるものであり、正しい理由でそれに遭遇しています。
ユーザーストーリーはユーザーが気にしていることです。それがユーザーの視点から書かれている理由です。タスクをユーザーの関心事として表現できない場合、それはユーザーの関心事ではない可能性が高く、これはおそらくここにあります。ユーザーが確認できる限り、技術的な借金タスクの前後で同じ機能が維持されるため、ユーザーは画面の背後で何が発生するかを気にしません。
技術的負債は開発者の関心事です。それはあなたが気にかけていることですが、そうでなければアプリケーションが本来持っていなかったであろう機能を実際には追加しません。
注：技術的負債により特定の機能を実装できない場合、その技術的負債の解決は本質的にその機能/ユーザーストーリーの一部であり、有効なユーザーストーリーが既にあるので、現在の質問は意味がありません。
ユーザーストーリーとそのようなタスクの記述の強制により、ワークロードはユーザー指向になり、ほとんどの企業にとって真のビジネス価値はそこにあります（機能/機能はユーザーの幸せにつながり、顧客獲得につながります）。このシステムでは、技術的なアップグレードは、機能/ビジネス価値の追加を許可する場合にのみ存在しますです。
そして、ここが問題の核心です：提案された技術アップグレードのビジネス価値は何ですか？
- ユーザーが望む機能を追加する場合、その機能はユーザーストーリーです。
- 保守性が重要な場合（つまり、将来のタスクをより迅速に実装できる場合）、これに費やされるコストと労力は、将来のワークロードを簡略化するために投資する会社から調達する必要があります。 ユーザーはそれを気にしない（これは機能ではありません！）これはユーザーストーリーではありません。
- セキュリティに関するものであれば、セキュリティの範囲に含まれます。これは必ずしもユーザーストーリーとして簡単に表現されるとは限りません（たとえば、平均的なユーザーはHTTPSの使用に関心がありません）。このように表現できます（「アプリケーションと安全にやり取りしたいユーザーとして」）が、このセキュリティ上の懸念がユーザーではなく会社から来ている可能性もあります（その時点で、投資している会社に戻ります）それ自体は前の箇条書きから）
- それがパフォーマンスに関するものであれば、それはユーザーストーリー理由の範囲内として解釈できます。ユーザーはナノ秒の最適化を気にしません。ユーザーは数秒のパフォーマンス向上を気にします。
- アプリケーションのUXを最新化することを目的としている場合は、ユーザーストーリーが明確になり、ルックアンドフィールが向上します。これがビジネス価値としてカウントされるかどうかは、状況に応じたものです。あなたの会社（およびその顧客）は、製品の美学にどの程度関心がありますか。
しかし、このロードブロッキングがほぼ明示的に作成された最大の箇条書きは開発者が自分のために何かをしているです。最新のおもちゃで遊びたい。間接的な利点（開発者の士気、開発者を最新の状態に保つなど）があると主張することはできますが、通常は実際の付加価値はありませんがあります。もしあれば、ビジネスバリューをユーザーストーリーとして簡単に表現できます。
つまり、ビジネス価値の機能の変化を説明できない（=ユーザーストーリー）ビジネス価値の追加がないことを示唆しています。ユーザーストーリー主導の環境では、これは、開発リソースを無駄にしないように意図的にブロックされている正確なシナリオです。ユーザーストーリーとしてそれをどのように表現するかを尋ねることは、会社が運用することを選択した意図的なチェックとバランスを回避する方法を教えてくれるでしょう。これはこれにアプローチする良い方法ではありません。
通常の先行（ユーザーストーリー）を回避する必要がある場合は、ビジネスバリューに関係のないアップグレードとその間接的なメリットについて、プロジェクト管理者に相談する必要があります。
より直接的に顧客に焦点を当てた標準的なストーリーには、「現状として...できる...として」とガーキンの「指定>いつ>その後」の受け入れ基準を使用します。
これはユーザーストーリーに限定されないことに注意してください。この形式は、開発者の懸念を表すためにも使用できます。
として開発者依存性注入を実装するする必要があるモック/単体テストを使用して将来のデバッグ作業を軽減する。
この形式が唯一の要件である場合、実際にはこれにユーザーストーリーを使用する必要はありません。しかし、会社がこれをユーザー主導のビジネス価値に制限している場合、技術的な負債は悲しいことに無視されます。
私は、開発者の懸念を考慮せず、ユーザーの懸念のみに関心がある企業のファンではありません。しかし、私は開発者として幹部の決定を下すのは私ではありません。会社がそうすることを選択した場合、私はそれを却下することはできません。
「スクラムフレームワークは、実行する必要がある内容のみを記述しますが、方法を強制しません実行する必要があります。」 「ユーザーストーリーは、機能要件を「今のところ十分」に捉えるための優れた手法であり、さらなる会話の余地を残します。しかし、スクラムはそれらを処方したり要求したりしません。他の手法は、次の3つを促進するのに役立つ限り問題ありません。
- 彼らは、製品バックログをスクラムチームとその利害関係者が理解できるようにします。利害関係者は、製品バックログを表示し、今後の予定とその順序を十分に理解できる必要があります。
- 彼らが要求する詳細レベルは、製品開発の不確実性に適合する必要があります。未来にあるアイテムは、スプリントに引き込まれるアイテムよりも詳細が少なくて済みます。
- 彼らは、スクラムチームと関係者（ユーザーを含む）の間の継続的なコミュニケーションと会話を促進する必要があります。」
Scrum.orgの " 神話4：スクラムでは、製品バックログはユーザーストーリーで構成されている必要があります "からの引用
また、David Evansによる " Telling Better Stories "基調講演もご覧ください。
概要：
- バックログには、あらゆる種類のストーリーがあります。私のチームでは、ユーザー、技術、研究の3つのタイプを提案しました
- あなたはする必要はありませんユーザーストーリーの「[理由]」フォーマットになるように「[ロール]として[アクション]したい」として使用します。