web-dev-qa-db-ja.com

あなたのチームは、JIRAで行うすべてのことを行う必要がありますか?

私は、カンバンタイプのフレームワークにJIRAを使用しているスクラムマスタータイプの役割のチームで作業を開始しました。過去6〜12か月間、彼らはJIRAを使用してほとんどすべてのことを行ってきました。これには、通話中の人の追跡、トレーニングなどの人事/個人的なタスク、リーダーの個人的な開発目標の設定、定期的にスケジュールされた会議、休日まで含まれます。

私の現在の考え(そうでないと確信して幸せです)は、これはJIRAの最適な使用方法ではありません。私の理論的根拠は、プロジェクトの作業を表すビューを取得するために、ラベルを適切に使用し、複雑なフィルターを使用する必要があるため、ボードが複雑になることです。

プロジェクト以外の問題を削除するように依頼するのは間違っていますか?

付け加えると、ほとんどすべてのチームがこのようなものを削除して喜んでいます。異議を唱えているのは特定の1人のキャラクターにすぎません。

2
Spionred

Jiraは チームの作業管理を支援する を目的としたツールです。したがって、チームワークに使用することを意図しています。あなたはより具体的にプロジェクトの仕事に興味があるようです。

これらの2つの次元(チームvs個別xプロジェクトvs非プロジェクト)を考慮に入れる:

  • プロジェクト作業が含まれている必要があります。
  • チームに関連する非プロジェクト作業が発生する可能性があります。典型的な例は、最初のリリース後に予期しない問題を解決するためにチームが要請された場合のサポートアクティビティです。 issue type に基づいてフィルタリングすることで、カンバンボードの選択から除外することができます。以下の議論は、これらを かんばん コンテキストで維持することを支持して語っています:
    • 非プロジェクトとプロジェクトの作業の違いは難しい場合があります。リクエストするのはバグですか?開発すべき未対処の要件?または他の種類のサポート?チームの作業を完全に把握できるように、タスクをよりよく理解してください。
    • レーダーでプロジェクト以外のサポート活動を行うことは、正しい判断を下すのに役立ちます。より多くの人が必要ですか?これらのサポート活動は、作業明細書/チームの範囲に含まれていますか?
    • これらのアクティビティがチームの範囲内にあり、Jiraを使用しない場合は、別のツールが必要になる可能性があります(たとえば、多くのITSMリクエストおよびインシデント管理ツールの1つ)。しかし、その場合、チームは追加のツールを学習する必要があり、これによって効率が向上するかどうかはわかりません。
  • チームに関係のないプロジェクト以外の作業は避けてください:
    • まず、個人的な問題は個人的なものである必要があります(ヨーロッパでは [〜#〜] gdpr [〜#〜] は、開発ツールに人事関連の要素を配置することに対する法的な議論でさえあり得ます。同じ効果を持つ他のプライバシー規制である)。
    • 次に、チームメンバーが別のチームに移動した場合はどうなりますか?すべての彼/彼女の個人的なタスクで何が:これは人(アイテムを失うことではない)とチーム(それらがまだ関連しているかどうかを確認するためにオープンアイテムを分析する)の両方の問題になります。

ホリデーやその他の欠席はチームには関係ありません。これはスコープ内のタスクではありません。これは容量管理にのみ使用され、これはJiraが設計したものではありません。

あいまいな点は、プロジェクトに必要な個別のトレーニングだけです。ここでは、両方のオプションの引数を見つけることができます。

2
Christophe

それは、チームが必要だと感じる可視性とトレーサビリティのレベルに依存します。

あなたが言及することのいくつか-コールローテーション、会議、休日-は、どのトラッカーの問題よりも、カレンダーにはるかに適しているようです。

会社に関連するタスクや学習目標などは、おそらくJiraで追跡できます。これにより、可視性が向上し、チームのキャパシティを確認するのに役立つケースをどのように構築できるかがわかります。

私の個人的な哲学は、Jiraプロジェクトは特定の製品またはサービスに相当するということです。チームが構築中のソフトウェア製品以外のものを追跡したい場合は、適切な課題タイプとワークフローを使用して1つ以上の他のJiraプロジェクトを作成し、関連するプロジェクト全体でデータをプルするダッシュボードとボードを作成することをチームに奨励します。

結局のところ、あらゆるコンプライアンス上の懸念を除いて、チームは可能な限りツールとワークフローを制御できます。

1
Thomas Owens