エントリーの編集
![loading...](https://b.st-hatena.com/0c3a38c41aeb08c713c990efb1b369be703ea86c/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/0c3a38c41aeb08c713c990efb1b369be703ea86c/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
『保守・運用で使うTrac』
Tracを使い始めて2年近くなりますが、バグトラックとしての使い道以外に、タスク管理の観点からTracの利... Tracを使い始めて2年近くなりますが、バグトラックとしての使い道以外に、タスク管理の観点からTracの利用を推奨する記事もちらほら見かけたります。 実際に利用していると、タスク管理で使った方が便利であることも多かったりします。 または、ナレッジ管理のような側面で使うのもありかなとか。 開発の現場においては、構築する機能やモジュール単位、テストフェーズでのバグの報告とその対応などに使われたりもしますが、開発後の保守・運用のフェーズに入ると業務の内容ががらっと変わるために、そういう使い方もあまりしなくなります。 構築というよりは、機能の改善や運用の中で見つかった不具合への対応などが中心になってきますので、必然的にその要望や対応時のタスクの管理というものが色濃くなったりします。 後述しますが、保守・運用の中で業務の役割も違ってくるので、チケットの粒度もまた違ってくることにもなったりします。 開