ユーザーストーリーに関連しないタスクに取り組む方法
いくつかの作業が必要であるがユーザーストーリーに関連していないと思われるすべての問題を配置する開発者タスクコレクターを作成したいと思います（たとえば、スタートアップアニメーションの目に見えない癖を修正し、lintでコードをスキャンし、アプリケーションでEasyTrackerを有効にします。未使用のリソースなどをクリーンアップします）。
これらすべての問題を処理する時間があるかどうかはわかりません。次のスプリントではそのうちの1つを実行し、2つのスプリントで後で1つ実行するなどです。
スクラム/スプリント計画でどのように対処しますか？また、プロダクトオーナーは、何をいつ行うかを決定する必要がありますか？
単一の製品/プロジェクトと単一の開発者プールについて話している場合は、強くすべてのアイテムを含む製品バックログを1つだけにすることをお勧めしますそれに含まれていると述べた。バックログが2つあると、管理者にとって悪夢になります。あなたと製品の所有者は、それぞれのバックログに取り組むためのリソースを求めて戦うことになると思います。
ユーザーストーリーがビジネス価値の観点から表現されている場合は、スプリントに計画するのに問題はありません。私は現在、次のようなユーザーストーリーを持つプロジェクトのスクラムマスターです。
- 開発者として、新しい開発者がシステムを理解しやすいように、ビジネス用語の最近の変更を反映するようにテーブルと列の名前を変更したいと思います。
- 開発者として、報告された問題をより簡単に診断できるように、エラーのログ記録を改善したいと考えています。
- システム管理者として、システムのログを埋める偽のエラーを排除して、ログノイズが問題の特定を妨げないようにしたいと考えています。
技術的でない言葉で表現されていても、ビジネス上のメリットの観点から、製品の所有者がこれらのいずれかをスプリントに含めることを拒否している場合は、製品の所有者が間違っている可能性があります。
そのような不幸な立場にいるのに製品の所有者を変更できない場合は、すべてのシステムにメンテナンスが必要であることを彼らに思い出させることが役立つ場合があります。また、 技術的負債 の概念と、ある時点で常に返済する必要がある方法について説明していることもわかりました。これは有用な例えです。
最後に、現在行われていないこれらのより細かい技術的ポイントのいくつかは、実際には、製品所有者が望んでいる機能の実装の一部である必要があることに気付くかもしれません。上記の例のいくつかに基づいて、スタートアップアニメーションを実装するためのユーザーストーリーは、表示されているかどうかにかかわらず、「癖」がある場合は適切に完了していなかったと言えます。同様に、静的コード分析メトリックの標準がある場合、開発者がLintを使用してそれらのメトリックを測定し、コードが標準を満たしていることを証明した場合にのみ、ユーザーストーリーが完了したと見なす必要があります。これらが一般的な標準である場合は、 doneの定義 に含める必要があります。それらがユーザーストーリー固有のポイントである場合、それらはユーザーストーリーの受け入れの条件である可能性があります。
これは、ユーザーストーリーに関連しないタスクの性質によって異なります。チーム内で追跡 障害 を検討しましたか。
スクラムでは、障害とはチームの生産性を妨げるものです。
あなたが言及したタスクは（部分的に）障害と見なされる可能性があり、スプリントで一定量の障害に取り組むことができます。誰が何をするかを決めるのは、障害の場合は本当にチーム次第です。彼らはそれが最も痛いところを知っているべきです。
これらの問題は、プロジェクトの「技術的なバックログ」を構成します。私が行う傾向があるのは、メインの製品のバックログと同様の方法でそれらを追跡することです。多くの場合、これは、ユーザーストーリーのように、チケット/バグ追跡システムにそれらを追加することを意味します。ただし、製品のバックログではなく、技術的なバックログに属するものとして明確にマークする必要があります。付箋が付いた物理的なバックログがある場合は壁の別のスペース、ソフトウェアを使用している場合は別のトラッカーです。一部のアプリケーションでは、課題にタグを追加することもできるため、タグを使用するか、極端な場合は、課題のタイトルに「[TECH]」のようなプレフィックスを使用できます。
ただし、技術的と見なす一部のタスクは、実際にはユーザーストーリーを表す場合があることに注意してください。パフォーマンスや安定性などの非機能要件が非常に重要な場合があるため、応答時間の改善や、監視の拡張やテストの改善によるシステムの安定性の向上などは、ユーザーストーリーとして非常によく「販売」できます。これらの変更を実装することで期待される結果とコストについて、プロダクトオーナーとオープンであることが重要です。