仮説検証スタイルとアジャイル開発の関連性

勝間和代の本を読みながら、アジャイル開発との関連性についてメモ。
＃ラフなメモ書き。

【元ネタの本】

昨今、外資系コンサルタントやMBAホルダーの思考スタイルであるフレームワーク思考、仮説検証スタイル、ロジカルシンキングなどが流行している。
それらの本を読んでみると、確かに実際の仕事で役立つ。

これらの本で興味深いと思ったのは、限られた情報の中で、精度の高い意思決定をする技術の重要性だ。
つまり、鮮度はいいけれど正確さが多少悪い判断の方が、遅くて正確な判断よりも重要である、と。

この意思決定のスキルは、中間管理職よりも経営者のように上級マネジメント職での基本技術のように思える。
実際、経営者は、動きの激しいマーケットの中で、素早く正しい舵取りを要求されている。

この意思決定の構造は何か？
それが仮説検証スタイルなのだろう。

つまり、限られた情報から、論理的に整合性が取れている仮説を一旦作り、それから行動すべき対策を導き出すことだ。
勝間和代の本では、この構造を「空-雨-傘」フレームワークと呼んでいる。

空は客観的な事実。
雨は人の解釈、主観。
傘は解釈に対する行動、対策。

「空-雨-傘」やロジックツリーなどのフレームワーク思考で、限られた情報から推論して一つの仮説を作る。
仮説があるからこそ自信を持って実行できる。

実行した結果を仮説から導き出される結果と比較して評価する。
それが検証プロセスになる。
その評価によって、仮説を更に修正して強化していく。

いわゆるPDCAサイクルにおけるCheckとAction。

この手法はアジャイル開発に似ている気がする。
アジャイル開発では、イテレーション又はスプリントと言う定期的な期間の中で、実現すべき要件をシステム化していく。

要件であるストーリーは、システムの観点から眺めれば曖昧であり、実装前にいくらきちんと設計しても、システムとして動作しなければ分からない所もある。
また、ストーリー通りに作ったとしても、顧客が受入テストで動かしてみたら、障害があるだけでなく、些細な機能を変更したい、などの改善要望も出てくるだろう。

開発者の戦略としては、与えられた要件から論理的整合性に矛盾なく動作するシステムをまずは作り、早くリリースしていく。
そして、顧客のフィードバックを受けて、仕様変更を受け入れる余力を保持できるように、設計も実装も開発チームの体制もあらかじめ作っておく。

与えられた要件のうち、一部は間違っていたり、あるいは、開発者が要件をきちんと認識できていなかった部分もあるかもしれない。
でも、間違った認識に基づいたとしても、ロジカルに設計して実装できたならば、後から修復は可能だと思う。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」でも、下記の一節がある。

意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても、変わらずしっかりしているはずです。

つまり、意思決定のプロセスが正しく進んでいるならば、限られた情報で誤った方向に進んだとしても、検証プロセスを速める事によって、正しい方向へ軌道修正できる能力がある。

アジャイル開発へ仮説検証プロセスを意識的に取り入れたならば、現場リーダーは自信を持って意思決定できるのではないだろうか？

TortoiseHgの日本語化メモ

TortoiseHgでVer0.8がリリースされたので、さっそくインストールしてみた。
しかし、パス名やファイル名に日本語があるとコミットすらできない。

下記で色々調べてみた。

【元ネタ】
2009-06-27 - 負けないように頑張る日記
2009-06-15 - 負けないように頑張る日記
2009-07-02 - 負けないように頑張る日記

kuy / thg-ja / wiki / Japanese ― bitbucket.org

物置にあるノート: fixutf8を使うために設定しないといけないこと

TortoiseHg で日本語ファイル名 - あすかぜ・ねっと

methane / hg-fixutf8-jp / overview ― bitbucket.org

hg-fixutf8 更新 - methaneの日記

結論は、TortoiseHg で日本語ファイル名 - あすかぜ・ねっとによると下記の通り。

2009/07/05 現在、TortoiseHg 0.8 ではダメ文字を含む日本語ファイル名はコミットできないようです。
どうしても日本語ファイルを使いたい場合は、 TortoiseHg 0.7 + hg-fixutf8 の組み合わせか、 TortoiseHg 0.6 + win32mbcs の組み合わせを使いましょう。
CUI では、Mercurial 1.3 + hg-fixutf8 の組み合わせで動作するようです。

TortoiseHg 0.8でメニューも日本語化されるが、日本語を含むパスやファイルはコミットすらできない。
残念で仕方ない。

分散バージョン管理はGitやBazaarなど色々あるが、MercurialはSubversionやCVSに似ていて使いやすいように思う。
MercurialのWindowsクライアントTortoiseHgはまだ実用に耐えないが、じきに普及してくるはずだ。

Subversionがバージョン管理のデファクトスタンダードになった理由は、WindowsクライアントであるTortoiseSVNが使いやすいからだ。
ExcelやWordの差分機能、BTSチケットと連携のように、昨今のアジャイル開発のトレンドをうまく取り込んでいるように思う。

同様に、CVSのWindowsクライアントTortoiseCVSもある。
Eclipseのような重厚なツールは必要ない。

昨今のソフトウェア開発では、メインラインモデルのように複数のコードラインによる並行開発が一般的になった現状がある。
分散バージョン管理は、そのWindowsクライアントがキラーアプリになるだろう。

TortoiseHgのバージョンアップを切に望む。

バグはマインスイーパーみたいだ

「品質がスケジュールよりも優先される理由: プログラマの思索」を書いた後に思ったこと。
バグはマインスイーパーみたいだ。

1個のバグが出るたびに、周辺の機能は正常動作が確認できなくなる。
わずか10％のバグが出たとしても、殆ど全ての機能がみなしバグになってしまい、テストしても無意味になる。

ほんのちょっとの地雷があるだけで、その周辺の広範囲は地雷原になってしまう。

ハードウェアでは、ある程度の不良品を出さなければ、逆にきちんとテストできているのか、不審がる。
信頼度成長曲線のような品質保証のモデルが既に理論的に作られている。

でもソフトウェアでは、バグはなるべく出さない方がいい。
バグが少ないほど、品質は安定し、スケジュールも短縮化し、工数も少なくなる。

品質はスケジュールよりも優先する。

品質がスケジュールよりも優先される理由

CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。
mgさんのコメントを書きながら、考えたことをメモ。

【元ネタ】
アジャイル開発は受託開発の方が向いている: プログラマの思索

「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。
第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。

SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。
設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。

仕様変更が来たけれど、バグ修正を優先すべきか？
バグ修正よりも、目先のタスクをこなすべきか？
全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？

今、僕はTestLinkで結合～受入テストを管理していて、「品質がスケジュールよりも優先する」の原則の重要性を改めて感じている。

TestLinkでは、テスト実施結果をリアルタイムに表示できるので、テスト実施数だけでなく、成功ケース数、失敗ケース数、ブロック数を毎日集計できる。

仮に、テスト中のテスト計画にあるテストケース数が500ケースあったと仮定しよう。
開発チームあるいはテストチームは、500個のケースをこなしていくと、必ず失敗するケースが発生して、バグが出てくる。

この時に、テストケース同士で依存するケース数が平均10個だと仮定しよう。
例えば、Amazonのような小売系Webシステムならば、カート画面のテストの次に注文画面のテストケースがあるから、カート画面と注文画面のテストケースは依存していることになる。

すると、テストケースが1個失敗するたびに、バグが1個増えて、依存するテストケース10個が「ブロック」になる。
理由は、依存するテストケースは、テストしたとしても必ずバグが出る「みなしバグ」だからだ。
つまり、ブロックしたテストケースは、一生懸命にテストしたとしても工数の無駄だ。
バグが修正されなければ、テストしても無意味なのだ。

今、仮に、テスト計画の全テストケースを実施して、失敗率が5％だったと仮定しよう。
すると、失敗ケース数やバグ数は25件あり、依存するテストケースは250件だから、ブロックするテストケース数は250件になる。
つまり、500件のテストケースのうち45％しかテストで「成功」、つまり、品質が確保されたに過ぎず、残りの55％はテストで確認すらされていない状況になる。

更に、失敗率が10％だったと仮定しよう。
すると、失敗ケース数やバグ数は50件になり、ブロックするテストケースは単純に数えると500件になる。
つまり、10％以上失敗したら、殆ど全てのテストケースが「みなしバグ」の状態なわけで、もはやテストしても工数の無駄。

結局、テストよりもバグ修正を優先しなければ、テストすら終わらない。
バグ修正よりも仕様変更を優先したとしても、みなしバグが多発した状態で機能追加したとしても、状況は一段と悪化するだけだ。

「ソフトウェアでビジネスに勝つ」本では、品質が良ければテスト工程が短縮されてスケジュールは前倒しになる、と書かれているが、おそらく上記のような事実を指しているのだと思う。

TestLinkの良い所は、上記のような事実を過去のテスト実績から集計して分析できることだ。
過去のテストから、バグが頻発した要件は注意したり、あるいは、過去の開発でバグが多発した要件のテストケースを再利用して、念入りにテストするといった戦略を取る事もできる。

アジャイル開発というよりもソフトウェア開発のプロジェクト管理が、品質・コスト・納期の三角形ではなく、スコープ・コスト・納期の三角形でマネジメントする理由も同じだ。

ソフトウェアの品質を優先すれば、自然にコストは下がり、スケジュールも短縮できる。
「品質がスケジュールよりも優先する」原則をIT技術者は再考すべきではないか？

Redmine -もっと手軽にプロジェクト管理!

下記の本が7月末に発売されるらしい。

著者の一人である倉貫さんはXPJUG代表であり、Rails製SNSであるSKIPの開発者でもある。
実際、SKIPのタスク管理が行われているRedmineは公開されている。
SKIPと絡めた運用プロセスが解説されるのだろう。

SKIP - 概要 - SKIP - Redmine

目次を読んでいたら、さっそく読んでみたくなってきた。。

クラウド時代のビジネスモデル

クラウド時代のビジネスモデルについてメモ書き。
＃きちんと理解できてないので後でまとめる。

【元ネタ】
クラウドコンピューティング - Wikipedia

知られざる先進業界「地銀」に見るシステム共同化の真実 - ITPro

【1】クラウドコンピューティングには下記3種類がある。
1-1.SaaS(Software as a Service)
インターネット経由のソフトウェアパッケージの提供。
例えば、Salesforce CRM。

1-2.PaaS(Platform as a Service)
インターネット経由のアプリケーション実行用のプラットフォームの提供。
例えば、GoogleAppEngine。

1-3.IaaS(Infrastructure as a Service)
インターネット経由のハードウェアやインフラの提供。
例えば、AmazonEC2.

これらの特徴は、ハード不要、サーバー不要であること。
ユーザにとって、ITは利用するものである。
ITシステムはユーザ企業にとって資産ではない。
データセンターを維持する運用コストは馬鹿にならない。

技術の特徴は、ハードの仮想化だ。
特にGoogleAppEngineは、ユーザから見れば、アプリケーションをデプロイすればすぐに起動できる。
VMWareも同様の技術の流れ。
本番環境もアプリケーション実行環境も全て仮想化してしまった方が、後で安くつく。

【2】クラウド化が進むとビジネスそのもの大きく変化する。
ITはサービスであり、利用料さえ払えば誰でも使える。
ハードもソフトもシステムも自前で保有する必要はない。

そもそも受託開発は必要ないのでは？
SaaSを利用して、ERPやSNSを社内に展開すればいい。
膨大な運用コストはユーザ企業は必要ない。
この場合、ソフトウェアをクラウド上で利用する。

あるいは、ユーザ企業にSW開発の能力があるならば、ユーザ企業自身が自社開発すればいい。
自分たちが業務や問題点を一番よく分かっているのだから、自分たちの業務改善のために自社システムを作ればいい。
その場合、インフラやプラットフォームとしてクラウドを利用すればいい。

すると、ソフトウェアシステムこそが、ユーザ企業のビジネス上の競争優位の源泉という発想になるはず。

【3】IT化よりもクラウド化が最も進んだ業界がある。
それは銀行。
知られざる先進業界「地銀」に見るシステム共同化の真実 - ITProによれば、特に地方銀行がそうだ。

地方銀行の事務を支えるシステムは、複数の銀行による共同利用になっている。
システムは共通だから、銀行の独自性は、使うパラメータが微妙に違ったり、帳票出力する項目が微妙に違ったりするだけ。
地方銀行の事務はどこも殆ど共通なのだ。
つまり、銀行の看板が違うだけで、銀行の業務は全く同じ。

だから昨今、銀行の統合再編がやりやすいのだろうと思う。
米英が最近まで、金融とITで産業再生して高成長した理由は、上記にあるのかもしれない。

ところで、銀行に勤めている人に聞くと、昔と比べて仕事が面白くないと言う。
昔は、銀行独自の仕組みやシステムがあったので、この帳票のこの項目は、こういう業務から発生してきたんだな、と言うのが、経験するにつれて分かってきたけれど、今はシステムがブラックボックスのために全く分からない。
しかも、昔は預金や融資が主な業務だったのに、今は投資信託などのように高度な専門知識が要求されるため、昔のスキルが全く通用しない、と。

システム化、クラウド化が進むにつれて、ホワイトカラー、特に事務員の仕事は単純労働に近くなっている。
SEもIT土方と言われているし。

おそらく、今後、工場のようなハードに依存しないサービスを中心とした業界は、上記のようなクラウド化が進んでいくのではないか？
すると会社の看板が違うだけで、中身はどこも同じではないか。

そして、クラウド化が進むにつれて、IT業界も半導体業界のように、大量の投資資金を持つ会社しか生き残れなくなるだろう。
大規模なデータセンターを運用できる資金力と、常時稼動し続ける耐障害性や膨大のトランザクションをさばききる技術力がなければ、もはや生き残れないのでは？

今はIT業界は、技術革新が盛んで、個人でもプログラミングスキルに秀でていれば、世界を変えることもできる。
でも、じきに半導体業界のように、膨大な投資を延々と続けることができなければ、じきに淘汰されるのでは？

チケット駆動開発はツールによる改善か、プロセスによる改善なのか

チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。
「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？　それともプロセスで改善したのですか？」

質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。
そのプロセス改善はツールに依存しすぎではないか？
ツール無しの開発プロセスにできるのか？
チケット駆動開発は、BTSがなければ運用できないのか？
と。

この質問は今の僕が抱える問題点の一つを持っている。
それについては後でまとめる。

【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。
すなわち、障害だけでなく要望なども取り扱う。

この方法は、Issue Trackingとも呼ばれている。
つまり、障害修正のワークフローをSW開発における全ての作業の管理に拡張しようとすることだ。

SW開発の作業は、バグ修正というプログラミングだけではない。
ビルド環境を作ったり、リリース作業、テストデータの流し込みもある。
仕様変更によって設計書を直し、ソース修正もする。
お客から電話やメールで依頼される調査もある。
現場リーダーならば、スケジュールを作ったり、上司や顧客へ報告書を作ることもある。

それら全ての作業をチケットに登録して、進捗や作業状態をチケットで追跡していく。

すると、このようなプロジェクト管理は、BTS無しでも、PostItのようなカードでも運用可能だろうと推測できる。
実際、XPの計画ゲームを第三者が見ると、チケット駆動開発と何ら変わることはない。

でも、さかばさんによると、チケット駆動開発をアナログでやりたければ、PostItに判子の欄やチェック欄を追加すればいいでしょ、と。

例えば、チェック欄は、その作業のワークフローにおけるステータスが完了したかどうかに使う。
判子の欄は、その作業のステータスが完了した場合、現場リーダーやテスト担当者がレビューしたり検証して、承認したら判子を押す。

つまり、PostItにワークフロー管理機能を追加した点がチケット駆動開発が強調した点の一つ。
しかし、アナログのPostItは管理が面倒だ。
ホワイトボードや模造紙で、かんばんの上にPostItを貼り付けるのがPFのプラクティスの一つでもあるが、PostItは紛失しやすい。
また、集計しにくい。

マネジメントという作業の基本スキルは、予定と実績の比較にある。
PostItによるアジャイルな運用は、実績管理しかできない。
この点がBTSを使う利点の一つ。

現場で開発者の感想を聞くと、チケット駆動開発を自分のToDo管理に使っているようだ。
例えば、日々のタスク管理をCheckPadやRememberTheMilkのようにWeb上で行う感覚。

このやり方を推し進めると、チケットでリスク管理や課題管理も自然に行うようになる。

例えば、開発者がリファクタリングすべき作業ではないか、と気になった箇所は、優先順位の低いチケットとして登録しておく。
このチケットはすぐに作業する必要はないが、このチケットに絡む作業が発生した場合、その時点で作業の一部として取り込む運用もできる。

管理者としては、このチケットは将来のリスクの一つ。
3人日と見積もったチケットが実は5人日もかかってしまった理由の殆どは、リファクタリングの作業工数をあらかじめ見積もりできていなかったからだ。

この運用を始めて、開発者は積極的に、ソースで不安な所、コーディングルールに則っていない所をチケットに登録してくれるようになった。

あるいは、設計書に従って実装して、設計時の仕様漏れや仕様の不明点を質問が出た場合、課題としてチケットへ登録する。
このチケットは、障害修正と異なり、設計者や顧客へ問合せを行うワークフローで管理する。
つまり、このワークフローは変更管理、あるいは、インシデント管理の一部なのだ。

このチケット管理がおそらくIssue Trackingの発端ではないかと推測される。
課題のチケットは、上手に運用しなければ、単なる質問に過ぎなかったのに、仕様漏れとしてテスト工程で工数が大きくかかってしまう危険がある。

だから、チケットで質問と回答を履歴として残し、テスト工程や運用保守で追跡できるように記録しておく。

【2】チケット駆動開発の定義によれば、チケットとソース管理の連携というもう一つの特徴がある。
これこそが、従来のアジャイル開発のタスク管理になかったもの。

この運用ルールに開発者が慣れてしまうと、チケット無しでソースをコミットするのが不安で仕方なくなる。
チケット無しのソース修正をしてしまうと、変更理由が後で自分でも分からなくなるからだ。
特に、昨今のSW開発は開発者の出入りが激しいため、去ってしまった開発者のパッチの修正意図はすぐに分からなくなる。

これは後々の変更管理で大きくリスクとして響く点の一つ。
ソフトウェアは常に手入れしなければ、雑草が生えた公園のように、すぐにエントロピーが増大して品質が劣化していく。

【3】チケット駆動開発はウォーターフォール型開発でも運用できるだろうと思う。
しかし、アジャイル開発のプロジェクト管理に特化できる点が大きな特徴だと思っている。

現場で、Redmineにおける開発者の使い方を見ると、最初はチケット一覧で自分の担当チケットだけフィルタリングして、ToDo管理している。
しかし、僕が朝会などでRedmineのロードマップ画面を見ながら説明するうちに、開発者も自然にロードマップ画面を中心に見てくれるようになった。

理由は、自分のタスク状況だけでなく、チームの進捗がRedmineのロードマップ画面で一目で分かるからだ。
やっぱり、自分の作業、自分の役割がプロジェクトでどんな役割を担っているか、を開発者も知りたいらしい。

Redmineと比較して、Tracのロードマップは機能が貧弱だ。
終了チケットの進捗率しか表示してくれない。

ロードマップこそがアジャイル開発の肝だ。
ロードマップでプロジェクトの進捗、更にはプロジェクトのゴールが見えるし、そして、マイルストーンをXPのイテレーションとして運用すれば、自然にアジャイル開発になる。

Redmineでは自然にアジャイル開発できたのに、過去の僕が、Tracではチケットを乱発したり放置されがちに運用してしまったのは、Tracのロードマップやバージョン、マイルストーンを上手に運用できなかったのが理由だと思っている。

だから、Tracを運用して一番不満な点、そしてTracの最大の弱点の一つは、ロードマップ機能だと思っている。

逆に言えば、Redmineのチケット管理をアジャイル開発のプロジェクト管理に応用できた経験のおかげで、TracやMantisでも、チケット駆動開発できるようになった。

つまり、チケット駆動開発は、Redmineでなければできないわけではない。
数少ない経験から、BTSならば何でも可能だという気がしている。

【4】実際の現場で運用して、今はツールとセットでプロセス改善している、と回答せざるを得ない。
でも、RUPやCMMIのように、管理者からプロセスを開発者へ押し付けて、上からプロセス改善するよりも、ツールを使っていたら自然にプロジェクトの生産性がアップしていた、という方が、現場では使いやすい。

XPやアジャイル開発のように、チケット駆動開発も下からプロジェクトを改善していくのだ。

チケット駆動開発の運用例part2

八朔さんによるチケット駆動開発の運用例をメモ。

【元ネタ】
チケット駆動開発 - Live a meaningful Life

プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。
プロマネらしく、チケットの構造が上手だと思う。

このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。
【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。

アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。
顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。
そうでなければ、開発者が作業するレベルにならないからだ。

後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落とす所まで考えておられた。
つまり、テストケースは、要件とストーリー(ユースケースぽい業務シナリオ)のマトリクスで作れるはず、と。

そうすれば、チケット(要件)→テストケース→バグ→ソースコミット　という形で追跡可能になる。
僕は今、TestLink上で要件管理とテストケース管理を紐づけているが、最終的にはRedmine上で要件管理も行いたい。
その方が、スケジュール管理や工数管理もやりやすいからだ。

昨日のPFP関西WSでは、Redmineをタスク管理に実際に使っているという人もチラホラいた。
今、チケット駆動開発は熱いのかもしれない。

チケット駆動開発の運用例

チケット駆動開発の記事があったのでメモ。

【元ネタ1】
チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead

kanu_orzさんによるTracのチケット管理の運用例。
インシデント管理や問題管理にTracを下記で運用していると思われる。

・チケットをExcelで一括インポート
・Tracで工数を入力、集計
・チケット集計結果をExcelで出力

特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。

これは、いわゆるエンドユーザコンピューティングかもしれない。
つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に帳票(ここでは月次報告用の工数集計)出力する
のは、Tracで行わず、ローカルPC上で作業しているから。
何でもかんでもシステムで作業してもらう必要はなく、スキルがあれば、元ネタから自分で作ればいい。

また、興味深いのは、インシデント管理と問題管理を分離しようという問題意識を持っていること。

「インシデントからそのまま問題管理へ移行してしまうので、初期対応状況の進捗把握が難しい。」
「他からみた場合、対処せず放置しているように見える。」
という指摘は、そうだと思う。

障害修正の発生源を探ると、顧客からのクレームや問合せが発端だった、という時は多い。
チケット駆動開発では、インシデント管理と問題管理のチケットを混在させると、ワークフローやチケットのライフサイクルが異質なため、扱いづらい弱点がある。

だから、ワークフローの単位でプロジェクト別に分けた方が、おそらく運用しやすいのではないかと思う。

僕の少ない経験では、チケット駆動開発のワークフローは、ITILの言うインシデント管理・問題管理・変更管理・リリース管理の4種類にまとめ上げられると思う。
つまり、SW開発や運用保守の日々の作業は、上記の4種類のいずれかのワークフローに帰結すると考えている。

【元ネタ2】
redmine勉強会に参加してきました－実践redmineカテゴリ設計にご用心 - かたるほどでもない技術系ブログ

20090612 実践Redmine @ Redmine勉強会

6月に開かれたRedmine勉強会でのRedmine運用例。
興味深いのは、「各画面で利用できる分類まとめ」のページ。
このページで、Redmineのチケットが各画面からどのように参照されるのか、が一目で分かる優れもの。
チケットという一つのインスタンスをこれだけ多くの観点から集計したり参照できるのだから、Redmineは優秀だと思う。

読んでみて、感想をメモ書き。

「なぜかバージョンに対してwikiが設定できる」とあるが、その理由は、バージョンをシステム開発のマイルストーンと考えれば、そのマイルストーンまでにやるべき作業の詳細や一覧をWikiに書きたい要望があったからではないか、と推測する。

「トラッカーはどの画面でも現れる。ただ、権限設定とセットとなっているので管理には注意が必要」という指摘は、トラッカー(チケットの種類)がワークフローそのものだからだ。
Redmineのトラッカーと言う概念は、Tracにおけるチケットの種類に相当するが、Redmineの方がはるかにワークフローという概念がはっきりしている。

「バージョンはプロジェクト毎に自由に設定でき、なおかつロードマップを利用されるために欠かせない分類」という指摘は、Redmineのバージョンが、XPのイテレーションやScrumのスプリントに相当するものだからだ。
Redmineのバージョンの概念は、Tracのマイルストーンやバージョンに相当するが、Redmineの方がはるかにアジャイル開発っぽいように思う。

「ステータスはあくまで状態でしかなく、後の分類には利用不可能」の指摘は本来の意図がよく分からなかった。
ワークフローの観点では、ステータスは非常に重要だ。
Redmineサマリでは、ステータスごとにチケット数を集計してくれる重要な機能だ。
だからこそ、進捗報告の資料の元ネタにもなりうる。
おそらく別の文脈で話されたのだろうと思う。

「カテゴリは、プロジェクトごとに柔軟に運用可能」の指摘は、参考になった。
RedmineのカテゴリはTracのコンポーネントと同じく、システムの機能の単位だ。
例えば、Javaのパッケージの単位、バージョン管理のtrunkやbranchのようなコードラインの単位、あるいは、jarやwar、DLLというコンポーネントの単位が相当するだろう。
だが、上記の例から離れて、成果物の単位、工程の単位、あるいは、1つのワークフローにおける種類にしてもよいと思う。

つまり、「新規→修正→解決→検証→完了」という問題管理のワークフローがあった場合、そのワークフローは障害修正だけでなく、新規開発やレビュー工程でも使える。
だから、例えば、「問題管理」というトラッカーがある場合、そのトラッカーには必ず「バグ修正」「新規開発」「レビュー」のカテゴリをアサインする運用があってもよいと思う。

他の人のチケット駆動開発の運用例は非常に参考になるので、共有していきたい。

第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』

先週に開催された第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』がとても素晴らしいのでリンクしておく。

第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』

View more presentations from rrrkitamura.

上記の資料では、下記の点が非常に分かりやすい。

１・チケット駆動開発におけるワークフローを、チケットやプロジェクトのフロー図で説明している、
２・チケットとバージョン管理の連携による利点である変更管理を強調している。

「バージョン管理ツールとチケットの連携。チケット駆動開発では、OUTPUT（コミット）と INPUT（チケット）が紐付く。」という指摘こそが、チケット駆動開発の核心だ。
プロセスの入出力が、チケットとソースコミットに対応するという指摘は非常に鋭い。

補足すれば、チケット駆動開発は、上記のワークフローを透過的に行っているのも利点の一つだ。
つまり、開発者のToDo管理を通じて、ワークフローと言う概念が上からではなく現場で根付いていること。
RUPやCMMIのように、上からの押し付けのプロセス管理は、開発者の作業効率を落とす。
しかし、チケット駆動開発ならば、開発者は作業報告を気にせずに作業できる。

現場の運用例がどんどん公開されて、皆で共有されていけばいいなと思う。