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

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のように、上からの押し付けのプロセス管理は、開発者の作業効率を落とす。
しかし、チケット駆動開発ならば、開発者は作業報告を気にせずに作業できる。

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

紙やExcelによる管理が残っている工程

2007年頃のバグ管理の資料があったのでメモ。

【元ネタ】
[Think IT] 第3回：取材お断り！の裏事情 (2/3)

・現状は、半分以上が紙もしくはExcel
・今後は、Bugzilla、Visual Studio 2005 Team Foundation ServerなどのBTSを使いたい人が多い

以前、バグをExcelで管理していた時、バグ管理IDは特別なExcelシートで採番するやり方で運用されていた。
そこでユニークなバグ管理IDを採番した後、その障害管理票を紙に印刷して運用していた。
その紙には、判子の欄があった。
判子の欄には、開発者、テスト担当者、プロジェクトリーダーの3つの欄があった。
それは、他の人の作業した結果を認めたら、各人が判子を押していく運用フローになっていた。

つまり、ワークフローと言う概念が当時の開発者だった僕の頭にはなかったけれど、たとえアナログであろうともワークフローは厳然として存在していた。

そして今は、RedmineやTracのチケットでプロジェクト内部の作業を全て管理する運用を始めて、リーダーだけでなく開発者もテスト担当者もワークフローと言う概念を、少しずつ認識し始めている。

この仕様変更は、どのチケットと関連しているのか？
このマージ作業は、どの障害修正から発生したのか？
自分が作ったプログラムは誰がテストするのか？
プロジェクトの中で自分のプログラムはどんな重要性を持っているのか？

いずれもチケット一覧、ロードマップから判別できる。

しかし、殆どの作業がBTS上でIT化された中で、未だに紙ベースの作業が唯一残っている。
それは、変更管理・進捗会議や設計レビューなど、4～10人による複数人での作業。

それらは大量の紙を印刷して配布され、その紙を見ながら、議論してメモしていく。
その会議中は全員分かり合った気分になっているが、後でメモを読み返して議事録にすると、微妙にニュアンスがずれていたりする。

議事録ドリブンできちんとやれば、そんなことは解決できるが、ExcelやWordの議事録はすぐに散らかってしまう。
せっかくレビューで仕様漏れをチェックし、ソースインスペクションもするのに、紙ベースで残すので、Excelの議事録にまとめるために二重の手間がかかる。

本来ならば、その場ですぐにExcelにレビュー指摘事項を一つずつ記録して、それをきちんと反映したか、というチェックを行いたい。

あるいは、突然の仕様変更に対し、方針を立てて、メンバーごとに調査を依頼する場合、それらをWikiなどに反映して、メンバーが作って持ち寄った成果物をチェックしたい。

そのワークフローをもっとスムーズに行いたいのだ。
今はメールや紙ベースで散在してしまっている。
後の運用保守で、それらの経緯がいつも分からなくなる。

どうやら3人以上による作業の場合、ペアプロも行えないので、紙やホワイトボードでコミュニケーションを取り合うしかない。
そして、それらはExcelの議事録を残すしかない。

チケット駆動開発は、個人のタスク管理には威力を発揮するが、複数人の作業によるワークフローを乗せるのはまだ分からない。

BTSチケットへどのようにレビュー結果や議事録をのせるか？
チケット駆動開発には、まだ課題は残る。

TestLinkから外部サーバーのBTSに接続する方法

TestLinkのあるサーバーから外部サーバーのRedmine/Mantisへ接続する方法でメモ書き。

【元ネタ】
FreeBSD/Mysql/外部接続 - PukiWiki Plus!

TestLinkにあるmantis.cfg.php、redmine.cfg.phpの設定は正しいのに、何度やっても、TestLinkからBTSチケットへリンクできない。

原因は、外部サーバーのBTSにあるMySQLが、localhost以外はデフォルトで接続不可になっている。

--確認
select User,HOST,Password from mysql.user;

--ユーザを追加
GRANT ALL ON [BTSのDB名].* TO '[DB-user]'@'[TestLinkのサーバー名]' IDENTIFIED BY '[DB-password]';
FLUSH PRIVILEGES;

MySQLを知っている人なら当たり前だろうけど、ちょっとはまった。

但し、TestLinkからTracへの設定は下記を参照すれば簡単。
Trac0.11からXML-RPC Pluginがデフォルトで付随しているため、trac.cfg.phpにURLを設定するだけでいい。

Trac と TestLink の連携 - かおるんダイアリー

アジャイル開発は受託開発の方が向いている

ある人と話して気付いたこと。

アジャイル開発は受託開発の方が向いている。

組込系の製品開発やパッケージ製品開発では、マーケティングやビジネス上の要請から、既に要件が殆ど決められていることが多い。
だから、ウォーターフォール型開発で進めやすい。

受託開発では、おおまかな要件は決まっているが、あくまでも方針だけ。
顧客のためにカスタマイズしていく間に要件が絞られて、具現化していく。
ガチガチのウォーターフォール型開発で進めると、度重なる仕様変更を制御できずに、コストや納期がオーバーしやすい。

だから、小刻みにリリースしながら、顧客のフィードバックをイテレーション単位で取り込んで、システムをブラッシュアップしていく。
コストと納期は厳守しながらも、スコープ(要件)を変化させることで、顧客満足を稼ぐ。

でも、アジャイル開発だからといって、設計書は不要、とか、計画は不要、というわけではない。
要件の変化を確実に追跡できる変更管理の仕組みは必須。
どのイテレーション(バージョン)に、どんな改善要望や障害修正を反映していくか、というリリース計画を作るのが重要。

チケット駆動開発がアジャイル開発のインフラを提供していく。