過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。
悩んでいたこと
RedmineやTracなどのITS(Issue Tracking System＝問題追跡システム…こういう呼び名だと今、初めて知りました)に登録するチケットの粒度、単位です。
背景
Railsを採用したWebシステムを4,5人で構築するというものでした。
で、そのPJで、本格的にITSを使って「チケット駆動開発」(的)なことをしてみようとなったわけです。
まずはこうやってみた
MVCモデルで分割していたので、機能毎のモデル/コントローラ/ビューをそれぞれ1つのチケットとして登録してみました。
その結果
なかなか「チケット駆動開発」のリズムになりませんでした。
なぜだろう？(推測)
1：チケットの粒度が大きすぎた。
(設計の善し悪しもありますが)当時はコントローラにそれなりの量の業務ロジックが実装されていました。
なので、下手すると1日以上かかる実装量を1枚のチケットにしてしまったのが原因ではと思います。
2：Railsの開発スタイルとチケットの単位が合っていなかった。
Railsでは頻繁にMVC間を行き来して、分業したりせず開発するスタイルが合っていました。
ところが前述したようにチケットはMVC単位だったため、MVCともちょくちょく進んではいるものの…という感じで、チケットの完了による進捗が見えませんでした。
次やるとしたらどうするだろう？
これの解は出ていません。
が、今のPJ(SAStruts+S2JDBCで3,4人)では(粒度もまちまちですが)少なくともタスク漏れがあるよりはマシ…という考え方から、「まずは登録！」のスタイルで運用しています。
感覚的には、数分程度で終わる、かつ、チームメンバーの確認(レビューや仕様確認)が不要なタスクはチケット登録しないようにしています。
で、朝会などの中で、チケット間の親子関係を作るなりして、「進捗が見える」単位に調整しているという感じです。
なんかこの辺の運用方法は、メンバーの人数、スキル、マインドにもよるので、絶対的な正解はないと思いますが、議論したりして深掘りしたい内容です。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo by tony.eckersley on Visual hunt / CC BY
コメント