チケット駆動開発は課題管理が中心

TracやRedmineの運用を前提にしたチケット駆動開発は、従来のウォーターフォール型開発のプロジェクト管理とは手法が違う。
下記のBlogを読んで考えたことを書く。

【元ネタ】
プロジェクト管理ツール検討失敗

【1】SW開発ではガントチャート保守のコストが高い

汎用機＋CobolによるSW開発は、プログラミングやビルドのコストが高いから、ウォーターフォール型開発で十分だった。
最初に作った計画が変更されることはない。

しかし、特にWebシステム開発では、実際の受入テストでバグ修正だけでなく、大量の改善要望が発生して、当初の計画や見積もりと食い違う時は多い。
だから、XPなどのアジャイル開発は、小規模リリースというプラクティスを実践して、小さく作って小刻みにリリースして、顧客からフィードバックを受けて更に開発するやり方を取る。

ウォーターフォール型開発なら、ガントチャートを途中で大きく変更することはないが、アジャイル開発では、頻繁なタスク追加や変更が生じるため、ガントチャート保守のコストが高くなる。

【2】チケット駆動開発ではガントチャートは重要ではない

Redmineでチケット駆動開発を実践し始めて、ガントチャートの重要性が低くなった。
Redmineではガントチャートがデフォルト表示だが、その機能よりもロードマップというイテレーション計画の方が重要だと分かってきた。

Redmineでは、ラフなタスク管理をしている感じ。
チケットの当初の作業期間や工数見積もりが、実際に作業すると時間がかかる時は多い。
チケットはまさに課題、つまり、Issueだ。
ガントチャートで予測通りにタスクがはかどるとは限らない。
チケット管理は、SW開発のToDoを緩やかに管理するが、むしろ、作業の追跡性、一貫性を重視する。
まさに変更管理の観点を含む。

【3】チケット駆動開発はSW構成管理のインフラ

アジャイル開発では、計画の変更を前提に開発する。
計画の変更が多いということは、変更要求(RFC)をベースラインとして確定し、更にソースまで追跡できるインフラを必要とする。
しかし、つい最近まで、変更管理や継続的インテグレーションを含む包括的なSW構成管理のインフラが無かった。
ようやく、TracやRedmineのような強力なプロジェクト管理ツールのおかげで、SW構成管理のインフラが整うようになってきた。

SW開発では、ガントチャートによるガチガチのプロジェクト管理よりもSW構成管理による追跡性や一貫性を保障する方がはるかに重要だ。

コードレビューはペアプログラミングの代替手段

garyoさんに教えてもらった「Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」」の感想を書く。

【1】コードレビューができないプロジェクトの問題点

コードレビュー以前に、レビューというプロセスが存在しないプロジェクトは数多い。
相次ぐバグ修正や仕様変更にひっきりなしに対応するのに追われて、設計書やコードを書いただけになってしまいがち。
特にデスマーチプロジェクトでは、雑な作業の結果である雑な成果物ばかり作られる。
読んでも誰も分からない、とか、誤植が多い、などの症状が頻発するだろう。

レビューのない開発チームでは、設計思想や運用ルールの情報共有ができていない。
どんな開発でも、フレームワークやハードを含めたアーキテクチャの上で設計してプログラミングする。
その思想を理解するには、最初は時間がかかる。
特に昨今のWebシステム開発では、3カ月おきに開発者が入れ替わりがちだから、途中加入の開発者は設計思想や運用ルールに慣れるまで生産性が落ちる。

また、プログラミングには誰でも癖がある。
色んな人に見られた方がプログラムの可読性は必ず上がる。

だからこそ、レビューを上手に使って、チームに早くスムーズに溶け込めるように使いたい。

【2】コードレビューはペアプログラミングの代替手段

Googleはコードレビューに力を入れている。
上記Blogの下記のフレーズが気に入った。

(コードレビューは)ペアプログラミングの良い代替手段
(コードレビューは)開発者間の信頼関係を築く
　システムの引き継ぎが容易
　次のプロジェクトに行きやすくなり、流動性が高まる

XPのプラクティスの一つであるペアプロには、賛成も批判も多い。
しかし、ペアプロの目的や利点をはっきりさせれば、導入したくなるはずだ。

実際の開発や運用では、ペアで作業する場面は多い。
本番リリース作業や本番のデータ保守作業は、普通は2人でペアで行うのが普通だろう。
本番作業では1度のミスも許されないから、それだけのコストをかける価値がある。

また、新しい技術を取り入れて技術検証する時などは、席は離れていても、実質2人で議論しながら試行錯誤する時が多いだろう。
普通は一人で考えても上手くいかないから。

コードレビューの目的や利点は、上記Blogから考えると下記2点に尽きると思う。

1.ペアプロの代替手段
2.プロジェクトの引継ぎが楽になる

コードレビューとはペアプロであり、それによって情報が共有され、信頼関係が作られるからこそ、作業の引継ぎがスムーズになる。
コードレビューはあら探しではないのだ。

XPのペアプロは必ず同席という物理的制約があるが、ReviewBoardやCodestrikerなどのコードレビューWebシステムを上手に運用すれば、チャットのような感覚でコードレビューできる。

更にコードレビューしたコメントをチケットのように、重要度や優先度、作業状態を付けて管理できれば、ソースの品質は更に高まるだろう。

変更管理は検事の立証作業に似ている

ITILの変更管理プロセスは、まるで検事が事件を立証していく作業に似ている。
そのデジャブから考えたことを書く。

【元ネタ】
ITILの変更管理

【1】どのプロジェクトでも、納品後の検証が最もプレッシャーがかかる。
検収で上がった不具合は、決められた期限で、デグレしないように確実に修正していかなければならない。
課題として管理し、症状を把握し、原因を調査して、対策を立てて、PG/テスターにアサインし、最後にPLが確認する。
このプロセスをいかに早く回すか、が鍵。

システム全体の機能とお客様の業務の整合性を考えて、設計していく作業をしていると、まるで自分が検事になったかのような気分になる。

というのも、お客様から上がってきた要望や不具合の指摘に対し、設計書や要求定義書、過去メールを引っ張り出して、本来の要求は何なのか、を突き詰めていく作業だから。

だから、過去はこんな仕様だったから仕様変更ですね、とか、これはバグではなく元々の仕様が間違っていましたね、というふうに、元々の要求を探っていく。
そして、以前お客様はこんなメールを書きましたね、とか、こんな要求を言ってましたが矛盾してますね、と、本来の要求を追い詰めていく。

この作業はまるで、検事が、現場の証拠や犯人の行動から事実を論理的に組み立てて、犯人を追い詰めていく作業に似ている。

要求を論理的に追い詰めた後の証拠があると、お客様も無理難題は吹っかけられなくなる。
そして、開発者へも、仕様と要求の本来の意図を確実に説明することができる。

【2】Redmineでプロジェクト管理全般のタスクを管理し始めて、バグ管理だけでなく、仕様変更、プロジェクトの立ち上げ時のスケジュール作成、サーバー環境の構築、顧客からの問合せ調査など、SW開発全般のタスクにも使えることが分かってきた。
Redmineは構成管理の強力なインフラだ。

Redmineでは、チケットに全ての作業履歴が残る。
更に、チケット同士の相互リンク、チケットとSVNリビジョンの相互リンクとしても残る。
又、SVNリポジトリにあるWordやExcelの仕様書、ビルドスクリプトも同様に、SVNリビジョンとチケットが相互リンクできる。
このインフラのおかげで、バージョン履歴から要件やソース修正理由を追跡しやすくなった。

この構成管理のインフラのおかげで、3年前にパッチを当てた修正理由を簡単に探し出すことができる。
すると、設計者やPLは、顧客の要求と過去の修正理由からシステムの変更仕様を設計して、仕様に矛盾がないか、他の機能に影響が無いか、など、仕様の整合性や一貫性を更に突き詰めることができる。

この作業は、丁度、法廷に集められた証拠から一つのストーリーを組み立てる検事の作業に似ている。
Redmineはこの作業の生産性をアップしてくれる。

これが、Redmineが構成管理のインフラになる利点だ。
そして、最近のSW構成管理は、ソースのバージョン管理や、常時統合のようなビルド管理だけでなく、変更管理のプロセスも含むようになりつつある。
だからこそ、昨今のSW構成管理の難易度は数年前と比べて格段に上がっているように思う。

TestLinkを運用して気付いたこと

TestLinkをテスト仕様書代わりに運用し始めて、メーリングリストで使い方を聞いたり、自分で色々試してみた。
色んな気付きがあったのでメモ。

【1】数千、数万のテストケースをTestLinkへインポートするには、下記のExcelマクロでXML出力して、TestLinkのXMLインポート機能を使う。
このツールのおかげで、既存のテスト仕様書からTestLinkへテストケースをコンバートするのが非常に簡単になった。

TestLinkCnvMacro

TestLinkへテストケースを全てインポートして一番驚いたのは、わずか数人のプロジェクトですら、テストケースが1千ケースを越えていることだ。
但し、ここでのテストケースは単体テスト、結合テストのどちらも含んでいる。

今の感触では、20人月規模のプロジェクトならば、TestLinkへインポートするテストケース数は1万ケースを越えるだろう。
つまり、普通のプロジェクトでは、数千、数万レベルのテストケースでもってテストしなければ、品質を保証できないのだ。

100人月規模のプロジェクトならば、数万～数百万という膨大なテストケースを実行しなければならないだろう。
そうなると、そもそも人間の手で検証可能なテストの限界に来ているのではなかろうか？

そんなことを考えると、我々開発者は、これだけの規模のテストケースをきちんと管理できているのだろうか？
そもそも、テスト工程になると、納期間際でテストする時間も潤沢に無いし、たくさんの人手がかかるので修正・検証・管理工数が非常に大きくなる。
だから、単体テスト、結合テスト工程は非常に難しいのだ。

テストプロセスで重要な点は、システムの操作で考えられる業務フローをテストで全て網羅することだ。
一つでもテストしていないケースがあれば、そこからバグに発展する可能性は非常に大きい。
WindowsやIEのセキュリティパッチが月1回公開されていることからしても、たった一つの未実行テストが大きなバグになりうる例が数多くある。

だからこそ、テスト計画時にテスト戦略を考えるのが重要だ。
つまり、どのテストケースを最優先にするのか、限られた時間と人員でテストの範囲をどこまでに絞ってテストするか、限られたテストでどこの機能の品質を最優先で確保するのか、というテスト戦略が重要になる。

膨大なテストケースを全てテストするのは、地球が滅びる時間を越える時だってあるのだから。

今までの自分の現場がいかにテスト管理していなかったか、を痛感させられた。

【2】TestLinkはテスト計画がテストマネジメントの中心になる。
Redmineロードマップとは機能が違う。

TestLinkは下記のようなフローになる。

テストプロジェクト作成
↓
テストスイート作成
↓
テストケース作成
(実際は、ExcelマクロでXMLインポート)
↓
テストケースをテスト計画へ追加
↓
ユーザをテストケースへアサイン
↓
テスト計画へビルドへアサイン
↓
テストケース実行
↓
リリース後、テスト計画を修正できないように、無効にする
↓
テストケースをXML出力し、Excelへコンバートして納品用テスト仕様書を作る

どうやら、大量のテストケースをストックしたテスト仕様と、実際にテストケースや担当者をアサインして実行するテスト計画を切り替えて運用するやり方みたいだ。
正直まどろっこしい所がある。

でも、アジャイル開発よりもテスト技法の方が古くから研究されているので、上記のフローには何かしらの意味があるのだろうと思う。

【3】テストNGの場合、TestLinkのテスト実行画面からRedmineのバグチケットへ連携する機能がある。更に、テスト結果画面にある「失敗したテストケース」リンクから、失敗したテストケースとバグ登録したBTSリンクの一覧が表示される。
この機能のおかげで、検証作業が非常にやりやすくなった。

また、TestLinkもRedmineと同様に、テスト結果をリアルタイムに出力できる。
失敗(つまりテストNG)が多ければ、バグが多いという事実もすぐに分かるし、ケースの消化率もすぐに分かるので進捗管理になる。

TestLinkのツールとして提供されているExcelマクロへ、毎日のテスト結果のCSVをインポートすると、テスト消化数の簡単なグラフを作ることもできる。
これは、バーンダウンチャートに相当するだろう。

TestLinkReportMacro

ソフトウェア工学が教える所によれば、たくさんのバグが出て修正したシステムは、リリース後もバグが多く出て品質が悪いという。
そんな知識も考慮しながら、TestLinkのテスト結果を眺めれば、プロジェクトのある種の傾向を読み取ることもできる。
いわゆるデータマイニングは非常に面白い。

TestLinkはテストケース管理ツールに過ぎないけれども、Redmineと連携するとテスト工程で大きな威力を発揮する可能性を非常に感じている。

過剰品質

過剰品質について考えたことを書く。

【元ネタ】
ITILのキャパシティ管理

【1】SW開発が製造業と決定的に違う点は、品質はトレードオフにならないことだ。
製造業のプロセス改善で頻出するQCD(品質、コスト、納期)の三角形によるマネジメントは有用でない。
SW開発でも特にXP等のアジャイル開発は、機能、コスト、スケジュールの三角形でマネジメントする。

品質をトレードオフにしない理由は、品質が落ちれば、SW開発プロジェクトの存続そのものが成り立たなくなるからだ。
実際、メンバーの作業の品質が落ち、成果物の品質が落ちる症状が出始める。
最終的には、バグだらけのシステムそのものをリリースできなくなる。

【2】品質を確保するためにSW開発では色んな手段を選ぶ。

ITILのキャパシティ管理では、需要を制限して品質を確保する需要管理という手法がある。
これは、機能やユーザビリティを制限して品質を確保すること。

需要管理でよく出る例は、災害時の電話網だろう。
阪神大震災や新潟の震災のような大規模な災害では、通信インフラの能力が落ちている上に、被災地へ普段の倍以上のアクセスが集中し、すぐに通信インフラが麻痺する。
本当に役立つ救助活動で通信インフラは必要なのだから、電話などのアクセスを大幅に制限して、通信インフラの品質を確保する手段を取る時が多い。

でも、もっとお金をかけて通信インフラを拡張すべきかと言われると、実際はコスト面から現実的でない時が多い。
つまり、需要を制限することで品質を確保する。

ITILが言うITインフラのキャパシティは、技術力でスケーラビリティ、ユーザビリティを拡張しやすい面がある。
実際、IT業界では、ムーアの法則に従って技術革新が行われてきた歴史がある。

しかし、99%から99.9999%へ品質向上するのは非常にコストがかかる上に技術的にも難しい。
このような要件は、金融や工場など、1度のミスも許されないシステムが多いだろう。

そもそも限られたリソース、資本で可能なのか？
この考えでは、品質はコストとトレードオフ。

ITILのキャパシティ管理の発想なら需要制限、アジャイル開発の発想なら機能の制限によって、品質とコストのバランスを取ろうとする。

トレードオフの基準は、そもそものビジネス要求を満たすための条件が「good enough」であるかどうかだ。
XPならスコープ(機能)・コスト・納期の三角形で「good enough」かどうか決める。

【3】ソフトウェアの品質にはマネジメントも含むのだと最近ようやく分かってきた。
ソフトウェアの品質を確保するために、コスト、納期、機能などのバランスを考えながら、顧客や開発者などのステークホルダーと駆け引きする。
その状況では、プロジェクトリーダー、あるいはアーキテクトは調停者の役割を果たす。
色んなステークホルダーの利害関係から、妥協点を探り出し、リリースまで持ち込む。

だから、SW開発はマネジメントがより重要になってくる。
アーキテクチャやプログラミング技術で解決していくのは、IT業界にいるなら当たり前。
むしろ、プロジェクトリーダーの仕事の大半は、機能の優先順位付けだ。

顧客は、機能や納期を決める権限を持つ。
開発者は、その機能の実装コストを決める権限を持つ。
当然、顧客の要求と開発者の工数見積は衝突しやすい。

しかし、スケジュール延期は、昨今のビジネスのスピードからして難しい時が多い。
工数がかかるから大量の人員を投入すれば解決する、という手法は、昔から失敗すると知られている。

その両者の関係のバランスを取るには、機能に重要度と優先度を付けて、機能を削るか、機能を小さく分割して小刻みにバージョンアップする戦略を取るのが一番現実的。

チケット駆動開発では、イテレーション単位でチケットの取捨選択を行う手法が、それに当たる。
これが本来のマネジメントなのだ。

構成管理は誰のためのものなのか？

気になる記事を見つけた。その感想を書く。

【元ネタ】
構成管理は誰のためのもの？

意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？

【1】最近のSW構成管理は、単なるバージョン管理、ビルド管理だけでなく、変更理由を追跡できる変更管理の観点を含む時が多い。
その分、構成管理の難易度が上がっているように思う。
単にSubversionやCVSでソースのみをバージョン管理できているだけでは、構成管理できているとは言えない。

そこで、気の利いたチームは、Rational製品のような重厚なプロセス付きの構成管理を導入する時があるだろう。
管理者は構成管理をしたがる。リリース作業がスムーズになるとか、デグレが減るなどの利点があるからだ。
しかし、逆に生産性が落ちる時が多い。

「意外と知らない構成管理の正体～第1回 ファイルバージョンの管理だけで十分ですか？」のように、構成管理の運用を現場に上手に当てはめないと、インクリメンタルな開発をすればするほど、たくさんのブランチへマージ作業の手間が増える。

だから、普通は、開発者は構成管理を嫌がる時が多い。
自分のタスクが増えるだけで、楽にならないからだ。

【2】Redmineによるチケット駆動開発の利点は、開発者は構成管理を意識しなくてもいいことだ。
チケット駆動開発では、担当チケットが自分のタスク。
ソースをコミットする時、仕様確認するたびにチケットへコメントを追記する時、必ずチケットに作業履歴が残る。
その後、Redmineがバックグラウンドで作業履歴をトレースできる環境を自然に作ってくれる。
実際、3年前のパッチの修正理由は、ソースのリビジョンに紐づいたチケットから追跡できる。
更に、強力なデータマイニング機能で、作業履歴の品質をSWメトリクスで表示すらできる。

【3】Redmineが何故、構成管理を意識しなくても良いインフラを作ってくれるのか？
これは、昨今の業務系Webシステムに特徴的なデータマイニング機能を流用しているからだ。
つまり、チケットに作業履歴を残すだけでバージョン管理、変更管理などに必要なデータを緩やかに関連付けてくれるから。

SNSが流行した理由は、アクセスログからお宝発掘にある。
つまり、アクセスログから緩やかに相関関係を探り出す。
見知らぬ人の足跡から新たな人間関係が発生するという面白さがある。

同様の例は、Amazonのレコメンドエンジンによる関連商品機能や、GoogleのPageRankによる有用度の高いHP検索機能があげられる。
つまり、たまったトランザクションデータからある種の傾向を吸い取り、マーケティングやビジネス上の意思決定の材料に使えるのだ。

最近のSW構成管理の特徴は、単なるバージョン管理だけでなく、強力な変更管理機能だけでなく、データマイニングによるSWメトリクス採取にあると思う。
バグ収束曲線、バーンダウンチャート、SVNリポジトリ統計などに、ソフトウェア工学の知識を流用すれば、プロジェクト運営の意思決定の材料になりうるはずだ。

SW構成管理は、ソフトウェア開発に必須のツールでありプロセスであり、ソフトウェア開発に従事する人たち全員のためにある。
でも、そのインフラは開発者が意識しなくても自然に使えるものであるべきだ。

Tracに有ってRedmineに無い機能

最近、Tracの情報がネットで溢れている。
Tracはプロジェクト管理機能を持つBTSとして一番有名なので、数々のプラグインが作られている。

その中で、Tracにはあるものの、Redmineには無い優れた機能についてメモしておく。
＃誰か実装してくれないかな。

【元ネタ】
trac + TracBurndownプラグインでスクラム開発のすすめ

バグ収束曲線やバーンダウンチャートを描画するQuery Chart マクロ

Tracでコードレビュー

メールをTracに蓄積 - MailArchiveプラグイン

【1】バグ収束曲線、バーンダウンチャート

バグ収束曲線は、累積バグ数と累積バグ解決数を日別にグラフ化したもの。
ソフトウェアメトリックスの中ではおそらく最も有名だろう。
特に、組み込み系の開発チーム、品質保証部の人達がよく使っているだろう。
バグをたくさん出した後にバグが減ると品質の歩溜りにいったと見なすことが多い。

バーンダウンチャートはバグ収束曲線とは逆に、残チケット数を日別にグラフ化したもの。
プロジェクトファシリテーションの実践で、プロジェクトの見える化の例としてよく使われる。
ソフトウェア開発の進捗管理は、残工数で測定する場合が多いから、バーンダウンチャートはまさにぴったりと言える。

プロジェクトリーダーとしては、これらのグラフは、システムの品質や進捗管理にまさに直結する重要な機能。
残念なことに、Redmineには上記機能がデフォルトではない。
でも、サマリ欄にチケットの作業状態の集計が表示されるから、原理的には実装可能のはず。

【2】コードレビュー

Redmineとは別に、下記のコードレビューWebシステムを導入しようとしていたが、未だインストールできてない。
PerlやPythonのライブラリのインストールは、Rubyよりもはるかに難しい。。

Codestriker(Perl製)

ReviewBoard(Python製)

コードレビューは、プログラムの品質チェックだけでなく、コーディングルールや設計思想をメンバー全員で共有することが重要だ。
これによって、メンバーのスキルが底上げされるだけでなく、信頼感も醸成される。

GoogleやMSがコードレビューを真面目にやっている事実からしても、開発プロセスの中でも大事な工程の一つと言える。
しかし、プロジェクトがデスマーチになるほど、コードレビューはおきざりになりがち。
また、コードレビューするために大量に紙で印刷して準備するのも面倒。

だから、Web上でコードレビューのコメントを気軽に書いて、チャットし合うような雰囲気で使いたい。

できれば、レビューコメントもチケットのように、作業状態(修正前・修正済み)や重要度、優先度などの種別があるとなお良い。
そうすれば、レビューで指摘した箇所がクリティカルなのか、指摘された箇所は既に修正されたのか、を追跡できる。

Redmineにもリポジトリ欄があり、ソース差分を表示できるのだから、そこにコメントを付ける機能を実装すればいいだけ。

【3】メールのアーカイブ化

メーリングリストのメールなどをTracへ保管し、Tracで表示・検索できるプラグインがある。
このプラグインの利点は、インシデント管理に使えることだ。

顧客からの要望や障害の指摘などは、必ずメールベースで行うのが普通だろう。
電話対応では、いつ何を話したか、開発者も顧客も膨大な業務で忘れるから、必ずログとして残るメールを使うだろう。

以前は、メールのやり取りが増えると、インシデント管理するために、メールからExcelの管理台帳へコンバートして、要望を一つずつ手作業で追跡していた。
しかし、毎日のメールが20通以上に増えるともはや手作業では、作業漏れなどが発生して、管理できなくなる。

でも、このプラグインをうまく使えば、メールを分別して履歴として残して追跡すれば、インシデントのライフサイクルを管理できるだろう。
このインシデントが、プログラム修正につながる要件へ発展するから、要件管理にもなるかもしれない。
実際は、このインシデントから変更要求が確定すれば、チケットに起票して、その後はチケット駆動開発のワークフローに乗る。

できれば、メールに作業状態(受付・担当・着手中・終了)や重要度、優先度があれば更に管理しやすくなるだろう。

いずれの機能もTracで実装できるのだから、Redmineでも実装可能のはずだろう。
色々試してみたい。

チケット駆動開発の本質はバージョン・ファースト

チケット駆動開発(TiDD)について考えていることを書く。

※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん)

【元ネタ】
チケット駆動開発は、まちゅさんによって提唱されている。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4)

【1】チケット駆動開発のプラクティス

チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。
※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。

【1-1】チケット・ファースト(Ticket First)
　プロジェクト内部の作業は、チケットを受け取ってから始まる。
　つまり、工数が発生する作業は全てチケットに作業内容を書き、その後の作業履歴もコメントで追記していく。
　
　チケット無しの作業は禁止。
　チケット無しのSVNコミットも禁止。
　このルールによって、Redmineのロードマップ、チケット一覧を見れば、今誰がどんな作業をしているか、今どんな作業状態なのか、すぐに判別できる。

　全てはチケットありき。

【1-2】チケットで分割統治(Divide and Conquer by Ticket)

　garyoさんに教えてもらった。
　チケットの工数や規模は、プログラミングの分割統治アルゴリズムのように、制御しやすいサイズまでチケットを分割する。
　チケットは仕様書ではなく、作業指示書であり、タスクカードだ。
　だから、チケットの規模は1週間以内になるように調整している。
　
　実際のチケットは、WBSを細分化したタスクに相当するだろう。

【1-3】小規模リリース(Small Releases)

　Redmineのロードマップ画面で、大まかなイテレーション計画を作る。
　つまり、バージョン毎にチケットをグループ化し、バージョンのリリース日にマイルストーンを設定する。
　
　Redmineを運用して分かったことは、Redmineのロードマップ機能は、XPのイテレーション計画であり、Scrumのスプリントに該当することだ。
　プロジェクトリーダーは、このイテレーション計画に従って、システムの機能を分割し、小規模なサイズで、短いサイクルで小刻みにリリースしていく。
　小刻みなバージョンアップ戦略によって、XPのイテレーション、Scrumのスプリントを実現できる。

【1-4】ふりかえり(Retrospect)

　プロジェクト内部の作業ログを全てチケットに記録すると、自然にRedmineのDBに格納される。
　成果物はSubversionの管理下に置けるから、Redmine＋Subversionで構成管理DB(CMDB)の管理下に置かれている。
　この基盤があるから、信頼度成長曲線、バーンダウンチャート、SVNソース行数、SVNコミットログ回数などのソフトウェア・メトリクスを簡単に集計できる。
　バージョンをリリースするごとに、これらのメトリクスを使って、メンバー全員でKPTを行い、次バージョンへ向けて改善していく。

　これらのプラクティスはXPやアジャイル開発に当然、影響を受けている。
　他にもあると思うので更に考えたい。
　

【2】バージョンの概念をもう一度見直そう

　Redmineを運用して分かったことは、チケット駆動開発はソフトウェア構成管理と密接に関係していることだ。
　実際、Redmine＋Subversionが構成管理DB(CMDB)になり、この基盤があるからこそ、成果物のバージョン管理だけでなく、作業記録や作業理由、ソース変更理由をRedmineで管理できる。

　つまり、Redmine＋Subversionはバージョン管理と変更管理を自然に実現するインフラになっている。
　ここで、バージョンという概念をもう一度見直してみよう。
　バージョンとはそもそも一体何なのか？
　
　僕の考えでは、バージョンは本来の意味でのベースラインである。
　つまり、2種類の意味があると思う。

【2-1】ある時点のシステムをいつでも再現できるポイント(タグ、バージョン)

　構成管理の観点に相当する。
　例えば、導入や変更で失敗した時の切り戻しポイント、あるいは将来の作業のための信頼できる作業ポイント。
　本番リリースしたものの、致命的な障害が発生して前のバージョンに戻さざるを得なかった時に良く使うだろう。
　Rollbackできる切り戻しポイントそのものだ。

　だが、ビルド作業が手作業の現場では、前のバージョンをビルドして再現するのが難しかったりするだろう。
　タグ付けという作業を行わない現場では、前のバージョンの成果物そのものを提示すらできないだろう。

【2-2】ある時点でステークホルダー(顧客、開発者など)が要件や仕様などで合意した状態

　変更管理の観点に相当する。
　変更管理はそもそも、顧客から変更要求(Request for Change)が発生して、元々確定していた要件や仕様が変更されることを管理するためにある。
　そもそもRequest(依頼)なのだから、対応せずに却下する時もありうる。

　だから、変更要求がどんな経緯で発生し、どんな議論が生じて、どの仕様で合意したのか、を記録する必要がある。　
　当然、開発チームは、工数や技術上の難しさなどの観点から、口を挟む権利はある。

　しかし、マネジメントの弱い開発チームは、開発チームの立場の意見を言わずに顧客の言いなりで全てを抱え込んでしまい、合意を取らないまま開発を進めて、リリース間際になって火を噴くことが多いだろう。
　あるいは、顧客と合意した内容や履歴をきちんと記録していないために、無駄に時間を浪費したり、他システムへの影響を把握できずに、リリース後に障害を発生させたりするだろう。

　バージョンという概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいる。

【3】チケット駆動開発の本質はバージョン・ファースト(Version First)

　チケット駆動開発が短期リリース、小規模リリースできる理由は、バージョンという概念をきちんと管理できているからだ。
　チケット駆動開発のライフサイクルについて考えてみよう。
　
　まず、チケット・ファーストのプラクティスで、顧客など利害関係者が合意した仕様をターゲットバージョンとして定め、詳細化した仕様から作業内容を定めて、チケットへアサインして、バージョン単位に振り分ける。
　そして、分割統治のプラクティスで、開発者が作業しやすいスコープや工数までチケットを分割して紐付けて、アサインする。
　更に、短期リリースのプラクティスは、ターゲット・バージョンのチケット全てが終了状態になったら、リリースする。
　最後に、リリース後にバージョン単位のチケット集計結果、SVNリポジトリ統計を材料として、開発メンバー全員でふりかえり、Keep(良かった点は次回に続ける)・Problem(問題点)・Try(次に挑戦する)を洗い出して、次のバージョンに向けて改善すべきものは改善していく。

　このように、チケット駆動開発はチケット・ファーストから始まるが、本質はバージョン・ファースト(Version First)だと思う。
　ウォーターフォール型開発は最後のリリースまでバージョンという概念が無いが、アジャイル開発は小刻みなバージョンアップでシステムを育てていく。
　バージョンという概念こそ、ソフトウェア構成管理の根本概念に当たると思う。

何故、テスト管理ツールが必要なのか？

「きちんと学びたいテストエンジニアのためのTestLink入門：第1回　テスト管理システムとは何か？」が公開されている。
何故、テスト管理ツールが必要なのか？を説明していて、非常に分かりやすい。

Testlinkは、オープンソースのテスト管理Webシステム。
主に、シナリオベースのテストケースの作成と管理、集計表示の機能を持つ。

Testlinkが必要になる状況は、システムテストで大人数の人員を投入して、大量のテストケースをこなす場合だろう。
テストケース数が数千、数万の場合、Excelベースのテスト管理ではもはや管理できなくなる。

Redmineも同様だが、Testlinkを使うもう一つの利点は、テスト手法のベストプラクティスがたくさん詰まっていることだ。
「ビルド」「ブロック」「all pair法」など、テスト技術に関するノウハウが組み込まれている。
世界中の開発者、テスト担当者が触って、自分たちの要望を取り入れているから、ある意味で業界標準のテスト技術とも言える。

Testlinkの運用については後日触れてみたいと思う。