ついにRedmineのtrunkにSubtasking がコミットされた！ - プログラマの思索
ついにRedmineのtrunkにSubtasking がコミットされたのでメモ。 【元ネタ】 Twitter / yusuke-kokubo: #redmine ついにtrunkにSubtaking がコミットされた！ Twitter / yusuke-kokubo: #redmine 1.0ではチケットの親子関係がサポートされます。 Redmine - Feature #443: Subtasking - Redmine Redmine - リビジョン 3573 - Redmine (下記引用開始) Adds subtasking (#443) including: * priority, start/due dates, progress, estimate, spent time roll-up to parent issues * descendant issues tree d
Redmineチケットの関連リンク - プログラマの思索
Redmine.JP Blogに分かりやすい記事があったのでメモ。 【元ネタ】 チケット同士の関連づけ | Redmine.JP Blog Redmineチケットで「関連する」リンクはよく使し、分かりやすい。 例えば、trunkへのマージ作業の発生元がリリースブランチの障害修正の場合、リリースブランチのチケットNoを「関連する」に追加する。 そうすれば、何故マージ作業を行うのか、担当者も理解しやすくなる。 しかし、それ以外の「重複する」「先行する」「ブロックする」は分かりづらかった。 チケット同士の関連づけ | Redmine.JP Blogを読んで、ようやく完全に理解できた。 「重複する」機能は、Mantisにも同等の機能があるので分かりやすい。 「重複する」リンクを使う場面は、いわゆる同件(同類)バグの場合があるだろう。 例えば、発見したバグをチケットに登録したものの、実は以前のチケッ
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
メトリクスの威力 - プログラマの思索
チケット駆動開発を上層部へアピールするのに最も効果的なことは、現場の数字を提示することだ。 社長や取締役、管理職は、数字が非常に好きな人達。 彼らは、いつも売上の数字とにらめっこしている。 彼らは月次売上のために、請け負ったプロジェクトの進捗や品質をすごく気にしている。 チケット駆動開発を実践すると、チケットに日々の作業状態がリアルタイムに入力されるため、進捗をリアルタイムに見ることができる。 RedmineやTracでは、生成されたガントチャートから、赤色のタスクが遅延しているのが分かる。 カレンダーを見ると、月別のタスクの一覧が表示され、取消線のないタスクは作業中であることが分かる。 ロードマップから、バージョン単位の進捗が出るので、マイルストーンまでの残日数と比較して間に合うのかどうか考えることができる。 チケット集計結果であるサマリから、バージョンやコンポーネント単位の残チケット数
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
課題管理対決！Redmine vs. Trac
Redmineの機能と特徴 Redmineは、Ruby on Rails上で動作する、Webインタフェースの課題追跡（Issue Tracking）ツールです。原稿執筆時点（2008年9月現在）での最新のバージョンは0.7.3です。 Redmineが搭載している機能は、「マイルストン設定（ロードマップ）」「カレンダー／ガントチャートの表示（概要）」「作業時間の登録／集計（チケット、概要）」「作業履歴の閲覧（活動）」「課題の登録／追跡管理（チケット、新しいチケット）」「伝言板（ニュース）」「文書の登録／閲覧（文書、Wiki）」「ディスカッション（フォーラム）」「ファイルの共有（ファイル）」「ソース管理との連携（リポジトリ）」「ワークフロー定義」「メール通知」「RSS配信」「ユーザの管理/ロール・権限の設定」です。なお、かっこの中はRedmine画面上で対応する主なメニュー項目名です。 筆者の
アジャイル開発のインフラ - プログラマの思索
SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。 大量の印刷した紙、手作業の多い仕事に囲まれている。 ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。 一つは、ソースコード管理。 二つ目は、検証可能なビルド環境。 そしてBTS。 この3つについて考えてみる。 【1】ソース管理 プログラミングで仕事するならば、ソース管理(SCM)は必須だ。 ソース管理システムの本質は、前回のプログラムへUndoができること。 つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。 ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。 ソース管理で重要な作業はブランチやタグ付けができること。 ブランチは、枝分かれしたバージョンツリー。 タグは、ある時点でバージョン付けられたソース
プログラマの思索: オープンソースBTSはソフトウェア開発のベストプラクティス
ソフトウェア開発は3つのモードがあると思う。 最初は新規開発モード。 そしてソフトウェア開発の中で最も難しく、最もプロジェクトマネジメント能力を要求されるバグ管理モード。 最後は、運用保守モード。 BTS（バグ追跡システム）は、主にバグ管理モードで使われる。 つまり、各開発者のプログラムを繋ぎ合わせて正常に動かす結合テスト。 あるいは、色んなブラウザに対応しているか、とか、高負荷なアクセスに耐えれるか、などのようなシステムテスト。 BTSとは、そこで上がったバグを収集し、修正し、検証する一連の作業をフレームワーク化したもの。 主にWebシステムで作られている。 このBTSについて再考してみる。 【1】BTSに至るまでの歴史 一昔前。 結合テスト以降のバグ修正は、Excelベースだった。 バグを見つけた人が、Excelのバグ報告票に起票する。 そのExcelを修正担当者に渡し、修正してもらう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
