TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead
今更公開した新年会の資料を「チケット駆動開発の運用例: プログラマの思索」で取り上げていただいたのですが、ちっと補足しておきますよ〜っと。 喋る用の資料であることと説明不足ですかね、修行が足りなさを痛感します。 この辺とかこの辺を良く読んで勉強し直せって感じですね。*1 チケットをExcelで一括インポート ごく初期だけで日常的な運用には使っておらず、複数のツールを使って管理するのは運用(利用)負荷が上がるだけなので、基本はtracのチケットのみで管理しています。 チケットの入力負荷の軽減を図るためにコンポーネントだとかチケットタイプ・関係者などの定型的な情報をリンクにパラメータとして埋め込んでwikiにまとめてあります。チケット分類によってはチケットの中身までテンプレート化して用意しているパターンもあります。 Tracで工数を入力、集計 これは何度か触れてますがTimingandEsti
そろそろTracのワークフローについて語っておくか - almost nearly dead
思いのほかワークフローに言及する人が少ないので、この辺で少し語ってみることにしてみる。 0.10までのtracは基本的には new → assigned → closed という非常に貧弱で単純。 これに対処すべくTracの利用者の多くは、管理者以外はチケットクローズしないという運用ルールを決めたり、実装者にクローズさせておいて確認日を入れるカスタムフィールドを用意して対処したり、とりあえず人に優しいとは言えない状態でした。 まぁ当然この貧弱さは問題視されていなかったわけではなく、0.11へのバージョンアップでワークフローがカスタマイズ可能になり問題を解決することが可能になっているわけです。 0.11では デフォルトワークフローの変更 これは assigned の後に accepted というステータスが追加になりました。 これにより0.10以前では把握が難しかった着手・未着手の状態が、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
