内部開発チームの問題追跡

Question

エンドユーザーとプロジェクト管理の観点から欠陥/拡張機能を追跡する標準的な問題追跡システムがあります。しかし、私たちはまた、コードの特定の部分をリファクタリングすることや、エンドユーザーが相互作用しないアプリケーション内の何かを変更することを含む内部チームの欠陥を追跡する必要があります。

同じトラッキングシステムでこれらの不具合と機能強化を追跡するのが最善ですか？これで私の予約は、ユーザーの欠陥を見てプロジェクトマネージャは、これらの内部要求によって混乱し、不必要な懸念を引き起こすことです。内部チーム使用のためだけに別の欠陥追跡システムを立ち上げていますか？

Answer 1

コーディング時間を短縮するために余分な管理作業を楽しめない限り、システムの数は（ほとんど）常に向上します。

私はピボタルトラッカーがあなたが話している混乱を避けるために、そして顧客に明確な焦点を置くためにこれらを分けているのが好きです。ユーザーの欠陥は「バグ」であり、目に見える顧客の利益を持たない内部アイテムは「雑用」であり、顧客価値を提供しないため多くのビューには表示されません（ユーザーストーリーはありませんそれ）。

私は、ほとんどの課題トラッカーが問題の種類を分解する方法を持っていると思います。「テクニカル債務の払い戻し」の問題をバグとは別に分けると思います。

なぜプロジェクトマネージャーが知らないタスクを開始するのかを検討することもできます。この作業をなぜ行う必要があるのか​​が明確になるように、これらの言い回しをするだけでよいでしょう。したがって、 "Refactor User Authentification"の代わりに "User login systemのメンテナンス性を高める"か、タスクの基本的な目的が何であってもかまいません。

明らかに、すべての技術的タスクはビジネス上の価値を提供し、正確に何を提供するか（「自分のコードはよりエレガント」であることを考慮する）は良い練習になるはずです。