Redmineを使いこなせてチームに対するアドバイス

興味深いTwitterがあったのでメモ。

【元ネタ】
Twitter / kashisan: 最近行った #Redmine を使いこなせてチームに対するアドバイス。「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」、「各トラッカーのステータスがどういう状況を表すか定義する」「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」

Redmineを有効に運用出来ていないチームに対するポイントは3点ある。

１・「チケットの説明には成果物を記載して、その成果物をリポジトリにコミットする」
２・「各トラッカーのステータスがどういう状況を表すか定義する」
３・「それぞれのトラッカーがどういうフローになるかがわかる資料を作る」

ポイント1は、チケットファーストの原則。
プロジェクトにある全ての作業はチケットから始まる。
そのためには、チケットは成果物単位、つまりWBS単位である方が担当者も作業範囲が明確だし、管理者も成果物の進捗から、プロジェクト全体の進捗を測定できるようになる。
駄目なチームは、チケットのアウトプットが不明確だから、担当者も作業の目的が分からないし、管理者も進捗が分かりにくい。何よりもアウトプットの品質も悪くなる。

ポイント2は、作業の状態を明確化すること。
駄目なチームは、コミュニケーションのキャッチボールが悪い。
SEが設計書を作ったらPMががレビューするとか、PGがバグ修正したらテスターが検証する時には、各担当者の作業状態をチケットのステータスに関連付けると運用しやすい。
自然なペア作業になる。
二人の目を通すことによって、自然に品質が向上する。

ポイント3は、ワークフロー管理によってPMBOKやITILの言う変更管理プロセスを実現出来ること。
バグ修正と問い合わせのワークフローは全く違うのに、一つのワークフローですべての作業を制御しようとするのは、所詮無理がある。

また、顧客の要望を受けた場合、リリース範囲に含めるか、別のイテレーションに回すのかという判断、あるいは、誰がその要望を調査して分析するのか、その担当を決定するのが重要になる。
その場合、きちんとワークフロー管理しておかないと、何故システムに実現してくれないのか、何故放置されたままなのか、というクレームが顧客から来る。

だから、自分のプロジェクトでどんな業務があるのか、どんなワークフローが必要なのか、業務分析しておくのが重要。
実はSIer自身が、自分たちの業務範囲、自分たちの特徴、自分たちのワークフローを理解していないという現実がある。

実際は、朝会やふりかえりなどで、現場の開発者と試行錯誤しながら、自分たちのワークフローを作っていくのが現実的だと思うし、その方が自分たちの環境にフィットする。
パッケージ製品のお仕着せのプロセスを適用してもダメなのだ。

これがプロセス改善と呼ばれるものになる。