すべての管理として、これには一般的な慣行はありませんが、ここに私が個人的に使用し、私たちの会社に統合しているいくつかのガイドラインがあります.
- 要約は、問題を説明するものでなければなりません。バグ、機能、タスクなど、問題の種類を説明する単語を含めないでください。これが「問題の種類」属性の目的です。例: 「問題がないかサイトを再確認し、権限の問題を解決してください」または「テキストの修正」。
- Priority、Due Date、Environment、Component/s、Affects Vers、Fix Vers、および Labels 属性を使用するのは良いことですが、より多くの属性を定義すると、より多くの情報が問題に保持されることに注意してください。より説明的で、より管理しやすくなります。
- 説明フィールドには、正式な方法で記述された利用可能なすべての情報を保持する必要があります。
サブタスク:
これはあなたの組織に完全に依存しますが、私が個人的に報告した Greenhopper にバグがあり、現在解決されています。
「サブタスクの見積もりは、RapidBoard の計画パースペクティブのマスター タスクに表示されません」
「急速なボード スプリントで問題が発生しています。マスター課題*には独自の見積もりはありませんが、サブタスクを含めると見積もりがあります。添付のスクリーンショットからわかるように、このマスター課題を含めると、次のスプリントでは、そのすべての子課題の見積もり合計が表示されません。それらはまったく表示されません。"
そのため、サブタスクについては、この新しい (修正された) 機能を使用するようになりました。マスター タスクの見積もりは、課題のすべての見積もりの合計です。私は、マスターが非常に複雑なものである場合にのみ、個人的にサブタスクを実行しますが、私の仕事ではそれが毎日の仕事です。
これが役に立てば幸いですが、これは私の個人的な意見です。