チケット駆動開発が楽しい瞬間

まちゅさんの記事を読んで思ったことをメモ。

【元ネタ】
「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06)

今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました - SiroKuro Page

「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06)のような状況は、僕も経験した時がある。
本番ソースはRational Clearcaseで厳格に管理されているため、開発チーム内部ではSubversionでソース管理していた。
そして、全て出来上がったら申請書を出して、承認してもらった後、全員で手分けしてClearcaseへ一括コミットする。
やりにくくて仕方ない。

まちゅさんの言う通り、ソフトウェア開発で厳格に管理すべきワークフローを間違えているのだと思う。

ところで、Redmineでチケット駆動開発を運用し始めて楽しいと思う瞬間は2つある。
一つは、チケットをどんどん消し込んで、ロードマップ画面でイテレーションの進捗率が上がっていく場合。
最初はたくさんのチケットを一括インポートするから進捗は0％だが、皆で手分けしてチケットをCloseしていくと、毎日の進捗は少しずつ上がっていく。
毎朝と退社間際にロードマップ画面で、取引線がたくさん付けられたチケットを見るのが楽しい。

もう一つは、新しいワークフローを見つけて、新しいトラッカーを追加した場合。
現状のワークフローでは作業しにくい、という話が上がった時、どのステータスを追加するか、どのようなフローにするか、議論して、ワークフロー設定画面でトラッカーを追加する。
そして新しいトラッカーをメンバー全員に説明して、運用してうまく回り始めると、やった！と思う。
何故なら、新しいワークフローを身に付ける事で自分の開発スタイルのバリエーションが増えるからだ。
新しいワークフローは、現場リーダーの一つの武器になる。

僕の数少ない経験上、新しいトラッカーは、テストやレビューなど、二人以上の作業者が交互にペアプロしながら品質チェックするワークフローで生まれやすいように思う。
理由は、Redmineのデフォルトのワークフローでは、ペアプロのような複雑な作業フローは設定されていないからだ。

ペアプロで行うワークフローは、作業者とその作業をチェックする設計者の2人の作業になるので、そのチケットを消し込むのは時間がかかる。
しかし、このワークフローを使うべき工程では、ミスが許されない部分が多いから、厳格に管理する時が多い。
例えば、バグ修正＆検証、デザインレビュー(設計レビュー)など。

新しいトラッカーを見つける作業をしていると、ソフトウェア開発の業務分析をしている気分になる。
ソフトウェア開発は、新規開発もあれば、既存システム上の2次開発や保守、サーバーインフラの監視による運用保守など、色んな開発スタイルがある。
それぞれの開発スタイルでワークフローは違う。
どれだけワークフローを持っているか、が現場リーダーの手腕の見せ所。

我々IT技術者は受託開発で、顧客の業務を分析して、システム化する。
同様に、ソフトウェア開発の業務分析をきちんと行えば、どこを厳格に管理すべきか分かるはずだ。