バグ管理でTracを使う場合、各ベンダーでそれぞれカスタマイズしていると
思いますが、中企業以上、あるいは大企業の下請けとして利用するバグ票
のカスタマイズは思ったより大変な作業で、Tracに習熟した人がいないと
カスタマイズは面倒だと思っています。
そこで、ある程度使える雛形を作成して、テンプレートとしてTracに組み込み
できるようにしたいと考えています。テンプレートにより面倒なカスタマイズコスト
の削減と、色々な人のノウハウが詰まったバグ管理ができるようになると嬉しい
と思っています。
何人かの方に意見を聞きながら下記のWikiにまとめているのですが、みなさんの
ご意見をいただければと思っています。
http://trac.ultimania.org/trac/BugTracker
項目やフローの整理の部分はTrac/Redmine問わず利用できるので、デブサミの
勉強会のネタとして話をしてみるのもいいかと思っています。
整理しようと思って、ページを作るだけ作って時間が取れないのでいるのですが、
どなたか、旗を振って整理していただける方はいませんか?
(色々な人に意見を聞いてまとめるでokです)
ぶしつけなお願いですが、よろしくお願いします。
--
Takashi Okamoto
下記の件ですが、特に興味がある人がいなければ、一旦プロジェクトを
削除したいと思います。(その場合、社内のプロジェクトだけで使うことになると
思います)。
協力いただける方があれば、一緒にシェアしたいと思いますが、一人で作りこんだのを
公開するのは結構グレーゾーンなので、取りやめたいと思います。
よろしくお願いします。
2011年1月27日2:49 Takashi Okamoto <tora...@gmail.com>:
--
Takashi Okamoto
折角ので幾つか質問宜しいでしょうか?
1. 目的はなにか?
Tracは単体で不具合チケットに関するワークフローは可能かと思います。
その上でこのプロジェクトでの目的はどこにあるのでしょうか?
実際の運用フローにかんすることでしょうか?
その辺が良くわかりませんでした。
2.対象とするプロジェクトはなにか?
対象とするプロジェクトの分野・規模・形態などを教えてください。
例えば、受託と自社プロダクトでは最適解は異なると思います
興味深い試みと思いますので、是非このまま進めて戴ければと思います。
--
================================
Shuji Watanabe (skypeId: shuji.w6e)
Blog:
http://d.hatena.ne.jp/shuji_w6e/
Labo:
http://www.deathmarch.jp/
Community:
http://www.sapporo-java.org/
おかもとです。興味を持っていただいてありがとうござい舞う。
目的は
「TracLighntingで使えるテンプレートを用意して現場のバグ管理の手助けをすること」
で、ゴールは、
・整理されたワークフロー
・管理項目の定義(カスタムフィールドの定義)
・レポートの定義(ReportIncludeプラグインによるグラフ含む)
です。
対象とするプロジェクトですが、特に考えていません。考えようとして、バグ管理は
プロジェクトの規模、形態、工程により大きく異なるので、どこを対象にするべきか、
自分でも分らなくなってきました。
逆にみなさんはどのようなバグ管理の仕組みがあると嬉しいでしょうか?
ちなみに、私自身は業務でバグ管理する分には、既にバグ管理システムが用意され
ているから困りません。Tracでやってみたいなぁという思いはありますが。
そういう意味で、みなさんは、既に何らかなのバグ管理システムを導入しているので、
困っている人は、実はあまり居ないのかも...
ちなみにワークフローは、LaunchpadのワークフローからTriagedを抜いたものを採用
しようと思っています。
http://blog.launchpad.net/general/of-bugs-and-statuses
最後発のOSS開発プラットフォームだけあって、よく考えられています。
自分が思い描いてる理想に近いですね。
.
2011年1月30日18:17 Shuji Watanabe <shuj...@gmail.com>:
> --
> このメールは Google グループのグループ「Shibuya.trac」の登録者に送られています。
> このグループに投稿するには、shibuy...@googlegroups.com にメールを送信してください。
> このグループから退会するには、shibuya-trac...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/shibuya-trac?hl=ja からこのグループにアクセスしてください。
>
>
--
Takashi Okamoto
かおるんです
今のところ、ここまできちんとした形でのチケット運用はしていなかった
のですが、できることがあればお手伝いさせてください。
2月からTracを使った自社パッケージ的なところに加わる予定ですので、
そこでのフィードバックを入れたり結果を取り入れたりできればと思っています
2011年1月30日21:47 ちょび <tyob...@gmail.com>:
> --
> このメールは Google グループのグループ「Shibuya.trac」の登録者に送られています。
> このグループに投稿するには、shibuy...@googlegroups.com にメールを送信してください。
> このグループから退会するには、shibuya-trac...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/shibuya-trac?hl=ja からこのグループにアクセスしてください。
>
>
--
かおるん@なかむら かおる
mailto:kaor...@gmail.com
blogto:http://d.hatena.ne.jp/kaorun55/
twitter:http://twitter.com/kaorun55
Twitterで「バグ管理表の書き方って実は隠れた人気セミナー」とつぶやかれている方がいて、はぁ~確かにそうかもしれないな、と思いましたが、手元によいテンプレートなどあるはずもなく、ご協力できる点がありません。。。
でも期待してます。
2011年1月30日日曜日 中村薫 kaor...@gmail.com:
しばらく放置していたバグ管理ですが、一旦、「ばぐものがかり」としてサンプル実装を行いました。
フローというよりは、分析の観点からまとめています。
[バグ収束曲線]
http://kanon.ultimania.org/trac/kanon/report/9
[バグ傾向分析]
http://kanon.ultimania.org/trac/kanon/report/10
このあたりもオープンソースカンファレンスでデモしたいと思っています。
(というか、上記のURLそのままですが...)
管理項目については、引き続きまとめて頂ける方を募集します。
管理項目は、できれば、コミュニティでまとめたものを業務で使ってみたいと
思っていたのですが、業務の方は自分でまとめてしまったので、私にとっては
必要性が薄くなってしまいました。
しかしながら、必要性を感じている方は沢山居ると思いますので、是非自分が
まとめてやってみよう、という方を募集します。
よろしくお願いいたします
奈良先端大の森崎先生がこんなエントリを出されました。
RT @smorisaki: これはなかなか手厳しいなぁというバグ報告をみたことがありませんか?そんなバグ報告のやってはいけない集を集めようとしています。詳細をエントリにしましたhttp://bit.ly/dQLGxB