ツールが開発プロセスを改善する

Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。
下記の記事を読んで考えたことを書いてみる。

【元ネタ】
ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー

元請SIerがTracのような環境を提供できない３つの理由 - なからなLife

元請け企業が用意すべきもの - T/O

【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者

構成管理の基本は、任意のバージョンのシステムを再現できること。
今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。

CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。
今でも、Excelなどの設計書はバージョン管理で制御されておらず、ファイルごとバックアップして運用するプロジェクトは数多い。

そのようなプロジェクトでは、プロジェクトリーダーよりも権限の強い人がいる。
それは構成管理を担当するライブラリアンだ。
彼が手作業で、プロジェクトで発生した成果物を手作業で分類し、日別で管理して、リリースしてくれる。
彼がいなければ、プロジェクトの成果物が作成できないだけでなく、彼が整理してくれている成果物を元に作業する開発者も困るだろう。

アジャイル開発でもXPは、ソースの共同所有や継続的インテグレーションのプラクティスで、構成管理に焦点を当てた。
ソースの共同所有のおかげで、誰もが最新のソースに触れて、最新の機能を追加できる。
継続的インテグレーションのおかげで、最新のビルドモジュールが毎日作られる。

特に、継続的インテグレーションはビルドの重要性をSW開発者へ再認識させて、HudsonのようなCIツールを生み出した。
Hudsonも構成管理ツールの一種と見なせる。

XPは、ライブラリアンや管理者主体から、プログラマ主体の開発スタイルへ変えようとした。
XPの主張は、その政治的メッセージだけでなく、構成管理ツールの必要性を再認識させた点が素晴らしいと思っている。

【2】構成管理ツールが開発プロセスの作業ステータスを見える化した

RedmineやTracという強力なプロジェクト管理機能を持つBTSは、チケット管理の機構によってSW開発の作業全てを管理できる。
この開発スタイルがチケット駆動開発。

僕がRedmineでチケット駆動開発を実践して、強く感じた点は下記2つだ。

一つは、チケットの取捨選択という本来のマネジメントを意識したこと。

XPやScrumは小規模リリースのプラクティスに従い、２～４週間のサイクルで小刻みにリリースする。
小規模リリースを実践するには、わずか２～４週間で、ユーザが使えるレベルまでシステムの品質を持っていかねばならない。
このバージョンアップ戦略では、短い期間で開発できる機能に分割し、小刻みなバージョンアップで対応しようとする。
この時に、チケットの取捨選択という技術力と政治力をミックスした高度な判断能力を要求される。

もう一つは、従来の開発プロセスで意識しなかった作業ステータスが現れたことだ。
最近、テスト管理ツールTestLinkとチケット駆動開発システムRedmineを運用し始めて、従来意識しなかったワークフローが見える化してきたという経験が僕の中で増えている。

先日、TestLinkを運用している開発者とKPTしたら、ステータスを追加して運用したいというTryがあがった。
つまり、下記のフローが具現化された。

新規←TestLink担当者がバグ発見！
↓
担当←PLがPGをアサイン
↓
解決←PGがSVNコミット
↓
検証中←TestLink担当者が、解決チケットを検証する
↓
検証完了←TestLink担当者がNGのテストケースを「成功」にするタイミングでチケットを検証完了にする
↓
終了←PLが承認してCloseする

Redmineのデフォルト・ステータスには、検証中や検証完了のステータスは無い。
しかし、テスト担当者(TestLink)とバグ修正担当者(Redmine)が交互に作業し合うには、彼らの作業に対応するステータスが必要になった。

この経験を通じて、構成管理ツールが従来になかった開発プロセスを生み出しただけでなく、このような運用フローを意識しない従来の開発プロセスの弱点もはっきり認識できた。

バグは普通、結合テストのテストケースをテストしてNGの場合に発生する。
TestLinkでは、NGケースにバグ管理IDを紐づけできるので、バグ発生源を特定できる。

更に、TestLinkのNGケース結果画面で、NGケースとRedmineのチケットが一覧表示される。
しかも、Redmineチケット名は、「解決～バグxx発見！」というフォーマットなので、チケットのステータスも見える。
だから、チケットが解決ステータスになったら、テスト担当者はすぐに再テストすればいい。

このバグは直したんだっけ？
NGのケースはもうテストした？
という作業指示を僕が逐一出す必要が無い。

つまり、バグ修正フローでは、次々に現れるバグの修正に追われて、バグの状態を追跡できる仕組みが今まで誰もきちんと意識していなかったことが明確になった。

おそらくこのような現象が他にも色々あるだろうし、RedmineやTestLinkという強力な構成管理ツールのおかげで、開発プロセスがどんどん見える化するだろう。

【3】最近の構成管理は、メインラインモデル＋チケット駆動開発に特徴がある

3-1.SVNのバージョン管理も、単なるコミット履歴の機能だけでなく、メインラインモデルを当てはめることが多くなったように思う。
メインラインモデルとは、trunkとbranchで最新機能のコードラインと保守コードラインを使い分けることだ。
いわゆる2系統のバージョン管理戦略に相当する。
例えば、Rubyならver1.9系がtrunk、ver1.8系が保守ブランチで分けて開発することに相当するだろう。

メインラインモデルの利点は、機能追加のコードラインとバグ修正だけのコードラインを別管理できること。
これによって、開発者は目的に応じて、それぞれのコードラインを修正したり機能追加するから、見通しが良くなり、コードラインそのものも安定する。
弱点はマージ作業が発生することだが、SVNのmerge機能やマージトラッキング機能などで、マージ作業の難易度は下がりつつある。

3-2.Redmineによるチケット駆動開発は、単なるバグ管理だけでなく、SW開発全般の作業ステータスを追跡できる点に大きな意義がある。

チケット駆動開発の運用の難しさはやはり、チケット管理にあると思う。

7日のKOFでは、こんな質問があったので、僕はこう答えた。

Q.チケットの粒度はどうやって決めますか？

A.僕は新規開発とバグ修正でチケットの粒度を変えます。

新規開発
→一つの成果物を作る作業をチケットにする。
　基本は担当者1人で5人日以内にする。
　例：設計書を作る、一つの機能を実装する、など。

バグ修正
→一つのバグをチケットする。
　PGとテスト担当者の2人で作業する。
　結合テスト以降では、1人だけの作業ではデグレが発生すると致命的だから。

以前、Tracはバグ管理はしやすいが、プロジェクト立ち上げでは使い辛いという話をよく聞いた。
チケットに何を書けばよいのか、分からないということだった。

よく聞いてみると、チケットを仕様書代わりに使おうとして失敗している。
チケットがバグ報告票なので、チケットはバグに対する仕様を書くものと見なしたらしい。

僕はチケットは作業指示書だと思っている。
だから、チケットには必ずアウトプットがある。
チケットはプロセス管理に使うものであって、成果物の管理に使うべきではないと思っている。

【4】構成管理の最終目的は、作業の透明化
※ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 参照

ケントベックが言うには、リリース期間が短くなるにつれて、SW開発に質的変化が発生することを指摘している。
以前のウォーターフォール型開発なら、最後の1回だけリリース。
しかし、アジャイル開発なら、２～４週間のサイクルでリリースしなければならない。
だから、アジャイル開発はプロジェクト管理が非常に難しいのだ。

構成管理ツールの重要性をXPは指摘した。
この指摘によって、SW開発に何が起きたのか？

ケントベックが言うには、チームの作業の透明性が重要になったと言う。
テスト駆動開発で、自分が書いたプログラムが単体テストが通るか一目瞭然となった。
継続的インテグレーションによって、ビルドが毎日通るかどうか一目瞭然となった。
これは、開発者個人の作業が透明化されたことを意味する。
同様の現象が他にも起きるだろう、と。

チケット駆動開発は、SW開発の全ての作業のステータスを見える化する。
全ての作業が透明化される。

作業の透明化の利点は、コミュニケーションがスムーズになることだ。
デスマーチプロジェクトを見ると、負荷の高い人と低い人が極端で、大変な人を助けようというチームワークそのものがない。
構成管理ツールを導入してすぐに現れる効果は、コミュニケーションの改善と言われる。
チームの開発力をアップしてくれる。

今は、SW構成管理という概念そのものが実は曖昧だけれど、SW構成管理についてIT技術者はもう一度再認識すべきだと思う。