Redmainは、これまでいろいろな開発で、さまざまなチームやメンバーと使ってきましたが、
チームやメンバーそれぞれに、使い方の独自のクセがあり、
はじめからこのように使いましょう!
みたいな共通意識的なモノは、あまりおしつけずに、なんとなくまずは使い始めるというパターンばかりでした。(後から参加するプロジェクトなどはすでにルールできていますので、あまり変更することもできませんが。。。)
最初の段階では、とにかく導入して、互いにチケットを発行して、それを潰していくという、実作業を行い続けるのがよいかと思います。
その中から、結果として、このようにしようか?みたいな暗黙のルールが出来てくるよな運用が楽かと。
またメンバーの中に、すでにRedmine経験者がいらっしゃるなら、まずはその方のルールをスタンダードにするという程度でよいかと思います。
(このような曖昧で許されるかどうかは、わかりませんが、、、)
そのような中で注意というか、意外と、こんな使い方は・・・という点を書かせて頂きます。(ソフトやハードの開発でのバグトラッキング的な使い方のみですが)
・使い続ける
=>これは以外と大切だと思っています。意外と面倒がって、使われなくなって、結局エクセルの表での不具合管理にもどってしまった、案件がいくつかあります。
・必ず自分以外の担当者をつける
=>これも以外と困りもので、不具合の内容から、担当者が誰だか分からないようなときに、チケット発行者が、担当者を自分とか、入れない状態で発行されると、結局そのチケットは死んでしまいます。どのような状況でもかならず、更新時に自分以外の担当者に割り当てるというルールは必須です。
・チャットにしない
=>チケットが、チャットのようになってしまうことが多々あります。原因は、それぞれの更新の記載内容の曖昧さから来るモノです。きちんと記載すれば、このような事にはならないのですが。。。意外と発生します。
・権限(特にチケット終了)の確認
=>チケットを終了させられるのは、誰なのかはっきりしておきましょう。困った事に、やはり開発メンバーの中には、「これ直したし・・・」と、自分に割り当てられた不具合を、修正して、そのままチケット終了してしまう輩がいたりします。きちんと、検査されていれば良いのですが、、、うまく修正されていないと、結局デグレードの原因になったりします。(ただ、厳密に権限設定をしてしまうと、運用が面倒な所もでてくるので、権限は緩くして、紳士的につかえると本当はいいですね)
・同じ話題を書かない
=>いわゆるマルチポスト?みたいな状態になります。同じ不具合が何度も報告されてくると・・・担当者も嫌になってしまいます。記載する側も、同じ話題がでていないか、常にチェックしましょう。
という事で、すごくメールの量が増えるモノの、自分以外のチケットの通知もするようにしたほうが、このようなトラブルは減ります。ただ、メールが多くなるので、嫌になりますが。。。
・メンテナンス係をつける
=>チケットが放置されないよう、メンテナンス係が必要です。皆で運用しているから・・・というのは、無理です。結局自分のチケットつぶしのみに、夢中になり、放置された他のチケットは、見ないようにするのが、人間です。メンテナンス係さんが、嫌な仕事ですが、「このチケット進捗は?」と、あまり放置されているチケットには、突っ込みをいれましょう。
あと、以下は、本当に当たり前のルールですが・・・
・チケット発行する人は、誰が読んでも分かるように何が起きるのか、書かないといけない。
=>以外と、「なんちゃらのボタンを押したらフリーズした」だけみたいな、改めて深掘りが必要な書き方をされるのには、非常に困りました。過去のとある案件では技術以外の人間も混じっていて、そのような方から現象解析不明の不具合報告が・・・。困ったモノです。
・タイトルでおおよその内容が理解できるべき。
まあ、メールでもなんでもそうですが、タイトルでおおよそ、想像のつく形が理想です。
などなど、
つらつら、思いつく所書きました。
途中で、運用方法などは比較的簡単に変更できるなど、Redmineはよくできていると思います。
ぜひぜひ、活用されてください。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2015/11/08 00:19