私は、カンバンタイプのフレームワークにJIRAを使用しているスクラムマスタータイプの役割のチームで作業を開始しました。過去6〜12か月間、彼らはJIRAを使用してほとんどすべてのことを行ってきました。これには、通話中の人の追跡、トレーニングなどの人事/個人的なタスク、リーダーの個人的な開発目標の設定、定期的にスケジュールされた会議、休日まで含まれます。
私の現在の考え(そうでないと確信して幸せです)は、これはJIRAの最適な使用方法ではありません。私の理論的根拠は、プロジェクトの作業を表すビューを取得するために、ラベルを適切に使用し、複雑なフィルターを使用する必要があるため、ボードが複雑になることです。
プロジェクト以外の問題を削除するように依頼するのは間違っていますか?
付け加えると、ほとんどすべてのチームがこのようなものを削除して喜んでいます。異議を唱えているのは特定の1人のキャラクターにすぎません。
Jiraは チームの作業管理を支援する を目的としたツールです。したがって、チームワークに使用することを意図しています。あなたはより具体的にプロジェクトの仕事に興味があるようです。
これらの2つの次元(チームvs個別xプロジェクトvs非プロジェクト)を考慮に入れる:
ホリデーやその他の欠席はチームには関係ありません。これはスコープ内のタスクではありません。これは容量管理にのみ使用され、これはJiraが設計したものではありません。
あいまいな点は、プロジェクトに必要な個別のトレーニングだけです。ここでは、両方のオプションの引数を見つけることができます。
それは、チームが必要だと感じる可視性とトレーサビリティのレベルに依存します。
あなたが言及することのいくつか-コールローテーション、会議、休日-は、どのトラッカーの問題よりも、カレンダーにはるかに適しているようです。
会社に関連するタスクや学習目標などは、おそらくJiraで追跡できます。これにより、可視性が向上し、チームのキャパシティを確認するのに役立つケースをどのように構築できるかがわかります。
私の個人的な哲学は、Jiraプロジェクトは特定の製品またはサービスに相当するということです。チームが構築中のソフトウェア製品以外のものを追跡したい場合は、適切な課題タイプとワークフローを使用して1つ以上の他のJiraプロジェクトを作成し、関連するプロジェクト全体でデータをプルするダッシュボードとボードを作成することをチームに奨励します。
結局のところ、あらゆるコンプライアンス上の懸念を除いて、チームは可能な限りツールとワークフローを制御できます。