There are No Perfect Redmine
There are No Perfect Redmine - Presentation Transcript Redmine Junya Ogura <juno@sooey.com> Jun 12, 2009 Saturday, June 13, 2009 Redmine 18 projects 1,696 tickets 22 users 2008.10 Saturday, June 13, 2009 • Junya Ogura ( ) • • PHP, Ruby, Java id:juno sooey.com twitter.com/junya github.com/juno Saturday, June 13, 2009 • Trac • • Textile • CSV • • Saturday, June 13, 2009 Trac Saturday, June 13, 2009
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
脱Excel！ Redmineでアジャイル開発を楽々管理
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
recompile.net: サン流だけど一流のバグ管理心得
Java EE 5のStar Spec LeadであるBill ShannonがGlassfishのメーリングリストにバグの考え方の話を投稿してたんで、勢いで翻訳しちゃう。 大規模開発のときのバグ管理の心構えとしても興味深いですね ちがう、ちがう、ちがう。 バグポートフォリオをどうやって使うのかを、また説明しなきゃいけないようだね。もう毎回ずっと、ああもう、8年くらい？ リリースのたびに説明してこなかったっけ？ バグにそもそものプライオリティなんかないんだ。バグはプライオリティとともにうまれるわけじゃない。バグのプライオリティってのは、我々の決定なんだ。単なる技術的な決定じゃない。単なるバグの影響度でもない。単なる重大性でもない。バグは、リソース、ビジネス上の判断なんかによって、決定されるもんなんだ。 バグの優先度は、意思決定プロセスの結果なんだよ。つまり、どれがバグで、どれがバグじゃない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
