Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。 【元ネタ】 Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog Twitter / @mkinside82: ほんとにCommit Relation Editor Pluginそっくりですね/Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine Twitter / @mkinside82: @akipii もともとチケットが上がっていたようですね ⇒ http://bit.ly/HPLVM5 @haru_iida さん
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
