無料ブログはココログ

« [#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai | トップページ | CCPMから考えるボスのあり方 - マイクロマネージメントより親分肌 - »

[#TiDD] チケットが放置される理由

[#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai」にいただいた、たなかさんのコメントで「チケットが放置」されるとのご相談がありましたので、放置される理由を整理しました。

チケット駆動開発の基本的な内容を書いた「チケット駆動開発の背景にある思い」「チケット駆動開発がもたらすプロセス」(ポイントプロセスの変化チケット管理形式化リズム現場力)」「チケット駆動開発の落とし穴 - ベカラズとベシ -」とあわせてお読みください

あいまい

  • 担当が設定されないチケット:起票された後、担当が決められないままに放置されているとクローズされなくなります。予めデフォルトの担当者を決める、棚卸しをする、等の運用ルールが必要です
  • Done(タスクのゴール)の定義がない:クローズする条件が明確でないとクローズされません。チケットのゴールを明確にし、複数の内容があれば分割しましょう。
  • ツールの導入が目的になっている:導入さえできれば良いと思い、使われなくなります。また、詳しい人がいない場合や、不親切な場合も活用の意欲が出ないでしょう。チケットシステムを導入する際は機能の比較だけでなく、詳しい人や情報にアクセスできるかどうかも検討してください。

面倒

  • 情報共有できていない:Wikiで情報共有する際に、初めに作ることが多いのはチケットシステムのTIPS(やや古い)や関連情報のリンクです。協力しながら面倒さへらしましょう。
  • 必要なカスタムクエリがない:よく使うカスタムクエリ(あるいはレポート)を準備しておくと、日常的な活動が大きく効率化できます。
  • 義務があっても効果がない:管理の都合だけで運用ルールを決めると、現場にとって面倒なだけです。管理情報は適切にフィードバックすると共に、実作業を効率化して現場力を向上しましょう。
  • チケットに依存していない:チケット駆動開発に心地よいリズムが生まれるのは、チケット中心にプロジェクトが回りだすからです。チケットがないとうまくまわらないと思えるほどに依存する事が、最初の一歩です。
  • チケットの粒度が大きい:依存を阻害する物に粒度の大きいチケットがあります。チケットを見なくても作業できるので、見る事が億劫になります。

運用の問題

  • 基本ルールがない、または不正:チケットの基本ルールを決めましょう。たとえば、担当がクローズするのか、依頼者が確認してクローズするのか、チケットの種類(トラッカー)ごとに決めると良いでしょう。
  • ワークフローが厳密過ぎてボトルネック発生:誰がチケットの状態を変更できるのかは、ワークフローで変更できます。しかし、あまり厳密に決めてしまうと、権限を持つ人がボトルネックになりがちです。なるべく柔軟に変更できるようにしておく、権限が必要なチケットの一覧を確認できるようにする、などの工夫をしましょう。
  • 棚卸しがない:チケットにうまく依存できていると、チケットの放置は少なくなりますが、人間ですからミスはつきものです。週に一度ぐらいは棚卸しをしましょう。

チケットの放置は、チケット駆動開発がうまくいっていないサインです。そのままにすると、そんなやり方でも良いのだと思ってしまい、改善する事はありません。

上に挙げたような適切な対応をとるだけでなく、賛同する仲間を増やす、不満点を拾い上げて対策をとるといった、プロセス改善活動としての視点(CMM/Iがいつか来た道)も必要です。

チケット駆動開発の本質は任せる(楽をする)ことです。タイミングを見極めて、プロジェクト改善仕組みを活かし、ちょうど良いプロジェクトを実現してください。

【告知】 2013/8/24(土)
GxP社「SIの現場で使えるチケット駆動開発」セミナー
「チケット駆動開発の知っておくべき大切な事」と題して講演させていただきます。チケット駆動開発の勘所などもお話しする予定です。


« [#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai | トップページ | CCPMから考えるボスのあり方 - マイクロマネージメントより親分肌 - »

チケット駆動開発」カテゴリの記事

コメント

さかばさん、ありがとうございます。

放置される理由を見ると、該当するものがちらほらありました。

「ツールの導入が目的になっている」
→自分はそう思っていなくても、みんなにはそう感じられている。

「チケットに依存していない」
→チケットにやることを書いて、その内容を実施していくという流れではなく、チケットに登録したことで満足してしまい、結果として作業はやられない。もしくは、やったけどステータスが更新されていない。かといって、やることが他で管理されているかというと、他に管理しているものもなし。
なので、チケット化していないものは、やらないものになりのちのち指摘されてやることに・・・。

そもそも、要求や実施項目などが何も管理されていない状況で、何かをやることは開発者にとっては「やることが増えた」というマイナスイメージしかないです。
やることをやっていないから、苦労しているのは明白なのに・・・。

こんなきっかけから、TiDDでやることを管理し、簡単に楽しくやれればと、導入したのですが・・・。


「賛同する仲間を増やす」
→これ本当に重要ですね。大きな目標として、「忙しい状況をなんとか楽にしたい」は、全員一致しているんですが、その進み方は人それぞれ・・・。
みんなが同じ方向に向かっていくためには、大きな目標からもう少し小さな目標を共有していかなければいけないですね。

プログラムと違い、人は思ったとおりに動かないですね。(それが楽しみの1つなんですが)

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« [#TiDD] チケット駆動による理想的なプロセス改善 #JaSST_Kansai | トップページ | CCPMから考えるボスのあり方 - マイクロマネージメントより親分肌 - »