Redmineを使って気づいたことpart4～チケットの状態管理

Redmineを運用して気づいたことを書いてみる。

【元ネタ】
ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回　運用の開始｜gihyo.jp … 技術評論社

ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回　BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社

[redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06)

【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる

Redmineによるチケット管理で重要な概念はトラッカー。
Redmineのトラッカーは、チケットの種類を意味する。
デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。
バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分ければよいだろう。

Redmineでは、管理画面にあるワークフロー画面で、先行ステータスと後行ステータスのマトリクスでチケットの状態遷移を定義できる。
このチケットの状態遷移は、トラッカー単位、更にユーザーのロール単位で切り替えることができる。

Tracのワークフローよりも勝るRedmineの利点だと思う。

このワークフロー画面がプロジェクトリーダーにとって、自身のチームのSW開発フローを定める重要な機能になる。
プロジェクトリーダーは、何種類の運用フローを意識して管理しているか、が、この画面で一目で分かる。
レベルの低いプロジェクトリーダーは、ウォーターフォール型開発の1種類の運用フローしか持っていないから、結合テスト以降で苦労するだろう。

普通のSW開発では、障害修正と仕様変更の運用フローは異なる。
障害修正は、一つのバグ報告票に対して、PGとテスターが交互に修正＆検証し合う。

仕様変更は、設計者・PG・テスターの3人が必要なため、バグ修正よりもはるかに複雑になる。
設計者が仕様の方針決定の後に、PGのソース修正が始まるから、障害修正よりもフローが長くなる。
この運用フローを意識して使いこなせれば、Redmineの強力な変更管理機能のおかげで、作業状態を追跡するのが簡単で、運用後に履歴として簡単に検索できる。

更に、新規開発の場合も上記と異なるだろう。
新規開発は何も無い所から実装するため、要件定義や設計がより重視される。
だから、その工程のためのステータスが必要になるだろう。

僕は、TestLinkで判明したバグ修正フローをRedmineにのせた場合、運用フローを変えた。
普通は、新たなステータスが発生するタイミングは、担当者が増えた場合だ。
１ステータス＝１担当者として管理した方が楽だから。

【2】フィードバック、却下になったチケットは要注意

プロジェクト管理をチケット管理に置き換えて運用して、色々面白い現象に気付く。

PGがバグ修正したものの、テスターが検証するとNGになる場合がある。
その時に、フィードバック(差し戻し)というステータスが発生する。

僕が運用してみて気付いたことは、フィードバックになったチケットは、フィードバックを2回以上繰り返す確率が高くなる。
つまり、何度修正しても、テスト漏れや仕様漏れが発覚して、なかなか終了しない時がある。
殆どの原因は仕様漏れ、設計漏れが多いため、PGのミスとは言い難い。
だから、フィードバックのチケットは、根本原因を探るために細心の注意を払う必要がある。

あるいは、テスターがバグとして起票したチケットが、実は仕様通りと判明する場合がある。
その時に、却下というステータスが発生する。

却下の場合は、根本原因を探るのが重要。
チケット発行者が仕様を理解していない場合なら、技術力が低いか、設計者が仕様をきちんと説明していなかったのが根本原因だろう。
テストケースや設計書そのものが間違っていたのが原因ならば、設計工程の成果物の品質が低い可能性が高い。

いずれにしても、上流工程や運用フローに問題があるため、根本的な問題に対処しないと同じ過ちを繰り返す可能性が高い。

【3】複数のチケットを関連させる

バグが他のバグと関連しているため、チケット同士にリンクさせたい時がある。
Redmineのチケット欄には、追加というリンクがあり、ここにチケットIDを入力すればリンクできる。

Redmineの関連チケットの種類は下記4種類がある。

4-1.単なる関連 (related up) : 単に関係していることだけを表す
4-2.重複 (duplicates) : 同期してクローズされる
4-3.ブロック (blocks) : ブロックしている問題がクローズされないとブロックされた問題はクローズできない
4-4.先行 (precedes) : スケジュール的な前後関係を表す

よく使われるのは「単なる関連」。

二つのチケットの原因と修正方針が全く同じならば、「重複」を使う。
このケースは、一つのチケットの修正で他チケットのバグも直る場合に使う時が多いだろう。
「重複」されたチケットは、元チケットが終了ステータスになったタイミングで、終了になるので便利。

「ブロック」を使うケースは、別チケットの修正が終わらないと修正できない状況。
例えば、Amazonのように、カート画面で重大なバグが発生した場合、注文フローのテストやバグ修正は行っても、再検証の必要があるから、ブロックにして保留にしておく。
つまり、ブロックしている問題が終了してから、ブロックされた問題を終了できる。
「先行」も同様に使えるだろう。

ブロックの使い道は、変更要求の親チケットと複数タスクの子チケットの関連に使えるかもしれない。

チケット管理を上手に運用できないと、すぐにチケットは乱発されて放置されて、泥沼に陥りやすい。

10人以上のチームや複数チームで運用している場合は、Redmineのチケットを管理するだけの専門担当者をアサインする必要があるだろう。
更には、一つのチケットの修正方針を、管理者だけで判断できない状況が増えたら、ITILの言うCAB（Change Advisory Board：変更諮問委員会）」を開催して、複数の関係者と相談して決めざるを得ないだろう。

チケット管理こそがチケット駆動開発の肝。

商用開発は保守性よりも信頼性を重視する

保守性と信頼性のトレードオフについて良い記事があったのでメモ。

【元ネタ】
森崎修司の「どうやってはかるの？」 > 保守性と信頼性のトレードオフ : ITmedia オルタナティブ・ブログ

記事で面白いと思ったのは下記2つ。
一つは、オープンソースは保守性が重視されること。
ソースが読めないシステムは、最終的には誰も使わなくなるから。
その意味では、オープンソースはプログラミングのレベルが高いシステムと言える。

もう一つは、商用開発は信頼性の方が重視されること。
本番稼動しているシステムは、止まってはいけない。
保守性を実現するためにリファクタリングして、障害が発生したら、元も子もない。
だから、リファクタリングできずに、重複したロジックがあちこちにできたりして複雑になってしまって、最終的には誰もソースを改変できなくなる可能性がある。
商用システムは、最終的にはパッチで継ぎ接ぎだらけの汚いソースが増えているだろう。

実際のSW開発では、保守性と信頼性は両方とも大事。
でも、トレードオフの関係になる場合もありうることを知っておくべきだろう。

ソフトウェアもムーアの法則で巨大化する

garyoさんから下記の記事を教えてもらったので、その感想を書く。

【元ネタ】
森崎修司の「どうやってはかるの？」 > ムーアの法則に近いペースで大規模化するソフトウェア : ITmedia オルタナティブ・ブログ

組み込みソフトウェアは、ハードウェアがムーアの法則に従うのと同様に、どんどん大規模化しているらしい。
つまり、下記の経緯が発生したらしい。

一人で複数の組み込み系システムを作る
↓
一人で1個のシステムを作る
↓
複数人で1個のシステムを作る
↓
複数の会社で1個のシステムを作る
↓
更に、要件定義や設計、開発、品質保証の工程別に、複数の会社が入る。

人月の法則が示すように、大量の開発者、複数のチームによる開発は、デスマーチに陥る可能性は高い。

携帯電話の場合、もはや一つの会社で最初から最後までハードもソフトも内製で自作するのは非常に難しいだろう。
この傾向は、業務システムでも同様だろう。
ムーアの法則のスピードにSW開発はついていって、進化しているだろうか？

ふりかえりを実践してみて

Redmineでチケット駆動開発を運用し始めてから、自然にふりかえりを取り入れることが多くなった。
ふりかえりでは、KPTという思考フレームワークを使うことが多い。

このKPTという手法で、開発チームと開発プロセスを大きく改善できた経験をしたので、振り返ってみる。
＃ラフなメモ書き。後でまとめる。

【元ネタ】
初めてのプロジェクトリーダー（6）
「ふりかえり」でプロジェクトを改善する

オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」

【1】ふりかえりが無いチームは成長しない

成果物の品質が悪く、納期がズルズルと遅れる開発チームでは、同じ失敗を何度も繰り返す症状が多いだろう。
例えば、デグレ。
デグレが何度も起きると、その成果物そのものの信頼性が損なわれ、最終的には人間関係の信頼まで壊れてしまう。

そんな症状を見ると、駄目なチームはフィードバックプロセスが無い事実に気付く。
フィードバックが無いから、プロジェクト管理者は裸の王様。
現場の開発者の実情も気持ちも知らないから、リスクが突然表面化して、慌てて対策を立てても、手遅れだったり、的外れだったりする時も多い。

この症状はSW開発だけでなく、ビジネスでも同じだ。
現場のフィードバックの無い会社は、経営層が独裁者であり、経営層は裸の王様にすぎない。

特に、デスマーチプロジェクトでは、フィードバックプロセスが無く、目的の無い作業が延々と続けられる。
プロジェクトには必ず納期があり、プロジェクトを一つずつ経験していくうちに、ノウハウがたまって成長していくのに、ゴールの見えない作業は、単に疲労感をもたらすだけ。
開発者も管理者も成長しない。

現場から問題点のフィードバックがあれば、管理者も開発者もその問題を解決しようという行動が自然に出てくる。
「ザ・ファシリテーター2―理屈じゃ、誰も動かない!」では、人は問題に気付くと問題を解決しようと自然に動くものだ、という一節がある。

リスク管理に敏感な管理者ほど、リスクを嗅ぎ取るためのフィードバックを大切にするものだ。
すると、フィードバックする雰囲気作り、場作りが重要になってくる。
このフィードバックプロセスをマネジメントとしてフレームワーク化したものが「ふりかえり」だと考える。

【2】ふりかえりはフィードバックプロセス(つまり、評価＆改善プロセス)

アジャイル開発の一番の特徴は、インクリメンタルな開発だと思う。
２～４週間のサイクルで開発＆リリースを繰り返しながら、成果物を積み重ねていく。
チケット駆動開発も、バージョン単位で小規模リリースしていくから、インクリメンタルな開発を自然に行っている。
この時、バージョン単位でリリースした後に、ふりかえりを行うと効果的。

ふりかえりは、プロジェクトファシリテーションのプラクティスの一つとして提唱されているので、詳細はガイドを読むといい。
ふりかえりは一言で言うならば、PDCAサイクルの評価と改善プロセスに相当する。

僕のチームでは、Redmineロードマップに従ってバージョンをリリースした後、必ず、今回のリリースで何が良かったか、あるいは、何が悪かったのか、を自然にふりかえる雰囲気が生まれてきた。

全てのリリースがいつも成功するわけではない。
リリースした後に障害がすぐに判明する時もある。
リリースは成功しても、その過程で無理な作業を強いてしまう時もある。

チケット駆動開発では、リリース結果が終了チケットの履歴として残る。
バージョン履歴やコミットログ統計、チケット集計結果から、このチケットの修正方法が甘かった、とか、テストで混乱したのはテストケースの説明が不十分だったから、とか、工数見積もりを誤ったのはリファクタリングの作業を入れていなかったから無理が生じた、など、色んな意見が開発者から出てきた。
プロジェクトリーダーは、それらの意見を取り入れて、次のバージョンで改善した運用ルールを導入する。
その運用がうまくいったならば、一つの問題が解決したことになる。

このサイクルを意識化したプロセスが、KPTによるふりかえりだ。
フィードバックプロセスがあるからこそ、PDCAサイクルはらせん構造となり、チームは成長していく。

【3】KPTは誰もが意見しやすいような雰囲気を作る

KPTのからくりは非常に簡単。
Keep(良かったから次も続けたいこと)、Problem(問題だから次は止めたいこと)、Try(次に挑戦したいこと)の3つをチーム全員で書き出してまとめること。

僕がKPTで一番注意するのは、チーム一人一人が必ず1回は発言すること。
ワインバーグの本「スーパーエンジニアへの道―技術リーダーシップの人間学」には、技術上の問題を解決する意見を言った人は、そのチームの発言回数が最も少ない女性だったという例をあげて、少数意見を取り入れるリーダーシップの重要性を指摘している。

僕は、メンバーにPostItに書いてもらっている。
ホワイトボードへ書くようにしたら、うまくゆかなかった経験があったから。

普通の日本人は自己主張しない。
特に女性はそうだ。
大きな声を立てる人の意見だけが残り、数少ない少数意見が出にくい。
PostItなら、一旦静かになるが、どのメンバーも必ず一つは意見を出してくれる。

但し、他のファシリテーターから、ホワイトボードで書くやり方ができないのは、プロジェクトリーダーにファシリテーションのスキルが無いからだろう、という指摘を受けた。
他にも良い方法があるかもしれない。

【4】KPTに出てくる改善パターン

KPTをやって一番面白かったのは、リーダーがあげたKeepが、メンバーからProblemという指摘を受けたこと。
例えば、僕のチームでは、仕様確認をExcelで残す運用を僕がKeepにあげたら、開発者から、Excelでは欲しい情報を全文検索しにくい、というProblemがあがった。
これはリーダーの認識が裸の王様だった、という事実そのもの。
メンバーからProblemの理由をきちんと聞けば、それなりの理由があることが分かり、そこから問題点を改善しようとする雰囲気になる。

問題意識の強いチームは、Keepをすっ飛ばして、Problemを話したがる。
あるいは、Problemの中に、この問題はこのような解決策があるから試したい、というTryの意見が混じる時もある。
ProblemからTryの話が膨らむ時は、結構楽しい。
僕のチームでは、ProblemとTryの議論が白熱する場面が多くて、次のバージョンではこんな対策や運用を試してみようか、という結論に達する時がある。

そして、そのTryを一つずつ次のバージョンで取り入れていくうちに、開発プロセスは自然に改善されて、生産性が高くなってゆく。

Tryの項目が成功したならば、その項目はKeepに移る。
今後も続けるべき運用ルールになるだろう。
そして、その運用ルールでは解決できない新たな問題が又出てくるだろう。

KPTを続けると、Problem→Try→Keepという自然なループ構造が発生する。

しかし、KPTで全てがうまくいくとは限らない。
5回以上KPTを続けてみると、Problemに問題がずっと溜まり続ける時がある。
あるいは、問題解決策がTryに提示されているのに、放置状態になっている時がある。
つまり、TODOがたまるとTryが多くなる。

そんな時はProblemやTryの棚卸しが必要。
Tryに上がった解決策を実際に試して成功したか、その評価を聞く。
あるいは、Problemにあがった問題がどのように変化してTryへ移り、Keepへ昇華されたのか、辿ってみる。

すぐに解決できない問題も時には存在する。
そういう問題は、隠さないけれども認識はしておくべきだろう。

KPTによるふりかえりを僕が使った動機の一つは、RedmineやTestLinkの運用について開発者の率直な意見が聞きたかったからだ。
RedmineやTestLinkを導入して、プロジェクト管理も開発プロセスも劇的に変化したけれども、その運用が根付いた理由は、開発者の積極的な関与もあったから。

ツールとその運用は、セットで考えるべきだと思う。
その時に、KPTのよるふりかえりは大きな威力を発揮すると思う。

TestLinkを運用して気付いたことpart3～プロジェクト後半のプロジェクト管理はテスト戦略が大半

「ソフトウェアテスト293の鉄則」を読みながら、TestLinkを使って気付いたことを書き留めてみる。
＃ラフなメモ。論理的一貫性は後でまとめる。

【1】TestLinkを使う場面は、結合テストやシステムテストなど、シナリオベースのテスト工程。
このテスト工程は自動化できておらず、大量のテスターを動員してテストするのが普通だろう。

実は、プロジェクト後半のプロジェクト管理はテスト戦略が大半を占める。
理由は、二つあるだろう。

一つは、テスト工程はプロジェクト後半という時間とリソースの限られた状況があるため、バグが多発したら非常に制御しにくい。
もう一つは、結合テストやシステムテストのテストケース数は数千～数万の桁と膨大なので、どの機能を最優先でテストしてバグを潰すか、というテスト戦略無しでは、いつまで経ってもテストが終わらないだろう。

信頼度成長曲線の教える所によれば、ある程度のバグを出して修正して、初めて品質の歩溜りに達する。

しかし、SW開発の後半のテスト工程で、要件漏れや設計漏れが判明したり、突発的な仕様変更が来たりして、大きな修正工数が発生する時は多い。
テスト工程でバグを潰しているのに、大きな設計変更や仕様変更を盛り込んだら、バグの発生源が発散してしまい、品質を制御するのが非常に難しくなるだろう。

プロジェクト管理と言うと、進捗管理やコスト管理、要件定義、モデリング設計などをイメージするが、テスト戦略を作って実行し、そのプロセスを管理する重要性ははるかに高い。
現場リーダーは、テスト戦略の重要性を改めて認識すべきではないか。

【2】Redmine＋TestLinkを運用して、改めて、PLの采配は、いかに最小のテストケースで最大の品質を得るか、にある気がする。
限られたリソース、時間、人員でいかに最大の品質を確保するか。

でも、根本的に間違っているのではないか。

バグ０％を目指すならば、全てのテストケースを網羅してテストしなければならない。
でも、現実的には、テストケース数は爆発して、納期どころか有限の時間内でテストしきれない。

いかにテスト工程を手抜きして品質を確保するか、PLは躍起になっているのではなかろうか。
テストの自動化は解決の一つの手段にすぎない。
テストケース数が爆発したら結局、自動化しても全網羅は不可能。

ここで、アジャイル開発は、機能を分割して、小刻みにリリースしていくスタイル。
つまり、ユーザにとって重要な機能に重点を置いて、機能拡張し品質を確保する戦略を意識的に取る。

１００％網羅するテストは不可能だし、そもそも不要とアジャイル開発は割り切っていると思う。
特にXPは。

アジャイル開発の肝は、チケットの取捨選択、テスト戦略だと思う。
実現するチケットは、納期・スコープ(機能)・工数のバランスで優先順位が決まる。
優先順位の低いチケットは実装しなくていいし対応不要。

実装した機能のテストを優先して、まだ実装もされていない機能はテスト不要と割り切る。
優先順位の高いチケットを実装した機能のテストから始める。

Redmineを運用してみて、BTSの基本構造はチケット駆動開発(TiDD)だと確信する。
TestLinkは、Redmineと連携することで、テスト後のバグ修正で大きな威力を発揮する。

【3】「ソフトウェアテスト293の鉄則」を読みながら改めてテスト戦略やテスト手法について考えさせら得た。
僕が一番気になった鉄則は下記の通り。

2-1.バグの優先度と重要度を区別せよ。

テストで判明したバグは、まず、全て修正する必要はないことを改めて認識しておく。
バグが大量に発生したら、どのバグを最優先で修正していくか、優先順位付けするのが重要。
このバグは実は仕様通りです、という場面もあるから。

仕様はそもそも、お客様の要望の重要性と開発者の工数見積もりの間の認識で決まる。
バグも同様に、お客様の業務で重要な機能のバグを優先するだろうし、修正の工数見積が大きかったり影響が大きければ、慎重に修正するために工数を確保して実施する時もあるだろう。

バグの優先度をコントロールする役割を担う人がプロジェクトリーダー。

2-2.プロジェクト管理は機能、品質、時間、コストのトレードオフ。
　ウォーターフォール型開発は品質と時間が対立する。
　インクリメンタル型開発は機能と時間が対立する。

製造業では、QCDの三角形でマネジメントする。
SW開発では、機能・納期・コストの三角形でマネジメントするのが基本。

品質・納期・コストの三角形でSW開発を始めたら、品質を犠牲にせざるを得ない場面が必ず出てきて、その時にプロジェクトは崩壊へ一気に進むだろう。

ウォーターフォール型開発がSW開発に適用すると非常に危険なのは、そういう状況があるからだろう。
インクリメンタル型開発では、機能を小刻みにバージョンアップすることで、品質を確保しつつ、機能拡張していく。

メインラインモデルというバージョン管理のインフラがあれば、インクリメンタル型開発がやりやすくなると思う。

2-3.プロジェクトマネージャーは構成管理(と変更管理)の問題に気付け。

バグ修正で一番嫌なミスは、以前直したバグが再発するデグレードという現象だ。
コードが古く、パッチだらけのシステムなら、ソースを変更しにくいので、デグレの危険性が高いだろう。
コードがたとえ割と綺麗であっても、ドキュメントが揃っていても、デグレが発生する時もある。

デグレの共通の根本原因には、構成管理(訳注では変更管理も含むと書かれている)が貧弱だから、と指摘している。
この指摘は非常に鋭いと思う。

まずはソースコード管理とその運用について積極的に解決しない限り、直前のビルドで動いていた他の機能ももう一度確認する羽目になる。
XPの継続的インテグレーション、テストの自動化、のプラクティスを当てはめれば、大部分は解決できるだろう。

しかし、昨今のSW開発では、ITILの言う変更管理プロセスをどれだけコントロールできるか、という点が重要になってきたと思う。

バグを直すパッチを当てた時、他の機能が影響を受けないか、頭を巡らしているか？
開発者は、自分が作った機能しか詳しくないから、他の機能への影響まで考慮しない場合が多い。
だから、変更管理プロセスで、バグ修正の影響具合を設計の工程でコントロールできる能力をPLもSEもPGも必要とする。

この時に、チケット駆動開発のインフラがあれば、チケットに過去の変更理由が残っているため、影響調査が非常にやりやすくなる。
実際の追跡方法は、ソースのリビジョンからチケットを経由して変更理由を探すやり方だろう。

特に運用保守では、たとえバグがあろうとも稼動しているシステムの動作が正しいから、安易にパッチを当てると、バグ有りで運用していた顧客の業務まで変わる危険性がある。
だから、何故バグ有りになったのか、その理由を追跡する仕組みがあると非常にありがたい。

Redmine＋TestLinkはアジャイル開発のインフラを提供してくれる強力なツールだと強く思う。

TestLinkを運用して気付いたことpart2～ビルドと要件管理機能

先週、TestLinkのメーリングリストで、コミッタの川西さんとTestLinkのUI改善や運用方法について熱く議論した。
その議論で考えたことについて書いてみる。

【参考】
TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

TEF有志によるTestLink日本語化プロジェクト - TestLink日本語版で始めるテスト管理システム(簡易マニュアル)

僕はTestLinkを3ヶ月運用してみて、Redmineと同様にTestLinkは僕のプロジェクト運営に欠かせないツールになった。
僕のチームでさえも、単体～システムテストのケース数は数千オーダー。
もはやExcelのテスト仕様書で管理するのは非現実的。
しかし、テスト工程をExcelで管理しているプロジェクトが殆どで、どのプロジェクトも結合テスト以降の開発に苦労している。

特に、テストでNGとなったケースを一つずつバグ修正して品質を上げていくプロセスは、バグ修正者とテスト担当者のパイプラインをPLがどれだけフォローできるかにかかっている。

TestLinkでテスト担当者がテストでバグ出しして、Redmineで開発者がバグ修正していくパイプラインができた今では、TestLinkとRedmine無しのSW開発は考えられない。

しかし、TestLinkのUIは使いづらい機能があり、使いこなせない機能がある。
川西さんから、TestLinkの「ビルド」という概念と要件管理機能を改めて教えてもらった。

TestLinkにあるビルドの概念は下記の通りだ。

1.ビルドごとにテストケースをアサインすることはできない。

2.ビルドは、テスト計画にアサインされたテストケースを回帰テストで管理するためにある。
　(１の機能が実装されている理由に相当する)

#実際の運用のイメージ
　最初はビルドを1個だけ追加する。
　→ビルドに紐づいたテストケースをテストする
　→リリース時にビルドをCloseして、テスト結果を変更できないようにする。
　→2回目のテスト開始時に、新たなビルドを追加する。
　　テスト計画にアサインされた全テストケース(1回目のテストで成功になったケースも含む)をテスト開始。
　　1回目のテスト結果は無関係。
　→以下繰り返し。

3.イテレーション単位にテストケースを変更してリリースするならば、そのたびにテスト計画を作って、テストケースをアサインする。

#実際の運用のイメージ
　イテレーション1は機能A、イテレーション2は機能Bをリリースする計画を立てたと仮定する。

　イテレーション1を開始
　→機能Aのテストケースをテスト計画1にアサインする
　→テスト計画1へビルド1をアサインする
　→機能Aのテスト実行
　→機能Aのテスト結果が全て「成功」になったら、ビルド1をCloseする
　→イテレーション1をリリース
　↓
　→イテレーション2を開始
　→機能Bのテストケースをテスト計画2にアサインする
　→テスト計画2へビルド2をアサインする
　→機能Bのテスト実行
　→機能Bのテスト結果が全て「成功」になったら、ビルド2をCloseする
　→イテレーション2をリリース

つまり、XPやScrumのイテレーションはTestLinkのテスト計画に相当し、TestLinkのビルドはXPの継続的インテグレーションで行う統合ビルド(実際のシステムのビルド)と同等。

例えば、TestLinkのビルド＝Hudson(CIツール)のビルド番号として運用できる！
この例を聞いて、心底、ビルドの概念を理解できた。

もう一つは、TestLinkの要件管理機能。
TestLinkでは、要件をCSVインポートでき、その要件をテストケースと紐づけることができる。
テスト結果画面では、要件の単位でNGのテストケース数などをリアルタイムに見ることができる。
つまり、要件とテストケースのカバレッジを見れる。
この機能は、TracやRedmineに無い素晴らしい機能。

しかし、TestLink上で要件からテストケースを1個ずつ作成して、要件とテストケースを紐付けするのは、ケース数の桁が数千～数万の場合、非現実的。

今、自分が書いたテスト仕様書は、テストケースの行に必ず要件管理IDの欄を追加している。
理由は、テストの目的や観点を明確にして、お客様に説明するため。
つまり、僕の環境では、テストケースと要件管理IDを紐づけるマスタデータは揃ってる。
狙いは下記のトレーサビリティ。

要件(TestLink)→テストケース(TestLink)→【チケット】(Redmine)←ソース(Subversion)

上記のトレーサビリティができれば、設計漏れや要件漏れという上流工程の不具合はテスト仕様書の作成工程で潰せると思う。

今、Redmine＋TestLinkで結合テストや受入テスト、障害修正は非常にスピードアップできている。
しかし、バグ発生の原因を探ると、確かにPGMミスもあるが、仕様漏れや設計漏れ、他機能への影響の考慮漏れ、など、上流工程や変更管理の品質の方に問題がある。

その対策として、TestLinkの要件管理を使いたい。

残念ながら、TestLinkの要件管理機能は現場で使えるレベルではない。
しかし、Redmineと同じくTestLinkには更なる可能性があると思う。

【告知】XP祭り関西2009でチケット駆動開発を講演します

『ＸＰ祭り関西 ２００９』 の概要

■開催日時
　2009年１月24日（土曜日）
　10:00～17:00

■開催場所
　兵庫県伊丹市　生涯学習センター「ラスターホール」

　所在地 〒664-0865 兵庫県伊丹市南野2-3-25

　交通　　阪急伊丹駅より 伊丹市バス「稲野町8 丁目」
　　　　　　阪急神戸線塚口駅より 伊丹市バス「ラスタホール前」
　　　　　　阪急稲野駅より 西へ徒歩600 メートル

■内容
　▼ホール（２Ｆ多目的ホール）―先着１２０名

*※ 基調講演（10:30 - 12:00）
o 「Agile 2008　報告」 平鍋健児氏
o 株式会社 チェンジビジョン 代表取締役社長
o 株式会社 永和システムマネジメント 副社長
o オブジェクト倶楽部 主宰

* 講演①（13:00 - 13:15）
o 「ＸＰ寺子屋」 西　丈善氏
o 日本ＸＰユーザーグループ関西

* 講演②（13:15 - 13:45）
o 「マネジメントから自律へ」 土屋　秀光氏

* 講演③（13:45 - 14:15）
o 「名古屋アジャイル勉強会奮闘記～勉強会を立ち上げて楽しむ7の方法～」(仮)
　　　　 o 名古屋アジャイル勉強会

* 講演④（14:30 - 15:00）
o 「ゼロ機能リリースのもうひとつの側面
o ～ ワーキングスタイルを変える開発基盤をまず構築しよう ～」 中西　庸文氏

* 講演⑤（15:00 - 15:30）
o 「チケットファーストでアジャイル開発！～構成管理を見直そう」 あきぴー氏

　XPを代表とするアジャイル開発は広く知られてきましたが、実際の現場では運用のハードルが高いため普及しているとはいえません。
　しかしながら昨今、プロジェクト管理機能を持つBTS(バグ管理システム)をITS(課題管理システム)として運用してアジャイルに開発する手法が一部で注目されています。
　一部で提唱されている「チケット駆動開発(TiDD)」は、このBTSの運用フローをアジャイル開発の一プロセスとしてフレームワーク化を試みたものです。
　今回は、チケット駆動開発を実践して気付いたこと、考えたことについてお話します。

　▼会場１（２Ｆ視聴覚室）―先着３０名
* ワークショプ①（13:00 - 15:30）
o 「組込み開発におけるテスト駆動開発実践講座」 日本XP ユーザグループ関西

　▼会場２（１Ｆ学習室）―先着３０名
* ワークショプ②（13:00 - 15:30）
o 「プロジェクトファシリテーション入門」 Project Facilitation Project関西

　※　「基調講演」は、全員参加となっております。

=============================================================

詳しくは、ＸＰＪＵＧ関西のホームページをご覧下さい。

Agile methodologies and Redmine

Redmineのフォーラムで、XPやScrumなどのアジャイル開発とRedmineの強い関係性を議論していた。
気になったのでメモ。
＃あくまでも書きかけ。

【元ネタ】
Agile methodologies and Redmine

RedmineにXPの概念を機能追加できないか？という質問と回答のやり取り。
XPのイテレーションがRedmineのバージョンであること、ScrumのバックログがRedmineのチケット一覧であること、と喝破している。
素晴らしい！

The first feature of XP is iterative development process. In Redmine there are versions. So, we may use versions, as iterations. It is very good, (略)

The next important thing is Backlog. In reality it is issues list in Redmine. I.e. it is all issues (略)

XPのイテレーション計画はRedmineのロードマップそのもの。
XPはイテレーション単位で小刻みにリリースする。
Redemineもバージョン単位で小刻みにリリースする。

リリース後の終了チケット一覧は、Redmineでは問題タブにある変更記録という画面で表示される。
つまり、変更記録はChangeLogと全く同じ。
更には、Scrumのバックログに相当する。

XPのプラクティスや概念をRedmineの機能とマッピングできたら、Redmineをアジャイル開発のインフラの例とできるだろう。

だが弱点も言っている。
ストーリーカードとタスクカードをチケット管理にどのようにマッピングさせるか？

Each issue in XPlanner has subtasks. It is very good point. (略)

Sum of subtasks estimations - is estimation for the issue. It is very important, (略)

これは、親チケットを更に子チケットへ分割して紐づけた時、チケットの親子関係をビジネスルールとして実装できるか？という点。
普通、親チケットには元々の変更要求とその対策が書かれて、子チケットに各担当者の作業内容が書かれているだろう。
その場合、子チケットの作業期間と工数の合計と親チケットのそれが一致する制約がある。
更に、全ての子チケットのステータスが終了して初めて親チケットが終了になる制約もある。
それらのビジネスルールを実装するのは可能だろうが、BTSそのものとしては使いづらくなるかもしれない。

Redmineはタスク・トラッキング・システムだが、プロジェクト・トラッキング・システムではない。でも我々は、任意のレベルのプロジェクトにも使えるツールを必要としている、と言う指摘は的を得ている。

Redmine is task-tracking system, but we need project-tracking system. I.e. we need in good tools in a level of projects.

この思索を更に深めたい。

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」

関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。
CC Attribution ライセンスとします。

Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ from akipii Oga

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

チケット駆動開発は、まちゅさんが最初に提唱された。
しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。

僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。
その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。

コメントがあれば嬉しいです。

【参考】
Rubyist Magazine - RegionalRubyKaigi レポート (03) 関西 Ruby 会議 01

オクガクブログ::KOF２００８

(引用開始)
2つ目は、「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」というもので、RoRでつくられたBTSを活用した事例紹介でした。
これは素晴しくよかった。
プロジェクト管理しかもアジャイル的にBTSを活用して行うということで、興味深さ満載でした。是非うちにも導入したい。早速試してみようという内容でした。
(引用終了)

Redmineを使って気づいたことpart3～チケット分割のタイミング

Redmineを運用して気づいたことを書いてみる。

【元ネタ】
Martin Fowler's Bliki in Japanese - 支払利息の見積もり

PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス）

【1】登録したチケットを分割するタイミングがある。

WBSから初期スケジュールを作成した時、機能追加だけの実装内容のチケットの工数は3人日を見積もったとする。
しかし、実際にチケットを担当した開発者の実績は5人日をオーバーする時がある。

何故遅延しているのか、開発者に聞いてみると、機能追加する前のリファクタリングに時間がかかっている。
理由は、元々のソースはロジックが余りにも入り組んでいるため、リファクタリングしないと機能追加できないから、と言う。

そんな時、僕は、そのチケットからリファクタリングだけの目的の別チケットを新規登録し、リファクタリングは別チケットへ、機能追加は元々のチケットへコミットするように準備する。

そうすると、開発者もリファクタリングに専念できるし、SVNコミットのタイミングがリファクタリングと機能追加の2回に分割できるから、コードレビューしやすい。

チケットの実績工数が膨れ上がっている時、そのチケットはボリュームが大きすぎるのだ。
だから、開発者がプログラミングしやすいような観点でチケットは分割すべき。

この例の場合は、リファクタリングは、M.ファウラーの言う技術的負債に当たる。
元々のソースが綺麗ならば、リファクタリングと言う無駄な作業は不要だったはず。

SW開発では、このような技術的負債を当初見積もることができず、納期間際になって判明してあたふたするリスクをいつも抱えている。

他には、チケットの作業内容が曖昧で、お客様に逐一仕様確認しないと実装できない状況も頻繁にある。
そんな時は、担当者をPGからSEへアサインを変更したりして、質問と回答のやり取りを追跡できるように必ずコメントを履歴で残す。
RedmineのチケットDBに履歴があれば、全文検索できるから、運用保守後に非常に役立つから。

チケット駆動開発は、チケットの進捗具合からそのリスクを嗅ぎ取る。
この経験を元に、初期登録したチケットを積極的に分割するように運用している。

【2】登録したバージョンを分割するタイミングがある。

現在のプロジェクトは、Ver2.0を本番リリースして、Ver3.0に向けて開発中だと仮定しよう。
この場合、Ver2.0のコードラインは保守ブランチ、Ver3.0へのコードラインはtrunkで開発しているだろう。

しかし、お客様から突然、大きな仕様変更がやって来て、今の開発に機能追加して欲しいという要求が来たとする。
その場合、プロジェクトリーダーはどんな判断を下すべきか？

「成功する要求仕様 失敗する要求仕様」に書かれているように、現在の開発はVer3.0でリリースし、仕様変更をVer4.0(もしくはVer3.1)と2回のバージョンに分けて短い間隔でリリースするのが一番リスクが少ないと考える。

こういう状況では、trunkの品質は、ビルドできているが、まだ細かなバグがたくさん残っていて、本番リリースできる品質まで辿り着いていないだろう。
なのに、仕様変更のソースまで混ぜてしまったら、バグの原因が複雑になってしまって、いくらバグを潰しても、もぐら叩きのように品質を歩溜りまで到達させるのは非常に難しい。

「成功する要求仕様 失敗する要求仕様」のやり方は、タスクブランチを作ることだ。
つまり、突然の仕様変更は次の次のバージョンをターゲットとして、その機能追加を実装したコードラインはtrunkから分岐して、タスクブランチを作り、そのコードライン上で実装していく。
当然、trunkからタスクブランチへのマージは頻繁に行い、同期する。
Ver3.0をリリース後、trunkへタスクブランチをマージして、Ver4.0へ向けてバグFixしながら品質を高めていく。

このタスクブランチの開発戦略は非常に難易度が高いけれども、機能を疎結合に分割する設計が巧みならば、成功する確率は高い。

このタスクブランチの手法は、SQLインジェクションやセキュリティパッチなど緊急のバグ修正、バグ調査用のモジュール作成など、意外と頻繁に使う時が多い。

チケット駆動開発は、任意のバージョンにどんな機能やバグ修正を混ぜ込んでリリースするか、という観点でプロジェクトをコントロールできる。
つまり、チケット駆動開発は、trunkとbranchの２つのコードラインで開発するメインラインモデルと密接に関係している。

チケット駆動開発は、当初の見積もりに無かった突発の作業が発生した場合にいかに柔軟に対応するか、という決断と戦略能力が求められる。

チケット管理こそがチケット駆動開発の一番の肝。

Redmine 0.8.0 release candidate！

ついに来たRedmine 0.8.0 release candidate！
ver0.7.3が2008/7にリリースされて半年近く、ようやくメジャーバージョンアップする。

Redmine 0.8.0 release candidate のニュースには、下記の説明がある。

This new release brings a long list of features and fixes. Among them are:

cross-project search engine
cross-project time report
free ticket filtering on calendar and gantt
ticket integration via emails
wiki page protection and hierarchy
user's activity view

ver0.8では、デザインが洗練されて、UIが多機能で使いやすくなっただけでなく、数多くの新規機能もある。
プラグインも増えてきた。

Redmineでプロジェクト管理をし始めると、RedmineのチケットDBがナレッジDBそのものになってくる。
タスク管理、作業履歴、リビジョン履歴、顧客との質問のやり取り全てをチケットに残せば、全文検索できるから、いつでもどこでも欲しい情報を取り出せる。

Tracに無いRedmineの大きな利点は、複数プロジェクトを作れる点。
ver.0.8では、複数プロジェクトを横断する機能が強化されている。

KOF2008でも、下記のような質問があった。

Q.プロジェクトの親子関係はどのように決めますか？

A.観点によって親子関係を作ります。
　親プロジェクトは、プロジェクト共通の作業管理用。
　例えば、ビルド環境構築とか、テストデータ作成とか。
　子プロジェクトに、trunk, branch、あるいは、顧客の改善要望だけの管理、を作ります。
　つまり、子プロジェクトは、SVNリポジトリのライフサイクルと一致するように作ります。
　これらを一つのプロジェクトにすると、チケットが発散してしまうから。
　Tracは複数プロジェクトが作れないので、チケットが発散しやすい。

Redmineには、チケットをグループ化する観点として、プロジェクト、バージョンの2種類がある。
バージョンは、イテレーションに相当し、２～４週間のサイクルでリリースできる工数の範囲内でチケットをグループ化する。
プロジェクトは、Redmineではリポジトリと1対1に対応する設計思想で作られているから、SVNリポジトリ単位、つまり、trunkやbranchごとに作るのが良いと考える。

チケット駆動開発(Ticket Driven Development)では、バージョンというイテレーションの観点、プロジェクトというリポジトリのライフサイクルの観点で、チケットを色んな角度から管理できる。
後戻りできないウォーターフォール型開発や、ガントチャート中心のPMBOKと比べると、はるかに柔軟に管理できて、アジャイルに開発できるスタイル。

ver0.8のリリースが待ち遠しい。

Subversionを見直せ

SW構成管理の概念の中心は、バージョン管理。
バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。
デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。

おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。

もう一度、Subversionの機能を見直してみた。

【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社

最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。
メインラインモデルと呼ばれる。

メインラインモデルの手法を使って、本番運用中の保守branchと新規開発中のtrunkの2本のラインを、緊急のバグ修正は保守branchへ、仕様変更や機能追加はtrunkへと使い分ける。
これによって、品質保持と機能追加という矛盾したSW開発が可能になる。

SVNの基本機能をムービーで説明してくれているので、初心者や開発チームに新規加入した開発者へ説明する時に役立つ。
僕は上記の記事で下記の機能をもう一度復習した。

1-1.trunkからリリースする時は、必ずtagでスナップショットを取り、バージョン付けした直後にbranchを作る。
そうすれば、tagとbranchには、過去のリビジョン履歴も受け継がれる。

1-2.ファイルやディレクトリの移動や複製は、SVNコピー機能を使う。
　SVNコピー機能によって、リビジョン履歴も受け継がれるので、その後の運用保守で役立つ。

1-3.マージ機能を使えば、機械的にロジックの一部を最新リビジョンへ追加できる。
　マージトラッキング機能を使えば、マージのUndo作業も可能。

【2】Enterprise Architect と Subversion の連携 - かおるんダイアリー

モデリングツールEnterprise Architect(EA)とSubversionを連携する機能について説明されている。
EAはおそらくUMLモデリングツールの中では、最も使いやすく機能も豊富。

EAには元々、マスターファイルへローカルファイルのモデル(クラス図、シーケンス図等)をマージする機能がある。
上記の記事で、UMLで設計したモデルもSVNでバージョン管理できる。

ExcelやWordもSVNで差分表示できるから、同様にUMLモデルも含めて、仕様書も積極的にSVNでバージョン管理すべき。
仕様書もソースと同じくバージョン管理すべき対象なのだ。

【3】エンタープライズ環境におけるSubversionの複製アーキテクチャ - japan.internet.com デベロッパー

Subversion 1.5.0 での新機能 (WebDAV Write Through Proxy)

SVNリポジトリを安全に保管するために、バックアップするのは重要。
SVNなら、リポジトリを全てエクスポートするよりも、svnsyncでミラーリング機能を使うのが普通だろう。

つまり、開発者はマスターリポジトリへコミットすると、更にpost-hookされて別サーバーにあるSVNリポジトリへリアルタイムにコミットするように設定する。
これによって、タイムラグが生じることなく、マスターリポジトリとミラーリポジトリがリアルタイムに同期される。

だが、このミラーリング機能を更に進化させたライトスループロキシ(WebDAV Write Through Proxy)という機能がある。

最近、優秀な一部の開発チームは、Gitなどの分散バージョン管理を導入している。
分散バージョン管理の利点は、開発中のまだ検証されていないコードラインをローカルでバージョン管理できて、ビルドされていつでもリリース可能なメインラインへいつでもコミットできる点だろう。

特に最近のオープンソース開発のように、trunkにコミットできる開発者は一部のコミッタだけで、別のハッカーがソースにパッチを当てて動かしたい時に、分散バージョン管理の環境があると嬉しいだろう。

上記の記事は、ライトスループロキシというSVNの機能を使うと、複数のSVNリポジトリとsvnsyncを組み合わせることによって、更新可能なマスターリポジトリと読み取りOnlyのミラーリポジトリを作って、分散バージョン管理らしき環境を作ることができると説明している。

この方式を使って単純だが強力で高可用な性質を持つバージョン管理システムを構築することができる。

我々SW技術者は、バージョン管理というSW開発の最も根幹を成すプロセスを効率化し改善できないか、もう一度再考すべきだ。

PerforceによるSW構成管理

Perforceというソース管理ツールがある。
このツールは、CVSやSVNよりもマージやブランチ作成などの機能が優れていて、特にゲーム業界でよく使われていると聞く。

PerforceのHPにSW構成管理の良い記事があったのでメモ。
＃あくまでも書きかけのメモ。

メインラインモデルとSW構成管理の新たな関係。
継続的な改善と変更管理の密接な関係。
インクリメンタルな開発スタイルは品質管理、リリース管理に密接に関係する。

【元ネタ1】
PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス）

【1-1】メインライン（主流となる開発経路）を持つようにする。

何故、trunkというメインラインを1本ずっと保持し続けるか、の良い理由が書かれている。
メインラインを昇格していくモデルでは、開発者へ別の開発環境を作るという不要なコストを強いるから。
ソフトウェア開発の殆どの無駄な作業は、開発環境や本番環境の設定作業など、非常に神経質にならざるを得ない作業が多い。

【1-2】ブランチしようとするときに物理的なコピーをしない。

Subversionには、コピーという機能がある。
この機能は、ソースのコピーだけでなく、ソースの編集履歴も引き継ぐという重要な機能も持つ。
このおかげで、ソースの中に何故こんなパッチが追加されたのか、という変更理由をいつでも探すことができる。

だから、ブランチを作る時も、必ずSVNのブランチ作成機能を用いて、変更履歴も引き継ぐようにする。
つまり、最近のSW構成管理では、ITILの言う変更管理が非常に重要なのだ。

【1-3】「ソース＋ツール＝製品」。

SW開発では、プログラミングよりもビルド作業やリリース作業に非常に神経を払う。
XPのプラクティスの一つである継続的インテグレーションは、常時ビルドしてリリース可能なシステムを保つ点を指摘し、開発者へSW構成管理の重要性を認識させた。

つまり、製品は、ソースとそのソースファイルを入力とするビルドツールがセットになって初めて作られる。
この部分は、ITILの言うリリース管理に相当するだろう。

【元ネタ2】
PERFORCE 変更管理を通じた製品品質の向上

【2-1】実際、それはちょうど"編集－コンパイル－実行"のサイクルに良く似ている。
そのため、すべてのプログラマは、既にこのプロセスについて知っているはずである。

アジャイル開発が何故プログラマに熱狂的に支持されるのか？
おそらくその理由は、軽量言語のプログラミングスタイルと同じだからだ。

【2-2】このテクニックのもう一つの特筆すべき点としては、重要な出荷に関する問題を早い段階で解決することである。
しばしば、非常に重要な項目が、最後まで忘れられている場合がある。
各段階で完全な製品を出荷することによって、我々は、それらをより早く発見し、最終段階でのパニックを避けることができる。
納期間際での作業は、欠陥が紛れ込み易く、もしそれが何かクリティカルなものであれば、そのとき製品の品質はより悪化してしまう。

何故、頻繁なリリースが必要なのか、という説明。
リリース作業、ビルド作業は重要な作業であるとは知っているものの、手間がかかるから、普通は開発者は嫌がる。

インクリメンタルな開発プロセスのおかげで、メインライン(trunk)は常にリリース可能な品質に保たれる。

【2-3】この段階であなたは、バージョンプランニング－, ソフトウェアプロジェクトプランニング"の手法－を用いて、製品の次のバージョンに対する計画を立てるこ とが可能となる。
一つのバージョンは、製品の仕様が進展していく過程での一区切りである。バージョンはあなたが実際に予定したスケジュールの中で満たそうとした一定の要求サブセットである。バージョンを絶え間なく変わる要求のスナップショットとして考えても良い。

バージョンという概念がSW構成管理では非常に重要だ。
バージョンとは、Subversionのtagそのもの。
バージョンが作られるタイミングは、本番環境へリリースする時と一致する。

つまり、SVNリポジトリにある特定のリビジョンのスナップショット。
更に、SVNリポジトリにソースだけでなく、ExcelやWordの仕様書も含まれていれば、同様にリリース時にtagが付けられる。
その意味では、バージョンとは、成果物と仕様を定めたベースライン。

【2-4】このような詳細度レベルで計画を立てることに価値があるのは、せいぜい2ないし3バージョン先までであろう。というのも、要求は変更されるものであるし、次のバージョンで再度それに取り組む事になるからである。それよりも先の計画はラフなものにすべきであり、詳細な計画を遠い将来に亘って作成しても、労多くして益少なしである。
重要な要求に対してそれぞれバージョンを指定しなさい。

タスクブランチを作るタイミングは、trunkやリリースブランチでは対応しきれない大きな仕様変更が来た場合。
タスクブランチは、直近のターゲットバージョンから1つか2つ先のバージョンを指定するだろう。

【2-5】この変更管理プロセスのキーとなるコンセプトは、継続的な改善である。 これは常に要求に対して近づいていく事を意味し、また変更によって要求から遠ざかる事がないように する。
図4は、 私がこのシンプルな考えを説明するために好んで用いるダイアグラムである。 これは"ソフトウェア構成管理"とはどういうものかについて表している.

インクリメンタルな開発プロセスと変更管理は表裏の密接な関係を持つ。
XPなら2週間、Scrumなら4週間の短いサイクルで小規模リリースできるには、簡単で強力な変更管理の機構が必要だ。
強力な変更管理機能があって初めて、多数のバグ修正や仕様変更を短いイテレーションに混ぜ込んでもデグレが起きない開発スタイルができあがる。

【2-6】変更を追跡し管理する目的で、2種類の文書が使われる: 「問題」と「変更」である。
「問題」とは、製品が顧客の要望を満たしていない点について報告された文書である。これは、製品がその仕様に従っていない（欠陥）か、仕様が顧客の要望を表していない（エンハンスメントまたは新規要求）のいずれかである。この違いは顧客にとっては大したことではない。要するにどちらの場合でも、彼らが望む事を製品が提供していないので、変更して欲しいと言っているのである。本文書で述べられているプロセスは"新規開発"と "バグ修正"を同様に扱っている。「問題」は、製品にプロブレムが見つかったときにはいつでも作成される。「問題」はバグ報告書と改善要求を包括する。
「問題」は、変更に対する唯一のきっかけである。変更が顧客に対してその製品を改善 しないのならば、それを行う価値を持たない。インフラの改善であっても、結局は価値を上げる必要がある。

ITILでは、問題管理と変更管理を使い分ける。
エラーが、既知の問題なのか、そうでないかによって、問題コントロールとエラーコントロールの2種類を使い分ける。

【2-7】変更のチェックは、製品の完全性を保つために極めて重要である。それゆえ構成管理に とって重要なステップであるチェックとは、全体の設計戦略に対する変更の適合性をシニ アエンジニアがいかに保証するかという事である。そこは、CMMレベル3のキー・プラクティス[KPA1.1, L3-93]の一つである"ピア・レビュー"7のような確認のステップを組み入れるべき格好の場所である。(確認はCMMレベル3 [CMMI1.02, p267]のキー・プロセス・エリアである。) さらにはその変更が、そのグループに対するベスト・プラクティスとして適している かどうか、ソフトウェア品質保証がチェックできる段階でもある。

レビューを使うタイミングは、変更管理プロセスで使うべき。
レビューは欠陥のあら探しが目的ではない。
レビューは、よほど上手に運用しなければ、すぐに官僚化して、重厚なプロセスになってしまう。

【2-7】我々は、顧客が既に持っているリリースに対してパッチを当てることで、素早く顧客の問題を解決することができる。これは問題を修正するために、出来るだけ小規模で迅速な変更を行う事を意味する。これは、最新のマスター・ソースコードからビルドしたものを顧客に出荷するよりは良い。というのは、それでは、顧客に問題を引き起こしてしまうような方法で変更されている可能性があるためである。また最新のマスター・ソースコードを出荷する事も危険である。それらは、顧客の環境と互換性のない変更を含んでいる可能性があるからである。また、その仕様が分からないので（従って、どういう事をしようとしているものなのかを顧客に話す事が出来ない）、将来保守するのが容易ではない。それらは、おそらく最後のバージョン以降、十分なテストが行われていない。安定したリリースにパッチを当てることは、迅速で高品質な修正結果をもたらす。これが、バージョンブランチを推奨する主たる所以である

本番環境で動くリリースブランチとメインライン(trunk)を何故、別管理にするのか、という理由。
ITILの問題管理の観点からの説明。
品質が安定した本番リリースブランチ上ならば、迅速なバグ修正が可能で、更に品質も保たれる。

【2-8】欠陥に対する修正変更は、バージョン・ブランチにおいてのみ行われる。欠陥とは、リリース製品がバージョン仕様を満たしていない箇所を指す。通常"バグ"と呼ばれているものは、この定義に含まれる。9ほとんどの場合、製品がその機能の一つを実行出来なくなるものである。ある意味でバージョン・ブランチは、マスター・ソースコードがあるべき要求に向かって進化していくのと同様に、その仕様に向かって進化する。
最も重要な事は、バージョン・ソースは既知の物だという事である。そこからビルドされる製品は、完全にテストされた後でリリースされており、小さい変更は結果が予測可能なものでなくてはならない。こうした理由から、重要なことは余り多くの変更を行わない事であり、修正を行う場合は、顧客が抱えている特定の問題を解決するための必要最小限のものとすべきである。この狙いは、問題を迅速に修正することであり、他の問題を持ち込まないようにすることである。

本番環境で動くリリースブランチとメインライン(trunk)を何故、別管理にするのか、というもう一つの理由。
ITILの変更管理の観点からの説明。

本番リリースブランチでは、変更の影響が少ないパッチだけ当てる。
そうしなければ、品質を保持し続けることができない。

【2-9】受け入れ検査は、バージョン仕様に基いて行われる。バージョン仕様は、製品がどういうものでなければならないか（あるいは、要求とどのように違っているか）ということと、リリースがそれにどのように適合していなければならないかということについて厳密に述べたものである。受け入れ検査開発は、バージョンが計画されるのと同時に、製品の開発と平行して始めることができる。

バージョンとは、単にソースのスナップショットだけでなく、仕様のスナップショットでもある。
例えば、アプリケーションには必ずChange.txtが付属しているが、これは、機能の変更履歴そのもの。
同様に、業務システムであっても、バージョン履歴という変更履歴が、受入テストの仕様にもなる。

わずか２～４週間のイテレーションで次々にリリースしていく開発スタイルは、技術力に裏打ちされた開発プロセスが無ければ非常に難しい。
SW構成管理のインフラが整っていなければ、いくらアジャイル開発したくても、運用できないのが現実だと思う。

Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう

RedmineやTestLink、Hudsonなどのツールは一体何を改善して、何を目指しているのか？

一言で回答するならば、これらのツールはいわゆるSW構成管理をIT化するツールなのだ、と考えればよい。
つまり、下記のイメージだ。

Excelで進捗管理していた
→Redmineでプロジェクト管理をIT化

ソースや仕様書を履歴共有できる仕組みが無くファイルを日付管理していた
→Subversionで共同所有

Excelでテスト仕様書を管理していた
→TestLinkでテスト仕様書をWeb化

手作業でビルドしていた
→Hudsonでビルドを自動化(継続的インテグレーション)

我々IT技術者は、お客様がExcelやAccessで運用している業務をIT化、Web化するのが主な仕事なのに、肝心の自分たちのプロジェクト管理の殆どは、Excelで運用して四苦八苦しているだろう。

日本の殆どのSIerで働くPL/PMは、Excelのプロジェクト管理しか知らない。
だから、アジャイル開発のような頻繁なリリースに耐えうるプロジェクト管理技術を彼らは持っていない。

従って、いくらアジャイル開発したくても、XPを運用したくても、その理念を実現するインフラが無ければ、絵に描いた餅に過ぎない。
Excelによるプロジェクト管理はもはや時代遅れなのだ。

この思索を深めると、XPを代表とするアジャイル開発は、プログラマへIT化されたSW構成管理を提供して、プロジェクト管理を意識する必要の無い開発環境を提供しようとする動機があると読み取れる。

アジャイル開発の究極スタイルは、プログラマがプログラミングだけに集中すればいつでもリリースできるようになること。

実際、XPのプラクティスにある「コードの共同所有」「継続的インテグレーション」「テスト駆動開発」はまさにそれに当たるだろう。

今後のSW開発は、Excel無しで開発できるインフラをプログラマへ提供するのが重要になってくるだろう。

我々IT技術者は、この使い古されたSW構成管理という概念を再考すべきだ。