Mercurial以前と以後のチケット駆動開発

Mercurialのような分散バージョン管理を組み合わせたチケット駆動開発とそれ以前の開発スタイルの違いをまとめる。

【元ネタ】
Re:Re:mercurialでチケット駆動開発 - ろじぼ

Mercurialによるチケット駆動開発は強力だ！: プログラマの思索

ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索

Mercurial＋TiDD

View more presentations from akipii .

【Mercruial以前のTiDD】

「Mercurial以前のチケット駆動開発」シートにあるように、trunkと本番ブランチの2本でソース管理している。
基本は、trunkはリファクタリングや機能追加、本番ブランチは障害修正のみ行い、ソース修正の目的をコードライン単位に使い分ける。
理由は、コードラインの品質を維持したいからだ。
リファクタリングや障害修正、機能追加をtrunkの1本のみで行うと、突然の本番障害に対応できなくなるからだ。
そして、リリース予定のバージョンをtrunkからリリースするタイミングで、タグ付けして新しいバージョンの本番ブランチを作成していく。

これがメインラインモデルによる構成管理の原形。
つまり、本番ブランチはtrunkよりも品質が高く、硬いコードラインになる。
「硬い」という意味は、品質が安定しているだけでなく、ソースを触る作業も障害修正の目的以外は許されない意味も含んでいる。

すると、本番ブランチで障害修正を施した場合、trunkへマージする作業が発生する。
Subversion＋Redmineでは、「障害修正」と「マージ作業」のチケットを別々に作り、相互に関連付けていた。
そして、マージ作業のタイミングは、trunkへガンガン機能追加中のチケットの進捗と調整して、優先度を付けていた。
当然、trunkのリリース予定バージョンにマージ作業も機能追加のチケットもアサインされる。

つまり、チケットのリリース順は、ロードマップのバージョン単位に分割するため、バージョンの順番になる。
そして、チケットの開発順は、バージョンの内部でチケットの優先順位を付ければいい。

チケット駆動開発では、チケットの関連やチケットの進捗が見えやすいので、マージ作業をTODO管理のイメージで運用していた。
但し、マージ作業は手作業のままであり、タグ付られたリビジョンを参考にマージ作業を慎重に行う必要はあった。

【Mercurial以前の大規模プロジェクトの構成管理】

大規模プロジェクトでは更にこの状況が複雑になる。
本番ブランチとtrunkの扱いは基本はほぼ同じだが、テスト環境ブランチを別途作る時が多い。

テスト環境ブランチは、サブの開発チーム単位に作られ、バグ修正や機能追加などを行う。
trunkと別ブランチにする理由は、複数のサブチームのソースがtrunkに混じると混乱しやすいからだ。
つまり、trunkを常時リリース可能なラインにするために、テスト環境ブランチをタスクブランチのように扱う。

テスト環境ブランチ上で、開発者は修正し、テスターは検証する。
検証完了になったら、タグ付けし、trunkへマージしてリリースする。

このリリース作業では、普通はライブラリアンがExcelのリリース作業一覧を作っており、このExcelの一覧に従って、タグを見ながら慎重にマージしていく。
理由は、開発順とリリース順が異なる場合は多いからだ。
リリース順序は、複数のサブチームを統括するプロマネがユーザと調整して決まるが、裏では開発を先取りしている時も多い。

だから、Excelのリリース作業一覧が常に最新化されているのが重要になってくる。
結局、複数人が手作業で厳重に管理するプロセスになり、機動性は低くなる。

【Mercruial＋TiDD】

「Mercurialによるチケット駆動開発」は「Mercurial以前のチケット駆動開発や「Mercurial以前の大規模プロジェクトの構成管理」を更に洗練させた構造になる。
つまり、テスト環境ブランチをconfirmブランチとして扱い、Mercurialのpull＆pushでtrunkやconfirmブランチのマージ作業を自動化して、trunkを機能が最新かつ常時リリース可能な品質に保てる。
更にチケット単位にトピックブランチを作り、トピックブランチをタスクブランチのように扱うことで、trunkやconfirmブランチに品質が不十分なソースをコミットする危険性を防いでいる。

このようにブランチをたくさん作っても安心できるのは、分散バージョン管理の優れたマージ機能(pull＆push)があるおかげだ。

またこの開発スタイルは、オープンソースの開発プロセスに似ている。
つまり、トピックブランチがハッカーが作業するパッチ当てのコードラインに対応し、trunkへのリリースは、コミッタのレビューがOKの場合、trunkへパッチが反映される手順に相当するからだ。

分散バージョン管理のおかげで、SW構成管理の作業品質は確実に上がる。
チケット駆動開発と組み合わせれば、複雑なリリース作業を楽にしてくれるはずだ。

メトリクスでソフトウェア品質を見える化する

「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。

【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。
内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。

【本書で解説するEclipseプラグイン】
・Checkstyle → コーディング規約チェック
・FindBugs → バグパターン検出
・JUnit → 単体テストの作成/実行
・TPTP → プロファイリング(非機能テスト)
・djUnit → カバレッジ計測
・StepCounter → ソースコード行数測定

上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか？
僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは知らなかった(^^;)

JUnitを使った単体テストで網羅的なテストを行う為に、境界値分析や同値分析をどのように使うか、静的解析とJUnitの使い分けも、分かりやすく説明されている。

【2】特に「現場で使えるソフトウェアテスト Java編」の第8章「ソフトウェアの品質評価~メトリクスで品質を「見える化」する」の内容がとても素晴らしい。

CHAPTER 08　ソフトウェアの品質評価～メトリクスで品質を「見える化」する
8-1　品質評価の進め方
　　8-1-1　品質評価とは？
　　8-1-2　品質評価の作業手順
8-2　品質評価の技法
　　8-2-1　メトリクスを使った評価（定量評価）
　　8-2-2　時系列データによる品質評価（バグ収束曲線）
　　8-2-3　定性評価
8-3　例題による実習～プロセス/技法の実践方法
　　8-3-1　メトリクスの測り方
　　8-3-2　品質評価

メトリクスを利用した評価方法について詳しく説明されている。

日本の品質管理が生み出した手法「QC7つ道具」のうち「管理図」というものがある。
管理図は、品質の折れ線グラフが上限と下限の間の管理限界線内に含まれていれば、品質OKと評価する為の図。
例えば、メトリクスを管理図に応用して、上限と下限の範囲を品質の許容範囲と見なせばいい。

この時、メトリクスには色んな指標がある。
LOC、サイクロマチック数(複雑度)、凝集度、結合度。
テスト密度、コードカバレッジ、バグ密度、など。
これらの値は、SVNやRedmine、Hudsonにあるから自動集計できるだろう。

僕は、StatSVN・StatCVSをcronで動かし、システムのLOCや開発者のコミット具合をメンバー全員が見れるようにしている。
StatSVNを見ていると、結構気づきが多い。

次は、Sonarを試してみようと思っている。

【3】また、テスト密度とバグ密度、テスト密度とコードカバレッジのマトリクスによる品質評価技法の解説も面白い。
例えば、テスト密度とバグ密度では、下記4ケースが考えられる。

3-1.テストが足りなくてバグが多い場合
→根本的にテスト計画をやり直した方がいい。

3-2.テストが足りないのにバグも少ない場合
→テストをもっと追加実施した方がいい。まだバグが出る可能性があるから。

3-3.テストを実施しすぎたためバグが多い場合
→本当にバグを出し切ったのか確認した方がいい。まだバグが出る可能性があるから。

3-4.テストを実施しすぎたのにバグは少ない場合
→品質に問題がある可能性は少ない。

テスト後に上記のように分析すれば、テストの傾向が見えるはず。
あらかじめテスト計画で上記の分析を考慮すれば、テスト時に意思決定に混乱する事もないはず。

TestLinkCnvMacroを使えば、TestLinkのテスト実績を簡単に集計できるので、代用できるはず。

【4】又、バグ収束曲線の解説も分かりやすい。
バグ収束曲線は、横軸に時間、縦軸に累積のバグ数を取った時系列の折れ線グラフ。
バグ収束曲線は普通、S字カーブでバグが増えるものの、テストが進むにつれてバグが検出されなくなる状態になる。

このバグ収束曲線の品質評価を下記3パターンで説明している。

4-1.バグの目標値に向かって収束している場合
→理想的なパターン。
　但し、バグの増え方の角度によって、品質評価が微妙に異なるので注意。
　「Γ」「S」字ならば品質をコントロールできているが、ギザギザ型ならば、収束するのか注意が必要。

4-2.バグの目標値を超えて増えている場合
→とても危険なパターン。
　バグの目標値を越える時点、あるいはそれ以前に早く異常を検知し、根本原因を分析すべき。
　実際のSW開発では、バグ修正しながら仕様追加にも対応するから、スコープを制御できなければ、このパターンに陥りやすいと思う。

4-3.バグの目標値を超えて高い値で収束している場合
→バグの目標値を超えた時点で品質は悪いけれど、収束に向かっているので、潜在バグは少ないと想定できる。
　実際のSW開発では、当初よりもコストが増えても、このパターンに落ち着く場合が多いように思う。

バグ収束曲線とテストケース消化曲線を重ねたグラフがあれば、テストの生産性や品質の測定が分析しやすくなる。
このグラフ生成も、TiDD上で自動生成できるはず。

【5】バグの傾向分析として、T型マトリクスというマトリクスがある。
T型マトリクスは、縦軸にバグ発見工程、左横軸がバグを作りこんだ行程、右横軸がバグを発見すべき行程で表を作る。

設計・開発における 品質保証・ミス防止活動のあり方

対角線上にあれば問題ないものの、対角線以外で発見されたバグは、潜在バグや同類バグが残っている可能性を示すから、更に分析が必要というもの。

JaSST関西2009のTEF関西コミュニティセッションでも紹介された手法で知っていたが、使いこなしてないので、やってみたいと思う。

品質管理は日本のお家芸とも言える分野。
特に製造業は品質管理が世界一だから、今まで世界を制覇してきた。
しかし、IT産業の品質管理は正直ボロボロと言ってもいいだろう。
ソフトウェアのメトリクスの知識はおそらく、テスターは知っていても、開発者は意識していないのではなかろうか？

この本は入門書としても実践書としても読みやすいので、まずこのやり方を真似ればいいと思う。
そして、できれば、品質評価もTiDD上に載せて、品質評価プロセスを自動化したい。
SVNやRedmine、Hudsonに品質評価で使われる元ネタは存在しているからだ。

TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略

チケット駆動開発にTestLinkを導入してテスト管理してみて、テスト戦略みたいなものをぼんやりと感じた。
以下メモ書き。

【元ネタ】
脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所

テスト手法の概念をTestLinkで説明する: プログラマの思索

TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索

TestLinkを運用して気付いたことpart4～TestLinkの概念を再考: プログラマの思索

TestLinkを運用して気付いたことpart5～TestLinkのテストケースの概念: プログラマの思索

TestLink・BTS・SVN・Hudsonの関連構造: プログラマの思索

【1】Redmineによるチケット駆動開発はとてもアジャイルに開発できるけれど、システムテストや受入テストの進捗管理はやりにくかった。
テスト工程の進捗管理は、テストケースの実施数・成功数・失敗数の予定・実績を比較することにあるけれど、Redmineチケットはテストケースと一致しないからだ。
だから、TestLinkを導入して一番良かったのは、テスト結果集計画面で、リアルタイムにテストの進捗を見れるようになった事であり、それから早期に是正対策を取るのが可能になった。

TestLinkがExcelなどの他のテスト管理ツールよりも良い点の一つは、Redmine・Trac・Mantisなどの既存のBTSと連携する機能がある事だ。
この機能によって、テストケースに失敗した場合、BTSチケットにバグの内容を書き込んで、バグ修正とバグ検証をペアプロのように作業できるようになる。

SW開発で最も難しい局面は、結合テスト(Integration Test)・システムテスト(System Test)・受入テスト(User Acceptance Test)などの各テスト工程で頻発するバグをいかに直していくか、にある。
バグ修正＆検証フローは実はとても複雑なワークフローであるからだ。

脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－4　TestLinkのバグ検証とRedmineのバグ修正の連携フロー 」に書いたように、バグは修正して終わりではなく、バグ修正内容を検証して、更に失敗したテストケースが成功した所までの作業を含む。
そして、この作業は、バグを発見し検証するテスター、バグを修正する開発者、リリース作業を行うライブラリアン、そして全てのプロセスを監視するプロジェクトリーダーの4人が関わるので、そのやり取りだけで忙殺されやすい。

従来は、この作業内容をExcelの障害報告書に記載して、紙ベースで管理し、各担当者が判子欄にサインして承認するというフローをやっていた。
だから、バグが1日10件も出るととても煩雑になり、バグ管理だけでプロジェクトリーダーが忙殺される時も多かった。

TestLink＋Redmineの良い点は、この作業をチケット駆動開発と言うプロセス上で、バグ修正＆検証のワークフローを明示した点にある。
更に、脱Excel！ TestLinkでアジャイルにテストをする 4頁目－ ＠IT自分戦略研究所の「図4－4－5　バグ修正に対するRedmineチケットの状態遷移図 」に書いたように、Redmineのデフォルトのワークフローではバグ検証の作業管理がやりにくいので、更にカスタマイズした。

これが本来のバグ修正なのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた時の一つ。

【2】TestLinkのテストケースのステータスには「成功」「失敗」「未実施」以外に「ブロック」がある。
「ブロック」は事前条件を満足できないためテスト不能な状態を表す。
このブロックを初めて使いこなせて、テストにはバグ検証の限界があるのだと気付いた時が、TestLinkによるテスト戦略を感じた2番目の瞬間。

実際にテストしてみると、1個のテストケースが失敗すると、1個のバグが出て、後続のテストケースは全てブロックになる。
更に、バグに依存する機能のテストケースは、全て「みなしバグ」になり「失敗」になる。
また、バグの原因を追求すると、類似バグが出てくる為、更にバグが増えてくる。

ブロックやみなしバグの発生源は、ブロッキングバグと言われる。
まさに、テストどころか開発そのものをブロックしてしまう危険バグを指す。
テスト工程では、ブロッキングバグをいかに早く的確に潰すか、が鍵を握る。

実際は、1個のテストケースの失敗の影響はとても大きく、最低10個のテストケースが「失敗」又は「ブロック」になる時が多い。
つまり、「みなしバグ」や「ブロック」のテストケースはテストしても無意味なのだ。
以前は、「みなしバグ」や「ブロック」の発想がなく、とにかくテストしまくるものの、バグが出た為に再テストするテストケースが多発して、うまく制御できなかった。
だから、無駄にテスト工数を浪費して、肝心のバグ修正がおろそかになる場合も多かった。

そんな経験を経て、イテレーション単位にTestLinkのテスト計画を実施しながら、常にテストの失敗率に注目するようになった。
理由は、テストケースの失敗率がある上限を超えると、殆どのテストケースがブロック又はみなしバグで失敗の状態になってしまい、もはやテストしても無意味になる状態があるからだ。
僕の経験では、失敗率が10％を超えるともはやテストしても無意味で、ブロッキングバグを修正するよりも、最初から単体テストをやり直す方が早いように感じてしまう。

【3】TestLinkのテスト結果はビルドという概念で管理される。
ビルドはビルド番号を指すと教えてもらった時、ビルドでイテレーションを管理すればいいのだ、と気付いた瞬間が、TestLinkによるテスト戦略を感じた3番目の瞬間。

ビルドの利点は、同じテストケースを回帰テストで管理しやすくなる事。
また、ビルドのテストケースが全て完了したら、ビルド番号を振り直せば、ビルドモジュールの履歴に書かれたチケットNoからバグチケットを探す事ができる。

アジャイル開発にTestLinkを組み込む場合は、TestLinkのテスト計画をイテレーションと見なして、反復型テストを行えばいい。
すると、テストケースを作ってテスト計画を立てた時点で、テスト期間が短すぎたり、テスターや開発者が少なすぎたり、テストケースがそもそも多すぎる場合、実は納期までにテストが終わらない事実が判明する時がある。
原因は、テストと言うスコープを制御できていないのだ。

2～4週間のイテレーションにテスト計画を押し込めるには、2種類の戦略がある。
一つは、イテレーション内で開発とテストの両方を行い、テスト完了後にリリースするインクリメンタル型開発。
もう一つは、開発のイテレーションが完了後、せいぜい数百の単位でテストケースを分割したイテレーションを順次テストしていく反復型テスト。

普通のシステム開発では数千～数万のテストケースに膨れ上がる為、おそらく反復型テストが基本戦略になるだろう。
イテレーションとテスト計画を同一視することで、テストのスコープを制御しやすくしているのだ。

更に、後追いテストや五月雨式テストというテスト戦略も出てくる。
後追いテストは、テスト完了後からリリース直前までに優先度が低いテストケースや未実施のテストケースを後を応用に実施する事。
五月雨式テストは、仕様追加が頻繁な場合、仕様が決まって開発が終了次第、すぐにテストして、五月雨式に開発＆テストしていく事。

後追いテストも五月雨式テストも、十分すぎる品質よりもスケジュールを重視する昨今のビジネスを反映していると言える。
ほどほどの品質をまずは確保した後で、リリースを優先し、品質を作りこむテスト戦略。

プロジェクトリーダーは、インクリメンタル型開発・反復型テスト・後追いテスト・五月雨式テスト等のテスト戦略を意識的に使い分ければ、SW開発で最も難しいテスト工程をコントロールしやすくなるだろう。

TiDDを実践して気付いたことpart3～繰り返し開発の戦略

Redmineでチケット駆動開発を実践して改めて、アジャイル開発は繰り返し開発であると認識した。
Redmine、Trac、Mantisでチケット駆動開発を経験してみて、繰り返し開発の戦略やコツがあるのがぼんやりと分かってきた。
ロジカルに言い尽くせないけれど、以下メモ書き。

【元ネタ】
変更要求に対する選択肢: プログラマの思索

Subversionコードラインのライフサイクル: プログラマの思索

チケット単位に並行開発する事例: プログラマの思索

裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間: プログラマの思索

【1】チケット駆動開発では、タスクを全てチケットに書き起こし、それらチケットをリリース計画に基づいて各バージョンへアサインし、順次リリースしていく。
つまり、XPの小規模リリースとは、2～4週間という短期間でリリースを繰り返す繰り返し開発である。

繰り返し開発(スパイラルモデル)には、インクリメンタル型と反復型の2種類があるのは既に知られている。
インクリメンタル型は、各繰り返し(イテレーション)でどの機能を実現するかを決め、それを１回の繰り返しでリリースする。
反復型は、各繰り返し(イテレーション)でシステム全体の機能を少しずつ作っていき、何度も繰り返して完成させる。

RUPが反復型開発であるのに対し、XPやScrumのようなアジャイル開発は、基本はインクリメンタル型開発だ。
顧客価値を重視する開発スタイルだから、顧客へ早めにリリースすることを優先する。
つまり、XPの小規模リリースとは、小刻みに機能拡張しながらリリースしていくインクリメンタル型開発スタイルを指している。

インクリメンタル型開発の利点は、機能というスコープが小さいのでスコープを制御しやすい点にある。
リリースが最終ゴールだから、スコープが揺れていてはリリースできないからだ。

逆に反復型開発は、スコープを制御しづらい弱点があるように思う。
例えば、工程ごとの繰り返し開発の途中で、度重なる仕様変更を取り込んでしまい、スコープを制御できずに破綻してしまう時は多くないだろうか？

しかし、反復型開発では、システム全体の機能を何度も繰り返しながら作り上げるため、スコープさえ制御できていれば、品質を向上させるために使える。

【2】Redmineでチケット駆動開発を実践すると、自然にインクリメンタル型開発になったけれど、それだけでは品質には不安があった。
だから、TestLinkを導入して、システムテストや受入テストの工程を別のイテレーションで実施し、色んな観点のテストやバグ修正を行って、品質向上を図った。
すると、このイテレーションは、反復型開発に似ているのに気付いた。

つまり、リリースできる品質まで持ってきたが、更なる検証で品質を向上させたい場合、インクリメンタル型開発から反復型開発にチェンジして、複数回のイテレーションでテストを実施する手法だ。
これによって、TestLinkのテスト計画をRedmineのバージョンに見立てて順次テストしていく反復型開発がやりやすくなった。

【3】反復型開発を使う場面は他にもある。
特に、複数のサブチームによる大規模開発、ソフトウェア開発チームとハードウェアチームが連携する組み込み製品開発などが相当するだろう。

例えば、組み込み製品開発では、SWチームは、HWチームから提供されるハードウェアを元に、HWチームの開発サイクルよりも短いイテレーションで順次開発してみる。
理由は、早めにハードウェアとソフトウェアを結合して動作させながら確認したいからだ。

すると、この場合、HWチームの1イテレーションに対し、SWチームは複数のイテレーションをこなしていることになる。
つまり、イテレーションの入れ子構造で反復型開発を行っている。

反復型開発のもう一つの利点は、イテレーションの入れ子構造によって、開発のスケールアップがやりやすい点もあるだろう。

【4】インクリメンタル型開発が難しい理由は、並行開発になってしまう点にあると思う。

例えば、イテレーションで実装した機能をリリースしたら、そのシステムは顧客の前で動き続けるが、裏では開発チームが次のイテレーションの機能を実装し始める。
そして、次のイテレーションの機能をリリースしたら、前のイテレーションのシステムは廃止して、裏で次の次のイテレーションの開発を始める。
つまり、自然に、本番運用と新規開発の2種類のコードラインを常時保守せざるをえないのだ。

但し、並行開発に対する一つの回答は、メインラインモデルという構成管理手法で既に知られている。
つまり、trunkというメインラインからリリースする時は、ブランチを派生させ、常にtrunkが最新の安定した機能となるようにコードラインを保守する手法。

メインラインモデルの手法は、いくつかのバリエーションがある。
おそらく最もよく使われる手法はタスクブランチだ。
例えば、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0である時に、突然の仕様追加に対応しなくてはならなくなった場合、Ver3.1のタスクブランチを定めて、Ver3.0→Ver3.1→Ver4.0の順にリリースしていくという開発スタイル。
このタスクブランチの手法によって、品質を維持しながら、納期とスコープ、工数のバランスを取ることができる。

チケット駆動開発では分散バージョン管理を使って、更にトピックブランチという開発スタイルも選択できる。
つまり、チケットごとにトピックブランチをローカルに作って開発し、最後にtrunkへプッシュする開発スタイル。
これはタスクブランチを各チケットへ更に分化した場合に相当する。
GitやMercurialを使っていれば、おそらくスムーズに運用できるだろう。

チケット駆動開発による小規模リリースは、インクリメンタル型でも反復型でもどちらの繰り返し開発も運用可能だ。
繰り返し開発では、インクリメンタル型と反復型を故意に使い分ける戦略が重要ではないだろうか？
また、アジャイル開発が難しい理由は、インクリメンタル型と反復型を使い分けるノウハウがなかなか見当たらず、実践しにくい点にあるのではないだろうか？

開発に30分、テストに10万年

センセーショナル（？）な記事があったのでメモ。

【元ネタ】
開発するのに30分、テストするのに10万年 － ＠IT MONOist

わずか30分以内に書けるプログラムでも、全パス網羅のテストは単純計算で10万年かかるという。
更に、仕様漏れ、要件漏れを検出しなくてはならないから、テスト工数はもっとかかる。

SW開発が難しい理由の一つは、実装したプログラムの信頼性を保証する工数が天文学的数字のため、不十分な品質と割り切るしかないこともあるのだろう。

チケット駆動開発のアンチパターン

チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。
以下メモ書き。

【元ネタ】
チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

【1】チケットのアンチパターン
【1-1】乱発されたチケット

よくある最悪なパターンは下記2ケースがあるだろう。

設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。
あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。

そのままチケットに登録すると、チケットが乱発される。
そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。

こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。

【1-2】有効期限切れのチケット・放置されたチケット

終了予定日を過ぎて放置されたチケットを指す。
担当者がアサインされていないチケット、担当者も作業を忘れてしまったチケットが相当する。
こういうチケットが増えるたびに、チケットの精度も運用ルールも混乱していく。

対策としては2種類あると思う。
一つは、チケット管理の最終責任者は現場リーダーである事。
現場リーダーは、定期的に必ずチケットが最新の状態であるかチェックし、担当者へ逐一作業確認すべきだ。
担当者がアサインされていないチケット、リリース予定のバージョンがないチケットはすぐに保守すべきだ。
それが現場リーダーの本来の仕事であるからだ。

もう一つは、バックログのような特別なイテレーション、インシデント管理用プロジェクトのような特別なプロジェクトで管理すること。
顧客からの改善要望や問合せは、Scrumのプロダクトバックログのように、バックログのイテレーション又はインシデント管理用のプロジェクトで別管理する。
開発チームは、それらをチケットに登録しておくが、平時の開発作業とは別の作業であると認識し、リリース計画を立てる時に、顧客の要望や問合せを精査して、どのバージョンへリリースするか、取捨選択する。
つまり、XPの計画ゲーム、Scrumの計画プロセスに相当する作業を、バックログやインシデント管理プロジェクトで行う。

あるいは、ソースがコーディングルールに則っていない、とか、リファクタリングすべきだが優先度が低いなどの開発チーム内部の作業は、内部課題の特別のイテレーションで別管理する。
これらもチケットに登録しておくが、平時の開発で関係するチケットにリンクさせておく。
これらのチケットは、リスク管理に相当する。
工数見積もりが実績と大きく異なるのは、リファクタリング工数を見積もっていない場合がとても多いからだ。

【1-3】責任が重すぎるチケット

複雑で大変な作業、複雑な複数の成果物を作る作業を一人の担当者がアサインされた一つのチケットにしてしまう状況。
その担当者のプレッシャーは大きいし、担当者がもし新型インフルエンザにかかったら、誰もカバーできなくなる。

チケットは仕様書ではなく、作業指示書だ。
だからこそ、WBSのように成果物単位に細分化し、更に1個の成果物を一人の担当者が1週間以内に作業するまで細分化すべきだ。
実際の現場に合わせて、チケットの粒度はカスタマイズすればいい。

おそらくリリース後に集計したら、1人日以内のチケットへ細分化されているだろう。

【1-4】停滞したチケット

アサインされた担当者のチケットの進捗が進まない状況。
よくある状況は、進捗が90％のまま1週間経ってしまうこと。

対処としては2つある。
一つは、実績の進捗率は、0％・50％・100％の3種類と固定する方法のように、ルール化する。
つまり、チケットのステータスと進捗率を対応付けする。

もう一つは、チケットの中身を精査して、別作業を別チケットへ細分化すること。
チケットの進捗が悪い原因は、WBSの洗い出しが不十分だった時が多い。

例えば、1個の画面を実装するのに、実は複数の共通ライブラリ、モジュール、共通画面を作るために工数がかかっている、とか、新規の機能追加のはずなのに実はリファクタリングしていた、など、作業の予定と実績が大きく狂っている時が多い。
つまり、現場リーダーの作業割り振りが間違っているのが原因の大半だ。

【1-5】タスクがチケットに書かれない

開発チームでやるべき作業をチケットに登録していない状況。
例えば、ビルド作業、テストデータ作成作業、開発環境の構築作業などのように、顧客に無関係で開発チーム内部でやるべき作業を登録せずに、あうんの呼吸でやっている場合が多いだろう。

すると、やるべきタイミングで作業を忘れて、進捗が遅れたり、作業の品質そのものが落ちる。

この状況の根本原因は、WBSの洗い出しが不完全か、せっかく洗い出したWBSをチケットにすべて登録していないか、のどちらかだ。
つまり、現場リーダーがチケット駆動開発の運用ルールを徹底できていないのが根本原因だ。

【1-6】SCMと連携されてないチケット

SVNコミットする時に、チケットNoを書き込まず、チケットとSVNリビジョンが紐づかない状況。
まちゅさんは「No Ticket, No Commit!」と呼んで重視している運用ルール。
この状況では、せっかくのチケットが単なる作業履歴に過ぎない。

チケットとSCMが連携することによって、要件からソース、ビルドモジュールまでチケット経由で相互に追跡可能になる利点がある。
特に要件管理を実現したい場合に、とても強力な運用ルールだ。

【2】バージョンのアンチパターン
【2-1】ゴールの見えないバージョン

いつまで経ってもリリースできないバージョン。
よくある例は、顧客の改善要望の言いなりになって、バージョンへどんどんチケットを追加していくこと。
すると、いつまで経ってもリリースできないどころか、システムの品質がどんどん劣化していく。
機能追加すれば、必ずバグが紛れ込んでしまうからだ。

ScrumでもXPでも、スコープをあらかじめ制御しておくことを重視する。
イテレーション実施中に突然の仕様変更の要求が来たとしても、基本は次イテレーションに回して、すぐに対応しない方がいい。
機能追加よりも品質を重視する方が、手戻り作業が少なくなるからだ。

【2-2】優先度がごちゃ混ぜのバージョン

リリース計画、イテレーション計画がきちんと行われず、一つのバージョンに全てのチケットが放り込まれた状況。
例えば、顧客の問い合わせ・改善要望・障害報告、リファクタリングなどの作業が混じっていて、メンバーは、何から手をつければよいか、分からなくなっているだろう。

XPの計画ゲームでも、Scrumの計画プロセスでも、リリース計画をきちんと作る。
複数のバージョンを立てて、定期的に小刻みにリリースしていくという開発スタイルを取れば、チケットの優先度は自然に定まる。
顧客の要件の重要度と開発工数のバランスから、リリース計画が作られて、そのバージョンにチケットをアサインしていく。
上記の状況に陥った原因は、現場リーダーがプロジェクトのスコープをきちんと管理できていなかったことにあるだろう。

また、開発サイクルが異なるチケットは別管理にした方がいい。
例えば、顧客からの単なる質問やリファクタリングなどは、別のバージョンやプロジェクトで管理した方がいい。
本番運用のソースと新規開発中のソースをブランチで別管理するように、プロジェクトもブランチ単位で分けた方がいい。

【3】プロジェクトのアンチパターン
【3-1】大規模プロジェクトでごちゃ混ぜのプロジェクト

大規模プロジェクトでは、複数のサブチームのタスク管理が必要になるが、一つのプロジェクトに全てのサブチームのタスクが混在している状況。
TiDDを実践すると、経験的に5人以上のチームのタスク管理は非常に煩雑になる。
理由は、TiDDにおけるチケットの粒度は開発者視点なので、とても細かいからだ。

だから、複数プロジェクト機能を使って、サブチーム単位や工程単位などで分けた方が管理しやすいと思う。

また、チケット管理の専門担当者を配置し、随時チケットを保守させる。
更に、定期的に課題管理会議を開いて、チケットの棚卸を行った方が良い。
チケットに上がった問題が複数のサブチームが連携しなければ解決しない場合もあるので、調整作業が必要だからだ。
あるいは、どのチケットから手を付けた方が良いか、サブチームのリーダーの観点ではなく、もっと上層部のマネージャの観点で優先度を決めた方が良い場合も多々あるだろう。

他にも気付いたアンチパターンがあれば、随時追加していきたい。

TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間

TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。
＃下記はロジカルでないので注意。

【元ネタ】
裏プロセスは並行プロセス: プログラマの思索

チケット駆動開発のモチーフ: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【再考】TiDDのプラクティス集: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。
Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。
すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。

そして、リリース後にKPTによるふりかえりMTを開いて、リリースしたバージョンについて、KPTの観点でヒアリングして議論したら、自然にプロセス改善になっていた。
僕は、チケットの運用ルール改善や作業の品質改善を狙っていたのだが、メンバーからは、設計書のこういう部分が分かりにくいからバグが出た、このワークフローはやりにくい、チケットでタスクの見通しがよくなった、など、色んな意見が出て、紛糾した。
そして、次のバージョンへの対策も決まり、ちょっとずつ、開発チームの作業効率も上がった。

SW開発で最も嫌なのは、ゴールが見えず、残業や休日出勤が延々と続く状況。
いわゆるデスマーチ。
リリース前のシステムテスト、リリース直後の膨大な問合せや障害報告で起きる。
特に、ウォーターフォール開発で、ドカンと一発リリースした直後が大変。
ウォーターフォール開発では、イテレーションと言うリズムが無いのが一番嫌だ。

【2】アジャイル開発では、スコープをコントロールしながら、小刻みに機能拡張しながらリリースしていく。
だから、リリース後の障害報告や問合せもそれほど多くないし、開発チームがコントロールできる範囲内に抑えられる。
何よりも、スコープをイテレーションに閉じ込めて、イテレーションというリズムが生まれるのが気持ちいい。
XPやScrumならば、必ず２～４週間後にリリースというゴールがあるので、作業が見えやすい。

チケット駆動開発では、ロードマップ画面でリリース計画やチケットの取捨選択を行う。
つまり、ロードマップ画面で、スコープを制御しながら計画ゲームを行っている感覚だ。

イテレーションは通常２～４週間という小さいタイムボックスのため、納期やコストが固定だから機能というスコープで調整するしかない。
つまり、リリース計画を立てて、複数のバージョンを随時リリースしながら機能拡張するという小規模リリースを自然に行っていた。

小規模リリースという繰り返し型開発に気付いた瞬間が、これがアジャイルだ！と思った2番目の瞬間。

このロードマップは、チケット駆動開発で最も重要な機能だと思う。
ロードマップは、平鍋さんが提唱するプロジェクトファシリテーションの「見える化」の例で出てくる野球のスコアボードと同じだ。
ロードマップには、「最新の正しい情報」がバージョンの進捗率とチケット一覧が表示されていいる。
Webなので、「メンバーも現場リーダーも(できれば顧客も)」ロードマップを見れる環境にある。
そして、ロードマップにあるバージョンの予定や進捗から、直近のゴールはこれだ、と「次の行動」が誘発される。

チケット駆動開発はプロジェクトファシリテーションともすごく相性がいいと思う。

【3】Redmineは1プロジェクト＝1リポジトリという設計思想で、Subversionと連携できる。
更に、Redmineには複数プロジェクト機能がある。
だから、ブランチを別プロジェクトで管理してみたら、自然に並行開発になっているのに気付いた瞬間が、これがアジャイルだ！と思った3番目の瞬間。

Subversionをまともに使いこなすまで、ずっとtrunk1本だけのコードラインだったから、並行開発を意識する事はなかった。
しかし、小規模リリースしていくと、本番環境のソースはブランチ、裏で機能拡張中のソースはtrunkというソース管理に自然になる。
すると、マージ作業という面倒な作業が発生するので、Redmine導入前はSVNのタグを乱発してコントロールしにくかった。

Redmineでは、本番運用と開発中のチケットは別々に作り、マージ作業のチケットは発生源の障害修正のチケットとリンクすることで、開発者はすごく作業しやすくなったみたい。
管理者としても、マージ作業のタイミングを忘れる事がなくなったので、ありがたい。

上記の経験を通じて、繰り返し開発が難しい理由は並行開発という開発プロセスが隠れているからだ、と思うようになった。
一度リリースしたソースはそれで終わりではなく、ブランチとして次のリリースまで生き続ける。
開発チームは、次の開発をやりながら、本番運用のソースも保守しなくてはならない。
そして、裏で開発中のソースをリリースしたら、本番運用のブランチを新たに作り、以前のブランチを廃止するという運用サイクルが生まれる。

つまり、小規模リリースというプラクティスは、単なる小刻みな機能拡張による繰り返し開発だけでなく、複数のコードラインを常時保守する並行開発という開発プロセスが本質なのだ。

アジャイル開発が難しい理由は、この並行開発を制御できない点にあると思う。
ウォーターフォール開発であろうとも、組込み製品やパッケージ製品の開発では、複数の製品ラインを保守しながら本番運用と開発中の2系統のソース管理をしているのだから、もっと大変なはずだ。

逆に言うと、並行開発を意識している開発プロセス、開発チームは、自然にアジャイルな開発を行っているだろうと推測している。

Redmineの集計プラグイン、statSVN諸々

Redmineの集計プラグイン、statSVNの機能についてメモ。

【元ネタ】
redmine_chartsプラグインでバーンダウンチャートは表示可能: プログラマの思索

Redmine - PluginCharts - Redmine

Redmineのプラグイン (3) ゴンペルたん: これ本番ですか？

redmine_chartsプラグインもゴンペルたんも、migrationが必要なく解凍して配置するだけ。
redmine_chartsプラグインは、予定・実績工数の右肩上がりのグラフを表示する。
つまりバーンダウンチャートの反対のグラフ。

このグラフが良い点は、PMBOKの言うSV(スケジュール差異)を目の前で表示してくれること。
これによって、コストさえ決まれば、PMBOKの言うEVMが可能になる。

また、ゴンペルたんはチケット集計の推移グラフ。
期間中のチケットの登録数・解決数などを表示してくれるので、Redmineの活動ログと合わせて見れば、開発チームの活発具合を見ることができる。

【statSVN】
StatSVN - jUCMNav Cloud Commit

statSVNにはcloud commitという機能があり、この機能は、SVNコミットログにある単語の出現頻度を出力する。
これは、SWリポジトリマイニングと同様の機能だ。
即ち、コミットログから、ソース修正の解決具合や関連情報を解析して、ナレッジを導き出す。

具体例を見ると、当然「refs」「fixes」が多いが、「fixes」が本当に解決されているのか、を調べることもできるだろう。

BTSやSCMは、SW工学の宝庫なのだ。

要件管理が必要な理由

要件管理が必要な理由についてメモ書き。
＃後でまとめる。

要件管理の機能で最も重要と思われる成果物は、要件と機能のトレーサビリティマトリクス(TM)だ。
イメージは、下記の記事の図3 トレーサビリティマトリクス（追跡可能性マトリクス）に相当する。

＠IT：みんなが悩む要求管理（8）要求管理ツールの賢い使い方

イメージとしては、上位要件を行、下位要件を列にしたマトリクスを作り、上位要件に紐づく下位要件がある場合、そのセルに印を付ける。
このマトリクスがトレーサビリティマトリクス(TM：追跡可能マトリクス)であり、このTMがあれば、要件に変更が生じた場合、下位要件、更にはそれに紐づくテストケースの影響範囲が一目瞭然になる。
上記の図にある「サスペクトリンク」は、そういう機能だ。

実際の開発では、要求仕様と基本仕様、基本仕様と機能仕様のように、隣り合う要件ドキュメント(フェースタイプテーブTblのフェーズ)でトレーサビリティマトリクスを作ればいいだろう。

清水吉男さんが提唱する派生開発プロセスXDDPでは、トレーサビリティマトリクス(TM)が成果物の一つであり、TMで変更要求と機能が交差した箇所で修正が必要な場合、変更設計書が作られる。
ここで、変更設計書は、実際のソースの修正手順まで含んだドキュメント。

XDDPでは、TMによって変更箇所を洗い出し、更に変更手順まで設計プロセスで作成するというプロセスを含んでいるのが秀逸。
つまり、派生開発という仕様変更を要件から開発・テストまできちんと追跡するプロセスがあるのだ。

要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。

つまり、両方向のトレーサビリティツリー機能によって、ブロッキングバグに影響する要件、更にはそれに紐づくテストケースや機能が分かり、最終的には、ブロッキングバグの修正・検証工数も計算でるはず。
この手法はブロッキングバグの影響調査だけでなく、仕様変更による影響調査にも使えるので、精度の高い変更管理が可能になる。

即ち、要件管理を仕様変更に伴う影響調査として使い、設計工程の品質Upやリスク管理に応用したいのだ。

そして、その機能は、手作業ではなく、ツールでサポートすべきであると思う。
何故なら、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないからだ。
これが、TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。

ソフトウェア開発チームはオーケストラに似ている

ソフトウェア開発の特徴で良い記事があったのでメモ。

【元ネタ1】
ソフトウェア開発組織はオーケストラ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェア開発で伸びる人，伸びない人【第二版】：柴田 芳樹 (Yoshiki Shibata)：So-net blog

荒井さんの本「ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)」が紹介されていたので立ち読みしてみた。
「特別付録　音楽とソフトウェア開発」という章が面白かった。

ソフトウェア開発組織はスポーツではなくオーケストラ。
個人のスキルは前提条件であり、協調するのが大事。
一人のスキルが低いと、演奏する音楽全体の品質が落ちる。

オーケストラでは、指揮者(プロジェクトマネージャ)以外に、副指揮者(プロジェクトリーダー)、コンサートマスター(アーキテクト)の役割が必須。
管理者の仕事が3人に分かれているのに注意。
SW開発の大規模プロジェクト(数十人以上)も同様に、管理者の役割が分化されるはず。
アジャイル開発のような小規模チームでは、管理者が役割を兼務する時が多い。

バッハやモーツァルトもその時代の音楽楽器の技術をフルに使うことで、優れた楽曲を残した。
IT技術も、その時代に合った技術をフルに使えば、ベターなシステムが作れるはず。
しかし、IT技術は陳腐化が激しいので、システムの寿命も本来は短いのかもしれない。

【元ネタ2】
「ソフトウェアは工業製品ではない」　まつもとゆきひろ氏：柴田 芳樹 (Yoshiki Shibata)：So-net blog
ソフトウェアエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-net blog

日本のITベンダーのプロセス改善に何故、違和感を感じるのか？
彼らのプロセス改善の根底には、アートを作るのではなく、工業製品を作っているイメージがある。
ソフトウェア開発のプロセスが細分化されて、プログラミングではなくコーダになっている。

【元ネタ3】
ソフトウェアエンジニアの成長カーブ：柴田 芳樹 (Yoshiki Shibata)：So-net blog
開発チーム（組織）の成長：柴田 芳樹 (Yoshiki Shibata)：So-net blog

ソフトウェア開発において、成長できない組織や個人は、プロセス改善できない。
ソフトウェア開発においてプロセス改善するには、プログラミング技術が時代に乗り遅れないように、常に磨かなくてはいけない。