TracやMantisによるチケット駆動開発の運用方法 - プログラマの思索
最近、RedmineではなくてTracやMantisを使う機会が多い。 チケット駆動開発をTracやMantisで運用する方法について考えたことをメモ。 【チケット駆動開発を運用する時の注意点】 Redmineでなくても、TracやMantisでもチケットをXPのタスクカードのように扱うことはできる。 BTSのチケット管理をプロジェクト管理に置き換える発想は、Redmineの場合と変わらない。 しかし、Redmineに比べると、TracやMantisによるチケット駆動開発とAgile開発を組み合わせて運用するためには、いくつかのノウハウが必要だ。 僕の経験では、Redmineに比べるとTracやMantisは、イテレーション管理とSCM連携がやりにくい。 【1】Agile開発の基本である小規模リリースを実現するには、イテレーションをBTSに実装しなければならない。 Redmineなら、バー
これから使うならTracとRedmineどちらがよいか？ - プチ技術メモ
Tracを約一年、その後Redmineを約一年使った経験から言うと、これから使うならRedmineの方が断然いいと思います。 機能面では、それぞれに一長一短があるので、どちらが優れているかは人それぞれかと思います。一番の問題は、Trac本家のバージョンアップが、ここ数年停滞していることです。 とりあえず、直近３件のメジャーバージョンアップのリリース日を比べてみると次のようになります。なお、リリース日は、それぞれの本家リポジトリにタグが打たれた日としています。 Redmine Trac 0.9.0 2010-01-10 0.11 2008-06-22 0.8.0 2008-12-30 0.10 2006-09-28 0.7.0 2008-04-30 0.9 2005-10-31 ちなみに、Tracの0.12のリリース予定は2009-12-01となっていますが、大量の未解決チケットが残っていて
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
Shibuya.trac 2009新年会（2）とある会社でのTrac利用事例
2009年1月24日，有限会社シェアグリッド研修室で行われた，Shibuya.trac 2009新年会。この動画は，SourceForge id:kanuさんのセッションです。
Trac(0.11.5) って重すぎやしませんか - 肉とビールとパンケーキ by @sotarok
てことで色々試してはみたんだけど，どうにもこうにも重すぎる気がします．誰か良い方法を知ってませんか？ ためしてみたこと mod_python -> mod_wsgi うーん，心無しか速くなった気も．．． でも劇的な改善，みたいなものはないですね．所詮は Trac 本体そのものが重いんでしょうか． 考えられるものとして，DBへアクセスする部分が非常に重い（特にTimeline系とか）ので，色々情報とってきてほげほげは重いのかもしれない．timelineに表示する日数減らすとか情報減らすとかすれば少しは改善するかも．一応SQLiteの中身も見てみたけどIndexは張ってあるくさいしなあ． あと，WSGIをデーモンプロセスモードで動かしてみるとかいうこともやってみました． こうすると，DBへのアクセスが頻発するページ以外はたしかに爆速に！！！ ところが，Tracつかってるとしばしばおこる，DBが
RedmineとTracの機能比較part2～ポータビリティ、プラグインなど - プログラマの思索
あるTracユーザの話を聞いて、RedmineとTracの機能の違いを感じたので、考えたことをメモ。 【1】ポータビリティ(環境の持ち運び)はTracが勝る TracLightningでは、SQLLite＋SVNが一つのフォルダに存在するから、バックアップが簡単。 Tracはそもそも１プロジェクトしか扱えないので、1プロジェクトのTracDB(SQLLite)を持ち運んで同期を取ればいい。 しかし、Redmineでは、DBはMySQLが普通だから、バックアップや持ち運びはOracleのような操作が必要になる。 また、複数プロジェクトを扱っているから、1個のプロジェクトだけ持ち運んでも同期がとりにくい。 特に、客先と自社で受託開発のタスク管理をする場合、USBメモリでSQLLiteのDBを持ち運びできればすごく簡単だなと思った。 RedmineでもSQLLiteを扱うことはできるが、チケット
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
Shibuya.trac 2009新年会（5）さらにもう一つのTDDによるTrac Lightning2.1の新機能
Shibuya.trac 2009新年会（1）Trac導入事例(管理ツールとしてTracを使う)