従業員に課題トラッカーを更新させるのがそれほど難しいのはなぜですか？

私は、会社と職場の両方で、人々に問題を更新してもらうために常にこの苦労を経験してきました。私は、人々が心の良さから実際にそれを行ういくつかのケースを経験しましたが、時間の〜70％は人々を追いかけなければなりません。

一般的に何らかの形で管理を行う（私は最優先の開発者です）ため、私が説明しようとする主な理由は、人々を追いかけたり、進行状況の照会を中断したりしたくないからです。結局、人々は多くのことを尋ねられると思います。まれで極端な場合には、（レポートを作成する必要があるときに）チケットを更新することになります。

だから、この問題に遭遇しましたか？開発者にどのように問題追跡ツールを頻繁に更新するように奨励しましたか？あなたはどの程度の成功を収めましたか？

理由は、あなたがそう言うという事実は別として、彼らが問題トラッカーを更新すべき理由を理解していないからです。

何故ですか？私の推測では、トラッカーの更新は仕事に意味のある方法で影響を与えないので、おそらく解決策は実際に彼らの仕事をより良くするのに役立つ追跡システムを実装することです。

従業員は、課題トラッカーの更新は重要ではないと明確に感じているため、困難です。それを変更する必要がありますが、キャッチがあります。コミュニケーションは大変です。効果的なコミュニケーションは本当に難しい-あなたが思っているよりもずっと難しい。非常に難しいので、その通信は通常、偶然を除いて失敗します

見せて、言わないで。例えば。あなた（またはあなたの上司）がレポートのためにデータを必要とすることを伝えないでください。表示から従業員の最新の課題追跡が影響し、それらをどのように役立つかという観点。

例でリード。

私は開発者であり、仕事で使用している課題トラッカーを使用するのに苦労しています。私は彼らが物事を整理するためにすべてのためですので、これは残念です。当面の私の解決策は、パーソナルトラッキングツールを使用し、それを参照して毎日のスクラムの進捗状況について話すことです。

トラッカーを常に使用する理由は次のとおりです。

• IDEおよびソース管理とのシームレスな統合。ライセンスが既に購入されているため、不格好なWebアプリを使用します。タスクの作成/更新には永遠に時間がかかり、紛らわしいUI機能がいくつかあります。残念ながら、これを使用することは私たちのチームの制御を超えています。

• シンプル。これにより、タスクを追加するためだけに手動で入力された10個のフィールドを取得しないことを意味します。プロジェクト/コンポーネント/などを手動で入力して、1時間ごとの見積もりと完了時間 いくつかの分野などでは、単に時間を増やします。

• 唯一。これがどれほど一般的かはわかりませんが、プロジェクト管理では1つのツールを使用し、サポートでは別のツールを使用し、開発では3つ目のツールを使用します。1つが更新されない場合、3つは確かに更新されず、それらの間の同期は自動化されそうにありません。

まず第一に、「人々が進捗を更新する」とはどういう意味ですか？

「現在の見積もりを更新する開発者」、「問題を解決済みに設定しない開発者」、または「顧客/テスターが解決済みの問題をクローズしない」、またはすべてを意味しますか？

開発者の観点から見ると、考え方と文化が混在しています。

• 考え方：問題を解決済みに設定すると、完了したことを意味し、バグがある場合は責任を負います
• 文化：会社全体がそのようなツールを使用することにあまり熱心ではないが、他の組織戦略を好む場合

私の経験では、少なくとも正しい方向を指す文化が必要です。次に役立つのは、DoD（「完了」の定義）を定義することです-開発者（他の役割でも働いている）がリスト全体を満たしていると言うことができる場合、問題を解決済みとしてマークし、必要なく進むことができます振り返る

チケットがクローズされるまで、コーディングの進捗状況（通常はとにかく薄い空気から引き抜かれた任意の割合）について尋ねるのをやめます。測定する主なものがクローズされたチケットの数である場合、改善されます。

ただし、すべてのメトリクスをゲーム化でき、補完的なメトリクスとチームを組むと、メトリクスの動作が向上する傾向があることに注意してください。

他のいくつかの回答で指摘されているように、ここでの正しい質問はおそらく次のとおりです。なぜ問題追跡ツールがあるのでしょうか。問題追跡システムを実際に機能させて定期的に更新する場合は、この質問に対する適切な回答（管理の観点からだけでなく、開発者の観点からも）が不可欠です。

多くの企業では、問題追跡システムは主に管理レポートツールとして使用されています。管理者がレポートを実行できるようにプログラマに問題を更新させることはうまく機能しません。また、プログラマーに問題の更新を強制することも機能しません。更新された問題があるかもしれませんが、データに疑問を呈する必要があります。

私の経験では、開発者（およびテスター、管理者など）に問題追跡システムを効果的に使用させる唯一の方法は、それを開発プロセスに統合することです。これは、プロセスの一部の出力がプロセスの次の部分への入力になることを意味します。

バグ追跡システムに権限を与えるには、次のことをお勧めします。

• 開発者は、課題トラッカーに記録されたバグ/機能のみを操作し、それ以外の作業は行われません。すべてのアイデア、リファクタリングプロジェクト、新機能、開発するカスタムツールなども記録する必要があります。
• 問題は優先度順に処理されます。優先順位は部分的に管理者が決定する必要がありますが、開発者は優先順位を決定する際にも明確に発言権を持っている必要があります。これは、メンテナンスとリファクタリングの問題に関して特に当てはまります。

処理に関しては、次のようなものを使用できます。

• ステータス「新規」は、開発者がまだ問題をピックアップしておらず、優先順位付けされた問題のキューにあることを示します
• ステータス「割り当て済み」は、開発者に割り当てられていることを示します。これは、開発者またはチームリーダーなどの誰かが行うことができます。各開発者にいくつかの問題を割り当て、通常は新機能などの「重いリフティング」と、単純なバグや単純なメンテナンス作業などの簡単な選択を組み合わせることでうまくいくと思います。これにより、開発者は気分に応じて作業を選択できます。
• ステータス「進行中」は、開発者が問題に取り組んでいることを意味します。開発者ごとに1つまたは2つの問題のみを「進行中」にする必要があります。
• 問題が解決したら、開発者は問題のステータスを「テストが必要」に変更し、所有者をテスターに​​変更できます。これはテスターの作業キューでもあるため、これは重要なステップです。
• テスターは、ステータスを「テスト失敗」に変更し、所有権を開発者に戻すことで開発者のキューの先頭に戻るか、ステータスを「展開準備完了」に変更できます。
• 「リリース準備完了」ステータスの問題は、リリースの責任者がリリースサイクルに従ってマージおよびリリースできます。

要するに、問題追跡システムを開発プロセスの重要な部分にすれば、問題が更新されないことを心配する必要がなくなります。

ブラウザを開いてログインし、チケットを見つけて記入するのはあまりにも大変だと考えているのかもしれません。たぶんあなたはフックでそれらを奨励しようとすることができます。最近では、git / hgメッセージ[これらのいずれかを使用すると仮定する]でFIXED＃123のようなものを入力でき、コミットをプッシュするとチケットが自動的に変更されるのが一般的な機能です。そうすれば、開発者にとっては仕事がほとんどありません（各ブランチで別々の問題に取り組んでいる場合-すでにチケットIDを持っています）。おそらく、コミットメッセージにこれらの文字を追加します。このソリューションでは不十分な場合、おそらくチケットの範囲が大きすぎることを意味し、多くの小さなチケットに分割する必要がありますか？

これは、何よりも企業文化の問題のようです。誰がトラッカーを使用する必要があるのですか？これが1人の人またはグループがそこに放り込んだものであり、他のすべての人がただ受け入れて使用することを期待する場合は、幸運を祈ります。人々はそれが何であるかを理解し、それを使用する方法を知っており、それが実際に自分の人生（あなたの人生ではなく自分の人生）を容易にすることを受け入れない限り、経営者によって強制されない限り、彼らはそれを使用しません。そうは言っても、トラッカーの使用が会社の決定である場合、トラッカーを強制するのは管理者でなければなりません。あなたの役割に人々がトラッカーを使用/取得する責任と権限が含まれていない限り（あなたは開発者だと言ったように聞こえます）、あなたが何をするかに関係なく（あなたは現実的に、私見）。

これはおそらく、人々に定期的に時間を入力させるのが非常に難しい理由と似ています。それは退屈な仕事です...

多くの課題追跡システムはIDEに統合されています。たとえば、TFSワークアイテムトラッカーを使用すると、チェックインの実行時にタスクを解決済みとしてマークできます。チェックインをタスクに関連付けることを要求するオプションもあります。ワークアイテムの更新をチェックインプロセスの一部にすることで、作業が簡単になります。別の方法は、変更を実行するために別のインターフェイスで課題追跡を開くことです。

別のオプションは、誰かがトラッカーを開き、人々がステータスを提供するときにタスクを更新する、ステータス会議（または毎日のスタンドアップ中）を行うことです。

考慮すべき1つのことは、GUI自体が障害であることです。たとえば、いくつかの障害には次のものが含まれます。

• クリックが多すぎる
• 最適化されていない、または不十分な課題追跡アプリケーションサーバー
• ユーザビリティまたはアクセシビリティが低い

APIを公開すると、技術的な成果物（コードカバレッジ、単体テストレポート、ビルドステータスなど）と同じスクリプトを使用して、課題追跡を更新できます。

参照資料

• スクラムワイズ-API

• Jira Cloud REST APIリファレンス

• Alfresco Content Services REST API