redmineの文化を考える
= 状態遷移と役割を考える =

不倫は文化だ…
昔私はそう言った。
そう、redmineも文化があり、作らなくてはダメである。

redmineの文化とはなんだろうか？
自由主義のredmineでは開発者すべてが自分の文化(ルール）で使うこととなる。
それは大変危険なことである。開発者が異なれば文化が違う。
そう言った場合に新人が参加した場合は誰の文化に従う？
そう言う前に文化を決めることが重要になるわけである。

今回は最低限の文化(そろそろルールにするべきか考える)を決める事を考える。
最低限のチケットのスレートマシン図を下に書いておく。

はい、これに関して突っ込む部分は少ないだろう。
人によっては、終了ではなく”解決”と言う人も居る。
”解決”をテスターのテスト待ちと考えるなら重要なファクタである。
この”終了”と”解決”を考えた場合、試験を実施するか？しないのかである。
試験を失敗した場合には、再作成（フィードバック）が発生すると考えられるからである。
試験を考えると以下のステートマシンになる。

こうなりますね。

そうなると？
遷移は次になります。

• [“新規” -> ”進行中”　]
• [ “フィードバック” -> “進行中”]
• [“進行中” -> “解決”]
• [“解決” -> “終了”]
• [“解決” -> “フィードバック”]

この循環をredmineに設定しておけば、勝手なルール “進行中” -> “終了”　というのは設定できなくなります。
決められるステータスルールをロール別に考えると
開発者は試験(この場合は結合・総合試験)を実施することはない、
開発者は?

• [“新規”->”進行中”　]
• [ “フィードバック” -> “進行中”]
• [“進行中” -> “解決”]

この３つの権限が考えられます。

テスターは？

• [“解決” -> “終了”]
• [“解決” -> “フィードバック”]

の２つを変更することになる。

さて、解決ってなんやねん！となるでしょう。
そう言う場合はredmineの状態名称を変えましょう”解決？”　”試験待ち”でしょう。
“フィードバック”？ “修正待ち”でしょう。

さてさて、ここで、“フィードバック”を考えると、ここではバグが発覚するわけですわな。
そうするとバグ票を発行されるわけですから、バグのチケットを発行します。
そして、循環に使っていたチケット（ステータス”フィードバック”)のに対してバグ票チケットを付ける。
取り付けたバグ票チケットはメインの機能チケット（循環チケット）に関連として紐付ける。
そうすれば、バグの集計に便利だ…ろうな！

とかとか、もうちょっとノウハウ部分ってのがあるのでもう少しネタを引っ張ろう
ともあれ、今回は権限とステートマシンはそんな感じで最低限を決めれば楽に運用ができるだろう。

権限:開発者/テスター/管理者がどれがどの遷移をいぢれるのかはちょっと考えてください。
すべての人に管理者権限が必要である必要もありません。