ついに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によるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

Windowsで利用できるGUIのGitクライアントの1つに「TortoiseGit」がある。TortoiseGitはまだ開発段階のソフトウェアではあるが、2009年6月5日にリリースされたバージョン0.7.2.0では多くの機能が実装され、実用的に動作するようになった。本記事ではこのTortoiseGitを用いて、Windows環境でGitによるバージョン管理を行う方法について解説する。 近年、「Git」という分散バージョン管理システムが注目を浴びている。しかしGitはWindowsサポートが弱く、またGUIで利用できる使いやすいクライアントがなかったため、特にWindowsユーザーには導入や利用へのハードルが高かった。そこに登場したのが、Windowsのエクスプローラに統合され、GUIでGitによるバージョン管理が行えるツール「TortoiseGit」である。TortoiseGitはまだ

RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。

Redmine運用例の記事があったのでメモ。 【元ネタ】 [Think IT] 第2回：ProjectKeeperに見る開発方法論 （1/3） [Think IT] 第2回：ProjectKeeperに見る開発方法論 （2/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （1/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （2/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （3/3） 【特徴】 プロジェクト管理ソフトウェアProjectKeeperのタスク管理にRedmineを使っているらしい。 WebSphere＋DB2で動作するから、IBM系列と思われる。 記事を読むと下記の運用ルールがあると思われる。 1・Redmineには、製品ロードマップ、顧客要望、バグ情報などが一元管理され

「Gitを使いたいが、中央リポジトリにはSubversionを使わざるを得ない」という場合も多いだろう。そのような状況で便利なのが、SubversionリポジトリとGitリポジトリの橋渡しをする「git-svn」である。git-svnを利用することで、SubversionリポジトリとGitのローカルリポジトリを同期させることが可能だ。本記事では、このgit-svnの活用方法を紹介する。 git-svnのアーキテクチャ Gitの大きな特徴として、分散型アーキテクチャがある。分散型アーキテクチャでは、コミットはローカルのリポジトリに対して行い、ソースコードの同期はそれぞれの開発者間が持つローカルリポジトリ同士で変更点をやりとりすることで行う。もちろん公開リポジトリを利用したソースコードの同期も可能であり、柔軟な開発体制を取れるのが長所である。 しかし、一方でGitは非常に多数のコマンドがあり、

ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが

営業の人がRedmineでチケット駆動開発を実践した記事があったのでメモ。 【元ネタ】 redMineで仕事のディレクション・進行管理 | 陽のあたらない美術館 -人間再生- 上記Blogを見ると、下記の内容のようだ。 ・Redmineのバージョンは、0.6.4。 ・Web制作のタスク管理にRedmineを運用している。 ・バージョンには、「受注フェーズ」「企画・仕様」「ベータ版公開」「正式公開」が登録されている。 つまり、マイルストーンを工程単位にしている。 ・チケットには「見積書提出」「契約」「企画書提出」「仕様詳細検討」「開発１」「動作確認１」「サーバ設定」「調整」などのタスクが登録されている。 これらのチケットを工程であるバージョン単位にまとめている。 ・ガントチャートやカレンダー、ロードマップでチケットの進捗を管理している。 ・ステータスは「新規→担当→解決→終了」のため、Red

追記(2009-07-17)：僕の環境だけかもしれませんが、upgradeするときは「sudo port upgrade subversion +unicode_path」としないと、新バージョンがvariantsの指定無しでビルドされてしまいます。どうにも面倒なのですが、何とかならないもんですかね。 以前、僕は「濁点ファイル名も扱えるSubversionをMacPortsでインストール」という記事を書きました。MacのSubversionだと濁点を含む日本語ファイル名が上手く扱えないから、偉い人が作ってくれたパッチを当てるといいよ、という話題でした。 ところが、今日になってSubversion 1.6.0にしようと思ったらunicode_pathというvariantsの存在に気づきました。下記のようにすれば、濁点がうまく扱えるパッチを当ててくれます。 $ port install sub

Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー（あるいはアーカイブ）する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい（アーキテクチャ依存）。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア

Redmineを運用して気づいたことを書いてみる。 【元ネタ】 Martin Fowler's Bliki in Japanese - 支払利息の見積もり PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1】登録したチケットを分割するタイミングがある。 WBSから初期スケジュールを作成した時、機能追加だけの実装内容のチケットの工数は3人日を見積もったとする。 しかし、実際にチケットを担当した開発者の実績は5人日をオーバーする時がある。 何故遅延しているのか、開発者に聞いてみると、機能追加する前のリファクタリングに時間がかかっている。 理由は、元々のソースはロジックが余りにも入り組んでいるため、リファクタリングしないと機能追加できないから、と言う。 そんな時、僕は、そのチケットからリファクタリングだけの目的の別チケットを新規登録し、リファクタリングは別チケット

SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br

“泥”開発に対する最終兵器「Trac」とは？ 誰もが必ず1度はイライラしたことがある「情報の囲い込み」問題 情報の共有はプロジェクトを円滑に進めるうえで重要な課題です。極端な例ですが、例えば、図1の例で見てみましょう。 分かりやすいよくある例で示すと、各開発者の作業状況はメールや手帳上に記されています。検討やヒアリングした結果は、メールでほかの人に問い合わせたならメールボックス上にたまっていきます。打ち合わせなどで相手に会ってヒアリングしたなら、手帳やノート上にメモとして残っていきます。こうして、各開発者が自分のタスクの情報をメールやメモ、あるいは頭の中で“囲い込み”ながら開発が進んでいきます。 ここで、開発者がある機能を実装するために、「別の作業の状況や進捗（しんちょく）を把握したい」とします。 「誰が情報を持っているのか分からない」 まず、誰が情報を持っているのか分からないので、ヒアリ

今日のプロジェクト成果物とりまとめを前に昨日、メンバの1人が trunk 直下の2年半分のファイルが入っているプロジェクトディレクトリをなぜか削除してコミット。 朝きたら過去のリビジョンをエクスポートして再度追加して戻したとかで、全部履歴が切れてしまっていた。作業ディレクトリも全部入れ替わり。 こういう時は過去のリビジョンからの copy をすべし。 履歴が維持される 属性などもコピーされる 他のチェックアウト済み作業ディレクトリへの影響もなし といった点で優れている。 作業ディレクトリを使って消したディレクトリを戻す svn copy --revision R URL . svn commit -m "Resurrected dir1 from revision R" ここで R は間違えて消してコミットしたリビジョンの1つ前のリビジョン。 URL は削除したディレクトリの URL。 実