Tracを使い始めて2年近くなりますが、バグトラックとしての使い道以外に、タスク管理の観点からTracの利用を推奨する記事もちらほら見かけたります。 実際に利用していると、タスク管理で使った方が便利であることも多かったりします。 または、ナレッジ管理のような側面で使うのもありかなとか。 開発の現場においては、構築する機能やモジュール単位、テストフェーズでのバグの報告とその対応などに使われたりもしますが、開発後の保守・運用のフェーズに入ると業務の内容ががらっと変わるために、そういう使い方もあまりしなくなります。 構築というよりは、機能の改善や運用の中で見つかった不具合への対応などが中心になってきますので、必然的にその要望や対応時のタスクの管理というものが色濃くなったりします。 後述しますが、保守・運用の中で業務の役割も違ってくるので、チケットの粒度もまた違ってくることにもなったりします。 開
Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。 デブサミ2011では、[デブサミ]速報：2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。「チケット管理システム大決戦」というセッションは、デブサミ史上最大の観客数となったと聞いています。 なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか？ 開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、「作業を適切なサイズに分割する」「優先順位をつける」「人をアサインする」という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
インストール後の設定などをまとめる。 困ったらReadmeを参考ください。 ユーザ デフォルトでは「admin/admin」でログインできる。ユーザを追加してあとで削除しておくこと。 ユーザの追加・削除 「TRAC_ROOT\admin\apache」へ移動。 >adduser ユーザ名 パスワード で追加できる。削除は >removeuser ユーザ名 パスワード プロジェクトの作成 プロジェクト作成は以下のコマンド cd TRAC_ROOT\admin\traccreate-trac-env.bat "藤原プロジェクト" fuji001 引数1がプロジェクト名称。引数2がプロジェクトIDとなる。 しかし、なぜかこのバッチがうまく動かず、プロジェクトIDがdefaultになってしまった。そこでこの「create-trac-env.bat」の最初のif文の前（13行目ぐらい）に「set P
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
Trac Lightningは、Windows環境用のTracのオールインワンパッケージです。Tracは、Webサーバやバージョン管理ソフトといった複数のソフトウェアと組み合わせて使う必要があるため、サーバ環境を構築するための敷居が高いといわれていましたが、Trac Lightningを使えば、簡単に動く環境を構築できます。 Trac Lightningに含まれるもの Trac Lightningには、Tracを使うために必要なソフトウェアが一通り含まれています。Trac Lightningに含まれるソフトウェアには、Tracの日本語版であるTrac-jaをはじめとして、Apache HTTPサーバ、Python、バージョン管理ソフトSubversionといったTracを動かすために必要となるソフトウェアが挙げられます。さらに、Tracを便利に使うための数多くの有用なプラグインも含まれてい
最小限の管理コストで最大の「見える化」を 近年「開発の見える化」が話題となっていますが、いざやろうとするとなかなか難しいものです。 模造紙を壁に張り付ける「タスク看板」などを利用してタスクの「見える化」を行っても、肝心のタスクの実行状況が見えなかったり……。そんなことはないでしょうか？ 本当にチームメンバーのタスクを把握できているでしょうか？ そもそも「タスク」とは、コーディングやテストといった純然たる作業や、故障処理、管理、仕様変更などの副次的な作業も含みます。開発を見える化する際に基本となる1つの単位です。 今回紹介するMylynとTracを利用すると、タスク取得→コミット、タスク取得→コミット、……というリズムに乗った開発で、作業履歴（ログ）を残しながら各開発担当者の作業内容を明確にできます。最小限の管理コストで最大の見える化を。世にも不思議なMylynマジック、とくとご覧ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く