「継続的な進行中のタスク」をスクラムシステムに取り込む方法
スクラムを操作する場合、小さなタスクの明確に定義された停止点と開始点を作成することが常に重要であると考えられています。
しかし、「進行中」のタスクをスクラムシステムにどのようにキャプチャしますか？
デプロイ後の金曜日のように、通常、「古いコードのドキュメントとコードレビューに取り組み、悪い習慣がないか確認します」。絶えず新しいコードが見つかり、新しいプラクティスが出現するため、これには終わりがありません。ドキュメントの更新と古いコードの更新の非難が必要です。私たちも小さすぎて、これらのために個別のシステムを作ることはできません（開発者などはまだ開発と密接に結び付いています）。したがって、時間枠のマネージャーを提供するために、これらはスクラム作業に計算されます。
しかし、どのようにしてそれらを「マーク」することを提案しますか-両方の経営者が何が起こるかを知っており、同じ文言の継続的なバックログはありません。
これらの「継続的な進行中のタスク」を作成しないことをお勧めします。
一般的な「ドキュメントを更新して、悪い習慣のコードをレビューする」のではなく、明確な目的を持つ非常に具体的な作業またはタスクを定義します。改善が必要なドキュメントのタイプ、またはコードベースの特定の部分に関する特定の問題を特定します。これにより、ドキュメントの更新やコードの改善を製品の他の優先順位で優先順位付けし、特定の変更を行うことのコストと利点を可視化できます。
何が必要かわからない場合は、調整時間の一部を使用して、実行する必要がある作業を理解することを検討できます。
私の経験では、これはスクラムを行うときによく起こります。すでに発見したように、進行状況の監視は不可能になり、タスクはスクラムフレームワーク内に収まりません。
問題
このような継続的/継続的なタスクは通常、プロジェクトが終了するまで終了しません。したがって、それらをスプリントに計画することはできません。あなたは、いくつかのタスクを計画可能な特定の明確に定義されたタスクに分割することができます。一部のタスクでは、これが不可能な場合があります。
勧告
進行中のタスクの作業を計画するかどうかを自問してください。
これは、労力と必要なマイルストーンの量によって異なります（たとえば、ドキュメントを日付までにレビューできるようにします）。作業集中型のタスクの場合は、具体的でスコープを定義する必要があります（「データモデルの確認」、「設計ドキュメントのアーキテクチャの概要の更新」など）。
作業集約型ではないタスクの場合、労力を見積もることなくそのままにして、各スプリントに追加することができます。このようにして、タスクは忘れられず、少なくともスプリント計画およびスプリントレビューミーティング中に議論されます。
この特定のケースで進行中のタスクは、技術的負債の返済と見なすことができるようです。
通常、技術的負債を蓄積するデフォルトの対策は、あなたのDefinition of Doneを改善することです。
例：ドキュメント化されていないコードのドキュメントを作成するための継続的なタスクがある場合、DoDに「すべてのコード変更がドキュメント化されている」ことを追加することができます。
コードの臭いの修正に苦労している場合は、静的コードアナライザーを使用して、チームがDoDの一般的なコーディング標準に準拠していることを確認してください。必要な最小限のテストカバレッジ、UAT、コードレビューなどを定義の完了に追加することもできます。チームが考えていることは何でも、技術的負債を防ぐために必要です。