スティルハウスの書庫の書庫

はてなダイアリーで書いてた「スティルハウスの書庫」を移転してきました。

いつのまにかチケット駆動開発してた

チケット駆動開発のFAQ
http://forza.cocolog-nifty.com/blog/2009/08/faq-611b.html

チケット駆動開発って何だろう。。と思って読んだら、ここ数年の私の開発方法とよく似てた。私はこんな感じ:

  • タスク(=チケット)管理ツールとしてJiraを使う
  • 発注元の方に、要求仕様や外部仕様をJiraのタスクとしてすべて登録してもらう(優先度付き)。タスクが仕様書代わり(これはチケット駆動と違うみたい)
    • 開発中も随時変更したり追加してもらう
    • バグも改善もいっしょくた(ラベル分けはするけど)
  • 個々のタスクをサブタスクに細分化し、1つあたり数日でこなせる粒度にする
  • タスク全体の状況やこれまでのベロシティに基づいて、次回リリース(1回のiterationは1か月間くらい)までに実装したいおおよそのスコープを決める
  • 個々のタスクを優先度順に実装し、コミットする。コミットログにはタスクIDを書く。ソースのコメントにもタスクIDを書いたりする
  • タスクの実装が完了したら、QA担当または発注元の方にタスクを割り当てる
  • QA担当または発注元の方が動作を確認したら、タスクをクローズする
  • 個々のタスクごとに実装に要した時間(バグ取りも含む)をJiraのタイムトラッキングに記録しておく
  • リリース後もまったく同じやり方でスポット保守を提供

という感じ。かつ私の場合は最近ほとんど「見積りベースの契約」ではなく「時間給契約」(でも持ち帰り)でお願いしているので、仕様書代わりとなるJiraタスクの内容や優先度は、発注元の気分でがしがし変更してもらってOK。その代わり特定の要件に対する事前コミットメントはしないというやり方です。日雇いのデジタル土方感覚なのです。