プログラマの思索

XPのイテレーションの概念はTracとRedmineで微妙に異なる。
それについてのラフなメモ書き。

【元ネタ】
Redmine.JP | プロジェクトの設定
バージョン

Trac Lightningで始めるチケット式開発「電撃」入門 (3/4) - ＠IT
マイルストーンの設定、バージョンの設定

【1】XPやScrumを代表とするアジャイル開発で最も重要な概念は、イテレーションだと思う。
理由は、イテレーションがあるからこそ、繰り返し型開発が可能になり、そのイテレーションのサイズを小さくすることによって、XPのプラクティスの一つである小規模リリースも可能になるから。

イテレーションは、大ざっぱに喩えるならば、PDCAサイクルのプロセス。
イテレーションは、XPでは2～4週間、Scrumなら4週間のサイズで、計画からリリースまでのプロセスを含む。

TracやRedmineによるチケット駆動開発を実践してみて、イテレーションをコントロールするツールが今まで無かったから、アジャイル開発のプロジェクト管理が難しかったのだと気付いたこと。

頻繁なタスク変更をリアルタイムに保守するインフラがチケット駆動開発で提供されて初めて、アジャイル開発はより身近になったように思う。

チケットはXPのタスクカードをデジタル化したもの。
SW開発のタスクは、管理可能かつ追跡可能なサイズまでチケットを分割する。
そして、そのチケットは、イテレーション単位にグルーピングされる。

この時、イテレーションの概念の根本は何なのか？
僕は下記2つの意味を持つと考える。

一つは、リリースする時のスナップショット。つまりタグ。
もう一つは、ステークホルダーが要件や仕様で合意したベースライン。
このベースラインは、例えば、顧客から開発者へ設計書が渡る時や、開発者からデータセンターへモジュールがリリースされる時に発生する。

前者は、プログラマの観点では、システムのバージョンに相当する。
後者は、管理者の観点では、改定履歴のバージョン、つまりベースラインに相当する。

【2】上記のイテレーションの概念から、僕はアジャイル開発の特徴を二つ経験した。

一つは、早期リリースによる重大な問題の検出。
２～４週間毎のリリースは、実際のSW開発では正直しんどい。
システムを稼動させることは、単にプログラムを書けばよいものだけではない。
ビルドを通し、DBやWebサーバーも含めた環境で安定動作させるのは、実際に動かさないと分からないものだ。

また、要件漏れや設計漏れも、実際に動かして、顧客からフィードバックをもらわないと分からない。
設計書を書くという伝言ゲームだけでは、動くプログラムがないから、考慮漏れがすごく多い。
また、設計書通りに作ったとしても、実際に動かしてみると使い物にならず、他のやり方の方がいいというフィードバックも実は結構多いものだ。
SIerが顧客志向というサービス業であるならば、顧客のフィードバックを受けやすい開発スタイルは、顧客満足度を大きく左右させる。

もう一つは、平鍋さんの言うタイムボックスと言う発想。
２～４週間のイテレーションに含められるチケットの数は、正直限られる。
わずか10日～20日で作れる機能は、たとえチームのサイズが大きかろうとも、そんなに作れないものだ。

だから、チケットの取捨選択というマネジメント能力が管理者に大きく要求される。
基本は、優先度の低いチケットは捨てる発想が重要。

顧客のビジネス要件から、どの機能を実装するチケットが優先されるのか？
開発者の工数見積から、実現可能なチケットはどれなのか？
そのバランスで、イテレーションに入れるチケットは決まる。

イテレーションを思い通りにコントロールできれば、アジャイルに開発できるし、更に開発が楽しくなる。
月1回は必ずリリースがあるというリズムは、ゴールが見えず延々と残業が続くデスマーチとは違うプロジェクトになるだろう。

【3】このイテレーションの概念がTracとRedmineでは考え方が微妙に異なる。

Tracのチケットの属性には、「マイルストーン」「バージョン」の二つがある。
「マイルストーン」は、プロジェクトの区切りであるマイルストーンと同値。
管理者なら、週次報告で進捗を報告するだろうから、毎週の報告日が相当するだろう。

Tracの「ロードマップ」では、「マイルストーン」単位にチケットがグルーピングされる。
だから、Tracの「マイルストーン」はイテレーションに相当する。

更に、Tracチケットの「バージョン」は、リリース時のモジュールのバージョンに相当する。
これはプログラマの観点なら、リリース時に付けたタグと同じ。

しかし、Redmineでは、Tracの「マイルストーン」「バージョン」が故意に同一視されて、「バージョン」と呼ばれる。
Redmineの「バージョン」は、マイルストーンでありシステムのバージョンでもある。
Redmineチケットでは、ターゲットバージョンという項目でプルダウンで設定できる。

Redmine「ロードマップ」もTracと同様に、「バージョン」単位でチケットをグルーピングする。
しかし、Tracよりも終了チケットと進行中チケットの2種類の進捗を緑色の濃淡で表示してくれるので、より的確に進捗を把握できる。

僕は、Redmine「バージョン」にグループ化された全チケットがCloseされてリリースされたら、その直後に、Redmine「バージョン」へリリースしたモジュールのバージョンを付ける運用にしている。
理由は、そのイテレーションに名前を付けたいからだ。

この運用をし始めてから、僕は、Redmineの「バージョン」と言う概念が好きだ。

ターゲットバージョンという言葉は、例えば、

次のリリースバージョンは1.1だ！　
それに向けて頑張るぞ！

という場面を連想させてくれる。
何かワクワクしないかな？

Tracの「マイルストーン」「バージョン」は確かに区別すべき概念であろうが、Redmineの「バージョン」のようにイテレーションの概念として同一視した方が、チケットの運用はやりやすい。
イテレーションをリリースする時、リリース対象はモジュールだけでなく、仕様書も納品物の対象である場合が殆どだ。
だからこそ、プログラムだけでなく、仕様書にもタグ付けするし、そのために仕様書も構成管理の管理下に置く。

我々開発者にとって、「マイルストーン」も「バージョン」も同じ意味を持つ目標だから。

Redmineには「変更履歴」という画面があり、終了したイテレーションの履歴そのもの。
それはChangeLogと同じ。
我々開発者は、この「変更履歴」を残すために仕事しているようなものだ。

イテレーションのライフサイクルは、当初はリリース計画であり、開発中は２～４週間のPDCAサイクルであり、リリース後は、ChangeLogとして公開される。
そして、リリース後にそのChangeLogを開発者全員でふりかえりをすれば、次のバージョンで改善すべき内容が出てくるだろう。

イテレーションこそがアジャイル開発の肝。