プログラマの思索

RedmineとWBS駆動の相性の悪さについて、一つの意見を聞いたのでメモ。

【参考】
チケット駆動開発がWF型開発と相性が悪い理由: プログラマの思索

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

イテレーションの考え方は締め処理と同じ: プログラマの思索

何故チケット駆動開発はタスクやイテレーションの変更に強いのか？: プログラマの思索

【1】とある人から、RedmineとWBS駆動の相性の悪さの意見を聞いた。
その人曰く。

Redmineでは、チケットの担当者がどんどん変わっていくように運用すべきなのに、WF型開発に凝り固まっている人は、チケットの担当者を固定して作業を管理しようとする。
だから、プロジェクト管理をチケット管理に置き換えても、なかなか効果が出ない、と。

この意見は一つの真実を示していると思う。

チケット駆動開発では、チケットはペアプログラミングまたはペア作業のように、複数人でキャッチボールしながら、ステータスを変更してCloseしていく。
例えば、ソースコードを書いたらレビューアにコードレビューしてもらったり、設計書を書いたらレビューアに設計レビューして、フィードバックをもらって修正する。
バグを発見したら、開発者に修正してもらい、修正内容を再検証して、リリース担当者に最終リリースしてもらう。

つまり、一つのチケットは、一つの目的を達成するためのやり取りを記録する。

【2】しかし、WF型開発ないしWBS駆動で凝り固まっているプロジェクトリーダーは、一つの作業は一人の担当者に固定して、実績工数と進捗率を管理しようとする。

例えば、「カード払いにする」機能の追加依頼が来た時、設計・設計レビュー・実装・コードレビュー・単体テスト・テスト結果レビュー・リリースのように、工程ごとにタスクを細分化し、それぞれのタスクを一人の担当者に固定する。
このような作業管理はExcelやMSProjectを使いこなしている人に多い。

実際のExcelを見ると、縦軸に機能、横軸に工程(設計・設計レビュー・実装・コードレビュー・単体テスト・テスト結果レビュー・リリース)毎の予定日・作業日・担当者名、というクロス集計のような膨大な表で表現される時が多い。

【3】このような「1タスク＝1担当者」に固定する作業管理は、実績工数や進捗率を計測しやすいかもしれないが、実際の作業はとてもやりにくい。

他の作業が遅延すれば、担当者を入れ替えする必要もあるし、開始日や終了日もコロコロ変える場合が多い。
すると、毎日の担当タスクは流動的になり、どのタスクを最優先にしたらよいのか、ExcelやMSProjectでは分かりづらい。
プロマネも、Excelから最優先にすべきタスクを見つけ出すのは、かなりの手間だ。

しかも、ユーザ観点では、開発チームの誰がどんなタスクをしたのか、という過程は興味がなく、肝心の依頼した機能がいつリリースされるのか、後どれくらいの期間で終わるのか、が知りたいだけ。
だから、そんな細かな作業管理の詳細スケジュールは見たくもない。

「1タスク＝1担当者」に固定する作業管理は、担当者やユーザのためではなく、プロマネ自身が管理しやすくするための一つのやり方に過ぎない。

【4】「1タスク＝1担当者」に固定する作業管理にしてしまう問題は、チケットの粒度はどのレベルにすべきか、という問題に置き換えられる。

Redmineチケットの担当者を固定にする手法では、工程ごとにチケットを分割するので、チケットの粒度はあまりにも細かい。
おそらくそのやり方は、アジャイル開発に向かない。
アジャイル開発では、作業を工程で分断するのではなく、一つの機能を一つの塊の作業とみなして、並行作業する。

実際の開発は、設計書を書いてレビューを受けると、アーキテクチャをきちんと考えおらず、全然ダメで大幅に書き直す場合もある。
プログラミングしてコードレビューを受けると、ボロクソに言われ、確かに読みにくいコードなので大幅に直さざるを得ない時がある。
そのような手戻り作業は、ガントチャートでは管理しにくい。

ガントチャートに手戻り作業を追加すると、先行・後続のタスクの依存関係が崩れる。
また、担当者の作業負荷を正確に反映すると、山崩しが必要となり、ガントチャートを大幅に修正せざるを得なくなる。

かと言って、手戻り作業の実績をガントチャートに反映しなければ、進捗＆工数管理できないから、前工程に戻るような状態に反映しないといけない。
すると、いつまで経ってもガントチャート上では進捗が進んでいないように見えてしまう。

【5】チケット駆動開発が教えるには、チケットはタスクというよりも、一つの目的に従った作業にすべきであり、担当者を頻繁に変えながら、チケットに紐づく成果物をブラッシュアップすべきだ、という点だ。

設計書やソースコードという成果物は、仕様変更や機能追加などの要望、課題や問合せ対応、障害修正などの数多くのチケットで更新されながら、顧客の要望に見合う方向に収れんされていく。

一つのチケットに開発者、テスター、設計者、プロジェクトリーダー、顧客などシステムに関わる全員が担当して、解決されていくのがあるべき姿。
一つのチケットを一人でやりきるよりも、複数人で交互に担当し合う方が、二人の目による成果物の品質チェックで品質向上も期待できる。

つまり、「チケットの担当者を固定する」手法よりも「ペア作業」の方がチケット管理に向いている。

【6】さらに重要な点は、ペア作業によるチケット管理の背後には「ワークフロー」という概念が隠れていることだ。
すなわち、ペア作業はワークフロー管理機能によって、ステータスごとに誰が担当すべきか、という制御がツール上で実現されている点だ。
作業の種類(トラッカー)ごとに、どんなステータスがあり、どのようにステータスが遷移されるのか、という制御はあらかじめ決まっており、チームのメンバーはそれに従って作業するだけでいい。

「チケットの担当者を固定する」手法は、プロジェクト管理にワークフローという機能が必要である事実があいまいで、そのために進捗が遅れてしまいがちになるのではないかと思う。
つまり、「チケットの完了条件」があいまいなのだ。

実際、「機能Aの設計書が完成した」「機能Bのプログラムが完成した」という状態は、単なる作業が完了しただけではなく、レビューやテスト、プロマネの承認が完了して初めて、「終わった」と言うべきだ。
そして、それらの作業は、ステータスで制御すべきであり、その機能はワークフローとしてチケット管理ツールで実現されている。

ワークフローを明確に意識していれば、どのステータスで、どの担当者がボトルネックになっているのか、をチケット集計機能で即座に分析できる。
そうすれば、すぐに対策を打つこともできるだろう。

チケット管理にはたくさんのノウハウが込められていると思っている。