チケットファーストからビルドファースト、Gitoriousへ

Gitoriousやゼロ機能リリース(Zero Feature Release)に関するラフなメモ書き。

【元ネタ1】
Gitを使った開発・運用フローの紹介 | FIRN.JP

Gitという優れた分散バージョン管理をソフトウェア開発の中心の配置して、チケットやビルド管理ツールを連携する方法が書かれている。

GitoriousとRedmineを使った開発 - ひかえめプロジェクト

(引用開始)
ポイントは，フィーチャーブランチ，リリースブランチ，ホットフィックスブランチをそれぞれRedmineのチケットに対応付ける点です．
これらのブランチの名前をすべて id/xx （xxはチケットナンバー）にすることで，自動的にブランチ上のコミットがRedmineのチケットに対応付けられます．
(引用終了)

ブランチはRedmineプロジェクトだけでなく、チケット単位に作ってもいい。
分散バージョン管理を使っているなら、チケット単位に自分だけのブランチを作って開発して、masterへPush又はrebaseする時にチケットがCloseされる運用になるだろう。

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

Redmineを使いたいと思う人の理由の一つに、SCM連携としてGitがデフォルトで対応しているから、というものがあった。
Redmineと連携する場合、MercurialよりもGitの方が使いやすいのかもしれない。
(追記：Redmineコミッタのまるやまさんから、Redmine1.2では、Redmine＋Mercurialが最強です、とのコメントを頂いたので修正しました。ご指摘ありがとうございます。)

【元ネタ2】
第三回Jenkins勉強会に参加しました。あるいはZFRは次のムーブメントを起こすか - ハードコイルド・ワンダーランド

ソフトウェア開発の秘伝“Development Baseline 2007” － ＠IT

ゼロ機能リリースとは、一番最初のイテレーションで、ソフトウェア開発に必要な開発基盤や紙芝居(HTMLだけで、動くシステムではない)などをリリースすることらしい。
XP祭り関西2010でも、中西さんが、Trac＋SVN＋Hudsonという開発基盤を作るというゼロ機能リリースについて講演されていたのを思い出す。
XPのアーキテクチャスパイク、プロトタイピングに相当するように思える。

ゼロ機能リリースが必要な理由は、最初のイテレーションで、顧客へ価値あるソフトを提供する基盤を整えて、必要なフィーチャをできるだけ洗い出して、その後のイテレーティブな開発を順調に軌道に載せたいから。
牛尾さんが、この辺りのフェーズではストーリー供給力やストーリー検証力が必要、と言っていたのを思い出す。

色々考えてみる。

【追記】
かおるんさんから指摘を受けたので、修正・追記しておいた。

Twitter / @中村 薫: @akipii この話ですよね。 これなら納得です:-) http://bit.ly/kvuDNR