それらの多くはjiraをバグトラッカーとして、さらにプロジェクト管理ツールとして使用し、タスクへの添付ファイルの形式で要件を使用して作業を構築しようとしています。
これは統計であり、その例で注目すべきことを1つ示したいと思います-そのようなチームの大多数は、彼らが持っているjira設定に不満です-あなたは常に何かを調整したい（たとえば、フォームに新しいフィールドを追加する）これは、プロジェクトの今後の作業の負担です。
問題の本質は何ですか：jiraの最も重要な利点は、フォーム、状態、ワークフロー、フィルターを構成できることです。
奇妙なことに、これは同時に最大の欠点でもあります。心理的には、ツールに設定がある場合は、設定する必要があります。 これにより、次の問題が発生します。
- タスクのフォームとワークフローはより複雑になり、システム自体との作業はより複雑になります
- 新しい設定（フォームフィールドなど）は、作成後すぐに使用されなくなり、ゴミになり、既にオーバーロードされたインターフェイスが乱雑になります
- jiraのセットアッププロセスは非常に重要なので、特別な訓練を受けた人が必要です。通常は市場で購入するのではなく、独自に開発します。
しかし、ほとんどの（まれな例外はありますが）プロジェクトの本当に必要なタスクをタスクとバグ追跡の観点から注意深く見ると、すべてが非常に単純であることがわかります-最も単純な設定で十分です。
DEVPROMプロジェクト管理システムを開発するとき、「よりシンプルで、より理解しやすく、より良く、より便利である」という原則に導かれました。
- 複雑なセキュリティモデルは思いつきませんでした。アクセス権を厳密に定義されたユーザーロール（顧客、開発者、アナリスト、PMなど）に分割するだけで十分です。
- タスクとエラーには同じワークフローがあります。実際には違いはありません。
- タスクの状態が本当に必要なのは、追加、承認、スケジュール、作業中、完了、終了、延期のみです。
そして最も重要なこと-シンプルなツールを使用する場合、プロジェクトの開発に主なことに集中する時間を確保できます。
成功への追加の障害としてではなく、アシスタントとしてのツール。