サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Redmine 仕事のやり方 旧館より

チケットの粒度が難しい

投稿日:2010年10月6日 更新日:


過去のメモを整理していたところ、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

-Redmine, 仕事のやり方, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

打合せ前に少しだけ調べておく

とある社内での打合せの席で思ったことです。 「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。 その打合せは部門も違い、お互い初対面でした。 ただ、事前に「○○さん …

テスト工程

…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。 今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。 しかし現実は単体テスト …

新人研修の内容が現場へ連携するようにして欲しい

私の所属組織では、新卒採用後、数ヶ月の集合研修を経て、各部門のそれぞれのプロジェクトへ配属になります。 以前、私が担当していたPJに新人が配属されたことがありました。 で、その時に思ったことです。 思 …

SCRUM BOOT CAMP THE BOOKを読みました

「SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・ @yohhatu それでもいいけどw もうちょっとww …

経験値の絞り方

同年代なのに驚く程、人間的器や知識、考え方の成熟度合いに驚く人もいれば、いくら年上でも「なんだろうなぁ」と思う人もいます。 また若手技術者(技術者に限った話ではありませんが)を見る時にも同じようなこと …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。