« 2010年1月 | トップページ | 2010年3月 »

2010年2月

2010/02/28

テスト消化曲線とバグ発生曲線のパターン診断

テスト消化とバグ発生曲線(バグ収束曲線)をパターン分けした素晴らしい記事があったのでメモ。

【元ネタ】
山浦恒央の“くみこみ”な話(16):テスト消化曲線とバグ発生曲線の7パターン診断 - MONOist(モノイスト)

テスト消化曲線は、未実施テストケース数を時系列に表示したグラフで、普通は右肩下がりになる。
バグ発生曲線(バグ収束曲線)、累積バグ数を時系列に表示したグラフで、普通は右肩上がりになる。

テスト消化とバグ発生曲線は密接に関係している。
理由は、ブロッキングバグがたくさん出るほど、ブロックするテストケースが増えてしまってテストの進捗は遅れるからだ。

実際にTestLinkでテスト管理してみると、ブロッキングバグが出るたびに、テストに失敗するだけでなく、ブロックするテストケースも増える。
例えば、テストに1回失敗すると、10個ぐらいのテストケースはテスト不能になってしまう。

僕の経験では、TestLinkでアジャイル開発っぽくテスト計画を実施すると、テスト計画にはせいぜい500個ぐらいのテストケース数なのに、50件もバグを見つけたら、1ヶ月で全てのバグを潰すのはほぼ絶望的になる。
つまり、全テストケースの10%も失敗したら、殆どテスト不能になってしまい、テストしても無意味になってしまう。
結局、見つけたブロッキングバグをひたすら修正するのが一番の早道だ。

テスト消化曲線とバグ発生曲線の7パターン診断 - @IT MONOistでは、下記の7パターンに分類しているのが参考になる。
自分の経験と合わせて書いてみる。

1・理想型

→「消化したテスト項目数」と「摘出したバグの数」の実測値が予定の曲線に合致している場合。
 テストが計画通りに進んでいるパターン。
 普通のプロジェクトでは少ないだろう。

2・停滞型:テスト担当者の能力不足

→テストの進捗も遅れているが、バグも少ない場合。
 例えば、テスターが新人やヘルプで、テストの経験が少なかったり、システムの仕様を知らなかったりする場合が多い。
 普通のプロジェクトでは、業務に詳しい人を投入して、テストもバグ発見もはかどらせるようにする。

3・疑似高品質型:本当にプログラムの品質が良いか?

→テストの進捗は早く進んでいるが、発見したバグが少ない場合。
 いわゆるメトリクスの罠に陥っている時が多い。
 本当にバグが少なくて高品質なのか、あるいは、テスターの能力が低いのか、見極める必要がある。

4・真正高品質型:プログラムの品質が良い

→テストの進捗が計画通り、又は早く進んでいるが、摘出バグが予測よりも少ない場合。
 プログラムの品質が良い場合が多い。
 このパターンに当てはまれば、システムテスト工程になっても、毎日定時退社できる幸せなプロジェクト(笑)

5・お祭り型:ベテランの急ぎ仕事

→テストの進捗は早いけれど、摘出バグも多い場合。
 いわゆる「派手なお祭り状態」のパターン。
 バグが多いのにテストがはかどっている状態を類推すると、致命的なブロッキングバグは少なくて、すぐにバグを修正できているのだろう。
 つまり、バグは単純な原因が多いのだろうと推測される。
 熟練プログラマが急いで作ると、このパターンになるらしい。
 戦略としては、バグを傾向分析して、同種バグを徹底的に潰せば良い。

6・バグだらけ型:最も普通のパターン

→テスト進捗は予定通りだが、摘出バグがはるかに多い場合。
 普通のプロジェクトで最も多いパターン。
 テストケースの品質は普通で問題ないが、プログラムの品質が悪い典型的なパターンと言えるだろう。
 現場リーダーは、テスト工程がこのパターンに陥るのを普通は予測しているので、残業して休日出勤すれば間に合うだろう、と思ったりもする(笑)
 上記パターンと同様に、ブロッキングバグが出てブロックしたテストケースも多く出ているものの、確実にバグ修正できているから、今のペースで頑張ればいい。
 同種バグを潰す戦略が徹底できれば、システムの品質は上がってくるはず。

7・深刻型:前フェイズの品質が低い

→テスト消化数が少なく、テストは遅れているのに、摘出バグが予想通り、又ははるかに多い場合。
 ブロッキングバグが多発して、テスト不能な状態になりがちで、テストがはかどらない状況になっている。
 典型的なデスマーチ・プロジェクト。
 
 上記の記事では二つの戦略があると言う。
 一つは、「品質の悪いソース・コードをだましだまし使う」。
 納期目前でソースを捨て去ることはできないので、ソースへパッチを継ぎ接ぎしながら、テストをこなしていく戦略。
 普通のプロジェクトではよく見られるやり方で、最後は徹夜で残業して納めることになる。
 
 他方は、「すべてのソース・コードを捨て、設計し直す」。
 これが本来の正当な戦略なのだろう。実際一から作り直した方が早く作れて早くテストできる時が多い。
 この戦略を実行できるには、ソースのインターフェイスが間違っていないのが前提条件。
 インターフェイスは変えないが、中身のロジックは全て作り直せば、他プログラムに影響はしない。


TestLinkを運用すると、テスト実績はTestLinkCnvMacroで簡単にメトリクス分析できるし、バグ情報はRedmineなどのBTSに溜まっているので、いくらでも計測できる。
PerlやRubyなどのスクリプト言語を使えるなら、直接DBから検索して出力すればいい。

上記の記事を書かれた山浦さんは、ソフトウェアテストの専門家の方であり、「ピープルウエア 第2版 - ヤル気こそプロジェクト成功の鍵」の翻訳者の方でもある。
他記事もとても参考になるので、読んで欲しいと思う。

| | コメント (1) | トラックバック (0)

TestLinkのベストプラクティス集

TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。
あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。

【元ネタ】
脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所

TestLinkのFAQ: プログラマの思索

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

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

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

TestLinkを受入テストで運用する方法: プログラマの思索

【1】ブロック

テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。
ブロッキングバグが原因でテスト不能になった状態でもある。

例えば、Webのカート画面でカート投入のテストが失敗した場合、注文フローのテストケースは全てブロックになる。カート投入機能にバグがあるのだから、その状態で注文のテストを続けても無意味だからだ。

実際のテスト工程では、テストに失敗した場合、そのまま続行するかどうかの判断がすごく難しい。
テスト工程でテスターが大量投入される状況が多いので、システムの仕様を知らないテスターはその判断が難しいからだ。

テスト計画やテスト戦略がきちんと徹底されていないチームでは、ブロックすべきテストケースを実施して、テスト工数を無駄に浪費する。
つまり、NGが出たら、関係するテストケースはブロックで一時保留とし、他のテストケースにリソースを費やしたり、バグ修正に専念する方が賢明だ。

ブロックするかどうかの判断のために、テストケースの依存関係もテスト仕様書へ記述しておくと、テスターが作業しやすくなるだろう。
TestLinkには、テストケースの属性にキーワードがあるので、この項目に依存するテストケースを追記する運用方法もあるだろう。

【2】みなしNG

失敗したテストケースが原因で、テスト未実施だが失敗になる状態を指す。
ブロッキングバグが原因でテストしなくても失敗になる状態でもある。

例えば、Webのカート表示機能のテストで失敗した場合、カート追加やカート削除の機能も当然、テストを実施しなくても失敗が予想されるので、それらのテストケースをみなしNGとして、失敗ステータスにする。

実際のテストでは、みなしNGとブロックの使い分けは運用ルールによって異なるけれども、テストチームが開発チームへ実際の厳しい現状を伝えるために、故意に「みなしNG」を使ってびびらせる場合もある。
ブロックはあくまでもテストが一時保留だが、みなしNGはテスト失敗とカウントされるので、システムの品質が悪い事実としてカウントされてしまうからだ。

【3】みなしOK

過去に実施したテストケースで、今回の開発に影響しないテストケースをテストせずに成功ステータスとすること。
例えば、小売Webシステムでクレジットカード注文の仕様変更があった場合、クレジットカード注文機能のテストは行うけれども、今回の修正に全く無関係なコンビニ注文のテストは「みなしOK」として成功ステータスとする場合があげられる。

実際のテストでは、すぐにテストケース数が膨れ上がってしまうために、工数や納期を考えるとテストケースを間引く必要がある。
しかし、「みなしOK」の判断は、システムの仕様や過去の障害履歴などを十分に考慮して判断しなければ、テスト漏れになってしまう危険性があるので注意すべき。

【4】ブロッキングバグ

ブロックしたテストケースの発生源となるバグ。
文字通り、ブロジェクトの進捗をブロックしてしまい、プロジェクトを危険な状況に陥らせるバグを指す。

実際のテストでは、テストするほどバグがどんどん増える時が多い。
すると、失敗するたびにその10倍ぐらいのテストケースがブロックされてしまい、すぐにテスト不能に陥ってしまいがち。
つまり、バグが多すぎて、どれがブロッキングバグなのか分からなくなる時が多い。
そうなると、バグ修正できてないのに、無駄にテストを先に進めてテスト工数を浪費したり、デグレを発見したりして、テストチームのモチベーションを下げてしまう。

だから、テストに失敗するたびに、ブロッキングバグに目印を付けて、バグ修正はブロッキングバグを最優先に行って、テストの進捗を妨げないようにするのがテスト戦略の基本。

TestLinkには、失敗したテストケースをBTSと連携する機能があるので、テスターと開発者が相互にバグ検証とバグ修正を連携するワークフローが自然にできる。
だから、バグ修正の優先順位さえ間違わなければ、テストはスムーズに進むはず。

【5】同種バグ(類似バグ)

既存バグと同一原因の残存バグを指す。
例えば、画面のあるプルダウンのエラーチェックにバグがあれば、他画面でも同様のバグがあるだろう。

実際のテストでは、一つのバグの周辺には必ず他のバグが存在する確率が高い。
何故なら、バグを埋め込んでしまった原因は、開発者が仕様を完全に理解していなかったり、誤った実装方法を使い回していたりする時が多いからだ。
つまり、開発者の作業そのものに問題がある時が多い。
だから、同種バグを探すには、バグの原因分析が非常に重要になる。

【6】みなしバグ

ブロッキングバグの同種バグ。
例えば、みなしNGのテストケースのバグがあるだろう。

ブロッキングバグを見つけたら、そのテストケース周辺やその機能の周辺には、他のバグが紛れ込んでいる可能性が高い。
テスターは、ブロックを上手に使いこなしながら、限られた工数で数多くのバグを見つけ出さねばならないのだ。

【7】周辺テスト

ブロッキングバグ修正後、ブロッキングバグに関係する成功ステータスのテストケースを回帰テストしてみること。
例えば、カート削除のバグを修正後、既に成功ステータスで実施済みのカート表示やカート投入の機能を再テストする場合を指す。

実際のテストでは、既に成功ステータスのテストケースを再テストする必要はないけれども、回帰テストでバグ修正のデグレがないことを検証したいものだ。
TestLinkでは、テスト結果をビルド単位に別管理できるので、回帰テストの結果を履歴管理できる利点がある。

【8】後追いテスト

リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、優先順位が低くて未実施のテストケースを実施したり、回帰テストを行うテスト手法を後追いテストと呼ぶ。
後追いテストの目的は、更なる品質強化だ。

出荷前の時期になると、プロダクトリスクが発生するような重大なバグは殆ど潰されているが、エラー文言の修正だったり、UIの改善など、細かな作業はまだまだあるはず。
だから、空き時間を使って、細かなバグ修正とバグ検証を行い、システムのマイナーバージョンアップのリリースへつなげる。

※Nakaさんからのアドバイスによれば、後追いテストで、致命的なバグが見つかったら、販売を止めるか、判定基準も必要。致命的なバグが出た場合の事も考えて、緊急報告体制を引いておく事も大切、とのこと。

【9】五月雨テスト

開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
仕様変更が次々にやって来て、小刻みに検証せざるを得ない場合に用いる時が多い。

このテスト手法は、まさにアジャイル開発そのもの。
開発チームが単体テストまで開発が完了したら、すぐにテストチームがそのモジュールをテストし始めて、テスト結果を開発チームへフィードバックしていく。

TestLinkをアジャイル開発に当てはめるやり方は、「脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所」に詳しく書いた。
つまり、テスト計画をイテレーションと見なして、2~4週間のサイクルで順次テストしていく戦略を取る。

TestLinkを上手に使いこなせていない人の話を聞くと、テスト計画の単位が良くない。
例えば、テスト計画が1個しかなく、数千ものテストケースを実施しようとしていて、何ヶ月経ってもバグが直らず、いつまでたってもリリースできない状況が多い。
まずは、全てのテストケースを最低1回は実施できるように、複数のテスト計画に分割し、テスト計画に含むテストケース数をせいぜい500個以下に抑えて、順次テストしていくアジャイル開発っぽいテスト手法が最も確実だと思う。

【10】受入テスト

発注者が納品モジュールのバージョン単位でテストしていく手法。
まさに受入テストなのだが、開発チームのテスト手法である五月雨テストとは異なる。

TestLinkによる五月雨テストでは、テストケースを複数個のテスト計画にグループ化し、テスト計画をイテレーションと見なして、順次テストしていく。まずは全てのテストを通すことを最優先にするので、テスト結果は1個のビルドで管理している時が多いだろう。

逆にTestLinkによる受入テストでは、受入テストケースを1個のテスト計画にアサインするが、納品モジュールの単位でテスト結果を履歴管理する。実際は、TestLinkのビルドを納品モジュールのバージョンと見なして、納品モジュールのバグを記録しておく。
理由は、納品モジュールがバージョンアップするに従って、どこまで品質が保証されているか、明確に管理したいからだ。
TestLinkのVer1.8以降では、複数のビルドをまとめたテスト結果を表示できるので、使い易くなっているようだ。

つまり、発注者がTestLinkを使う場合は、TestLinkのテスト計画とビルドの関係が1対Nになるので、五月雨テストの時と異なるのに注意する。


TestLinkによるテスト管理を使いこなせれば、ソフトウェアテストや品質管理の技法が自然に身に付く。
是非、TestLinkを使ってみて、足りない機能はTestLinkをカスタマイズして機能改善してみて欲しい。

| | コメント (0) | トラックバック (0)

2010/02/27

TestLinkの隠れ機能~工数集計とステータス設定

TestLinkのVer1.8を使ってみて、隠れ機能を見つけたので書いてみる。

【1】Ver1.8以降では、下記のドキュメントに従うと、予定工数、実績工数の合計表示をテスト結果画面で集計できると書かれている。

testlink\docs\customfields_for_computing_times.txt

上記に従って、Ver1.8.2とVer1.8.4のTestLinkで、下記の手順を行ってみた。

【TestLink1.8.2】
1・4個のSQLを実行
2・テスト仕様で、テストケースを作り、予定工数を入力
3・テスト実行で、テストケースに実績工数を入力して「成功」にする
4・テスト結果で、「カスタムフィールド情報とテストケース」画面で実績工数が表示される。
 しかし、同じテストケースをグルーピングして実績工数を合計表示してくれない。
5・テスト結果で、「カスタムフィールド情報とテスト計画」画面では、「予定工数、実績工数が空欄表示される」。

【TestLink1.8.4】
1・4個のSQLを実行
2・テスト仕様で、テストケースを作り、予定工数を入力
3・テスト実行で、テストケースに実績工数を入力して「成功」にする
4・テスト結果で、「カスタムフィールド情報とテストケース」画面で実績工数が表示される。
 しかし、同じテストケースをグルーピングして実績工数を合計表示してくれない。
5・テスト結果で、「カスタムフィールド情報とテスト計画」画面では、「予定工数、実績工数の項目すら表示されない」。

Testlink5_2

上記の結果を見ると、1.8.4はデグレしているように見える。

上記は、TestLinkの隠れ機能のように思えるが、テスト予定日・予定工数・実績工数をテストケースやテスト結果の属性へ持てれば、テストのスケジュール管理を機能強化できるだろう。

【2】TestLinkのテスト結果には「未実施」「成功」「失敗」「ブロック」の4種類しかないが、もっと増やしたい場合がある。
例えば、システムテストや受入テストのように、複雑なデータパターンでテストしている場合、エビデンスは採取できたものの、検証に時間がかかる場合は、「検証中」という仮のステータスを設定したい。
「検証中」ステータスは「テスト実施済み」だが、まだテスト結果が未定の状態を表す。

「検証中」ステータスが欲しい理由は、とにかくテストの見かけ上の進捗を先に進めたい時だ。
テストを実施してエビデンスを採取するテスト実行者と、採取されたエビデンスを分析して確認する検証者の2人によるペア作業が発生するので、二人の作業状態を表すステータスが欲しいのだ。
つまり、「未実施」ステータスのテストケースはテスト実行者がどんどんテストを実施すればいいし、実施後は「検証中」ステータスに更新して、検証者に回せばいい。

他にもテスト結果のステータスを増やしたい場合があるだろう。

/testlink/custom_config.inc.php にある下記ソースを修正すると、TestLink実行・結果画面で、
「全て」「存在しません」「不明」というステータスが現れる。
実行後、「存在しません」「不明」ステータスは色付けされる。

----↓ここから↓----------------------------------------
$tlCfg->results['status_code'] = array (
"failed" => 'f', #失敗
"blocked" => 'b', #ブロック
"passed" => 'p', #成功
"not_run" => 'n', #未実施
"not_available" => 'x', #存在しません
"unknown" => 'u', #不明
"all" => 'a' #全て
);

$tlCfg->results['status_label'] = array(
"passed" => "test_status_passed",
"failed" => "test_status_failed",
"blocked" => "test_status_blocked",
"not_run" => "test_status_not_run",
"all" => "test_status_all_status",
"not_available" => "test_status_not_available",
"unknown" => "test_status_unknown"
);

$tlCfg->results['status_label_for_exec_ui'] = array(
"passed" => "test_status_passed",
"failed" => "test_status_failed",
"blocked" => "test_status_blocked",
"not_run" => "test_status_not_run",
"all" => "test_status_all_status",
"not_available" => "test_status_not_available",
"unknown" => "test_status_unknown"
);

$tlCfg->results['default_status'] = "passed";
----↑ここまで↑----------------------------------------

Testlink1_2

Testlink2_2

Testlink3_2

Testlink4_2

「全て」ステータスは、テスト結果のステータスプルダウンの一種と推測される。
「存在しません」「不明」ステータスの使い方は不明だ。
上記のステータスは、Ver1.8の隠れ機能と思われる。

TestLinkにある上記2点の隠れ機能がver1.9で早く実現して欲しいと思う。

| | コメント (0) | トラックバック (0)

2010/02/26

FP法で業務モデルを計測する

児玉公信さんの本「システム開発の見積りのための実践ファンクションポイント法」を読んで、ファンクションポイント法を業務モデルの計測に使えないか、考えてことをメモ。
#まとまっていないので、あくまでもメモ書き。

ファンクションポイント法(FP法)は、機能の規模の見積もりとして古くから知られている。
しかし、計算が複雑で、見積もりの根拠となるモデルが曖昧なため、普及しているとはいえない。
システム開発の見積りのための実践ファンクションポイント法」で興味深いと思った点は下記の通り。

【1】業務設計やシステム提案という早い段階で、概算の工数見積もりを出す道具として、FP法を使うこと。

FP法を使うタイミングとしては、RFPによる提案やシステム化構想、業務設計など、プロジェクト計画書を作る段階を想定している。

実際の業務設計では、顧客の現行業務と新業務の二つのモデルを作り、システム化の利点をアピールして受注する。その時、現行業務モデルと新業務モデルの2つのモデルが作られる。
これを元に、FP法が使えるモデルへ変換して、システムの概算規模をFP法で計算できれば、過去のプロジェクトの実績から、おおよその工数を計算できる。

業務設計における要件定義と言う早い段階で規模を見積もりできる利点は多い。
要件定義では、SIとユーザ企業がシステム化対象のスコープをすり合わせる工程のため、お金や時間の制約から、おのずと開発対象のシステムの規模は収まるはずだからだ。

システム開発の見積りのための実践ファンクションポイント法」では、ある相場では「1FP=15人日」という事例が載っている。
つまり、1個の機能を作るのに、3週間かかっている計算になる。

この事例を考えると、業務モデルに出てくる機能は、約1人月で作れる規模感覚で洗い出せばいいだろう。
例えば、100FPならば、見積もり工数は75人月となり、1年未満の中規模プロジェクトになるだろう。
但し、FPと工数の関係は、プロジェクトによって大きく異なるため、注意しよう。

【2】FP法が使えるモデルとしては、「システム開発の見積りのための実践ファンクションポイント法」ではER図とDFDを推奨している。実際、ILF・EIFのようなデータと、EI・EO・EQのような機能の関係を表せればいいからだ。
Astahのようなモデリングツールの場合、岡島さんが推奨するように、ユースケース図にロバストネス図をミックスしたモデルを書けばいいだろう。

JRubyでJUDE CRUD-APIを試す - TECH-moratorium : テクモラトリアム

FP法のアルゴリズムは、所詮、Excelのマクロで作れるレベルなので、Rubyで実装してしまえばいい。
Astahでモデルを書いた場合、JavaAPIを通じてモデルの値を取得できるので、JRubyを使えばいいだろう。
Rubyプログラムの中で、JavaAPIを簡単にコールしてモデルの値を取得できるからだ。

システム開発の見積りのための実践ファンクションポイント法」で面白いのは、FP法が使えるモデルの書き方の注意点が、OOAやDOAと発想が似ていること。
まず良いモデルを作るのが、FP法では大事。
つまり、良いモデルかどうかを、FP法で計測することもできるのが面白い。

駄目なモデルは、機能やデータの漏れがあるために、実際に開発してみると、見積もり工数が大きく変わってしまう。
良いモデルならば、その後の要件の変更を新たな要求と見なして、顧客に追加のお金を要求することもできる。

OOAやDOAというモデリング技法にFP法を応用すれば、単なる工数見積もりだけでなく、モデルのメトリクスとして使えないだろうか?
つまり、モデルの規模だけでなく、モデルの品質にFP法を使えないだろうか?

【3】FP法が普及すれば、受託開発の契約を工数ではなく、システムの開発規模でやり取りできる可能性があること。

IT業界の悪いビジネス習慣は、人月ビジネス。
時間を切り売りするビジネスでは、品質が悪いシステムほど時間がかかるから、お金が儲かるという悪循環が発生しがち。
品質を向上させて生産性を上げる方向へ開発者の動機が向かない仕組みになっている。

しかし、「システム開発の見積りのための実践ファンクションポイント法」の最後では、アメリカで開発規模の単位で契約を結び、スコープを調整しながら開発するユーザ企業があるという話が載っている。
これは、まさにアジャイル開発そのものだ。
一定期間に一定規模のシステムを開発していくならば、自然に段階リリースして開発しているだろう。

アジャイル開発では、システムの規模はストーリーポイントという概念で表現されている。ストーリーポイントは、「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」にあるように、開発チームの議論の中から作られる。
しかし、モデルを作っているならば、FP法のアルゴリズムを使えばシステム規模を自動計算できるはず。

人月ビジネスから規模ビジネスへIT業界が変わるならば、生産性の向上が利益に直結するから、技術革新も生まれやすくなるはず。
FP単価、つまり、1FPで実装される工数が小さいほど、わずかな工数で同等の規模のシステムを作れるからだ。
つまり、SIにとってFP単価が受託開発ビジネスの利益指標になればいい。

ストーリーポイントの計算にFP法を用いて、アジャイル開発を補強できないか、考察してみたい。

| | コメント (0) | トラックバック (0)

アジャイル開発と要件管理

 要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。


【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。
「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。
「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。

「要件」には3種類あると言う。
一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。
2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。
3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。

我々技術者が見る要件は、システム要件に相当する。
しかし、顧客と話す場合、業務要件でなければ会話ができない。
更に、システムを売り込む時のように提案する場合、事業要件で話さなければ、経営層の心に響かない。

実際は、業務要件をまとめるのが要件定義であり、システム要件は基本設計(外部設計)の工程で行われる時もあるだろう。

【2】要件定義書を作る場合、顧客の現行業務を洗い出し、問題点を吸い上げて、解決策としてシステムを導入する点を入れる。
要件定義の作業で重要なポイントは、要件に漏れがないことだ。

問題点と要件はN対Nの関係で対応付けられるため、複雑になりがち。
MECEでなければ、要件定義書が分かりにくいし、その後の設計でも混乱の原因になってしまう。

実際の要件定義では、顧客に何度もヒヤリングしながら現行業務を理解して、問題点を洗い出していくので、要件を何度も書き直す。
そのたびに、更新漏れや依存関係の間違いが発生しやすい。

普通、要件定義書はExcelで作られるため、要件IDの項番がずれやすく間違いやすい。また、依存関係をハイパーリンクで作ってもよいが、保守が大変。
やはり要件定義は難しい作業なのだ。
要求管理ツールは、要件の依存関係と言うハイパーリンク機能を実現しているのがウリの一つだ。

最終的には、要件定義書の元ネタとなる要件は要件管理ツールで制御せざるを得ないだろうと思う。

【3】「要求開発と要求管理―顧客の声を引き出すには」では、要件の複数リリース管理で、要件にバージョンを入れる事を提案している。
つまり、1回、2回と小刻みにリリースしていく時に、要件もバージョン管理の配下において、要件の履歴や状態を管理しようとすること。

TestLinkのVer1.9betaでは、「SRS versioning」という新機能がリリースされている。
この機能の意味を僕は最初分かっていなかったが、これは、ソフトウェア要求(SRS)にリリースバージョンを導入できることを指す。

SRSをバージョン管理できる利点は、要件がリリースされているか、リリースされていないか、リリースされたならばどのバージョンに反映されているか、をすぐに判明出来ること。

特に、アジャイル開発のように小刻みにリリースしていく開発スタイルでは、これは非常に重要な機能になる。
何故なら、ストーリーカードをどのバージョンでリリースしていくか、というトリアージ(取捨選択)こそが、XPの計画ゲームであり、Scrumのスプリント計画であるからだ。

つまり、要求のバージョン管理は、リリース管理に密接に絡む重要な機能だ。
特に、アジャイル開発のように、頻繁にリリースする開発スタイルならば尚更だ。

TestLinkの要件のバージョン管理の機能の詳細を僕はよく知らないが、TestLinkの要件はテストケースと紐づけることができるため、TestLinkのテストケースが全て成功になってリリースされたら、それに紐づく要件もリリースバージョンが付与されると推測される。

要求管理ツールには、普通はリリース管理の機能として、要件のバージョン付け機能が付いているのもウリの一つ。

【4】TestLinkの要件には、要件同士をリンクする機能がある。
これは、要件の依存関係を表している。
つまり、要件定義書における要件同士のハイパーリンクと同じ機能だ。

成功する要求仕様 失敗する要求仕様」では要件の依存関係の種類として「必須依存」「作業依存」「サブセット依存」「網羅依存」「価値依存」が紹介されている。

(以下、要求を要件とみなす)
・必須依存
 要求Bを満たして、要求Aを満たす場合。
 例えば、要求Bを削除すると、要求Aも削除される。
 依存関係の方向は、片方向と双方向の2種類がある。

・作業依存
 要求Bを実装すれば、要求Aの実装が簡単になる場合。
 要求の工数見積で重要になる。

・サブセット依存
 要求Bは要求Aの一部である場合。
 要求の親子関係に相当する。

・網羅依存
 子要求の機能の和が親要求の機能と同等になる場合。
 サブセット依存の一種。
 要求の工数見積で重要になる。

・価値依存
 要求Bを満たすことによって、要求Aのニーズが弱まる(強まる)場合。
 例えば、要求Bをリリースすると、要求Aの優先順位が下がる場合。

アジャイル開発おけるイテレーション計画やスプリント計画を作る場合、ストーリーカード同士の依存関係、ストーリーカードとタスクカードの依存関係を考えながら、ストーリーカードを取捨選択しなくてはならない。
だが、ストーリーカードの枚数が多いと、ストーリーカードが漏れたり、整合性が取れていなかったりして、リリースした後で要件漏れに気づく危険がある。

だから、XPやScrumでは、2~4週間と言う短い期間で複数回リリースする戦略を取ることによって、要件のスコープを小さくし、ストーリーカードの枚数を少なくするように制御している。

この時に、ストーリーカードの依存関係を種類できちんと区別できていれば、要件漏れの危険性はより少なくなるだろう。
特に、価値依存の場合のように、リリースによって要件の優先順位が変わってしまう場合は要注意だ。
何故なら、リリースによって、関連する要件の優先順位が下がるならば、その要件をイテレーションから外すことによって、余裕を作ることができるからだ。
できればその作業は、要求管理ツールで自動化できるとなお良いだろう。

【5】「要求開発と要求管理―顧客の声を引き出すには」にあるように、要求管理ツールでは、要件の依存関係を管理できること、更には要件のリリース管理つまりバージョン管理の2つの機能は必須だ。
その機能によって、要件からリリースモジュールまでのトレーサビリティが実現される。

要件のトレーサビリティの利点は、仕様変更によって要件を削除したり更新したりする時の影響範囲が分かること、更には影響範囲から工数見積もりを計算できることだ。

Redmineのチケットで要件管理をする場合、関連リンク機能にある「関連する」「重複する」「先行する」などを使えば、依存関係の種類を制御できるかもしれない。

要件定義と言う上流工程の作業の品質が悪ければ、いくら設計力やプログラミング力があっても、漏れた要件に気付くことはできない。
要件管理という発想をアジャイル開発に注入して、アジャイル開発を補強できないか、更に考えてみたい。

| | コメント (0) | トラックバック (0)

2010/02/21

イノベーションのジレンマ~過剰技術・過剰品質の罠

下記の記事を読んでメモ。

【元ネタ】
【レビューBOOK REVIEW - 半導体業界は"技術立国・ニッポン"の幻想から脱却できるのか | エンタープライズ | マイコミジャーナル

日本の製造業は品質も技術も世界一と言われるが、半導体産業は今や韓国を中心とする新興国に覇権が移った。
その理由は、「過剰技術・過剰品質という病気」を持っているかららしい。
いわゆるガラパゴス現象。
つまり、狭い市場に特化した高品質・高機能な製品は、世界で売れなくなる現象。

日本の携帯も同様の症状に陥っている。
i-modeは確かに優れていたが、今はiPhoneに技術の覇権が移っている。
本屋のコンピュータの本棚を見れば、iPhoneプログラミングの本がわんさか売られている。
販売だけでなく、開発者の興味も移りつつある現状があるのだ。

この現象を説明するモデルは、「イノベーションのジレンマ」という本で既に解説されている。
プロセス改善のような持続的イノベーションの世界を打ち壊す革新的な製品が出て、破壊的イノベーションが生じて、ビジネスのルールが変わってしまうというもの。

イノベーションのジレンマ」では、ショベルカーやディスクドライブメーカーの産業を例にして、詳しく解説している。
イノベーションのジレンマ」を読んで僕が最も興味を惹いたのは序章の冒頭だ。
著者が「何故、優良企業が失敗するのか」という研究に取り組むために良い例はないかと探していた時、こんなアドバイスを受けたと言う。
遺伝の研究者は、人間ではなく、ショウジョウバエのように1日で生まれて死ぬ短いサイクルのモデルを使って研究する。
産業界で最も近いショウジョウバエの例は、ディスクドライブメーカーだから、それを元に研究すればいい、と。
この文章を読んで、すごく怖いと思った。

IT業界、半導体業界も、産業界のショウジョウバエのような存在なのかもしれない。
常に破壊的イノベーションを生み出さなければ、取り残されるだけでなく、その産業で生きられなくなる。
プロセス改善という持続的イノベーションだけでは生きていけない。

アジャイル開発なら、ビジネスの変化や要求の変化に対応することで、破壊的イノベーションを取り込むことはできないか?
ソフトウェアアーキテクチャの技術の高さが鍵を握っていると直感している。

|

2010/02/20

チケット駆動開発にPSPの概念を持ち込む

PSPの記事を読んで、チケット駆動開発にPSPの概念を持ち込めないか、メモ。

【元ネタ】
特集:ゼロからはじめるPSP ─Personal Software Process | エンジニアマインド … 技術評論社

ゼロからはじめるPSP ─Personal Software Process:第1章 PSPを導入する理由(わけ) ~自立したエンジニアのためのライフハック | エンジニアマインド … 技術評論社

ゼロからはじめるPSP ─Personal Software Process:第2章 PSP のインフラ構築 ~ PSP を始める前に | エンジニアマインド … 技術評論社

ゼロからはじめるPSP ─Personal Software Process:第3章 記録による改善 ~ アスケイドにおける事例の紹介 | エンジニアマインド … 技術評論社

ゼロからはじめるPSP ─Personal Software Process:第4章 無理なくPSPを活用する ~アスケイドにおける今後の展開 | エンジニアマインド … 技術評論社

PSP(Personal Software Process)は、個人向け開発者のCMMI版。
CMMIと同様にレベルがあり、0~3まである。
PSPは、開発者個人で成果物の規模や工数を計測し、自己改善していく手法。
PSPの本を読むと、ここまで計測すると面倒だ、と思ったりもする。

Redmineによるチケット駆動開発では、チケットに予定・実績工数を書くし、カスタムフィールドに規模を追加すれば、PSPで必要な計測データは全てRedmineのDBに格納される。
後は、PSPのプロセスをチケット駆動開発の運用ルールに当てはめればいい。
チケット駆動開発では、計測データの元ネタを入力するプロセスが自然であり、バックグラウンドでメトリクスをいくらでも出力してくれる利点がある。

最初は、自分の見積と実績に差異が出るだろうが、じきに見積もりの精度も上がるし、学習した分だけ、プログラミングの規模も大きくなっていくだろう。
自己改善していく過程をチケット集計表示できれば、モチベーションアップにもつながる。

PSPのアイデアをTiDDへ持ち込めるかどうか、もう少し考えてみたい。

| | コメント (0) | トラックバック (0)

2010/02/19

今年注目のツール

面白い記事があったのでメモ。

明鏡止水: 今年のサーバーの楽しみ

僕が今年注目するツールは下記の通り。

Redmineは0.9.2が出て、使い易くなった。
プラグインが対応すれば、OSSのプロジェクト管理ツールの中でもかなり良い部類に入ると思う。

TestLinkも1.9beta2が出て、今年中に1.9が出るだろう。
要件管理、レビュー管理ができるそうなので、楽しみ。
特にTestLinkは使い辛い部分が多いので、どんどん改善して欲しいと思っている。
TestLinkによるテスト管理、要件管理は、かなりのポテンシャルがあると思っている。

個人的には、Review Boardを使いこなしたいと思っている。
コードレビューは重要と分かっているにも関わらず、結局実践出来ていない。

それから、教育管理システムMoodleにも注目している。
IT技術者にとって使う機会は少ないけれど、教育もWeb化できると幅が広がるのではないか?
ただでさえ、教育の世界は世間の流行に遅れている。
小学生でもPowerPointでプレゼンし、Wordで宿題を提出できる時代なのだから。

TortoiseHgも頻繁にバージョンアップして、今は0.9.3。
日本語の文字化けもしないし、ファイル名に日本語名を入れてもOK。
ローカルでバージョン管理するのがすごく楽になった。

TortoiseGitにも注目したい。
今のVerは1.3.6で、UIがかなり洗練されている。
GitもWindowsクライアントが改善されたので、随分使い易くなった。
ファイル名に日本語がOKになれば、使おうかなと思っている。

明鏡止水: 要求管理の悩み

上記のように、トレーサビリティをバグ管理の工程だけでなく、本来は要件定義や設計で使いたい。
どの要件が、どの機能に紐づいて、どんな仕様に落ちて、ソースになって、テストされて、バグが解決されたのか、トレーサビリティを使って追跡したいのだ。
1次開発でバグが頻発した機能が分かれば、2次開発でも手を入れればバグが出やすくなるから、レビューを多めに入れたり、回帰テストを広く行ったりするなどの対策を取ることができる。

Redmine、TestLink、Hudson、Subversionという複数のツール管の連携は取れている。
それらに、StatSVNやSonarなども連携できる。
今後は、トレーサビリティを重視する傾向が強くなれば、複数のツールを行き来できる機能が重要になってくるだろう。

| | コメント (0) | トラックバック (0)

プロセス・エンアクトメント

Rational Team Concertの記事があったのでメモ。

【元ネタ】
Eclipseの開発手法を受け継いだ 分散アジャイル開発のためのプラクティス(1/4):CodeZine

はじめて使うJazz (2) ― プロジェクトのリリース計画・反復計画・タスク実行(1/8):CodeZine

Rational Team ConcertはIBMが作ったアジャイル開発を支援する製品。
IBMと言えば、RUPのように、反復開発というよりもウォーターフォール型開発っぽいプロセスをやっていると思っていた。
この製品を使えば、Eclipseプラットフォームで、アジャイル開発を実践できるみたい。

興味を惹いたのは下記の2つの記事。

はじめて使うJazz (5) ― プロセス・エンアクトメント(1/6):CodeZine

(前略)
 ソフトウエア開発のプロジェクトにおいて「誰が、何をして、何を作成する」といった定義は開発プロセスと呼んでいます。通常プロジェクトを運用するためにさらにこれらに付随する「うまくいくための経験則」や、やってはいけない「べからず集」も含まれていることが多いものです。
 こうしたプロセスを、それを定義しただけの単なる読み物ではなく実質的な効力を持たせるようにすることをJazzでは、「プロセス・エンアクトメント(Process Enactment)」と呼びます。つまり、Jazzが狙っているのはツールがプロセス・エンアクトメントを実現し、開発者が自然とプロセスに従うようにするというものです。
(後略)

「プロセス・エンアクトメント(Process Enactment)」という言葉は初めて知ったけれど、感覚は分かる。
RedmineやTestLinkの機能に慣れると、プロジェクト管理やテスト管理はこういう風に実践するのがベストプラクティスなのだ、と分かってくる。
何故なら、OSSであるRedmineやTestLinkのそれらの機能は、世界中の開発者が実践してみて、より良いプロセスを実現するための機能であるからだ。

だから、自分たちの開発プロセスをツールに当てはめるよりも、一度頭を空にして、ツールがスムーズに使えるように運用した方が良いと思う。
そうすれば、自然にベストプラクティスが身に付く。

ツールがプロセスを改善してくれるのだ。

はじめて使うJazz (6) ― ダッシュボードでリアルタイムにプロジェクトの状況を見える化(1/4):CodeZine

(前略)
 ダッシュボードと聞いてすぐに思いつくのは車のダッシュボードでしょう。車を運転するために必要な各種情報が集められています。車のスピード、エンジンの回転数、ガソリンタンクの残量、走行距離、各種警告灯などです。例えば、ガソリンの残量があとどのくらいかを判断して、運転者はどのタイミングでガソリンスタンドに行くかを判断することができます。ここに表示される情報はリアルタイムの情報です。当たり前のことですが、運転者はこのデータが正しくまさに今のガソリンの残量を示しているから正しい判断ができるのです。もし、ダッシュボードに表示されるガソリンの残量が1日前のものだったらどうなるでしょうか?ダッシュボードではまだ残量があることが示されていますが、実際には既に残量がなく、ガス欠で車が止まってしまうという事態になってしまうでしょう。
 これをソフトウェア開発の現場に置き換えてみると、プロジェクト・マネージャが定期的にプロジェクトの状況を経営層やお客様に報告してさまざまな判断がされています。そのためにプロジェクトのメンバーが自分の作業をまとめてプロジェクト・マネージャに報告し、プロジェクト・マネージャがそれらを集計、グラフ化などを行うといったことが行われていると思います。これらの報告までの作業が1週間かかるとすると、1週間前の状況に対して判断することになります。これでは、プロジェクトがガス欠で止まってしまうという事態が起こる可能性があるかもしれません。
(後略)

PFでは「見える化」を実現するために三つのツールが用意されている。
それは、かんばん、ダッシュボード、あんどん。
ダッシュボードで良く出る例はバーンダウンチャート。
バーンダウンチャートを見れば、プロジェクトの進捗や今後の進捗も予測できる。

上記のように、ダッシュボードなどのツールは、プロジェクトの状態を計測する計測器。
車の運転席には速度メーター、ガソリンメーター、走行距離など各種計測器があり、ドライバーはそれを見ながら車の状況を把握する。
同様にプロジェクトも計測器が必要だ。
PMBOKの言うPMISは、単にプロジェクトのインプットとアウトプットを管理するシステムだけでなく、プロジェクトの状況を見える化するためのツールであるべきだ。

プロジェクトを見える化して、問題がどこにあるか分かれば、人は自然に解決の方向へ動き出す。
問題を解決しようと言う積極的な力は、人間に本来備わっているのだ。

ファシリテーションは、人間に本来備わっている能力を引き出すためのツール。
PF(プロジェクトファシリテーション)は、ITプロジェクトに特化したファシリテーションなので、アジャイル開発にも相性がいい。

ツールがプロセスもプロジェクトも改善してくれるきっかけを作り出してくれる。

| | コメント (0) | トラックバック (0)

2010/02/18

Redmineの語源は赤い地雷源

Redmineを書いているBlogをメモ。

【元ネタ1】
でぃべろっぱーってへてむる: Redmineの上手な使い方2(あえて最適化しない)

でぃべろっぱーってへてむる: Redmineの上手な使い方(チケット・フォーラムの切り分け編)

下記の運用方法が参考になる。

「Redmineを(開発プロセスに)合わせるよりも、(開発プロセスを)Redmineに合わせてみる」
「Redmineの得意分野を知っておく」
「(Redmineは)何をするか、しているか、したか、を見える化するツール」
「チケットを発行する前にフォーラムで話し合う」

Redmineの運用がスムーズになると、目に見えない秩序のおかげで開発チームが安定しているような感覚になる。
多分それがチケット駆動開発であり、そのプロセスを他人に説明できるレベルにしようと僕は試みている。

【元ネタ2】
でぃべろっぱーってへてむる: この夏おすすめのRedmineテーマ: watersky

このテーマは夏の海のようで綺麗。
夏になったら使ってみたい(笑)

【元ネタ3】
でぃべろっぱーってへてむる: Redmineの語源はRed Lineじゃないのか

Redmineの語源は「赤い地雷源」だと思う。
RedはRubyの赤色。
mineはWindowsのゲームであるマインスイーパーと語源は同じ。ロシアのWebサイトで赤い洞穴のアイコンがあって、それで初めて気付いた。
Redmineは元々BTSだったから、バグ(地雷源)をRailsで管理するシステムという発想からきたんじゃないのかな。

| | コメント (0) | トラックバック (0)

2010/02/16

TortoiseSVNの差分比較でWinMergeを使う

TortoiseSVNの差分比較でWinMergeを使う方法をメモ。

【元ネタ】
TortoiseSVNの差分機能は素晴らしい: プログラマの思索

TortoiseSVN の設定

WinMerge 2.6(日本語版)のインストール -- Subversion hacks / ファイルの比較・マージソフト"WinMerge(日本語版)"をインストールする方法

xdocdiff -TortoiseSVNでWord, Excel, pdfのdiffを見るツール-

TortoiseSVNのデフォルト機能では、Officeファイルの差分比較はTortoiseMergeが使われて、Officeの差分履歴機能を使って表示する。
確かに便利だけど、差分箇所が一覧で見えにくい。
Diffのようにテキストだけでいいから差分表示して欲しいから、差分表示はWinMerge、マージ機能はp4Mergeを使う設定にした。

この時、TortoiseSVNの差分ビューア欄の「高度な設定」で、docやxlsが拡張子の行を消せば、上記の設定が反映される。
この設定を忘れて、はまったのでメモしておく。

ちなみに、TortoiseHgでも、上記の設定は可能。
おかげで、MercurialでもOfficeの差分比較が可能になる。

TortoiseHgでExcelの差分を見る方法: プログラマの思索

WordやExcelで仕事している上司や事務の女性も、そして作家も編集者もデザイナーもTortoiseSVNに慣れて欲しい。
バージョン管理の発想の有無は、仕事の生産性に大きく直結するからだ。

| | コメント (0) | トラックバック (0)

2010/02/14

技術書をアジャイルに作る

技術書をアジャイル開発のように、プロセスを自動化して漸進的に作っていく記事を見つけたのでメモ。

【元ネタ】
Subversionのこと - Gakuya-ura.net

Geekなぺーじ : オーム社開発部での開発体制

Geekなぺーじ : オーム社開発部の方とのやり取り

主な流れは下記の通り。

原稿をSVNでバージョン管理
→Texコンバート、PDF出力はデイリービルドで毎日出力
→著者と編集者がレビューし合って、原稿にすぐに反映していく

まさにアジャイルだね。
プログラミングだけでなく、出版やポスター印刷なども全てアジャイル開発のプロセスを適用できるのではないだろうか?

PCを持つ一般人も、MercurialやGitとは言わずとも、SVNには慣れて欲しい。
TortoiseSVNという優れたWindowsクライアントがあるから、従来よりもバージョン管理が扱いやすくなっている。
バージョン管理、版権管理という概念は、現在では、デジタルメディアを扱う人にとって必須ではなかろうか?

| | コメント (0) | トラックバック (0)

Redmineのニコニコカレンダー・プラグイン

Redmine.JP | "Redmine" on Twitterで、Redmineのニコニコカレンダー・プラグインが紹介されていたのでメモ。

【元ネタ】
YukiKita's redmine_niko_cale at master - GitHub

ニコニコカレンダー

メンバーのモチベーションアップやチームの雰囲気の改善に関わる小物は、とても役立つ。
進捗報告のツールよりも、何よりも楽しい。
今度試してみよう。

| | コメント (0) | トラックバック (1)

2010/02/13

チケット駆動開発のスケールアップ

Redmineを大規模プロジェクトで使っている例を見たのでメモ。

【元ネタ】
複数プロジェクトとワークフローの設定について - Redmine Users (japanese) | Google グループ

上記のメールでは、下記の規模まで使っているらしい。

例1:
プロジェクト:12
ロール   : 8
ステータス :25
トラッカー :12

例2:
プロジェクト:200~400ぐらい
ロール   : いまのところ6個にしぼっているけど今後は20ぐらいになりそう
ステータス :6ぐらい
トラッカー :20以下

正直な感想は、すごい!の一言。
Redmineはおそらくこんな規模まで運用するとは想定していないと思う。

上記の問題点は、Redmineによるチケット駆動開発のスケールアップにある。
サブチームの数が無制限でも運用に耐えれるのか?という問題。

スケールアップはプロセスの標準化と密接に関係する。
そもそも1970年代にウォーターフォール型開発の論文が出てプロセスが提唱された理由の一つは、それまで職人芸で作られていたソフトウェア開発を、大規模なシステムでも開発できるように、スケールアップできるようにしたから、と聞いたことがある。
プログラムの規模、開発チームの規模、システムの規模、それらが大規模化した時、プロセスと言う共通のルールが無ければ、大規模なシステムは作れない。

TracやRedmineによるチケット駆動開発は、本来5人程度で1プロジェクトのタスク管理が発端だった。
そして、Redmineの複数プロジェクト機能を使えば、複数のサブチームのタスク管理も可能になる。
例えば、開発チームと問合せオペレータのチーム、開発チームとサーバー保守チーム、コンポーネント単位の開発チーム、など色んな観点がある。

だが、従来のRedmineではワークフローやロールまで大規模化するのは難しかった。
やはり、サブチーム特有のワークフローやロールはあるから、標準化しなければ、どんどん複雑化するからだ。

しかし、RedmineのVer0.9では、プロジェクトの階層が無制限になり、ユーザグループにも対応した。そして、Ver0.9.1のワークフロー設定画面では、トラッカーで使用されているステータスのみを表示させることもできるから、ワークフローの管理もやりやすくなった。

つまり、Redmineの最新バージョンでは、プロジェクト特有のワークフローやステータス、トラッカー、ロールを制御しやすくなっている。
棚卸しのための課題管理会議(CCB、CAB)を上手に運用できれば、単なる1プロジェクトだけではなく、社内全体の複数プロジェクトも管理できるようになるだろう。

Redmineはどんどんエンタープライズ向け機能で、スケールアップに力を入れているようだ。
大規模プロジェクトでのチケット駆動開発の運用について、色々考えてみたい。

| | コメント (1) | トラックバック (0)

2010/02/09

XP祭り関西2010~チケット駆動開発を用いたソフトウェア品質改善事例

XP祭り関西2010のTiDDセッションで小枝さんが講演された資料が公開されたのでメモ。

公開資料だけでは雰囲気が伝わりにくいけれど、小枝さんは物腰が柔らかく、現状のSW開発の問題点を的確に分析されていて、とても興味深かった。

・組込SW開発では、SW開発部隊以外にHW部隊や品質保証部隊など社内の別の部署と連携する必要がある。
 そのために、コミュニケーションがスムーズにいかない場合がある。
 
・「システムテストの手戻りが多い」という問題点を最優先に対処した。
・一部の協力会社の開発者は、製品知識が少ないので間違った理解で実装してしまうため、単体テストで防げない。
・多発する変更要求やバグを正確に開発者へ伝えるために、TiDDを採用した。
・BTSとしてMantisで運用した。
 Mantisは、ステータス別に色分けされるので、ぱっと見ただけで状況が分かる。
 新規(紫)や担当(黄色)が多い場合、チケットが未着手か遅延しているので、早急に対処が必要。
 解決(緑)が多い場合、テストやレビューで止まっているので、早急にリスケが必要。

・チケットにはバグだけでなく、仕様変更なども登録する。
 「仕様変更に対処しなかった」という意思決定の結果も残した方が後で役立つ。
・TiDDには、イテレーションのPDCAサイクルとチケットのPDCAサイクルがある。
 チケットのPDCAサイクルを早く回せば進捗がはかどる。

・チケットの粒度はプロジェクトに応じて変わる。
・細かいチケットになるほどチケットは溢れる。
 だから、ランクを付けて、ランクの順にチケットをこなす。
 例えば、100枚のチケットがある場合、10個ずつランク分けして、10個ずつ作業してリリースしていく。
 そうすれば、作業しやすくなるし、自然にアジャイル開発になる。

・チケットをイテレーションに割り当てて、約1ヶ月のサイクルで小刻みにリリースした。
 すると自然にアジャイル開発になった。
 開発にリズムが出て、開発者のモチベーションも向上した。

・TiDDで解決できない問題点もまだある。
  システム設計が不十分
  テスト技術力が低い
  要求管理が不十分

組込製品開発のように、多数の部署と連携しながら開発する場合、TiDDによって情報共有がスムーズになる利点がある。
しかし、TiDDはいわゆる下流工程では威力を発揮するが、上流工程のコントロールなどではその効果が得られない時もある。
それらは今後の課題と言えるだろう。

| | コメント (0) | トラックバック (0)

2010/02/08

Redmineチケットの関連リンク

Redmine.JP Blogに分かりやすい記事があったのでメモ。

【元ネタ】
チケット同士の関連づけ | Redmine.JP Blog

Redmineチケットで「関連する」リンクはよく使し、分かりやすい。
例えば、trunkへのマージ作業の発生元がリリースブランチの障害修正の場合、リリースブランチのチケットNoを「関連する」に追加する。
そうすれば、何故マージ作業を行うのか、担当者も理解しやすくなる。

しかし、それ以外の「重複する」「先行する」「ブロックする」は分かりづらかった。
チケット同士の関連づけ | Redmine.JP Blogを読んで、ようやく完全に理解できた。

「重複する」機能は、Mantisにも同等の機能があるので分かりやすい。
「重複する」リンクを使う場面は、いわゆる同件(同類)バグの場合があるだろう。
例えば、発見したバグをチケットに登録したものの、実は以前のチケットと原因が同じ場合、それら2つのチケットは「重複する」にすればいい。
但し、「関係元」を以前のチケット、「関係先」を後で発見したバグのチケットの関係にする必要がある。
そうすれば、「関係元」チケットが終了すれば、後で発見したバグのチケットも自動的に終了する。

「ブロックする」リンクを使う場面は、TestLinkのブロックのように、ブロッキングバグを登録する場合だ。
ブロッキングバグを解決しなければ、他のチケットも作業できず終わらない状態を表現する。
つまり、ブロッキングバグのチケットはプロジェクトのボトルネックであり、文字通りプロジェクトの進捗をブロックしている危険なチケットなのだ。
だから、優先度は「最優先」になっているケースが多いだろう。

「先行する」「後行する」リンクは、ガントチャートのスケジュールのFS関係を単に表現しているだけ。
作業が数珠繋ぎになっている場合、このリンクを使えばいいだろう。

チケットの関連リンク機能を上手に使えば、作業の見通しも良くなる。
しかし、使いすぎると運用が重くなるので、使う場面を限定してルール化すればいいと思う。

| | コメント (0) | トラックバック (0)

Excelのプロジェクト管理は何故良くないのか

XP祭り関西2010のTiDDセッションの感想を読んでメモ。

【元ネタ】
[TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば

2010-02-07 - winplusの日記

XP祭り関西2010に参加してきた - Basic

XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style

【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。

(前略)
それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。
この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。
倉貫さんの Excelならダメだが Googleスプレッドシートならいいという判断の根拠と、あきぴーさんのExcelでの管理を実施したときの問題点をぶつけていただけると、興味深いお話がうかがえたのではないかと妄想。
(後略)

Excelでのプロジェクト管理は今まで随分痛い目に遭ってきた(笑)

数年前まで、障害報告票をExcelで書いて、担当者が変わるたびに印刷しては判子で承認してもらい、エビデンスを印刷してホッチキスで止めていた。
フィードバックがあるたびに、障害報告票はどんどんかさばっていくし、余白に書ききれなくなる。
それら障害報告票は、共有サーバー上で一意の障害管理IDを発行して作られる。
更に、毎朝、リーダーがExcelマクロを使って、それら障害報告票の状態を集計して、進捗管理していた。
当然、更新漏れがあったり、共有ファイルの書き込みでロックがかかったり、壊れたりする場合、それだけで進捗が分からなくなる。
現在の進捗や課題を洗い出すだけで、たくさんの開発者の労力を消耗してしまう。

又つい最近まで、仕様の不明点はExcelの課題一覧で管理していた。
それら課題を洗い出した後、顧客に回答してもらい、課題一覧に書き込む。
しかし、回答してもらったからと言って、その回答を精査すると矛盾が出たりする。
過去の回答と矛盾が無いか、今上がっている課題は誰がボールを持っているのか、Excelでは把握しづらかった。
そもそもExcelでは全文検索しづらいし、仕様が多数のExcelファイルに散在していると、逐一目で追いかけないといけない。

Excelの仕様書もそう。
つい最近までExcelの仕様書も上記の管理ファイルも構成管理していなかったため、更新されるたびに「課題一覧_yyMMdd.xls」のようなファイルがどんどん増える。
誤って更新するとどのファイルが最新なのか、自分も分からなくなる。

【2】上記の経験を通じて、Excelのプロジェクト管理には下記の問題点があると思う。
一つは、作業のステータスが把握しづらいこと。そのために、最新化や集計が難しい事。

障害報告票の内容をBTSチケットに登録すれば、いつでもBTS上で作業状態を確認できる。
TiDDの運用ルールさえ徹底できれば、いつでもチケットは最新化されているから、形式上の進捗報告は必要ない。
そして、BTSの自動集計機能を使えば、進捗だけでなく工数や品質に関するメトリクスをいくらでも出力できる。
そのメトリクスを上手に使えば、プロジェクトの意思決定をサポートできる。

BTSチケットは障害だけでなく、SW開発の一般のタスクも登録すれば、その恩恵が受けられる。
この特徴がIssue Trackingと呼ばれるものだ。
そして、問合せもチケットに登録してしまえばいい。
問合せもその状態(ステータス)が重要であり、溜まった問合せチケットを集計すれば、傾向分析にも使える。
もう一つ嬉しい利点は、RedmineやTracには全文検索機能が付属しているので、過去の問合せの履歴を簡単に検索できる点もある。

もう一つは、Excelファイルがバージョンアップしていくものか、そのプロジェクト1回限りのものなのか、区別していない事。

ファイル名に日付を入れて更新するものは基本は、構成管理の対象であるべきだ。
特にExcelの仕様書は、たとえバイナリファイルであろうとも、SVNの配下に入れれば、過去の履歴をさかのぼる事ができる。又、TortoiseSVNの差分比較機能を使えば、Excelでも差分比較できる。
つまり、Excelの仕様書はソースと同じく、システムが生きている限りバージョンアップしていくべきなのだ。

逆に、そのプロジェクト1回限りのExcelファイルはBTSのチケットやWikiなどでWeb化すればいい。
例えば、Excelの課題一覧は、BTSチケットで管理すべき対象なのだ。
そうすれば、BTSの優れたプロジェクト管理機能のおかげで、進捗情報や作業履歴を簡単に管理できる。

そして、SCMにコミットする時にチケットNoを必ず書き込むルールを徹底すれば、仕様書もソースと同じく、成果物の変更をチケットと紐づけることができる。
これはまちゅさんは「No Ticket, No Commit!」と呼んでいる運用ルール。
このルールのおかげで、要件からビルドモジュールまでのトレーサビリティが実現でき、運用保守フェーズでリバースエンジニアリングする時に大いに役立つ。

上記の経験を通じて、Excelで管理しているプロセスは全てIT化できると確信している。
実際、我々が受託開発で顧客に提供しているWebシステムは、顧客がExcelを使っている業務を狙い打ちにしているからだ。


TiDDセッションでは、インパクトを与えられたと思うけど、聴衆からのフィードバックや議論ができる環境にすれば良かったなと思う。
今後の反省として生かしたい。

| | コメント (0) | トラックバック (2)

2010/02/07

XP祭り関西2010~元気が出るチケット駆動開発

さかばさんの発表資料が公開されたのでメモ。

【元ネタ】
元気が出るチケット駆動開発 - 補完型TiDDの経験 - @XP祭り関西2010: ソフトウェアさかば

パッケージ製品開発でTracをシステムテストで使った時に、TiDDを導入した話で非常に参考になる。
興味深い点は2つ。
一つは、TiDDを適用した工程をシステムテストに限定したこと。
懇親会でも質問を受けたけれど、プロジェクトでいきなり全ての作業をチケットで管理する運用は難しい場合もある。
その場合は、まず障害管理の一つのツールとして導入して、テスト工程をコントロールするのに注力すればいいと思う。
昨今の開発でBTS無しでバグを管理するのは非常に難しいからだ。
また、バグ管理の運用にメンバーが慣れれば、開発の作業や問合せもチケットで管理したくなってくるだろう。

もう一つは、TiDDを導入したら、開発チームの風通しが良くなり、メンバーが自発的になってきたこと。
バグや技術ノウハウの情報がBTSに一元化されるので、コミュニケーションの材料になる。
更に、チケットをToDo管理のように扱えば、忘れそうなタスクを一旦チケットへ起票して、後で精査する運用にもなる。
すると、メンバーが自分の作業の為にチケットを使うようになる。

BTSというツールとTiDDという運用ルールを上手に組み合わせれば、効果が上がる。
ノウハウが積極的に公開されるといいと思う。

【補足】
XP祭り関西のログは「#xpjugkansai」タグでTwitterで流れてます。
是非追いかけてみて下さい。
Twitter / Search - xpjugkansai

| | コメント (0) | トラックバック (0)

XP祭り関西2010~XPの10年を振り返る

XP祭り関西2010で基調講演した倉貫さんの発表資料が公開されたのでメモ。

【元ネタ】
XP祭り関西2010に参加しました - Social Change!

上記資料の29頁「Point of SalseからPoint of Useへ」のスライドがとても素晴らしい。
いわゆる受託開発は製造業の製品開発と同じく、買った時点が最高品質。手に入れた後は、減価償却という名のもと、価値がどんどん劣化していく。
クラウドを例とするソフトウェア開発は製造業と異なり、使いながら品質も価値も上がっていくスタイル。

これは、ソフトウェア開発の本来の性質を表している気がする。
ソフトウェアはバージョンアップしていきながら、品質も機能も使い勝手も上がっていく。
1回のリリースだけでソフトウェアが完結するわけではないのだ。
複数回のリリースを前提にソフトウェアを機能拡張していく開発スタイル、つまりアジャイル開発こそが、本来のソフトウェア開発である気がする。

MSのOffice製品もWindowsOSも十年以上の時間を経て、ようやく品質も機能も十分でこれ以上バージョンアップは不要という時代になったけれど。

今、2週目のアジャイル、Agile2.0と呼ばれている。
MSやIBMなどのツールベンダーも自社の開発支援ツールに「アジャイル」という言葉をキーワードにして販売しているけれど、何故今になってアジャイル開発が再び注目されるようになってきたのか?

今一度考え直してみたい。

【補足】
XP祭り関西のログは「#xpjugkansai」タグでTwitterで流れてます。
是非追いかけてみて下さい。
Twitter / Search - xpjugkansai

| | コメント (0) | トラックバック (0)

【公開】XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

昨日、XP祭り関西2010が無事に終了した。
多分150人近い参加者だったと思うので、大成功だった。
東京から長瀬さん、AgileJapanのebackyさんやミルズさん、日経BPの井上さん、XPJUGの倉貫さん、岡山からてつさん、福井から岡島さん。
東京や名古屋など遠方から結構な数の人が来てくれた。

関西はアジャイル開発のマーケットが十分にある手応えを感じた。

チケット駆動開発セッションも、懇親会で感想を聞くと評判が良かったみたい。
TiDDの事例や試行錯誤を聞けて興味深かったらしい。
実際にBTSを使っている人もいれば、今から試そうとしている人もいて、色んな観点で聞いていたようだ。

僕はWeb系開発でRedmine、さかばさんはパッケージ製品開発でTrac、小枝さんは組込製品開発でManitsを使って、TiDDを実践した事例を三者三様で話した。
僕も、二人の話は既に聞いていたけど、改めて聞き直すと、なるほどと思う部分が多い。

パネルディスカッションは、倉貫さんも交えて4人の体験談を話してみた。
倉貫さんが、RedmineでTiDDを実践するサイクルが遅いのでGoogleのスプレッドシートでタスク管理している、という話が出て盛り上がった。

でも、僕は納得していない(笑)
Excelの課題管理をGoogleのスプレッドシートでWeb化しただけで、Excelと何ら変りないから。
Excelでプロジェクト管理しているプロセスは、全てIT化できると確信しているから、WebでExcelを再現するのはおかしいと思っている(笑)

今日の評判を聞く限り、チケット駆動開発のマーケットも十分にあるみたい。
アジャイル開発が少しでも普及できればいいなあと思っている。

参加してくれた人達にありがとう!

昨夜の僕の発表資料を公開しておく。

【補足】
XP祭り関西のログは「#xpjugkansai」タグでTwitterで流れてます。
是非追いかけてみて下さい。
Twitter / Search - xpjugkansai

| | コメント (0) | トラックバック (2)

2010/02/05

Redmine運用例part3~OpenPNE3

Redmine.JP | Redmine on Twitterで、OpenPNE3が何故Trac+SVNからRedmine+Gitへ変更したのか、その理由と運用例が書かれていたのでメモ。
内容がとても素晴らしいので、共有する為に書く。
#下記は僕の想像の部分も含む。

【元ネタ】
【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループ

OpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking System

OpenPNE 3 - How To Report Issue (ja) - OpenPNE Issue Tracking System

バックポートとは 【backport】 - 意味/解説/説明/定義 : IT用語辞典

【提案】OpenPNE3 の BTS と SCM を Trac + SVN から Redmine + Git に変更する ([Suggestion] Switch the BTS and the SCM that are used for OpenPNE3, from Trac + SVN to Redmine + Git) - openpne-dev | Google グループの内容を整理すると、下記になる。

【1】Tracの問題点

(引用開始)
a. 多くの情報が OpenPNE2 向けのものであり、その大半が OpenPNE3 に適合していない

b. 情報が OpenPNE2 向けなのか OpenPNE3 向けなのかが判別できない

c. ドキュメントが多くなりすぎて管理できておらず、現状に追いついていない誤った情報であることが多い

d. チケットのキーワードに「確認中」「テスト待ち」などのステータスを設定し、進捗を把握しているが、独自の方法であり、外から見て状況を把握できなかったり、新規参加者が適切に使用できるようになるまで時間を要する

e. 複数のバージョンにまたがるチケットは、まず、現安定版の対応バージョンをマイルストンに設定し、その後、旧安定版、開発版の順でキーワードに対応バージョンを指定している。独自のレポートを用いてなんとか管理しているが、ルールが複雑でわかりにくい

f. e のような管理をおこなっている関係で、開発の進捗がロードマップから追えない(ロードマップに記録されるチケットはマイルストンにそのバージョンが指定されている物に限られるため)

g. チケットやレポートなどが全プロジェクトで共用である。そのため、ドキュメントやプラグインに関するタスクが OpenPNE3 本体のものと混在してしまい、扱いにくい

h. 標準で Subversion 以外の SCM を扱えず、それ以外の SCM で開発されているプラグインなどの管理がおこなえない

i. リモートのリポジトリの管理ができず、 GitHub など外部のリポジトリで開発されているプラグインなどの管理ができない
(引用終了)

要約すると、下記の問題点があったと言えるだろう。

1-1・旧来のTracでは情報集約できてない。
1-2・チケットのステータスを増やせないので、複雑なワークフローに対処できない。
1-3・Tracのバージョンとマイルストーン、ロードマップの機能だけでは、複数のブランチのタスク管理がやりにくい。
1-4・SVN以外のSCM(例:Git)が使えない。リモートのSCMリポジトリが扱えない。

【2】SVNの問題点

(引用開始)
A. 気軽に fork ができず、 fork 先での改善を fork 元にインポートするのは困難である

B. プラグイン開発などの途中で OpenPNE3 本体に問題を見つけた場合、コミット権限がなければ容易にフィードバックができない

C. すべてのコミットは公開されることを前提にしなければならない。たとえば実験的なコードの中に暫定的に生のパスワードを入れる必要があった場合、その実験段階のコードはコミットできないまま大きく膨れあがっていくという危険な状態になる

D. コミットの際に、元のコードの作者と取り込んだ作業者との区別が付けられず、すべて作業者の名前でコミットされてしまう

E. インターネットにつながっていなければコミットがおこなえない

F. リポジトリのサーバがダウンしていた場合にコミットがおこなえない
(引用終了)

要約すると、下記の問題点があったと言えるだろう。

2-1・気軽にタスクブランチやトピックブランチで実験(ハック)する事がやりにくい。
2-2・パッチを作っても、コミット権限が無いのでテストできず、フィードバックしにくい。
2-3・パッチ作成者とマージした人の区別が付かないので、作業履歴が分かりにくい

当然、Gitならば、上記の問題点を全て解決できる。

【3】Redmine導入による解決方法

(引用開始)
a, b, c・Redmineへ変更すれば解決できる

d・独自にチケットのステータスを作成できる

g・プロジェクトがウェブから複数作成でき、それぞれにチケットやレポートを作ることができるほか、チケットを他プロジェクトのチケットと関連づけることもできる

h・SVN, CVS, Git, Mercurial, Bazaar, Darcs などをサポートしている

i・リモートのリポジトリを扱える

e と f・現状の運用を、「開発版で対処してからバックポート用のチケットで取り込み作業をおこなう」という形に変更する
(引用終了)

要約すると、Redmineで下記のように解決する。

3-1・Redmineの複数プロジェクト機能などを使って、情報を整理する。
3-2・想定されるワークフローごとにステータスを追加する。
3-3・Redmineの複数プロジェクト機能を使って、ブランチのタスク管理を分ける。
 チケットに必ずリリース予定バージョンを付与すれば、バージョンをイテレーションと見なせば、機能拡張を小刻みにリリースできる。
 Redmineのロードマップは、バージョンをリリース後、変更履歴として自然に表示できる。
 更にや他のチケット集計機能を使えば、進捗や作業状態がリアルタイムに分かる。
3-4・当然、GitもMercurialなども使える。SVNならリモートもOK。

興味深いのはOpenPNE 3 - Ticket Workflow (ja) - OpenPNE Issue Tracking Systemにあるワークフローだ。

ステータスには「レビュー待ち」「テスト待ち」があるので、コードレビューやテストの作業担当者がきちんとアサインされていると推測される。
つまり、開発者とレビューイやテスターが別人なので、自然にオンラインのペアプロのような作業になる。
故に、二人の目による品質チェックが有効に効いているはず。

また、終了ステータスに「再現せず」「無効」「対応せず」という別のステータスがあるのも注意。
Bugzillaでもこれらのステータスは存在しているが、これらはRedmineのデフォルトステータスの「却下」に相当する。
つまり、別の理由で対処せずに完了にした事を意味する。
実際のバグ修正では、確かにバグもあろうが、再現できないバグのチケットはある一定期間が経ったら却下(再現できない・対応せず)する時もあるだろう。
あるいは、報告者がバグと報告しても、そのバグは仕様通りです、と却下(無効)する時もあるだろう。

ステータスを細かく分類しておけば、Redmineのサマリ欄でステータスごとのチケット数が表示されるので、リリース後に分析資料として使える。

又、トラッカー(ワークフロー)は、バグ・改善・バックポートの3種類がある。
「バックポート」という言葉は初めて知った(恥)

バックポートとは 【backport】 - 意味/解説/説明/定義 : IT用語辞典によれば「新しい機能などを古いソフトウェアに移植すること」。
例えば、trunkやタスクブランチなどで修正したパッチをリリースブランチにマージする作業をバックポートと呼んでいるのだろうと推測される。

普通は、リリースブランチ上で障害修正を施せば、必ずturnkにマージ作業が発生する。
しかし、セキュリティパッチなど安定性に関するバグ修正は逆に、trunkのような最新機能を持つコードラインからリリースブランチへマージされる時もあるのだろう。

その場合、「開発版で対処してからバックポート用のチケットで取り込み作業をおこなう」ワークフローなので、下記のタスク管理を行っていると推測される。

開発ブランチのチケットとリリースブランチにあるバックポート用のチケットを相互リンクしておく。

開発ブランチのチケットは終了ステータス

開発ブランチのチケットにあるリビジョンからパッチを作成

リリースブランチへ上記パッチを取り込む

古いバージョンでも動くように当然テストして、バグがあれば修正

バックポート用のチケットにパッチ取込のリビジョンが紐づけられる

レビューやテストが終われば、バックポート用のチケットも終了ステータスへ更新

つまり、各ブランチ間のタスクやマージ作業をチケットで管理することによって、作業漏れをなくす。
この手法によって、複数ブランチによる並行開発のタスク管理が非常にスムーズになる。

上記の運用ルールを読む限り、最近の開発スタイルに合った良い例だと思う。
今後、「Trac+SVN」から「Redmine+Git(Mercurial)」へタスク管理や構成管理を入れ替える運用例は増えるだろうと思う。

|

2010/02/03

アジャイル開発の本質は頻繁なリリースにある

アジャイル開発の本質はどこにあるのか?を考えてみた。
ラフなメモ書き。

アジャイル開発の特徴は一体何があるか?

それはタイムボックス形式で小刻みにリリースすること。
それは小規模リリース。
それは設計と開発に区別がないこと。
それは人を重視したプロセス。
それはリーン開発である。
それはテスト駆動開発である。
それは変化を受け入れるプロセスである。

色々言われているけど、本質は何だろうか?
僕は「頻繁にリリースできること」だと思っている。
技術・マネジメント・環境の3つの観点で考えてみた。

【技術】
以前に比べると、「頻繁にリリースできる技術」は確実に進歩している。
XPが生み出した継続的インテグレーション(CI)はその最たるものだ。

CIの本質は、常時リリース可能なコードラインを保持出来る点にある。
trunkをHudsonでワンクリックすれば、すぐにビルド&デプロイできるのだ。
Cobolやアセンブラの開発が主流の頃に比べると、ワンクリックでリリースできる技術が既にある。
従来は、手作業でビルドして、FTPでサーバーにアップして、サーバーを再起動する手間がかかっていた。

そのコードラインの品質を保持するための技術が、TDDでありリファクタリング。
頻繁にリリースするために、コードラインにたくさんの手が入り、強固なルールが無ければすぐに品質は劣化する。
だから、テスト駆動で開発するし、継続的にリファクタリングしてソースの品質を維持する。

昨今は特にソフトウェア構成管理(SCM)の技術革新の影響が大きい。
MercurialやGitのような分散バージョン管理のおかげで、ブランチ管理とブランチの品質維持がすごく容易になった。
そのおかげで、コードラインを特定の目的で使い分けることができる。
リリースブランチは障害修正だけで品質重視。
trunkは常時最新の機能を反映しておく。
タスクブランチやトピックブランチは、特定の目的のためにパッチを作るための一時的なブランチ、など。
それらのブランチは分散バージョン管理の優れた自動マージ機能ですぐにtrunkへ安全に反映できる。

だから、勇気を持って新機能を実験できるし、それをすぐにリリースして反映できる仕掛けがある。

【マネジメント・プロセス】
PMBOKもScrumもスコープ管理を重視する。

例えば、PMBOKの品質管理では、スコープ外の品質向上の作業は「金メッキ」と呼ばれて、けなされる。
Scrumでは、バックログを常に保守してリリース予定の機能を優先順位付けするし、スプリント計画を実行している間は、外部からチームへ割り込みの作業を許さない仕掛けがある。

Scrumの言う日次Scrumは、PFの朝会のようなものだ。
日次Scrumは、メンバーに自身の役割を自覚させるだけでなく、スプリントのゴールを共有し、スコープから外れないように意識づける仕掛けだ。
そして、日々の問題はScrumマスターが解決するように動く。

アジャイル開発は、繰り返し開発の一つ。
繰り返し開発には、漸進型開発(インクリメンタル)と反復型開発(イテレーティブ)の2種類があると思う。
漸進型開発が反復型開発よりも優れているのは、頻繁なリリースがあるために、自然にスコープに制約がかかること。
リリースが定期的にあるため、イテレーションを超えるスコープは実現できない仕掛けがある。
昔も今も、リリース作業は大変だから。

RUPのような反復型開発は、内部で繰り返し開発があるものの、最後の1回しかリリースしない。
だから、スコープがどんどん増えてしまい、WF型開発と何ら変わらない。
よくある失敗例は、設計工程だけ、開発工程だけ、などのように、工程ごとの繰り返し開発を実践して、スコープが発散してしまい、リリースには程遠い品質になってしまうこと。
「頻繁にリリースする」という小規模リリースの制約条件が、スコープの発散にたがをはめるのだ。

アジャイル開発を運用すると、当初見積もったタスクよりも作業は増える。
実際、Redmineの1個のバージョンに、WBSから落としたタスクを一括インポートするものの、バグが出たり、設計漏れが出たり、予期していない技術リスクが判明したり、当初予定しなかったチケットがどんどん増える。
だから、予定通りにリリースするには、チケットの整合性を図りながら、タスクを削ってリリースする時が多い。

これが本来のマネジメントなのだ。
そして、これが「変化を抱擁する」ことなのだと思うようになった。

【環境】
とはいえ、アーキテクチャや品質を度外視してリリースできるわけではない。
でも、以前に比べると、ソフトウェアを巡る環境が随分良くなってきている事実もあると思う。

まず、強力なフレームワークが普及したおかげで、アーキテクチャの作り込みに力を注ぐ必要が減った。
例えば、RailsやSeasarがあげられる。
これらのフレームワークのおかげで、アーキテクチャの開発は不要になり、アプリケーション層の業務ロジック実装に専念すればいい。
つまり、頻繁に変わりやすい業務ロジックやUIに注力すればいい開発スタイルが主流になりつつある。

また、安いHWのおかげもある。
HDDは壊れても取り替えた方が安い。
サーバーも安くなったので、スケールアップしやすいし、更には、仮想化技術を使って、開発環境そのものを仮想化できる。
仮想化された開発環境で何度もテストできる。

更に、頻繁にリリース可能なデプロイ環境が普及したこともある。
例えば、Webシステムならば、warファイルをデプロイするだけでリリースが終わる。
組み込み製品でも、例えば携帯電話ですら、ソフトウェアアップデート機能が標準化されたおかげで、アプリケーションを販売後に更新できるし、更にはROMすらもアップデート可能になった。
だから、ある程度の品質を確保できたならば、リリースを優先して、後から細かなバグFixしたソフトをバージョンアップする戦略も取れる。

これらを考えると、アジャイル開発しやすい技術やマネジメント、環境が普及して、より早くリリースできるようになったと思う。
昨今「2週目のアジャイル」「Agile2.0」と呼ばれるブームはそのような背景があるのかもしれない。

| | コメント (2) | トラックバック (0)

2010/02/01

Redmine for ITIL

ITILにRedmineを導入したソリューションサービスを展開している会社があったのでメモ。

【元ネタ】
Redmine for ITILの特長|ホロンテクノロジー[Holon Technology]--サービス&ソリューション--

サーバー監視ツールHinemosでエラー検知後、Redmineでインシデント管理するらしい。
OSSで固めているのが面白い。

統合運用管理ツール「Hinemos」が検知した事象発生から対処までの運用プロセスを一元管理します。 システムでの事象発生から対処、対処状況の管理までを一元管理が可能です。
ITILサービスサポートの各プロセス(インシデント管理、問題管理、変更管理)に基づいた運用プロセスの統制により、確実で正しい業務運用を支援します。
作業手順の標準化や役割を明確にすることで、IT運用プロセスの統制を図ることができます。

説明を読むと、下記の流れでRedmineを使っていると思われる。

Hinemosで障害を検知

→インシデント管理:Redmineのチケットへ障害内容を自動登録(スクリプトを自作している?)
→登録されたチケットをオペレータが確認する

→問題管理:オペレータがチケットを解決できないならば、開発チームや上司へエスカレーションする
→開発チームはチケットを精査し、既知の問題なら解決策を提示する。未知の問題ならば、是正対策を作り、CAB(変更諮問委員会)へRFC(変更要求)を送る。

→変更管理:CABは、RFCに対しリリース計画を立てて、作業の実施を開発チームへ命じる

→リリース管理:開発チームは、リリース計画に従って開発し、リリースする

Redmineのチケットに登録されると、サマリやチケット一覧、ガントチャートなどのチケット集計機能で作業状態をすぐに判別できる。
更に、チケットのトラッカーをインシデントの種類で区別すれば、各種のワークフローで作業を管理できる。

画面を見ると、トラッカーには「ハード障害」「ネットワーク障害」「アプリケーション障害」「操作ミス」「確認漏れ」などで分類されているので、それぞれのトラッカーに特有のワークフローがあるのだろうと類推される。
実際、障害に応じて、ハードウェアベンダーに問い合わせて解決する場合と、自社の開発チームに問い合わせて解決する場合は、ワークフローが明確に異なるからだ。

サマリを見れば、トラッカーの観点だけでなく、チケットの担当者やカテゴリ(おそらくインシデントの分類)、優先度などの観点でステータスごとに集計表示してくれているので、重宝するだろう。
ガントチャートを見れば、作業の進捗が一目で分かる。

更に、下記のチケット集計プラグインも使っているようだ。

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

チケットの累積数がインシデントの累積数に一致するので、時系列でインシデントの増減を一目で判別できる。
他にChartsプラグインなど各種のチケット集計プラグインがあれば、インシデントの傾向分析をすることもできるだろう。

僕もITILをRedmineに持ち込めると考えていたけど、既に製品化されていたのは驚いた。
誰でも似たようなことを考えつくのかもしれない。

ITILのプロセス関連図: プログラマの思索
TiDDにITILの概念を持ち込む: プログラマの思索

| | コメント (0) | トラックバック (0)

« 2010年1月 | トップページ | 2010年3月 »