アジャイルなレビューをサポートするツールを5つ
Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie
Redmineに負けないようにTracのワークフロープラグインを作る - いつまでもとりあえず
Redmineに負けないために必要なことをまず調べる。このページを見ると、RedmineはTracker(チケットの分類)と,role(権限でいい)の二つの種類別に、元->先ステータスを選んでいく仕組みになっているようです。ただ、チケットの分類が山ほどあれば山ほどクリックしていかないとダメなんじゃないかと思うんですけど…これが設定しやすいと言っている人が多いんだから、なんか、私が想像しているよりもすばらしいやり方があるんでしょうかね。 Tracでは、標準のConfigurableTicketWorkflowでは権限に対応していで、そのほかにAdvanced Ticket Workflow PluginのTicketWorkflowOpTriageでは(マイルストーンとか何でもアリなんだけど)チケットの分類で、ワークフローを分岐できるようになっている。次のように設定したとして、分岐先が、ag
ITS大決戦〜JIRA vs Redmine vs Trac〜 - White scenery @showyou, hatena
そもそも発端は先日のデブサミで上記のタイトルの発表があったのですが*1、比較的ぬるめな内容で「どのツール使ってもいいからExcel消しましょう」というヌルい結論で終わってしまってたので、 こういうことをうっかり言ってしまいました。 そしたら今日のShibuya.ChiliprojectTracで 晒し上げにあったorz http://www.slideshare.net/SeanOsawa/ss-6974319 というわけで導火線に火をつけたようなのでガチで比較を行っていくみたいです！ http://confluence.atlassian.co.jp/display/ATL/Comparison+of+issue+tracking+systems 余談 よくTracのメリットで「Windows版のインストールが楽」ってのがあるんだけど、実はRedmineも一括インストーラがあって(しかも
BTSのワークフローと解決状況とカスタムフィールド - wyukawa's diary
それぞれのBTSのワークフローはなかなか特色があるね。 Tracのワークフローは以下のようになります。 new（新規） → assigned（アサイン済み） → accepted（受け入れ済み） → closed（クローズ） TracWorkflow – The Trac Project TracはResolution（解決状況）がある。 解決状況についてはこちらが参考になる。 BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索 Tracの後発のRedmineのワークフローは以下のようになります。 New（新規） → Assigned（担当） → Resolved（解決） → Closed（終了） 課題管理システム - Redmineガイド Redmineは解決状況は無いですが、Redmine本家のサイトはカスタムフィールド作ってやっているようです。 Seasa
【公開】デブサミ2011でチケット駆動開発とチケット管理システム大決戦セッションで話します #tidd - プログラマの思索
【元ネタ】 創発 未来につながるために 世界に帆を立てるために Developers Summit 2011 セッション内容～創発 未来につながるために 世界に帆を立てるために Developers Summit 2011 【17-B-3】チケット駆動開発～タスクマネジメントからAgile開発へ～ 最近、RedmineやTracのような高機能なBTS(バグ管理システム)をソフトウェア開発のタスク管理に適用して、アジャイルに開発する「チケット駆動開発(TiDD：Ticket Driven Development)」が静かに広まっています。 チケット駆動開発は細かな作業をチケットで管理することから生まれましたが、アジャイル開発と関連する点が多いことから、アジャイル開発をブラッシュアップする技術としても、利用されるようになりました。 本講演では、ソフトウェア開発の歴史におけるチケット駆動開発の意
redmineで案件を回したいんですよ!! - お前の血は何色だ!! 4
redmine さんでどうやったら綺麗にプロジェクトとが回るか考えてみた。 やりたい要件。 ・五月雨式に案件が降ってくるのが困る。 ・その修正は、ただの思いつきなのか、戦略なのか明確にしたい。 ・修正点や活動の記録がほしい。 ・できれば、ソース管理とかと連動してくれたらいいな。 ・運用フェーズも、新規大型リリースフェーズも、インフラアラートもすべてできないと嫌だ。 ・エスカレーションするんだってばさ!! ・複雑奇っ怪なワークフローは No Thank you サブプロジェクトかトラッカーか 例えば、企画と開発とデザインとサポートがあったとして、こいつらは、サブプロジェクトにするべきかどうか。 ほげほげプロジェクト +企画サブプロジェクト +開発サブプロジェクト +デザインサブプロジェクト +サポートサブプロジェクトor ほげほげプロジェクト トラッカーに 企画,開発,デザイン,サポートを作
チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する - プログラマの思索
最近は、yuguiさんや色んな人のつぶやきに触れて、励まされたり、ハッとしたりする時が多い。 「Redmineによるタスクマネジメント実践技法」を出版してから、チケット駆動開発が今後進むべき道について再考してみた。 ラフなメモ書き。 【元ネタ】 Twitter / Yugui (Yuki Sonoda): redmineがtracの劣化クローンだった時代など最早信じられないな。機能も著しく向上し、実装も改良され、更にはいろんな先進的なプロジェクト管理の試みをするひとたちが集まるコミュニティを得た。 Twitter / Yugui (Yuki Sonoda): 一読しただけでは微妙に未消化でその時が来たらもう一度読まねばならないけど、『Redmineによるタスクマネジメント実践技法』は良い本だ。Redmineという特定の製品に依存した話はそんなに多くなくて、むしろTiDDの背景解説とパターン
Redmineのトラッカーやステータスの付け方 - プログラマの思索
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合／バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合／バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
チケット駆動開発の参考書「Redmineによるタスクマネジメント実践技法」 - rabbit2goのブログ
Tracを使い始めたきっかけは、情報共有用のWiki(PukiWki)、障害管理（影舞）、ソースコードビューワ(ViewVC)というツール類を一つに統合出来ると分かったからだ。元々、リポジトリ内のソースコードや障害情報をウェブブラウザ経由で参照していたのだけど、それらのURLリンクを辿って、例えば「障害情報からソースコードの該当箇所を参照」したり、「打合せ時にソースコードの該当箇所を参照」するようにしたら便利だと分かり、あちこちにリンクを貼りまくった記憶がある。当時はこんな素朴な仕組みでも快適に使っていたのだ。 しかし、一旦Tracを知ってその便利さに慣れてしまうと、もう元のツールには戻れなくなってしまった。Wikiからソースコードやチケットへのリンクが容易に作成出来て、マイルストーン毎に何の作業がどれだけ残っているのか「見える化」可能なのだ。こんな便利なツールは他に無い！と判断して、さっ
なぜロードマップが重要なのか - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
RedmineとTracの比較 - wyukawa's diary
これまた今更感のあるネタですが少し調べてみたので書いておきます。比較対象バージョンはRedmine 0.9.4とTrac 0.11.7です。 あと僕は基本的にTracユーザです。といっても使い倒しているわけではありません。Redmineに関しては実戦投入したことはありません。 1. インストール これは前提条件を明確にしておかないと比較にならないので、OSはLinuxでtracdやMongrelのような開発サーバではなくApahceに連携させるという前提にします。なのでTracLightningはのぞきます。あとSubversion使う前提にします。 この前提にたつとインストールはどっちも面倒だと思います。結局本体とは別にTracならmod_pythonやmod_wsgiと連携させますし、Redmineならpassengerに連携させるのでその辺が面倒だなと。 Redmineだとさらにマイ
Redmine運用例part3～OpenPNE3 - プログラマの思索
Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac＋SVNからRedmine＋Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。 内容がとても素晴らしいので、共有する為に書く。 #下記は僕の想像の部分も含む。 【元ネタ】 【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System Ope
これから使うなら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となっていますが、大量の未解決チケットが残っていて
チケット管理システム活用メモ - 科学と非科学の迷宮
trac を使い始めて大体7ヶ月ぐらい。 気をつけなきゃいけない点をメモ。 1.死んでもチケットは切れ とにかくチケットを切ること。 チケット管理システムになれてくると、タスク等の情報をチケットに依存するようになる。 逆に言えば、チケットに書かれていない情報はチーム全員の頭の中から容易に忘れ去られるということだ。 半年前のミーティングで言った言わないというお決まりの口論をしたくなければ、チケットは切っておくこと。 ぐちゃぐちゃなチケットは悪いチケットだが、チケットを切らないのはもっと悪い。 2.チケットは独立した内容にしろ。チケット内の情報が分割できそうだったらすぐに分割しろ 一つのチケットで長々とコメント書いても、後から読み直す人はほぼいないと言っていい。 数画面以上にも及ぶ長い議論の最中に仕様変更の話が書いてあったら最悪だ。 それは地雷となり、数ヶ月先に訪れるであろう、踏まれる瞬間を静
TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間 - プログラマの思索
TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 ＃下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK
チケット駆動開発のアンチパターン - プログラマの思索
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
【再考】TiDDのプラクティス集 - プログラマの思索
チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。 なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 チケット駆動開発のベストプラクティスを収集したい: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 チケット駆動開発 - Live a meaningful Life チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) 2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記 チケット単位に並行開発する事例: プログラマの思索 [tech]チケット駆動開発 - Kazumi
redmine_chartsプラグインでバーンダウンチャートは表示可能 - プログラマの思索
下記プラグインをインストールしてみたら、バーンダウンチャートの表示が可能だけでなく、機能が豊富でとても素晴らしかった。 以下メモ書き。 【redmine_charts】 Redmine - PluginCharts - Redmine mszczytowski's redmine_charts at master - GitHub pullmonkey's open_flash_chart at master - GitHub ruby on railsでグラフを作成する。Open Flash Chart編←【2009/11/18 追記】 【インストール方法】 $redmine/vendor/plugins へredmine_charts、open_flash_chartのフォルダを解凍して配置する ※open_flash_chartフォルダがないと、redmine_chartsが動作しな
Redmineのプラグインが充実している - プログラマの思索
昨年に比べると、Redmineのプラグインがすごく充実している。 いろいろ試してみてメモ。 【コードレビュー】 r-labs - Code Review - Redmine Redmineリポジトリ画面からコードレビューのチケットを発行できる。 UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。 それぐらい素晴らしいプラグイン。 【Hudson】 r-labs - Hudson - Redmine RedmineからHudsonと連携できる。 以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。 Hudsonを使っているなら、このプラグインは必須。 このプラグインのおかげで、ビルド管理をチケット駆動開発に含
RedmineやTracを上手に活用する6つのポイント
photo credit: Mackトラ ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。 ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。 しかし、あまり深く考えずに導入すると、 「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声 「この課題って本当に終わってるの？」といった疑心暗鬼 「このタスク、誰も進めてなかった！」という驚愕の事実が期限前日に判明 などといった状況に陥りがちです。 ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。 ポイント1 チケット項目はマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
