Trac vs Redmine！導入に悩む人のための7つの比較ポイント
世の中には相反するものが存在します。例えば、ゴジラとモスラ。アジャイルとウォーターフォール。目黒と目白。アルジェリアとナイジェリア。そして、RedmineとTrac。 デブサミで大盛況だったチケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかですが、各ユーザ同士の戦いを期待した人も多かったと思います。しかし、@ryuzeeさんの[Trac]デブサミでITSに関するセッションに登壇しました #devsumiにまとめられているように、ツールは「やりたいこと」を考えて利用し、それを「使う人が改善していくこと」が大切なので、戦わせるのはとても難しい。 はじめに 私世代の人間ならば、「孫悟空とドラえもんはどっちが強いか」といったことに興味を持ってしまい、RedmineとTracもガチンコ勝負させたくなるものです。また、チケット管理シ
Tracで、昨日クローズされたチケットの一覧をみたい - （ひ）メモ
修正後の動作確認のためとかに。 チケット見る→レポートの登録の、レポートのクエリに: select id as ticket, summary, changetime as modified ,milestone , owner as __group__ from ticket where status = 'closed' and changetime > strftime('%s','now','-$WITHIN day') order by owner desc, changetime descと入力して保存して、/report/13?WITHIN=1 とかにアクセスすればOK ご察しの通り、?WITHIN=3 とすればここ3日以内にcloseされたチケットの一覧が見られるでやんす。
RedmineやTracを上手に活用する6つのポイント
photo credit: Mackトラ ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。 ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。 しかし、あまり深く考えずに導入すると、 「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声 「この課題って本当に終わってるの？」といった疑心暗鬼 「このタスク、誰も進めてなかった！」という驚愕の事実が期限前日に判明 などといった状況に陥りがちです。 ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。 ポイント1 チケット項目はマ
006 Tracマクロを3つだけ覚えれば梅雨でも仕事が楽しくなる - EC-One ナレッジセンター レスキューサービス ブログ
こんにちは！id:EC-OneのAkiです。 昨夜の雨はすごかったですね、梅雨でもじめじめせずに楽しく過ごしたいものです。 Tracで楽しくプロジェクト管理 EC-One（イーシー・ワン）ではプロジェクトによって、ソースコードやタスクの管理にTrac&Subversionを使っています。 Trac&Subversionに精通したエンジニアだけでなく、プロジェクトに関わる人みんなにTracを活用してもらうには、やはり「楽しさ」が重要ですよね。そんな訳で今日は「覚えると仕事が楽しくなる3つのTracマクロ」についてお話しします。 1. 見出しの一覧を目次のように表示してくれるPageOutline TracWikiの一番上に以下のマクロを書くと、見出しが自動的に目次化されます。 [[PageOutline]] 実際使う特には、例えばこのように書くと [[PageOutline]] = Trac
そろそろTracのワークフローについて語っておくか - almost nearly dead
思いのほかワークフローに言及する人が少ないので、この辺で少し語ってみることにしてみる。 0.10までのtracは基本的には new → assigned → closed という非常に貧弱で単純。 これに対処すべくTracの利用者の多くは、管理者以外はチケットクローズしないという運用ルールを決めたり、実装者にクローズさせておいて確認日を入れるカスタムフィールドを用意して対処したり、とりあえず人に優しいとは言えない状態でした。 まぁ当然この貧弱さは問題視されていなかったわけではなく、0.11へのバージョンアップでワークフローがカスタマイズ可能になり問題を解決することが可能になっているわけです。 0.11では デフォルトワークフローの変更 これは assigned の後に accepted というステータスが追加になりました。 これにより0.10以前では把握が難しかった着手・未着手の状態が、
Tracチケットのテンプレートを管理するTicketExtPlugin - 現場のためのソフトウェア開発プロセス - たかのり日記
Tracでは、要件やバグ、タスクなどといったチケットの分類を定義することができます。そのような分類を分ける場合、分類毎にチケットの内容を定義できると便利です。 例えば、Tracではカスタムフィールドを定義することが可能ですが、要件やバグの分類でそれぞれ利用するフィールドを変えたり、説明のフィールドに記述する内容を変えたりといったことです。 しかしながら、Tracではそのような指定ができません。 チケットの分類は指定できるのですが、チケットの内容は1パターンだけであり、利用しにくいところ。 そこで、Tracのプラグインを作成し、TracHacksに登録しました。 TicketExtPlugin このプラグインでは、以下のことが可能です。 チケット分類に応じて、説明フィールドにテンプレートを適用 チケット分類に応じて、カスタムフィールドの有効／無効を設定 WebAdminから、テンプレート定義
LDAPでTracの認証と権限の管理を行う - 現場のためのソフトウェア開発プロセス - たかのり日記
今日は久しぶりにいい天気でしたが、夜には、また急激な雨。個人的には涼しいのはうれしいのですが、なんか日本の気候も大分変ってしまった感じですね。 さて、Trac0.11がリリースされたこともあって、何かと調査しているのですが、今回はLDAPに関する情報についてです。 Tracでは、LDAPを利用して認証や権限の管理を行うことができます。大規模に利用したい場合、LDAPでユーザ認証や権限の管理ができるのはとても便利です。 認証については、apacheの認証機能を利用して比較的簡単にできるのですが、権限はLDAPのスキーマが関連しており、設定が複雑です。いろいろ調べて実現できるようになったのですが、情報が少ないのでまとめておきます。 動作環境 以下の環境で検証を行いました。 Windows Vista TracLightning 2.0.6 Trac0.11 Apache 2.2.8 Pytho
2008-01-29 - やっとむでぽん - tracプラグイン/マクロ/パッチ一覧
Trac Hacksに登録されているプラグイン、マクロ、プロセッサなどに、日本語でひとこと説明をつけた一覧です。基本的にTrac-Hacks上の説明を読んで書いているので、実際に動かしていませんし、勘違いもあると思います。 もともと10月くらいからちょこちょこ作っていたリストなので、情報は最新ではありません。しかもまだ半分も書けてないうえに、変なエントリも混じってますが、なにかの役に立つといいなーと思って公開します。 後々どこかへ移動するかもしれません。誰でも編集できるWikiとかに載せたほうが役に立つかも(Trac-Hacksに載せるとか？)。 AccountManagerPlugin ・ユーザアカウントの管理。 ・フォーム認証。 ・ユーザが自分でパスワードを変更、アカウント削除できる。 AcronymsPlugin ・アクロニム(略語)を登録しておくと、自動的にHTMLの<acrony
第4回 Tracではじめるバグ管理入門
「チケットは開発を救う」と考え，2007年のITpro Challenge!にてチケット駆動開発を提唱した。Tracを使う最大の利点はチケットとリポジトリ・ブラウザを連携できることだと考えている。 前回（第2回～第3回）までの連載で，Tracのインストールと基本的な設定が終わりました。これからの連載では，Tracを上手に運用するためのコツをご紹介していきます。 Tracの主な機能には，Wikiとリポジトリブラウザ，それにチケットによるタスク管理システムがあります。Wikiとリポジトリブラウザは使っていても，チケットは使っていないという方は意外に多いのではないでしょうか。そこで第4回では，チケットの一番の用途である「バグ管理」について説明します。今回の説明には，Trac 0.11（日本語版）が含まれるTrac Lightningのバージョン2.0.4を使用しますが，基本的な考え方は以前のバー
[trac]勤務状況をレポートしてみる - おちこぼれSE日記
「規則正しい生活をしよう」などと、ひと月程前に書いたような記憶もあるが... ブログにはりつけている「早起き生活」のグラフを見ればわかるとおり、ここ一ヶ月は惨澹たる状況でした。 うちの会社はプロジェクトごとに収益管理を行っていて、2週ごとに各プロジェクトに関わった工数を申告する仕組みになっている。 一つのプロジェクトに集中できれば「労働時間=工数」となり問題はないが、複数のプロジェクトに関わっていたりすると、申告のときにどのくらいの比率で関わったか、とか、いろいろ調整するのが面倒だったりするので、今月から労働時間をtracに実績時間として入力するようにしてみた*1。 で、tracでレポート出力するとこんなイメージになる。 上から4,5番めが僕の本来の業務、ここ二週間は他のプロジェクトサポートが多かったことがわかる。 ちなみに、この業界、普通一週間は40Hだよね? このレポートを出力するSQ
![[trac]勤務状況をレポートしてみる - おちこぼれSE日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/2fdb21e2d5462e7a32cdc54763c937496dcae025/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fr%2Fraptor555%2F20071101%2F20071101223239.png)
やどりぎ@NET: trac + TracBurndownプラグインでスクラム開発のすすめ
ソフトウェア開発手法とその管理システムには様々な選択肢がある。私もこれまで色々試行錯誤してきたのだが、今は、tracとバーンダウンチャートを追加するプラグインであるTracBurndownプラグインでスクラム開発という環境が気に入っている。 この環境を導入したきっかけは、転勤で勤務地が変わったことである。 これまで、東京でチームを組んでソフトウェア開発をしており、その仕事を引き続き仙台で行うことになったが、今までの開発プロセスだと不都合が出始めた。 タスクカードを使った「かんばん方式」とスクラムをベースにした開発プロセスを組み合わせて使っているのだが、物理的に開発拠点が分離してしまい、タスクカードが使いにくくなってしまったのである。 いいタイミングなので、周囲の評価が高いので試してみようと構築していたtracにバーンダウンチャートのプラグインを導入して、全面的に移行することにしたという訳だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20090911/p01/
http://www.machu.jp/posts/20090301/p01/