どのPBIレベルでブランチを作成する必要がありますか？

Question

ユーザーストーリーレベルでブランチを作成するのを間違えてきました。 参照： ユーザーストーリー！=機能。

私は、機能とエピックを整理するという私の貧弱な慣習のために、このようにやってきたと思います。これは、永続的であり、基礎となるストーリーを親にするための単なる組織的な投稿です（ ...）。

エピックと機能を作成するためのより良い方法は何ですか？

。

私はエピックと機能を使用してバックログを整理してきたので、同僚と私はそれらを使用してユーザーストーリーを作成する場所を決定しました。これに伴う問題は、デザイナーとして私がどの特集記事に属するかを決定する必要がある孤立したユーザーストーリーを持っているだけではないと私は信じています。これにより、作成者が別の「機能」の下に既に存在していることに気づかないため、ユーザーストーリーが複製されるという現象が発生しました。

では、ユーザーストーリーを後でではなく孤立したものとして作成し、それらがどの機能に属するかを判断するように要求する必要がありますか？ではなく、製品の所有者は、ストーリーが属する機能の決定を試みます。

。

この計画の変更について私が抱いているもう1つの懸念は、かなり迅速に移動したユーザーストーリーに基づいて開発し、完了時にストーリーブランチをメインブランチにマージしてから展開することです。

各ストーリーの「終わり」でメインとマージしてから機能ブランチの次のストーリーに進むことで、ストーリーブランチではなく機能ブランチで作業している間も迅速な展開を維持できますか？

。

さらに、おそらくより直接的で強力な方法であり、この場合の例は、前述のすべての回答よりも多くのコンテキストを提供する可能性があります。

ブランチの実際の例と、実際の開発プロジェクトに含まれているストーリー、機能、タスク、エピックを提供します。

。

これが私のバックログのモック図です

（E-＃）エピック

（F-＃）機能

（S-＃）ストーリー| （B-＃）バグ

（T-＃）タスク

（E-1）サイト全体の改善

（F-2）CMS

（S-3）開発者として、cshtmlページの@inheritsを監査し、Strongly Typingページをより適切に使用する方法を確認します

（S-4）CMSバージョン7.5.8にアップグレード

（T-5）バックアップ

（T-6）Nugetアップグレード

（T-7）アップグレードを実行

（T-8）マージ構成ファイル

（E-9）公開サイトを改善する

（F-10）ホームページの改善

（S-11）広告主として、ホームページに広告を表示して、広告の視認性を高めたい

（F-12）レビューを改善する

（S-13）旅行者として、星の数でレビューをソートできるようにしたいので、＃Iでレビューを見ることができます興味がある

（T-14）これを実現するために、関数に並べ替えロジックを作成します

（T-15）ソートを要求する適切なUXを作成します

（S-16）旅行者として、私は古いレビューをよく見たくないので、見たくありません。

（F-17）記事の改善ページ

（S-18）読者として、記事にタグを付けたいので、興味のあるタグが付いた他の記事を表示できます。

（E-19）クライアントバックエンドポータルサイトの改善

（F-20）アカウント管理

（S-21）ポータルユーザーとして、何が起こっているのかを知るために通知をメールで送信したい

（F-22）アドマネージャー

（S-23）広告主として、広告ごとに予算を設定して、より細かく管理できるようにしたいと考えています。

（S-24）広告主として、自分の画像をアップロードして、広告をより適切にカスタマイズできるようにしたいと考えています。

（F-25）請求マネージャー

（S-26）ポータル管理者として、過去のステートメントを表示できるようにしたいので、過去の請求を理解できます。

Arthur van Leeuwen · Answer

離れていくべきいくつかのものを融合しているように見えます。

まず、分岐戦略と作業項目の内訳構造が一致する必要はありません。分岐戦略は、使用しているソースコードにどのように到達したかを伝えるために使用する必要がありますが、作業項目の内訳を惜しみなく追跡する必要はありません。

2番目：ユーザーストーリーと機能は、必ずしも新しいバージョンを展開する際の粒度ではありません。新しいバージョンを顧客に公開する前に、エピック全体または複数のエピックを実装する必要がある場合があります。それは、その叙事詩を実装している間、ブランチを離しておく必要があるという意味ではありません。より頻繁に内部リリースが必要になる可能性があるため、定期的に統合する必要があります。これは、例えばを使用することによって助けられます。機能を切り替えます。

3番目：作業項目分解図は、実装されている機能の知識をエンコードするための最良のリポジトリではありません。たとえば、次のようにするのが賢明です。実装されたすべてのユーザーストーリーを説明するドキュメントをソースツリーに保持します。ドキュメントを読みやすく整理することは、開発作業の一部であり、「このユーザーストーリーはプログラムの他の部分とどのように適合するのか」という疑問に答えるのに役立ちます。複数の作業項目で同じユーザーストーリーを持つことはまったく悪いことではないことに注意してください。つまり、そのユーザーストーリーは複数の理由で機能する必要があることがわかります。同じユーザーストーリーの発生が月ごとに時間的に区切られている場合もあります...その場合、ソースツリー内のドキュメントは、作業された作業項目の履歴よりもはるかに望ましいです。追加のキックについては、ユーザーストーリーのチェックを自動化して、ドキュメントが生きたドキュメントになるようにすることができます。

これが物事を少しクリアすることを願っています。

注意すべき点の1つは、製品のバックログに抽象化レベルが混在しているように見えることです。ユーザーストーリーを作成するときに価値を念頭に置いておくと、その罠を回避するのに役立ちます。そのための1つの方法は、whyスタックをポップすることです。例えば。「ポータル管理者として、過去の明細書を表示できるようにしたいので、過去の請求を理解できるようにしたい」の場合は、「なぜ過去の請求を理解したいのですか？」などと、値まで提供されているのは透明です。