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

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

【元ネタ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

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

【再考】TiDDのプラクティス集

チケット駆動開発を運用する上で、あった方がよいと思う運用ノウハウをプラクティスとしてピックアップしてみる。
なお、下記には、他の人のアイデアも含まれているので、引用先をリンクしておく。

【元ネタ】
脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

チケット駆動開発のベストプラクティスを収集したい: プログラマの思索

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

チケット駆動開発 - Live a meaningful Life

チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)

2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記

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

[tech]チケット駆動開発 - Kazumi007の日記

１・チケット・ファースト(Ticket First)

プロジェクトの作業はチケットを受け取ってから始める。
作業が発生したら、まずチケットに起票してから始める。
このルールが徹底されて初めて、チケット駆動開発が始まる。

そして、チケットはXPのタスクカード(作業指示書)として扱う。
すると、チケットに作業履歴が残り、運用保守で検索しやすくなる。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

チケットを成果物の単位で作ると、作業しやすくなる。
例えば、「設計書を作る」「機能Aを作る」「バグを直す」「テスト仕様書を作る」など。
つまり、チケットはWBSから作り出すこともできる。
この手法はPMBOKにも流用可能のはず。

２・チケットはシンプルに

チケットの入力項目やワークフローは必要最低限にし、シンプルにしておく。
チケットに必須項目や入力項目が多いと、開発者がチケットの更新に億劫になり、チケットに最新の状態が反映されなくなってしまう。
特にワークフローが複雑な場合、メンバーが慣れるのに時間がかかり、TiDDの威力が半減する。

リリース後のKPTによるふりかえりMTが、チケットの運用を見直すタイミングになる。
リリースをこなしながらチケットを改善していけばいい。

３・分割統治(Divide and Conquer)

プログラミングと同様に、タスクは分割して統治する発想が大事。
複雑なタスクはWBSでツリー構造に階層化したり、分割する。
この時、分割統治の観点として、チケット・イテレーション・プロジェクトの3つがあると考える。

3-1.チケットで分割統治

僕の経験では「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化するのが良いと思う。

実際は、リリース後にチケットを集計してみると、チケット1個の工数は1人日以下になっている時が多いと思う。
理由は、新規開発後のテストでバグ修正や、顧客からの問合せ(障害修正・改善要望)など、開発チームが予想していたタスクの規模を超える時が多いから。
タスクが増えすぎた場合は、小規模リリースやチケットの関連付け、他の分割統治のプラクティスで対応する。

又、遅延したチケットは作業しやすいように分割した方がいい。
例えば、機能追加のタスクなのにリファクタリングに時間がかかっているチケットは、リファクタリングと機能追加のタスクに分ける。
開発者が作業しやすいように、コミュニケーションを取りながら、臨機応変に行えばいい。

他に、GitやMercurialのような分散バージョン管理を使っているならば、2009-09-17 gitだからこそできるチケット駆動開発のやり方- kunitの日記のように、チケット単位でトピックブランチを作る運用方法もあるだろう。

3-2.イテレーションで分割統治

細分化されたチケットは、リリース計画やイテレーション計画に基づいて、各イテレーションにアサインされる。
チケット駆動開発やRedmineでは、イテレーションをリリースバージョンと同一視するため、小規模リリースを実現でき、自然にアジャイル開発になる。
チケットをどのバージョンでリリースするか、という取捨選択や、イテレーション内部でのチケットの優先順位付けがプロジェクトマネジメントそのものになる。

アジャイル開発と同様に、チケット駆動開発でも、イテレーションを上手に使うのが重要だ。
僕がよく使う手法として、バージョンと対応されない特別なイテレーションとして、「バックログ」や「内部課題」を作っている。

「バックログ」は、顧客から寄せられた改善要望のチケットを貯めるイテレーション。
例えば、リリース直後に寄せられた膨大な改善要望は、バックログに溜め込んで保留とし、障害修正など、本番運用の安定に力を注ぐ。
そして、本番運用が落ち着いたら、バックログに溜まったチケットの難易度や優先度、予定工数などを洗い出し、リリース計画を立てて、チケットを各イテレーションへアサインしていく。

つまり、「バックログ」はScrumのプロダクトバックログのように、要望を一旦受け付けてフィルタリングし、リリース計画を立てる場とする。
即ち、XPの計画ゲームをバックログのイテレーションで行っているようなものだ。

又「内部課題」は開発者から寄せられたチケットのうち、優先順位が低い作業やいつやるか未定の作業を溜め込むイテレーション。
例えば、このソースはリファクタリングした方がいいが今手を付ける必要はない、とか、だいぶ先の予定作業などの備忘録。
そして、リファクタリングした方がいい機能を修正するタイミングで、進行中のイテレーションへチケットを移動して、リファクタリングも同時に行う。
あるいは、来るべき時が来たら、チケットをイテレーションへアサインしていく。

つまり、「内部課題」は開発チームのリスク管理を行うイテレーションだ。
「内部課題」のイテレーションを備忘録として使い、作業漏れをなくす。
特に、リファクタリングが必要な箇所はファウラーが言う技術的負債そのものだから、工数見積もりのリスクに直結する。
故に、システムのリスクに直結する情報は積極的にチケットへ登録する雰囲気作りが重要だと思う。

「バックログ」も「内部課題」も終了期限の無い特別なイテレーションとして扱うのに注意。

3-3.プロジェクトで分割統治

プロジェクト単位でチケット管理する状況は、顧客からの問合せと開発のタスクを分けたい時が多いだろう。
つまり、インシデント管理と実際の開発は、BTSの複数プロジェクト機能を使って、プロジェクト単位で管理する。
この方法によって、開発チームは、開発と無関係なインシデントのチケットを意識することなく作業すればいい。

他の例としては、大規模プロジェクトで、サブチームごとにタスク管理したい場合や、サブシステムやコンポーネント(jar, dllなど)の単位でタスク管理したい場合があげられるだろう。

４・No Commit, No Ticket

TiDD提唱者のまちゅさんが「チケット無しの成果物のコミットは不可」というルールをこのプラクティスで呼んでいたので、引用させてもらった。
チケットファーストのルールに従うと、必ずコミットする時にチケットNoは存在する。
つまり、修正意図の不明なコミットを排除する意味が込められている。

このルールのおかげで、運用保守時にリバースエンジニアリングしやすくなる利点がある。

５・チケットは常時最新に

八朔さんがTiDDで最も重要だと述べたプラクティス。
チケットに登録したとしても、進捗や情報が更新されないと、BTS上で最新の進捗情報を確認できなくなる。
特に、リリース直後に問合せや障害が大量に発生して、チケットが乱発されたり、放置されたりする時に起きやすい。

だから、チケット管理の責任者が常にチケットの状況を見ておく必要がある。普通はプロジェクトリーダーがその役割を担っているだろう。
大規模プロジェクトでは、専門のチケット管理者を配置して、進捗確認させるといいだろう。
また、チケット更新やSVNコミットのタイミングで関係者へメール送信する機能を使えば、気付きやすくなる。

他に、RedmineやTracでは、活動欄でSVNリポジトリ・チケット更新・Wiki更新などの履歴が表示されるので、最新情報を見る事ができる。
故に、活動ログの活発具合が開発チームの活発度に直結するので、注意した方がいい。

６・チケットは関連付ける

八朔さんの運用方法では、チケットは、要件-成果物-作業のツリー構造で関連付けられる。
このやり方ならば、チケットをタスクカードだけでなく、ストーリーカードとして扱う事もできる。

あるいは、複雑な機能を実装するチケットを分割した場合、関連するチケットをまとめるために、Redmineの関連リンク機能を使えばいいだろう。

僕がよく使う方法は、マージ作業が発生した場合、マージ作業のチケットに発生元のチケットを関連リンクさせておく。
これによって、マージ作業の意図を関連元のチケットから理解しやすくなる利点がある。

７・小規模リリース(Small Releases)

チケット駆動開発では、リリースバージョンをXPのイテレーション、Scrumのスプリントと同一視してアジャイルに開発していく。

RedmineやMantisでは、ロードマップ画面がイテレーション計画を行う機能になる。
そして、リリースされたイテレーションに紐づくチケットは、変更履歴画面でChangeLogとして残る。
この2つの機能おかげで、BTS上でリアルタイムに進捗情報や、リリース履歴を簡単に確認できる。

８・朝会

チケット駆動開発を実践すると、自然に朝会をするようになった。
朝会でロードマップ画面を見ながら、誰がどのチケットを担当していて、進捗が遅れているなら何が問題なのか、を議論する場になる。

朝会は、コミュニケーションが始まる場であり、リスク管理を行う場でもある。

９・ペア作業

Redmineの柔軟なワークフロー機能を使っていると、チケットは必ず2人の手を経て終了するようになった。
例えば、チケットを終了できる権限はプロジェクトリーダーのみとし、彼が承認したら終了できる。
あるいは、バグ修正のチケットは、開発者とテスターが交互にステータスを更新しながら検証していく。

XPのペアプロと異なるが、1枚のチケットを2人以上の手が加えられているので、ペア作業と呼んでいる。
ペア作業の利点は、自然な品質チェックと、自然なペアプロ。

１０・ふりかえり(Retrospect)

チケット駆動開発を実践して、イテレーションをリリース後、自然にふりかえりMTを行うようになった。
KPTで行ってみると、開発者も管理者も色んな思いが出てくる。
バグが多かった、無事に終わったけれどこうすればもっと良かった、このプロセスがやりにくかった、など。
チケット集計結果を見ながらKPTすると、チケットやワークフローの運用改善のアイデアが出てきて効果的。

他にも色々あると思うので、収集してみたい。

アジャイル開発と品質管理の関係

「アジャイル開発はMTTRを重視している」指摘を受けたのでメモ。

【元ネタ】
MSDN：可用性の概要

平均故障間隔 - Wikipedia

平均修復時間 - Wikipedia

ソフトウェアやハードウェアの信頼性や可用性に関する用語として、MTBF・MTBR・稼働率などがある。

MTBF＝稼働時間/稼動回数
MTBR＝修理時間/故障回数

稼働率＝MTBF/MTBF+MTBR
故障率＝1/MTBF

MTTRは可用性、MTBFは信頼性・障害密度に密接に関係するのは周知の通り。

MTBFが大きいほど信頼性は高いが、ソフトウェアのMTBFは格段に小さいように思う。
SRATS:Software Reliability Assessment Tool on Spreadsheet Softwareのサンプルでも、MTBFはわずか16時間に過ぎない。
つまり、16時間後には必ず障害(バグ)が出る。

しかし、MTTRが「0」に近ければ、信頼性が低くても稼働率は100％に近くなる。
つまり、バグ修正工数が少ないほど、ユーザ側から見るとシステムはずっと稼動しているように見える。

アジャイル開発で、「開発の一番重要なファクターは時間である。平均バグ修正時間をみれば品質がわかる」という話を聞いた。
つまり、アジャイル開発ではMTTRを重視している、と。
確かにそうだろうと思う。

リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性を高めてソースを修正しやすくすることにつながる。
つまり、バグ修正工数と言うMTTRを短くすることにも注力していると言っていい。

Googleでも、サーバーは故障するものであり冗長化することに力点を置いているという話もある。
極論な話だが、HDDが1時間に1回壊れたとしても、予備のHDDにすぐに取替えできるならば、問題ないという考え。
つまり、MTBFが小さくてもMTTRがほぼ0ならば、実際のシステムの利便性は問題ない。

システム開発でもそうだ。
度重なる機能改善やバグ修正があったとしても、修正工数を小さくできる余裕があるならば、自信を持ってプログラミングできる。
つまり、保守性が高く、可読性の高いシステムならば、どんどん機能改善できる余裕が出てくる。
すなわち、アジャイル開発と相性がいい。

プログラミングの保守性を高くする為のノウハウがGoFのデザインパターンでもある。
マネジメントのノウハウとしては、イテレーションという単位にシステム開発を分割して、スコープを制御する事によって、システムの安全性と継続性を重視する選択肢も取れる。

アジャイル開発と品質管理の関係についても色々考えてみたい。

TiDDにITILの概念を持ち込む

チケット駆動開発にITILの概念を持ち込めるか、考えた事をメモ。

【元ネタ】
サービスサポート - Wikipedia

ITILのプロセス関連図: プログラマの思索

ソフトウェア保守 - Wikipedia

XDDPの資料リンク: プログラマの思索

初心者歓迎！　ITIL連載講座：ITILの成り立ちと現状を知る (1/2) - ITmedia エンタープライズ

【1】ITILはIT運用プロセスのフレームワーク。
PMBOKと並んで、管理者がマスターすべきマネジメントツールだろう。

Itilプロセスフロー

View more presentations from akipii .

昨今のITの問題として、運用保守の作業負荷が増大している点が一番にある。
流行の早いWebシステムであろうとも、数年前に作ったシステムのアーキテクチャが時代に合わずに古くなっても運用せざるを得ない。
稼働中の古いシステムで、ユーザ企業は実際の業務をこなし、売上を上げているからだ。

そんな状況で、保守という名前でどんどん機能追加してシステムが不安定になったり、スケールアップが難しくなり、マンパワーでカバーするなどの問題点が噴出する現場が多くなっているだろう。

上記の問題に対し、ITILの利点は、運用保守や派生開発に応用可能で効果的な点だと思う。

運用保守の観点では、問題管理とインシデント管理を区別している点が重要だ。
つまり、障害の調査と根本対策を立てる問題管理と、ユーザから障害だけでなく改善要望や単なる使い方の質問までをサービスデスクで管理するインシデント管理はきちんと区別する。

例えば、「Webにログインするパスワードを忘れた」というユーザの質問に対しては「パスワードリマインダーを使って下さい」と回答すればいい。
この質問は障害ではなく、マニュアルを見れば、サポートデスクの女性がすぐに対応できる。

インシデント管理がしっかりすれば、開発部隊やサーバー保守部隊は、引っ切り無しにかかってくるユーザの電話から解放される。
インシデント管理で対応できなかったインシデントに対してだけ、エスカレーションして問題管理で対応すればいい。

派生開発の観点では、変更管理とリリース管理を区別している点が重要だ。
清水吉男さんが提唱する派生開発のプロセスXDDPでは、是正保守と改良保守(適応保守)を明確に区別する。
つまり、いわゆるバグ修正である是正保守と、ソフトウェア訂正ではないまったく新しい機能追加である改良保守は、開発プロセスがそもそも違うのだ。
例えば、携帯電話にカメラやお財布ケータイの機能を追加していくのは、どう考えても障害修正ではないのだ。
しかし、この例のような派生開発をきちんとした開発プロセスで行っている現場は少ない。

ITILでは、変更管理でRFC(変更要求書)を作り、RFCをCAB(変更諮問委員会)が精査して、設計・開発・リリースの計画をまず立てる。
そして、変更管理で作られた計画に従って、リリース管理のプロセスで実装してリリースしていく。

清水吉男さんが提唱する派生開発プロセスXDDPは、この変更管理のプロセスや成果物がしっかりしているので、特に組込み製品の企業がよく使っているのだろうと思う。

【2】改めて、ITILのプロセス群(特にサービスサポート)の目的をサービスサポート - Wikipediaから引用する。

１・インシデント管理･･･迅速なサービスの復旧を行い、企業が行う事業活動への影響を最小限に抑える
２・問題管理･･･インシデントや障害原因の追究と対策および再発防止策の策定を行う
３・構成管理･･･ITサービスの構成アイテム（CI）情報の精確な収集、認識と収集した情報の維持管理および確認・監査を行う
４・変更管理･･･CI情報の変更を安全確実かつ効率的に実施する
５・リリース管理･･･変更管理プロセスで承認された内容を本番環境（ITサービス提供媒体）に正しく反映させる為の作業（リリース作業）をコントロールする
６・サービスデスク･･･ITサービスを提供する組織とITサービスを利用する顧客の窓口的役割を担い、インシデント対応などのサポート業務を行う

チケット駆動開発のインフラであるBTSやSCMは、問題管理や構成管理を本来サポートしている。

ITILのプロセスをチケット駆動開発にのせられれば、BTSを問題管理以外のプロセスにも応用できる。
つまり、システムテストの障害管理だけでなく、日々の運用保守や新規開発、リリース作業の管理にもチケット駆動開発を応用できるだろう。

例えば、インシデント管理で、ユーザからの日々の問合せを、障害や改善要望などのカテゴリでフィルタリングし、システムを修正する必要のある要求はScrumのプロダクトバックログに詰め込む。
実際は、バグ修正のタスクと区別したいので、インシデント用のプロジェクトとワークフローを作って管理すればいいろう。
即ち、Redmineの複数プロジェクト機能、柔軟なワークフロー管理機能が必要になる。

例えば、変更管理では、変更要求をRFCとしてまとめて、CABは開発部隊だけでなくサーバー保守部隊やユーザの情報システム部門から構成して、RFCの精査やリリース時期の判断を下す。
そして、リリース管理では、RFCに従って、開発者がソース修正し、テスターが検証し、ライブラリアンがリリース作業を行う。

実際は、RFCにある要求をストーリーカード、RFCに基づく作業をタスクカードできちんと管理すればいいだろう。
そして、開発者・テスター・ライブラリアンの作業はチケットの属性によって使い分ければいい。
即ち、チケットの親子関係・柔軟な属性カスタマイズの機能が必要になる。
RedmineやTracにあるガントチャート・カレンダー・工数集計・バーンダウンチャートなどの多様なレポート機能があると、進捗管理が更にやりやすくなるだろう。

上記の思索を考えると、ITILのプロセスはチケット駆動開発と相性が良いと思う。
RedmineやTracをBTS(Bug Tracking System)だけでなく、ITS(Issue Tracking System)へ拡張する発想とITILがすごく相性がいいからだ。

同様に、PMBOKもチケット駆動開発に載せる事ができるか考えてみたい。
PMBOKはプロジェクト管理のフレームワークであり、その特徴は、リソース管理、コスト管理に優れている点にあると思う。
RedmineやTracの優れたレポート機能がPMBOKの概念の実装を補完してくれるはずだ。

redmine_chartsプラグインでバーンダウンチャートは表示可能

下記プラグインをインストールしてみたら、バーンダウンチャートの表示が可能だけでなく、機能が豊富でとても素晴らしかった。
以下メモ書き。

【redmine_charts】
Redmine - PluginCharts - Redmine

mszczytowski's redmine_charts at master - GitHub

pullmonkey's open_flash_chart at master - GitHub

【インストール方法】
$redmine/vendor/plugins へredmine_charts、open_flash_chartのフォルダを解凍して配置する
※open_flash_chartフォルダがないと、redmine_chartsが動作しない。
↓
rake db:migrate_plugins RAILS_ENV=production
↓
ruby -Ku script/server -e production -d
で再起動
↓
プロジェクト設定画面で、「チャート」をチェックしたらOK

【redmine_chartsプラグイン感想】
redmine_chartsプラグインは日本語化されており、初期表示で下記の説明があるので、一目で機能が分かる。
但し、redmine_chartsプラグインをフルに使うには、チケットに開始日・終了日・予定工数・見積工数・作業分類がきちんと入力されているのが前提になるので注意。

１・バーンダウン
見積もり、経過および残りの時間を表しています
２・記録時間割合
時間はメンバ、チケット、活動、カテゴリごとに分類およびフィルタした記録時間の合計に比例しています
３・記録時間予定
メンバ、チケット、活動、カテゴリごとに分類およびフィルタして時間経過を表しています
４・記録時間分布
各チケットの見積時間と記録時間と残り時間の割合を表しています。この割合は100%以下になるべきです。見積時間のあるチケットのみ表示しています。左端に表示しているバーはこのプロジェクトの平均値を表しています。

redmine_chartsプラグインがあれば、Tracのレポート機能と同等か、それ以上の運用が可能になるだろう。
このプラグインもRedmine運用で必須のプラグインだろう。

【redmine_version_gantt_chart】
Downloads - version-gantt-chart - Project Hosting on Google Code

２つめブログ バージョンガントチャートPlugin 0.1 完成

【redmine_version_gantt_chartプラグインの概要】
(前略)
Redmineに登録したチケットとバージョンの情報から、
開発者ごとの作業負荷とタスクの進捗状況をざっくりと確認できるプラグインをつくってみました。
標準のガントチャート表示機能は綺麗に表示できるんだけど、開始日と期限日の入力と更新が面倒で使わなくなってしまった。
なので、できるだけ「少ない入力項目」で、「大雑把な進捗」を確認できるものを目標にしています。
(後略)

【redmine_version_gantt_chartプラグイン感想】
ガントチャートで開発者の負荷をざっくり見れるので、マネージャと言われる人達に最も受けそうなプラグイン。
プロジェクトの進捗をバーンダウンチャートだけでなく、ガントチャートなど色んな観点のメトリクスで出力できれば、リスクに対して早期に是正対策を採りやすくなる。

【Estimate timelogプラグイン】
r-labs - Estimate timelog - Redmine
Redmineで予定／実績レポートを表示するプラグイン【estimate_timelog】を作ってみた - へたれエンジニア日記 ver.2

工数集計画面で、予定工数と実績工数をユーザごとに集計表示してくれる。
予実比較はマネジメントの基本だから、とても貴重。

Redmineのレポート機能も、世界中の開発者のおかげでTracと同等か、それ以上まで機能改善されている。
短期間でRedmineが改善されている原因は、チケットという情報がDBで一元的に管理されていて、Railsという優れたフレームワークのおかげでプラグインで機能追加しやすいからだろうと思う。

それから注目すべきは、優れたRedmineプラグインの開発者に日本人がチラホラのっている事だ。
日本でもRedmineユーザが増えている証拠なのかもしれない。

Redmineのプラグインに関しては、今後も試したものについてはフィードバックしていきたい。

【公開】SPES2009、SQIP2009の論文資料

チケット駆動開発の情報を今後のリファレンスとして使いたいため、SPES2009、SQIP2009の論文資料を下記に公開する。
但し、著作権は「作成者がAll Rights Reserved」としているため、閲覧のみでダウンロード不可にしているので注意。
下記資料を引用する時は、必ず参考文献にリンク先を明示して下さい。

【SPES2009】
「SPES2009 (Software Process Engineering Symposium)」(2009/7/16-17開催)

SPES2009経験論文～チケット駆動開発：BTS によるアジャイル開発の改善

View more documents from akipii .

【SQIP2009】
日科技連 | ソフトウェア品質 | 第28回 ソフトウェア品質シンポジウム2009（SQiP(スキップ)シンポジウム）(2009/9/9-11)

「チケット駆動開発- BTSでExtreme Programmingを改善する-」(経験論文)

SPES2009、SQIP2009の論文概要ともに、「チケット駆動開発によるアジャイル開発のプロセス改善」と似ているが、提示した問題については若干変えているので、注意して読んで欲しい。

【注意】
チケット駆動開発は、まちゅさんの発表「チケット駆動開発 … ITpro Challenge のライトニングトーク (4)」が発端にある。

yet another TDD

View more documents from Kohei MATSUOKA.

これらの経験論文の元ネタは、TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかばの論文「TiDD：チケット駆動によるアジャイル開発法」(PDF)にある。
ソフトウェアさかば: チケット駆動開発も合わせて読むと、チケット駆動開発の全貌が分かるだろう。

パッチベースのワークフロー

オープンソースではパッチベースのワークフローがあるという記事をメモ。

【元ネタ】
gitster's journal - 入門Gitの目次はというと

入門Git - idesaku blog

2009-10-11 - 未来のいつか/hyoshiokの日記

gitster's journal - 入門Gitの目次はというとで、下記の文章が目を引いた。

第十章ではじめて、オープンソースの世界で多用されるパッチ・べースのワークフローを登場させた。
会社で仕事に使うだけ、というユーザには馴染みのないワークフローと考え方だと思うので、パッチ・べースのワークフローを使わない向きは飛ばして貰っても、本の他の部分を読むのには全く問題がない。
そのかわり、ボクがこれまでLinus君と一緒に仕事をしてきて学んだ、オープンソースコミュニティで生きてゆく際のコツ、といったものを「オープンな開発プロセス」という一節としてこの章に加えることにした。
ボクの経験が、少しでもオープンソースに関わる人たちに役に立ってくれると良いな、という考えからだ。

入門Gitは今予約中で読んでいないので、以下想像した事をメモする。
＃間違っていたら後で直す。

上記の言うパッチベースのワークフローは下記の意味だろう。
オープンソースコミュニティできちんと管理されているシステムのソースコードは、必ずコミッタが厳重に管理している。
ユーザが機能追加やバグ修正したソースを反映させたい時、パッチを作ってコミッタに送る。
コミッタはそのパッチをレビューして、フィードバックし、OKならコミットする。

このワークフローは実は、ReviewBoardやRietveldなどのコードレビューシステムと同じだ。
つまり、パッチベースのワークフローの目的は、コードレビューによる品質チェック、開発者同士の暗黙知の共有を指すと思われる。

普通のSIでは、上記のようなワークフローを持ったコードレビューは持っていないのではないか？
実は、オープンソースの方がはるかに高品質な開発プロセスを持っているのではないか？

また、パッチベースのワークフローをGitやMercuiralのような分散バージョン管理が補完している特徴も見逃せない。
マスタリポジトリはコミッタしか変更できないが、開発者は自分の好きな場所でリポジトリをコピーできてハックできる。しかも、マスタリポジトリから即座に最新ソースをマージして、常に最新バージョンにできる。
この分散バージョン管理におけるトピックブランチの仕組みが、パッチベースのワークフローを簡単にさせているのだろう。

GitもTortoiseGitがかなり機能改善されたので、TortoiseHgと比較しながら使ってみたい。

Webシステムのリリース作業とフォールトトレランス

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」を読んで、Webシステムのリリース作業の大変さ、非機能要件における性能・稼働率についてあれこれ考えた。
フォールトトレランスとリリース作業に関するメモ書き。

【元ネタ】
フォールトトレランス

フォールトアボイダンス

フォールトトレランスの定義と具体例が理解しやすい。

フォールトトレランス(耐障害性)とは、「失敗や障害が起きることを見越して、どんな事態に陥っても全体としての機能を失わないようにすること」です。
フォールトトレランスを実現する方法は下記の通り。

フェールソフト(周辺故障)とは、「システムが誤動作をしたり部品が故障したりしても、機能を完全に停止するのではなく、可能な範囲で稼動させること」
フェールソフトは継続性を重視しており、フェールオーバーを含むこともあります。

フェールセーフ(安全側故障)とは、「システムが誤動作をしたり部品が故障したりしても、安全側に制御すること」です。
フェールセーフは安全性を重視しています。

フェールオーバー(冗長性故障)とは、「設備を必要最小限よりも多く用意して、システムを冗長（リダンダント）化させて障害に備えることにより、フェールソフトを実現すること」。
フェールオーバーは継続性を重視しています。

フールプルーフ(誤操作対応)とは、「利用者が操作や手順を間違えても、危険を招かないように設計すること」です。
フールプルーフは安全性を重視しています。

フォールトアボイダンスとは、「失敗や障害の要素を完璧な精度にしたり十分に訓練したりして、失敗や障害を発生させないようにすること」です。
フォールトアボイダンスは古典的な手法ですが、「人間は間違いを犯す」という思想が広がり、フォールトアボイダンスだけでは不充分なため、現在はフォールトトレランスに重点を置くことが主流になっています。

リリース作業中、あるいは運用中でもシステムが障害を起こしてしまう時はある。
フォールトトレランス(耐障害性)を実現する4種類の方法は、障害が起きてもそのダメージを少なくする為のノウハウだ。

そして、特に組込み機器ではそれらの機能も実装する必要があるため、余分な開発工数をあらかじめ考えておく必要がある。

昨今のWebシステムでも、そのリリース作業は、10年前よりもはるかに高度になっている。
リリース中もシステムをダウンさせない手法が一般的になっている。

昨今の普通のWebシステムは、WebサーバーもDBサーバーも複数のサーバーへ物理的にも論理的にも冗長化されている。
その場合、ロードバランサによって、負荷に応じて各サーバーへ振り返られている。

昔のWebシステムのリリース作業は、手間が多かった。
まず、システムを停止し、アプリケーションを1個ずつデプロイし、Webサーバーを再起動する。
Javaならば、warやjarではなく、classファイルを1個ずつFTPでアップしていた。
更に、JSPは初回表示が遅いので、Webサーバー起動後、各画面を表示してJSPをリコンパイルさせていた。
だから、そのリリース作業中の数時間はWebサイトが使えません、とあらかじめユーザへ連絡する必要があった。
ユーザ企業としては、システムのダウン中はシステムから売上が出ないから、リリース作業と言えどもダウン時間が長いほどダメージは大きい。

それに対し、最近のWebシステムのリリース作業は下記が普通だ。
リリースする順番ごとに各サーバーをWebから切り離し、バックグラウンドでアプリケーションをデプロイして再起動していく。
リリースできたら、ネットワークにつなげて、次のサーバーへリリースしていく。
この手法ならば、ユーザ側からは、システムがずっと稼働中でダウンしているようには見えない。

情報処理試験にある信頼性の問題(午後1・問4)にもあるように、Webシステムの障害を検知する仕組みも以前に比べると洗練かつ複雑になっている。
Webサーバーの障害を検出する機能として、ヘルスチェックがある。
ヘルスチェック機能は、ping監視という最も基本的な方法から、ポート監視、プログラムやシェルによるアプリケーション監視がある。
例えば、ping監視やポート監視はWebアプリとは異なる外部サービスで行ったり、アプリケーション監視はログ出力やヘルスチェック用のJSPで実装したりする。

また、情報処理試験の問題にあるサーバー構成図のように、負荷分散と冗長化を兼ねたデュプレックスシステムのアーキテクチャで、WebサーバーとDBサーバーを冗長構成するのが普通になっている。
このやり方ならば、稼働率も安定する。

ネットの情報によれば、Googleは「サーバーやHDDは定期的に壊れる前提でサーバーを構成している」らしいから、おそらく冗長化の技術が普通のSIよりも優れているだろうと推測される。

システムはプログラミングだけでなく、稼働率の高いサーバーの構築というタフな作業もあるのだ。

マネジメントのスピードが開発のスピードに直結する

倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。

【元ネタ】
アジャイル開発のボトルネック - Social Change!

(中略)
つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。
これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。
アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
(後略)

上記の指摘は、昨今のシステム開発の現状において非常に的を得ていると考える。

僕は、Redmineによるチケット駆動開発を運用して初めて、アジャイル開発はこういう開発スタイルなんだ！と実感した。
即ち、チケット駆動開発では、ロードマップ画面でバージョンをイテレーションに見立てて、小刻みに機能拡張しながらリリースしていく開発スタイルになる。
つまり、XPの小規模リリースを自然に具体化した開発プロセスになる。

すると、チケット駆動開発を運用する開発チームの内部作業はスムーズに進むようになり、顧客と仕様やスケジュールを調整するプロセスがボトルネックになってしまう現象が頻繁に起こるようになった。
例えば、開発チームではこういう仕様で進めるし、無理ならば代替の仕様が選択肢としてありますよ、と顧客に提示するが、そこで決定に時間がかかってしまう。
実際に作ってリリースして、顧客に見せたら、ちょっと違うよと言われる機能があったり、本来の要件が間違っていた事実も判明するが、どんなスケジュールで直していくか、優先順位を顧客が付けれない。
リリーススケジュールを開発側が提示して、返事待ちという状況が多くなる場合がある。

この状況の原因は、開発の速度よりも仕様やリリーススケジュールを決める速度が遅い点にある。

従来ならば、システム開発そのものに工数もコストもかかっていたが、Railsなどの優れたフレームワーク等のおかげでプログラミングの速度が上がってきた。
そして、RedmineやTestLink、チケット駆動開発で開発チーム内部の作業も効率化し、品質も安定するようになってきた。
すると、開発チームで制御できないプロセスがボトルネックになって、開発の速度に制約がかかる。
特に、レビューと言うプロセスでこの症状が顕著に現れる。

XPにはオンサイト顧客というプラクティスがある。
顧客も開発チームに加わり、ストーリーカードの優先順位付け、受入テストなどを行う。
実際の開発では、顧客が開発チームに入るのは難しいので、要件定義を行うSEがその役割を担っている。
倉貫さんはこの手法を「顧客プロキシ」(オンサイト顧客の代理人)と呼んでいた。

ここで、オンサイト顧客(要件定義を行うSE)の重要な役割の一つに、開発チームが作ったシステム仕様をレビューして、品質チェック後、承認するという作業がある。
このレビュープロセス(デザインレビュー)はすぐに完了できるわけではないし、レビュー後にその仕様で実装していくから、レビュープロセスのキューにどんどんタスクが溜まって、開発速度が落ちる現象が頻繁に起きるようになった。
かと言って、レビュープロセスを簡略化したり、無視していいわけではない。
そして、SEの代わりに顧客を連れてきても、状況はおそらく変わらない。

今の僕の経験では、デザインレビューが開発のボトルネックになっている。
つまり、デザインレビューの速度が上がらなければ、開発の速度が現状以上に上がらない。

要求を洗い出す作業と、要件を仕様化する作業は別の能力だと思う。
要求開発やBaBOKのレベルでは、業務の全体最適化(つまりエンタープライズアーキテクチャ)の観点から、システムのあるべき姿を導き出す。
しかし、我々ITエンジニアは、要件をいかにシステムとして実装して稼動させるか、という作業に注力を注ぐ。
それらの作業は大きく異なる。

その作業をつなぐ部分にボトルネックがあるのかもしれない。

レビュープロセスを効率化するには？

ReviewBoardとコードレビューに関するメモ。

【元ネタ1】オンラインコードレビュー支援ツール「Review Boad」

これまで自分がやっていたソースコードのレビューは紙に印刷して、赤ペンでガリガリ書いていくというスタイルだったので、ちょっと目から鱗でした。そんな感じでコードレビューをやっていくと手間がかかる割には、使い終わった後はゴミ箱に捨てられていたりしたわけですが、これを使うとレビュー結果が蓄積されていくので便利ですよね。
そう考えると初等プログラミング教育用としても使うのも面白いのかなと思っています。先生をやっていて、その辺りが一番やりきれない部分だったので。。。。

昔も今もコードレビューする場合、大量の紙を印刷して、赤ペンでガリガリチェックするのが普通だろう。
パソコン上で差分表示しながらレビューしてもいいが、レビューコメントを残したりするのが面倒だから。
モニタでは目が疲れる理由もある。

コードレビューやデザインレビューは、20年前の机上デバッグの頃と何ら進歩していない状況と言えるのではなかろうか？
だからこそ、ReviewBoardでコードレビューをWeb化する利点がある。

【元ネタ2】ReviewBoard: 雲の亀日記

雲は、ソフトウエアの開発では情報の共有が最も重要だと思っています。
ここで言う情報とは、仕様書とか機能のことではなくて、どちらかといえば、暗黙の知識・経験といったことを意図しています。その一つとして、開発者個人が持っている暗黙知の共有としてのコードレビューに高い意義があると個人的には感じています。ただ、現状のコードレビューにはその効果が全く無い（←極論）と思っていて何とかならないものかと、つねづね考えていました。
で、忙しいくせについついそういうことを検索していると、ReviewBord というものに行き当たりました。これは、素晴らしい。これを使うと、コメントとソースコードがリンクしてくれるので、後から見直すのも楽だし、修正方法も明確に理解できる。こういうシステムを導入することで、生産性は飛躍的に向上しそうな感じがします。
生産性向上には、プロセス以外のファクターの要素も絡んでいることが多くのマネージャーにもっと理解されるようになると良いですね。

ソフトウェア開発では、暗黙知の共有が重要とよく言われる。
その理由は、仕様や設計、アーキテクチャなどの情報はExcelや紙などの媒体だけでは、メンバーに伝わらないから。

何故そんな汚いパッチが付けられたのか？
何故そんな修正が発生したのか？

コードレビューは単なる欠陥探し、あら探しではなく、メンバー同士で暗黙知を共有し合う場でもある。
コードレビューはXPのペアプロの代替手段なのだ。

【元ネタ3】「ピアレビュー」を読みました ― ありえるえりあ

3章に「インスペクション」、「レビュー」、「ウォークスルー」の比較表があります。
誰が定義したんだ、と言いたくなる比較表で、この定義に従う必要性は感じませんが、この3つの用語、日常の中であまりに曖昧すぎて何を指しているのか分からないのも事実です。
比較表を見る限り、モデレータ、作成者、読み手の役割の部分が明らかな相違です。

* インスペクション: モデレータ、作成者、読み手を、それぞれ別の人が行う。
* レビュー: インスペクションとウォークスルーの中間形態(モデレータと読み手が一致する場合など)。
* ウォークスルー: 作成者がモデレータかつ読み手を兼ねる。

コードインスペクションをしていて思うのが、本当は、デバッガで動的にコードを追いながらコードを見る方が効率的だろうな、という思いです。
デバッガを使わず、頭の中だけでコードを動かしてバグを見つけられる自分のスキルを誇らしく思う気持ちは、正直に告白すれば、あります。
しかし、自分のささやかなプライドを満たすことがコードインスペクションの目的ではありません。

レビュープロセスは、プログラミングやテストとはプロセスが異なる点に注意すべき。
最も厳格なプロセスがインスペクション、中間がレビュー、プライベートっぽいプロセスがウォークスルー。

ウォークスルーは、IT勉強会でよく行われている形式だろう。

レビューで必要な役割は、プログラミングやテストの場合と異なる。
レビューでは、モデレータ・作成者・読み手・記録者の4つの役割がある。

普通は、レビューの形式が多いだろう。
つまり、レビューアがモデレータ、レビューイが作成者・読み手・記録者を兼ねる。

このプロセスの欠点は、レビューアやレビューイの負担が大きい。
レビューイは、レビューで指摘された内容を記録し、理解し、修正したのを再チェックするプロセスが曖昧になりがち。
レビューアは、たくさんのレビューイからレビューが寄せられて、開発プロセスのボトルネックになる。

しかし、インスペクションをいつも開催するのは工数がかかりすぎる。
普通は、インスペクションは優先順位の高い成果物に絞って行ったり、レビューの進捗管理に注意を払ったりする。

BTSを導入してタスク管理や進捗管理を効率化できたり、TestLinkを導入してテストの進捗管理を効率化できたように、レビューもツールを導入して効率化できないのだろうか？

【元ネタ4】Karl E. Wiegers著『ピアレビュー』日経BPソフトプレス、2004.3.1、2900円（税別）、＜高品質ソフトウエア開発のために同僚同士で行うレビュー＞

・ピアレビューはすべて、「計画、作業成果物の準備、レビューミーティング、エ
ラーの修正、修正の検証」の５つのアクティビティの何らかの組み合わせです。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ピアレビューの種類 　　計画 　準備 　ミーティング 　修正 　検証
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
インスペクション 　　　　○ 　　 ○ 　　 ○ 　　　　　　　○ 　　　○
チームレビュー 　　　　 ○ 　　 ○ 　　 ○ 　　　　　　 ○ 　　 ×
ウォークスルー 　　　　 ○ 　　 × 　　 ○　　　　　　 ○ 　　 ×
ペアプログラミング 　　 ○ 　　 × 　　 継続的 　　　　○ 　　 ○
ピアデスクチェック、 　 × 　　 ○ 　　可能 　　　　　 ○ 　　 ×
パスアランド
アドホックレビュー 　　 ×　　 × 　　 ○ 　　　　　　 ○ 　　 ×
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

レビューにも色んな種類がある。
最も効果があると言われるインスペクションを行う為に必要なノウハウを書いている本が『ピアレビュー』。

レビュープロセスは、おそらく20年前から何も進化していない。
レビューがシステムの品質改善に有用であると誰もが理解しているのに、徹底できない理由は、プロセスの運用に壁があり、プロセスを効率化できていないからだ。
何とかならないのだろうか？？

ここ5年間で、開発環境だけでなくプロジェクト管理を巡る環境が急激に変化している。
RailsやPHPで簡単にWebシステムを作れるようになってから、タスク管理・進捗管理・テスト管理・バージョン管理が急激に進化している。
チケット駆動開発もこの流れの上にのっている。

レビュープロセスもこの流れの延長線上で、運用のハードルを下げるべきだ。

オープンソースへの貢献は福利厚生

Googleの開発プロセスで面白い記事があったのでメモ。

【元ネタ】
ソースコードから見るグーグル気質、規律を持つ気さくな開発者集団　1頁：ITpro

ソースコードから見るグーグル気質、規律を持つ気さくな開発者集団　5頁：ITpro

【開発プロセス】
・グーグルの開発スタイルでは、デザインドキュメント＋コードレビュー＋単体テストが必須
・コードレビューや単体テストは、高品質なソフトウエアを開発するプロセスとして、近年その重要性への認識が高まっている

　自動テストだけでなく、コードレビューを開発プロセスに組み込んでいる点に注目すべき！
　コードレビューは欠陥探しだけでなく、より良い機能への提案や良いプログラムへの賞賛も含まれる。
　コードレビューは開発者同士の信頼関係を高める作用がある。
　コードレビューをそのように扱えば、チームワークの強化にもつながるだろう。

【オープンソースへの対処】
・オープンソース界出身のプログラマにとって、自分の書いたコードを社外の人々にも見せたいし、議論して磨き上げたい欲求は自然
・良いプログラマを集め、プログラマのモチベーションを高めることが、自社のプログラムやサービスを改善させる最良の手段

　オープンソースに優しい環境は、自社開発のリソース削減に役立つだけでなく、プログラマのモチベーションを高めているという指摘。

　Googleだけでなく、オープンソースという仕組みは、技術者にとって非常に重要だと思う。
　その理由と影響度合いはもう少し考えてみる。

テスト手法の概念をTestLinkで説明する

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。

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

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

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

下記の資料にまとめてみた。
ちなみに下記のテスト用語(方言？)はTEF関西のNakaさんから教わった。

Test Linkのテスト手法

View more presentations from akipii .

【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念

上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。
その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、開発者をびびらせる意味も込めて「失敗」にする。
つまり、カート削除2のテストケースは、みなしバグになる。

更に、カート機能でバグが発生していて注文機能のテストを進められない状況の場合、注文機能のテストケースは全てテスト保留にする。
つまり、注文機能のテストケースはブロックになり、カート機能のバグが解消され次第、テストを再開できる。

又、カート削除1のテストケースからRedmineへバグチケットが発行される。
このバグは、みなしバグやブロックしたテストケースなど数多くのテストケースに影響範囲があるから、ブロッキングバグになる。
つまり、ブロッキングバグはテスト進捗を妨げる重大なバグである。

ブロッキングバグの修正が完了し再検証する場合、テスターには、ブロッキングバグの検証だけでなく周辺の関連機能も回帰テストするように管理者は指示しておく。
理由は、ブロッキングバグの修正で、デグレが起きていないか、他機能への考慮漏れが発生していないか、確認して欲しいからだ。
上記の例では、カート投入機能は既に成功しているが、もう一度最初から、カートへ商品を投入してカートから商品を削除するようにテストする。
これを周辺テストと呼ぶ。

Ver2.0のテストを実施していて、今回の機能改修でソースを修正しなかった機能のテストは、既に運用済みで品質が担保されている場合もありうる。
例えば、Ver2.0で念のために実施する必要があるものの、テスト工数や納期の関係で優先順位が低くテストしなくてもいい場合がある。

これらのテストケースをあらかじめ成功にするが、テストを実施して成功にする状態と区別するために、みなしOKというステータスにする。
但し、みなしOKのテストケースでもしバグが発生したら、結局全てのテストケースを再テストする必要がある。

上記をまとめると、テスト実行後のステータスは、未実施・成功・失敗・ブロック・みなしOKの5種類がある。
更に、テスト結果の検証に時間がかかる場合、検証中というステータスも欲しくなるだろう。
例えば、クレジットカードのシステムでリボ払いの計算結果を検証する時、テスト結果を取得するだけで、検証は後日行う場合があるだろう。
この場合では、テスト担当者とテスト検証者は異なる時が多いだろう。
つまり、ステータスは、未実施・成功・失敗・ブロック・みなしOK・検証中の6種類は最低必要ではなかろうか？

TestLinkでは、ステータスが未実施・成功・失敗・ブロックしかなく、GUI上からステータスを増やせない弱点はある。
しかし、Ver1.8以降では、設定ファイルcustom_config.inc.phpに下記の記述があるので、ステータスを増やせるかもしれない。

// $tlCfg->results['status_code'] = array (
// "failed" => 'f',
// "blocked" => 'b',
// "passed" => 'p',
// "not_run" => 'n',
// "not_available" => 'x',
// "unknown" => 'u',
// "all" => 'a'
// );

【2】後追いテスト、五月雨テストの概念

上記2枚目で、Ver1.0のリリースが目前に迫っている時だとしよう。
携帯のような組込み機器、業務システム、パッケージ製品のリリース直前では、1週間前～1ヶ月前からコードがFreezeされて、開発チームは、インストーラを作成したり、本番環境を構築する等のリリース作業に入る。
リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、回帰テストを行うテスト手法を後追いテストと呼ぶ。

後追いテストの目的の一つは、空き時間を使って更なる品質チェックを行うことだ。
普通は、この時期では、製品に重大な支障が発生するようなバグは全て潰されているはずだが、表示がちょっとおかしかったり、UIをもう少し改善できるなど、些細な修正点はテストすればするほど出てくるはずだ。
そのようなプロダクトリスクの低いバグを洗い出し、次のVer1.1へマージしてリリースできるようにする。
但し、後追いテストで重大なバグが見つかった場合は、Ver1.0のリリースを延期することもあるだろう。

Webシステム開発では、リリースした本番ブランチ上のシステムに対して、リリース後に後追いテストで優先順位の低いテストを行う時もあるだろう。

一方、開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
例えば、携帯のテストならば、SNSメール登録が先に開発できて、普通の携帯メール機能は開発中の場合、SNSメール登録を先にテストしてバグ出ししていく。
そのテスト結果を開発チームにフィードバックして、普通の携帯メール機能にも取り込んでいく。

アジャイル開発は基本は五月雨テストだと言える。
つまり、開発できた機能から順次テストしていく開発スタイル。
脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で紹介した僕のテスト手法は、五月雨テストと同じだ。

僕がTestLinkを運用した時、テスト計画のテストケースが少ない場合、テスト計画をイテレーションに含めた。
逆に、テスト計画のテストケースが多い場合、開発のイテレーションから分離して、テスト計画を更に分割して、複数のイテレーションで順次テストしていった。
例えば、結合テストPh1・Ph2、システムテストPh1・Ph2・Ph3のようにテスト計画を順次実施していくテスト戦略になる。

僕のやり方とは別に、第5回　脱Excel！ TestLinkでアジャイルにテストをする - hokorobiの日記にあるhokorobiさんのテスト手法のように、1個のテスト計画で複数のビルドで管理する方法もある。
これは、Excelのテスト仕様書の管理と同じように、1個のテスト仕様書へ結果を追記していくのと同じやり方だ。

僕もこのやり方を試した時はあったが、アジャイル開発に組み込みにくかった。
理由は、イテレーションと言う概念を当てはめにくいから。
テストで一番嫌なのは、テストすればするほどバグが出て、バグ修正＆検証がエンドレスになってしまうこと。
イテレーションがあるからこそ、リリースが定期的にあり、プロセスを改善するタイミングが生まれやすい。

また、ビルドの途中でテストを中断して、次のビルドに移るから、テスト実行結果のステータスが曖昧になりがち。
そもそもブロックを使う必要もない。
ブロックや見なしバグなどが必要な理由は再テスト工数を計算したいからだ。
100件のテストを行う場合、10件失敗すれば、テスト工数は110件も膨れ上がる。
プロジェクト管理の基本はクリティカルパスの管理だから、再テスト工数を見積もるのは非常に重要なのだ。

又、テスターが少なすぎたり、テスト期間が短すぎたり、テストケース数が多すぎると、テスト計画を立てた時点でもはや全てテストできなくなる確率は大きい。
特に、デシジョンテーブルや直交表でテストデータのパターンを作りこむシステムテストでは、テスト網羅の観点からテストケース数が爆発しやすく、その危険は高い。
だから、イテレーションにテスト計画を組み込むことで、テスト工程のマネジメントを管理しやすくするのだ。

【3】とある勉強会で、最近のシステム開発の傾向は品質よりも納期を重視しているようだ、という話があった。

ビジネス的背景としては、3ヵ月後の景気すら誰も分からない状況で、数年もかけてシステム開発するのはリスクが非常に高い。
また、MixiアプリやGoogleのサービスのように、先にリリースした者がマーケットを支配する状況が多くなっているからだ。
だから、最低限の品質は担保した上で、小刻みにリリースしていく開発スタイルが多くなっているように思う。

更に、技術的背景としても、後追いテスト、五月雨テストのようなテスト手法がやりやすくなっている。
例えば、携帯電話やiPodのような組込み機器でも、リリース後にSWアップデート機能でアプリケーションだけでなくROMそのものも更新できるようになった。
Webシステムなら、サーバーにデプロイさえすればいいから、リリースしやすい。

つまり、後追いテスト、五月雨テストのようなテスト手法は昨今のSWテストにマッチしやすい特徴があると思う。

TestLinkはまだまだ機能改善の余地があるけれど、上手に使いこなせれば、テストプロセスの品質向上で大きな威力を発揮できると思う。

【公開】脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

下記の記事を公開した。

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所

上記の記事で、TestLinkで経験したこと、考えたこと、理解できたことは全て書いた。
記事のポイントは3つある。

一つ目は、TestLinkをアジャイル開発に組み込むための運用サイクルを工夫したこと。
基本は、TestLinkのテスト計画をイテレーションの一部、あるいは、開発とは別のイテレーションに見立てて、小刻みにテストしながらリリースしていく運用にする。
これによって、テストするほどバグが出て、延々とゴールのないシステムテストから解放される。

二つ目は、TestLinkに合わせたテストケースにすること。
結合テストやシステムテストで実際に使うテストケースを例にあげたので、理解してもらえると思う。
他人の話を聞くと、膨大な既存のテストケースをTestLinkにインポートする方法に苦労しているようなので、参考にして欲しい。

三つ目は、TestLinkとBTS(Redmine)と連携して、バグ修正とバグ検証をワークフロー管理すること。
この手法によって、バグ修正(PG)とバグ検証(テスター)がペアプロのように作業できるので、品質向上に役立つ。
更に、テストに失敗して影響範囲が大きい場合、テストケースをブロックする。
このブロックというステータスについても、詳しく説明した。
ブロッキングバグ、みなしバグという概念によって、再テスト工数が計算でき、最終的にはテストのクリティカルパスを導くことができる。
テストケースのステータスは「成功」「失敗」以外にも色々あることを知って欲しいと思う。

感想があれば是非フィードバックして欲しいです。

KnowledgeTree、Alfrescoをドキュメント管理に使う

オープンソースのコンテンツ管理システム(CMS)であるKnowledgeTree、Alfrescoをドキュメント管理に使うアイデアについてメモ。
＃あくまでもメモ書き。

【元ネタ】
文書管理システム - Wikipedia

Alfresco - Wikipedia

[ThinkIT] 第1回：NASAにも導入されたAlfrescoとは？ (1/3)

[Think IT] 第2回：AlfrescoがECMとして優れている理由 (1/3)

＠IT：明日からできるプロジェクト管理（2）

KnowledgeTree――様々なニッチ市場を射程に捉えるドキュメント管理システム - SourceForge.JP Magazine

【ダウンロード】
BitNami :: Alfresco

BitNami :: KnowledgeTree

KnowledgeTree、Alfrescoの特徴や使い道は下記だと理解している。

１・Web上の共有ファイルサーバーとして使う。
→共有サーバーでファイル管理の欠点は、最新版が分からなくなりどんどんゴミデータが増えていく点。

２・システム監査の一環として、監査証跡の管理に使う。
→ファイルのアクセスログを監査証跡として使い、不正なアクセスや更新がないかチェックする

３・履歴管理や要件管理
→SVNリポジトリのように更新履歴が残る。
　ファイル同士で相互リンクできる性質から、要件の追跡に使ったりできる。
　WordやExcelの差分表示は可能？？

４・ワークフロー管理
→文書ごとに修正フローを変える。ユーザ権限によってファイル操作を制御できる。

５・全文検索エンジン
→登録した全ファイル(Word、Excel、PowerPoint)を検索できる。タグ検索も可能？

CMSを使う動機は文書管理システム - Wikipediaに詳しく書かれているが、現場リーダーとしては、共有ファイルサーバーの代替機能としてだ。
つまり、共有サーバーにあるファイルサーバーをWeb上で一括して共有・管理したい。

ドキュメント管理はSVNのような構成管理でもよいかもしれないが、実際のプロジェクトでは、構成管理の配下に置かないファイルはとても多い。
それらは不要かもしれないが、後に必要になるかもしれないが、SVNで管理するほどでもない。
そんなファイルも全てCMSで管理すると楽になるのでは？という発想。

CMSを使ってやりたい事は二つある。

一つは、強力な全文検索エンジンをフルに使う事。
最新版のドキュメントから、欲しい仕様をGoogle検索のように検索したい。

僕のチームでチケット駆動開発を実践した時、ソースもドキュメントもSVNで全て管理したのは良かったけれど、最新の仕様が探しにくいという課題が開発者からあがった。

ソースならEclipse上でGrepすればよいが、ExcelやWordの検索はWindowsのデフォルト機能では遅いし使い勝手も悪い。
CMSの全文検索エンジンが使えれば、プロジェクトの全てのドキュメントから仕様を検索して、リバースエンジニアリングするのが楽になるだろう。

CMSを使わずとも、全文検索システム Hyper Estraierを使う手もあるかもしれない。

もう一つは、設計レビューで使いたい事。
RevireBoardのように、仕様書の差分箇所にレビューコメントを付けて、きちんと修正されたか確認するようにする。
これができれば、気軽にレビューできるし、レビューの指摘が修正されたか、更には修正を検証したか、というワークフロー管理も可能になるだろう。

ソースのレビュー管理は、コードレビューシステムRevireBoardもあれば、RedmineやTracのコードレビュープラグインを使う方法もある。
しかし、ExcelやWordで書かれた設計書のレビュー管理は、そのワークフロー管理が面倒。
CMSに付属しているワークフロー管理を上手に使えばいいかもしれない。

但し、ドキュメントはSVNで管理しているので２重管理になる。
TorotiseSVNの差分機能をレビューに使った方がいいかもしれない。

何よりも、レビューのボトルネックはレビューアの負担が大きいこと。
レビューアの負荷が大きくなり、開発もテストもレビュー工程で進捗が滞りがち。
レビューのワークフロー管理がうまく機能すれば、レビューの優先順位付けも楽になり、レビューの効率が上がるのではないか？
そのために、チケット駆動開発のように、レビューのワークフロー管理をWeb上で管理できるようにしたい。

まだアイデアに過ぎないが、色々試してみたい。

ソフトウェアテストPRESS Vol.9にあるTestLinkの記事

ソフトウェア・テスト PRESS Vol.9にありえるえりあさんによる TestLinkによるテスト管理記事が載っていたのでメモ。

【元ネタ】

TestLink使用レポート ― ありえるえりあ

TestLinkを検証しました ― ありえるえりあ

SWテストを管理者・開発者・テスト担当者の観点から書かれていて面白かった。
TestLinkの内容は上記のBlogと殆ど同じだった。

興味深かった点を書いておく。

【1】開発チームとは別にテストチームを作った理由が書かれていた。

元々、プログラミングによる開発が一番大事で、そもそもテストチームは必要とは思えなかった。
知っているテスト担当者から愚痴ばかり聞いていたから。
しかし、開発してテストしてリリースする一連の作業で、開発者だけの場合、開発者は実装するよりもテストする作業が半分以上に増えて、肝心の開発作業が滞りがちになった。
だから、開発者がバグ修正に専念できるように、テストチームを作らざるを得なかった、と。

この理由はなるほどと思わせる。
開発チームとテストチームの2つの部隊を作らざるを得ない理由は、マネジメントの問題なのだ。

単純な単体テストレベルならば、開発者もやっているが、システムテストや受入テストのレベルになると、テストの事前条件やテストデータの作りこみに手間がかかる。
更に、テスト結果の検証作業も、システムテストや受入テストでは、とても大変になりがち。
開発の片手間でできる作業ではない。
だから、テストチームの役割は、複雑なテスト作業とその検証作業の専任になる。
特に大規模開発ほど、この傾向は強いだろう。

又、テストチームのコストについて書かれた内容も興味深かった。
いわく、テストチームそのものは開発上のコストになるが、当社はパッケージ製品の開発が主業務なので、実際のテストは回帰テストが多い。
つまり、単純になりがちなので、テスト担当者が専門でテストした方が、開発者は実装の専念しやすい、と。

ハードと違い、ソフトはどんどんバージョンアップしていく。
だから、過去のバージョンの機能がデグレせずに正常動作することを検証する必要がある。
つまり、バージョンアップするに従って、テストケースは単調増加で増えていく。

過去のバージョンのテストは結局、回帰テストになる。
機能テストのレベルならばJUnitでテストを自動化できるが、システムテストや受入テストでは、UI周りのテストを自動化する速度よりも機能追加の速度が早くて追いつかず、結局、コストが合わない時が多い。

この辺りの解決方法の一つとして、TestLinkで手動のテスト作業の管理を効率化する点があるだろう。

【2】リリース判定条件として、信頼度成長曲線を止めて、タイムボックス形式(イテレーション)へ変更した理由が書かれていた。

ハードのように、信頼度成長曲線を書いてバグの歩溜まりになったらリリースする判定条件にしても、実際はリリース後に障害が数多く発生する時は多い。
その理由は、ソフトでは、信頼度成長曲線は人為的に操作しやすいからだ。
例えば、テストするスコープを狭めれば、確かにバグは減っていくだろう。

しかし、実際のソフトウェア開発は、仕様変更が任意に勃発するので、長期間スコープが固定化された状態はありえず、結局、バグはいつまで経っても収束しない時は多い。
だから、オープンソースのようにタイムボックスごとにリリースしていくのが一番現実的だ、と。

このリリース手法は、まさにアジャイル開発そのもの。
タイムボックスをイテレーションと見なせば、イテレーションというサイクルで小刻みに機能追加しながらリリースしていく開発スタイルになる。

アジャイル開発の場合、短い期間だけれどもイテレーションの間はスコープは固定されているので、品質を高めやすい利点がある。

例えば、イテレーション期間中に仕様変更が生じたら、次のイテレーションで対応するとアナウンスすればいい。
まずは目の前のイテレーションの機能を実装してリリースするのを目標とする。

又、品質とは、単に信頼性だけではない。
顧客にとっての価値とは、欲しい時に欲しい機能があることなのだから、納期も重要な制約条件だ。
品質重視でリリース時期が遅れたら、顧客のビジネスにも支障が出やすい。
だから、アジャイル開発では、スコープを制御することで、品質を保持し、納期を守るようにするのだ。

テスト工程のマネジメントは、上流工程のマネジメントよりもはるかに難易度が高い事実を改めて考える必要があると思う。

テストケースの作り方

TestLinkを運用し始めて、改めてテストケースの作り方が重要と思うようになった。
TestLinkのマスタデータであるテストケースの品質がよくないと、TestLinkの効果が出ない。

「はじめて学ぶソフトウェアのテスト技法」も「知識ゼロから学ぶ ソフトウェアテスト」もテストケースの作り方について初心者向けに書かれているようなのでメモ。

テストケースは基本は、パラメータの組み合わせだと思う。
パラメータの洗い出しは業務や設計が分かっていないとできないけれど、そこからテストケースを作成するプロセスはツールで自動化できないか探っている。

MicrosoftのPairwaise法(All-pairs法)ツールPICTを利用したテストケース自動生成ツールMTGに着目している理由も、テストケース作成のコストを下げて、品質を保持したいから。

又、テストの本で不思議なのは、ブロックの使い方について説明した本が見当たらないことだ。
TestLinkのブロック機能は、テスト工程のマネジメントを掘り下げる重要な概念だと思う。

Nakaさんにその不満をぶつけた所、「基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために」がいいと勧められたのでメモ。

プロジェクト管理インフラのふりかえり

プロジェクト管理インフラを使った履歴が書かれていたBlogがあったのでメモ。

【元ネタ】
僕はこんな開発インフラを使ってきた - watawata日記

以前は、VSS＋VisualStudioの環境がいまいち慣れなくて、CVS＋EclipseがJavaの開発環境で十分だと思っていた。
全てフリーだし。

そして、TracとSubversionが出た頃から、急激に開発環境が改善されつつあるように思う。
バージョン管理は、SVNからGitやMercurialへ発展している。
SVNでbranchの使い方が分かった。
そして、Mercurialを使いながら、可能性を秘めている分散バージョン管理について色々試している。

BTSは、Mantis、Tracもあるが、僕はRedmineが一番フィットしている。
Redmineで、リリース予定のバージョンを定めて、リリースできる単位でチケットを取捨選択するやり方がとてもアジャイルな感覚だから。
その方法から、クリティカルパスや工数管理などのプロジェクト管理につながる。

ビルドツールは、最初はContinium＋Mavenを使っていたが、ビルドはしてくれてもデプロイは手作業なのでイマイチだった。
Mavenも設定が多くて、あまり楽になった印象がない。
Antでビルド＆デプロイのスクリプトを自分で書き、Hudsonでビルド＆デプロイさせたら、ワンクリックでリリースできるようになった。
しかも、HudsonはRedmine、SVNと相性がいいので、非常に便利。

そして、テスト仕様書もExcelからTestLinkに変えて、テストのマネジメントの奥深さを色々考えている。
テストと品質保証はアジャイル開発の最後の難問だから。

ここ2、3年でプロジェクト管理ツールが急激に改善されている。
マネジメント手法そのものが、従来のExcelや文書でやり取りするやり方からツールでリアルタイムに情報共有するやり方へ改良されて発展している。
それらのツールはまだ発展途上で、ツール同士の連携も未完成だが、ツールが開発プロセスへ与える影響は今後大きくなるだろうと思う。

ITILのプロセス関連図

とある勉強会で、クレーム処理でITILの話が出てきたので、整理するためにメモ。
下記のプロセス関連図でITILは全て説明できる。

ITIL：Information Technology Infrastructure Library - Wikipedia

Itilプロセスフロー

View more presentations from akipii .

ITILのプロセスは、PDCAサイクルで覚えればいい。
但し、起点がPlanの変更管理とCheckのインシデント管理の2パターンがある。

RFC(変更要求)が来た場合、変更管理プロセスで、要求を実現するための計画を作る。
つまり、CAB(変更諮問委員会)がステークホルダーを集めて、例えば、実装方法やリリース作業、そしてレビューやテスト方法、評価などの方針を議論して、決定する。

次に、変更管理で作られた計画に従ってリリース管理で、作業者が対応を行う。
実際は、ソースを修正してテストして、リリースする。

他方、顧客からクレームが来た場合、サポートデスクでインシデントとして受け付ける。
サポートデスクは普通は、女性の事務オペレータだったりする。
インシデント管理では、クレームが障害なのか要望なのか単なる質問なのか、を整理する。
障害の場合、暫定対応を連絡する時もある。

次に、障害だと判明したら、問題管理に送られて、BTSへ登録し、根本原因の究明を行う。
問題管理では、原因調査と是正対策を取るのが目的であり、すぐに直すわけではない。

ここでよく出る言葉は、SLA(Service Level Agreement)、いわゆるサービス品質維持契約。
顧客とSIerで、運用するシステムの品質を契約にする。
インシデント管理におけるクレーム情報、問題管理における障害情報から、SLAを満たしているか評価するのに使われる時が多い。

そして、問題管理で作られた是正対策をインプットとして、変更管理で実装計画を立てて、リリース管理で実装・リリースを行う流れになる。

構成管理は、変更管理・リリース管理・インシデント管理・問題管理を支えるインフラであり、CMDB(構成管理データベース)で一括管理されている。
CMDBには、CI(構成アイテム)とCIの作業履歴が登録されている。
SVNリポジトリをもっと汎用化したもののようにとらえればいいだろう。

この流れを詳細化すればITILの用語や説明は分かる。
だからITILはそれほど難しくない。

でも、ITILの発想は、抽象的なPMBOKよりもSW開発の現場で非常に役立つと思う。
チケット駆動開発でも、ITILのプロセスフローを参考にした。
SW開発の現場リーダーは、ITILの考えに触れておくと、RedmineやTestLinkで何ができて何が利点なのか、よく分かるだろうと思う。

昨今、情報処理試験でも情報セキュリティとサービスマネージャ(ITIL)の資格が重視されていると聞いた。
ITILファウンデーションの資格は、このプロセスを詳細化したぐらいで簡単に合格できる。

アジャイル開発の最後の弱点

テスト工程のマネジメントは、ソフトウェア開発の上流工程におけるプロジェクトマネジメントよりもはるかに難易度は高い。
TestLinkを使ってみると、Redmineの運用よりもはるかに難しい。
一つでもバグが出るたびにブロックが発生して、前進できないのだ。

ブロッキングバグをストッピングバグとも呼ぶ事実を今夜初めて知った。
テストでは、ブロッキングバグ修正の優先順位付けがとても重要。
ブロッキングバグが直れば、ブロックした大量のテストケースを再開できるからだ。

そして、テストにもクリティカルパスがある。
プロジェクト管理の基本はクリティカルパスの管理だから、テスト工程のそれを見つけて、意思決定を間違えないように管理するのが凄く大事。

テストと品質保証はアジャイル開発の最後の弱点。
チケット駆動開発によって、SW開発のタスク管理やワークフロー管理はスムーズになる。
しかし、テスト工程では、チケットとテストケースは概念が全く異なるため、チケット駆動開発の効果が出ない。

もう少し考えてみる。

プロジェクト管理ツールの目的はプロセスの透明化

開発抽象化レイヤ - The Joel on Software Translation Projectを読み直して、もう一度考えを書き直す。

【元ネタ】
開発抽象化レイヤ - The Joel on Software Translation Project

開発抽象化レイヤーを担う人: プログラマの思索

RedmineやTracによって、Excelからタスク管理やワークフローをIT化する。
昨今の高機能なBTSによって、ワークフローやプロセス管理を開発者は特に意識せずに開発できる。

TestLinkによって、Excelからテスト管理をIT化する。
管理者やテスト設計者は、膨大なテストケースの管理や複雑なテスト計画・集計作業から解放される。

SVN、Mercurial、Gitによって、ソースだけでなく、WordやExcelのドキュメントもバージョン管理する。更に、BTSと連携してソースやドキュメントをチケットに紐付ける。
開発者も設計者も、ソースやドキュメントの変更理由をチケットから類推できる。

これらのツールが目指すのは、プロセスを透明化することだ。
ジョエルの言う開発抽象化レイヤを狭義に捉えると、開発者がプロジェクト管理を意識しなくてもクリエイティブに開発できるようにすることだ。

作業者がツールを使いこなせば、ツールの機能に隠されたベストプラクティスによって、自然にプロセス管理されている。
プロセス管理でがんじがらめな開発になるのではなく、複雑な連携作業やワークフロー管理はツールに任せて、開発者はクリエイティブに開発できる。
管理者も、マネジメント情報を収集する作業から解放されて、経営者のようにツールから出力されたマネジメント情報を使って、高度な意思決定に注力できる。

ソフトウェア開発において、プロジェクト管理やテスト管理、品質管理の問題が急速に言われ始めたのは、プログラミングを中心とする下流工程でここ10年大幅な技術革新が行われたのに、プロジェクト管理の技術が旧態依然のままで、プログラミングの速度に追いついていないからだろう。

Excelでチマチマと手作業で管理する技術は、RailsやSeasarのようなWebプログラミングの速度にマッチしていない。
わずか10～20人月のプロジェクトでLOCが1万行を超え、テストケース数も1千を超える規模では、ツールでプロジェクト管理を補完しなければ、せっかくのプログラミング技術の生産性も落ちる。

ツールに必要な物は何か？
それは、常に最新の作業情報、成果物、そして仕様。

最新の作業情報を入力データとして、BTSによるチケット駆動開発がプロセスを透明化する。
最新の成果物を入力データとして、バージョン管理ツールが開発プロセスのインフラを提供し、BTSとソース管理が連携して、成果物と作業情報を連携してくれる。

最新の仕様を入力データとして、ツールが仕様と成果物が紐づく。
この部分のツールは、TestLinkの要件管理機能のように、まだ不十分。
でも、昨今のように短期間で開発するには、作業情報と成果物と仕様が密接に連携できるツールを必要としている。

【公開】SQIP2009講演資料「チケット駆動開発- BTSでExtreme Programmingを改善する-」

SQIP2009の講演資料が公開されたのでメモ。

【元ネタ】
日科技連 | ソフトウェア品質 | 第28回 ソフトウェア品質シンポジウム2009　講演資料

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-: ソフトウェアさかば

「チケット駆動開発- BTSでExtreme Programmingを改善する-」　講演資料PDF は僕とさかばさんの共著の経験論文で、チケット駆動開発でアジャイル開発の諸問題を解決した試みの内容。
Blogで書き散らした内容とほぼ同じ。

他の興味深い講演資料だけ書いておく。

「スモークテスト自動化の効果とテスト自動化戦略」　講演資料PDF は、Seleniumを用いてTestLinkのUIをテスト自動化した発表。
Seleniumを使う場合のノウハウが書かれているので非常に興味深い。
Seleniumによるテスト自動化は、実際は運用がはるかに難しい。
理由は、WebのUIがコロコロ変更される速度にプログラミング速度が追いつかないからだ。
だから、上記の発表では、TestLinkのRCのバージョンがリリースされてUIが殆どFixされた状態から、Seleniumによるテスト自動化を試みている。
つまり、システムの仕様も品質もある程度落ち着いた段階で、回帰テストの自動化のためにSeleniumを使う戦略を採る。
この方法ならば、Seleniumによるテスト自動化の効果も大きいだろう。

「Pairwise法と制約表による制御パステストのテストケース自動生成」　講演資料PDF は、AllPair(Pairwise)法を使ってテストケースの自動生成を試みた発表。
MSのフリーのAllPair法ツールPICTをエンジンに持つExcelマクロを用いて、テストケースを自動生成する。
PICTで自動生成したテストケースは、仕様がある程度落ち着いた状態で、システムテストや受入テストのように、大量のデータパターンで業務フローを検証する時や回帰テストで効果があるように思う。

ハーフディ・チュートリアル1
「派生開発を制覇しなければ明日はない ―派生開発プロセス［XDDP］のすべて」講演資料PDF

清水吉男さんが提唱している派生開発プロセスXDDPを最初から最後まで解説している。
これ1枚あれば、詳細をほぼ把握できるだろう。

「無知見プロジェクトに対するXDDPの適用
- USDM、プロセス設計によるプロセス改善」　講演資料PDF

XDDPを未経験者の多いプロジェクトで試した事例。XDDPの実践例として参考になる。

要件管理はテストの目的のために存在する

要件管理とテストの関連についてメモ。

【元ネタ】
Software Testing - Columns: VerificationとValidation

テスト管理のベスト・プラクティス

ソフトウェア開発のすべての規律はテストの規律と関連がありますが、その中でもテストと特に重要な関連を持つ規律がいくつか存在します。
* 要件管理
* 変更管理
* 構成管理
「要件管理」は、大部分のテスト作業に先行するもので、極めて多くのテストのモチベーション (動機付け) と検証のニーズを提供します。プロジェクトの個々の要件管理プロセスは、テスト管理のプロセスに大きな影響を及ぼす可能性があります。この関係をリレー競走に例えると、第 1 走者が要件管理で、渡されたバトンを受け取る次の走者がテスト管理です。
(中略)
「変更管理」は、ソフトウェア開発のすべての部分に影響しますが、追跡される変更のなかでテスト作業に最も関連が深いものは「欠陥」です。欠陥はしばしばテスト・チームと開発チームの間の主な意思疎通経路の役割を果たします。また、欠陥から引き出される集計とメトリックスは、多くの場合、品質の指標としても使用されます。
(中略)
テストにはどのビルドをいつテストするかの追跡が不可欠であるため、「構成管理」はテスト管理にとって重要です。構成管理では、ビルドに加えて、テスト管理がテストの実行のために追跡する環境も管理します。
(後略)

テストが変更管理に関係するのは、バグという変更要求が正しく実装されたか検証するプロセスとして必要だから。
テストが構成管理に関係するのは、どのバージョン、どのビルド番号のモジュールでテストしたのか、という観点が必要だから。

テストが要件管理と絡むのは、要件がテストの目的そのものだから。
テストにはV&Vという考え方がある。

Verification(検証)は、正しいプロセスで、仕様通りに動いているか、テストする。
Verificationは普通、コンポーネントとして単体テストや結合テストで行う。

Validation(妥当性)は、製品が意図された要求を達成しているか、テストする。
Validationは普通、システムテストや受入テストで行う。

要件管理が必要なのは、Validationのテストにあると言っていい。
システムに単にバグがなければ、品質がよいわけではない。
製品として魅力的でなければ、システムの価値は下がる。

要件を意識したら、テストの目的が明確になり、テストケースもその観点で詳細化されるだろう。
要件は受入テストのために存在するのだ。

せっかく苦労してシステムを作ったのに、次から次へと改善要望がやって来る場合、製品としてまだ成長途中か、あるいは、ユーザの欲求不満があるのかもしれない。
つまり、要件をきちんと管理できていなかったのが原因の一つなのかもしれない。

同期安定化プロセスのメモ

クスマノの本「ソフトウエア企業の競争戦略」をもう一度読み直した。
この本には、マイクロソフトの開発プロセスである同期安定化プロセスについて詳しく書かれている。
考えたことをメモ。

【元ネタ1】
Y2’s blog ? Blog Archive ? 本: マイクロソフト・シークレット(上)

次に開発プロセスです。開発プロセスについては、クスマノ氏が「同期安定化プロセス」と読んでいるマイクロソフトの手法についての説明です。
しかし、読み進めていると、実はこれがほぼScrumやXPなどのアジャイル開発プロセスが進めている方法と同一であることがわかります。
この本が出版されたのが1998年、アジャイルマニフェストが公開されたのが2001年とのことで、実はアジャイルマニフェストを作成した人々は同期安定化プロセスを参考にしたのではないかと疑います。

少し具体的にあげると、
・定期的なビルド -- アジャイルやスクラムでのDaily Buildやイテレーション
・開発工程の分割 -- スクラムのイテレーション
・プログラム管理者と開発チーム -- スクラムのスクラムマスターとチーム
・設計書より成果物を優先 -- アジャイルでも同じ
・見積もりは開発者に行わせる -- スクラムでも同じ
などです。

マイクロソフトが編み出した同期安定化プロセスとアジャイル開発の類似性は、知っている人には知られている。
曰く、夕方5時にデイリービルド。
曰く、プログラマはテスト担当者とペアになって作業する。
曰く、開発目標は定めるが、頻繁に変わる設計書よりも動く製品を優先する。

つまり、複数のサブチームの成果物をデイリービルドで「同期」を取り、その度にテストして「安定」を図るのが同期安定化プロセス。

アジャイル開発も同期安定化プロセスも、結合テストを早期に行っていると言うのが最大の特徴ではないか？

SW開発はいつも、多数のモジュールをバラバラに作った後にビッグバン統合を実施し、結合テストを行って、初めて重大な問題に気付く。
単にコンパイルエラーが見つかるだけでない。

インターフェイスが合わなかったのは、設計書に記載が無かったからだ。つまり、設計漏れ。
動かしてみて顧客に見せたら、違っていると言われた。つまり、要件漏れ。
実際にビルドしようとすると、ビルド環境の構築作業が間違っていたり、ライブラリのバージョンに相違があったり、テストデータが足りなかったりしていたからだ。つまり、ビルド作業漏れ。
そういう重大な問題は早期にキャッチしたい。

しかし、実際のSW開発では早期に結合テストを行うことができない。
特にWF型開発ではそうだ。
何故だろう？

もう一つのテスト管理ツールRTH

TestLinkに似たもう一つのオープンソースのテスト管理ツールRTHを見つけたのでメモ。

RTH - Requirements and Testing Hub | Get RTH - Requirements and Testing Hub at SourceForge.net

Feature list ? RTH Blog

RTH Demo / Live System ? RTH Blog

RTH - Requirements and Testing Hub

デモサイトでいくつかの画面を触ってみた。
TestLinkよりも機能は少なく、デザインもシンプル。
しかし、テスト管理だけでなく要件管理もデフォルトで付属しているのが目を引いた。

テスト管理ツールもBTSぐらい普及して欲しいと思う。

TestLink・BTS・SVN・Hudsonの関連構造

TestLinkのポテンシャルについて考えたことをメモ。

【元ネタ】
要件とテストを関連付ける「テスト管理ツール」---目次 - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第1回 テスト管理ツール：表計算ソフトの限界超える - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第2回 テスト管理ツール：要件とのひも付けがカギ - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第3回 テスト管理ツール：管理者支援型か開発者支援型か - 要件とテストを関連付ける「テスト管理ツール」：ITpro

第4回 テスト管理ツール：導入時の二つの課題 - 要件とテストを関連付ける「テスト管理ツール」：ITpro

【1】TestLinkを使う人達は主に、発注側や品質保証部門。
TestLinkを使う対象は、結合テスト以降、特に受入テストで使う。

TestLinkはテストの計画・記録・集計の為にある。
テストの自動化に直接役立つわけではない。
TestLinkは、テストケースそのものがプロジェクトの資産になる状況、つまり、結合テスト以降、特に受入テストで大きな威力を発揮する。

だから、TestLinkを使う状況は、発注側が受託したシステムの受入テストだったり、品質保証部門が開発部隊が作ったパッケージ製品の受入テストだったりする。

上記のようなTestLinkの特徴を上手に用いれば、XPのプラクティスであるユーザテストで使って、効率をあげることができる。

【2】TestLinkの要件カバレッジ機能を要件管理に使う。

Software Testing - Columns: テストカバレッジによれば、「仕様書の要件をどれだけテストしたか、という指標は、仕様カバレッジや要件カバレッジと呼ばれます。」

TestLinkの要件解析画面は、要件から紐付けたれたテストケース一覧を出力できる。
従って、この画面では要件カバレッジを見ることができる。

TestLinkCnvMacroを使うと、テストケースのキーワードに要件管理IDを紐付けることで、TestLinkのテスト結果画面で、キーワード別のテストの状態を集計してくれる。
従って、この画面ではテストカバレッジ、つまり、要件が何％までテストで検証されたか、を見ることができる。

たったこれだけの単純な機能だが、凄いポテンシャルを感じている。
その理由は、下記のようなトレーサビリティを実現できるからだ。

TestLink,BTS,SVN,Hudsonの関連構造

View more presentations from akipii .

現在、BTSチケット・SVNリビジョン・Hudsonビルド番号は、各々のツールで相互リンクが実現されている。
つまり、BTSチケットからビルドモジュール、あるいは逆にビルドモジュールからBTSチケットへ追跡できる。
従って、「このバージョンのモジュールに、あのバグ修正は反映されているか？」という疑問に回答できるインフラが既にある。

更にTestLinkのテストケースを経由して、要件まで遡れれば、「このバージョンのモジュールで実現された要件は何か？」を探すことができる。
あるいは、「ユーザの要望で仕様変更に対応する場合、要件に紐づくテストケースや機能、チケットから、影響範囲は大体これぐらいになる」という作業も機械的にできる。

しかし、TestLinkの要件管理機能は1階層のCSV形式でしか登録できない。
本来は、要件とBTSチケットを相互リンクさせたり、要件と機能のトレーサビリティマトリクスを表示したり、テストケースから紐付けられた要件の一覧(つまりトレーサビリティツリーみたいなもの)を表示したい。

市販の要件管理ツールやテスト管理ツールは多々あるが、ツール同士の関連がない。
現場で欲しいのは、プロジェクト全体の成果物を相互リンクしてトレーサビリティを実現してくれるプロジェクト管理サーバーなのだ。

TestLinkはPHPでオープンソースで作られているから、誰でも手を加えることができる。
誰か大幅に改造してくれないだろうか？

PICTで出力したテストケースをTestLinkへ取り込む

組み合わせテストケース自動生成ツールPICTを使って、TestLinkにテストケースを取り込めたのでメモ。

本当は、garyoさんやshimauchiさんが行ったallpair.exeを使おうとしたが、PICTの方が多機能。
PICTでは、制約条件を考慮できるし、以前生成した組合せテスト結果を再利用して他の組合せを追加できる機能もあるから。

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ

TestLinkメモ(2) - 科学と非科学の迷宮

TestLinkメモ - 科学と非科学の迷宮

【元ネタ】
オールペア法テストケース作成ツール（PICT）と TestLink の連携 - hokorobiの日記

組み合わせテストをオールペア法でスピーディに！：第2回　PICTの基本的な使い方｜gihyo.jp … 技術評論社

pict : tech.kayac.com - KAYAC engineers' blog

TestLinkCnvMacro - TestLinkTools - SourceForge.JP

【手順】
1. PICTのインプットファイルを作る。

参考：組み合わせテストをオールペア法でスピーディに！：第2回　PICTの基本的な使い方｜gihyo.jp … 技術評論社

例：input.txt
OS種別: Windows Vista | Windows XP | Windows 2000, Linux, Mac OS X
HD容量: 250GB, 500GB, 750GB
HDインターフェース: USB2.0, IEEE1394, eSATA

2.PICTで生成する。
pict input.txt > output.txt

例：output.txt
OS種別 HD容量 HDインターフェース
Linux 750GB USB2.0
Mac OS X 250GB eSATA
Windows Vista 500GB USB2.0
Mac OS X 750GB IEEE1394
Windows XP 250GB IEEE1394
Linux 500GB eSATA
Mac OS X 250GB USB2.0
Windows 2000 750GB eSATA
Linux 250GB IEEE1394
Mac OS X 500GB IEEE1394

3.TestLinkCnvMacroのSuiteDTへ上記の組合せを貼り付ける。
　期待値、テストスイート等も記載して、テストケースらしく整える。
　最後に、XMLを出力する。

4.TestLinkへXMLをインポートすればOK。

PICTの結果さえできれば、TestLinkへの取り込みはすぐに終わる。

PICTを使う場面は、Webシステムならば、システムテストや受入テストで、本番用データのデータパターンと業務フローに従ってテストする時だ。
あるいは、組込み製品やパッケージ製品ならば、OSやハード、ブラウザ等の複数の環境で最後の受入テストをする時だろう。

本番リリース前のテストでは、ユーザに近いレベルのテストが多く、普通は単体テストで見つかるようなバグは無いのが普通。
だが、実際の本番データを使うと、予期していなかったデータが原因でシステムが正常動作しない時はままある。

そんな時、PICTを使って、データパターンを機械的に生成できるのは工数削減に役立つ。
と言うのも、本番リリース前のテストでは、テストデータを用意して、どのテストケースでどのテストデータを使うか、というテスト設計に一番工数がかかるからだ。
もはや仕様が分からなければ、テストケースもテストデータも作れない。

PICTやTestLink、TestLinkCnvMacroを使い始めて分かった事がある。
それは、テスト工程では、仕様がはっきりと分かっていて、仕様の直交性が保障されていなければ、テストしても工数の無駄ということ。

直交表やAllPair法を使うには、テストするパラメータとそのデシジョンテーブルが必要だ。
そのためには、デシジョンテーブルと同値であるシステムの状態遷移図が作れていなければならない。
しかし、設計が曖昧だと、システムの状態遷移図すら設計者が詰め切れていない場合もある。

ツールによって、単純作業は効率化できる。
しかし、ツールで使う入力データ、仕様というマスタデータの質が悪ければ、PICTやTestLinkをいくら使いこなしても無意味なのだ。

要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス

要求管理プロセスについて良い記事があったのでメモ。

【元ネタ1】
＠IT：みんなが悩む要求管理（8） 最終回 要求管理ツールの賢い使い方

　まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。
一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。
いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。
ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。

IBM Rational RequisiteProを使った要求管理の事例。
興味深いのは、トレーサビリティマトリクス（追跡可能性マトリクス）だ。
これは、清水吉男さんが提唱する派生開発プロセスXDDPにもあるTM(トレーサビリティマトリクス)と同じだ。

TMは、上位要件を行、下位要件を列で表示したマトリクス。
上位要件に下位要件が紐づいている場合、マトリクスのセルに印が付く。
このセルがトレーサビリティを示す。

つまり、TMで印を付ける作業が、上位要件に紐づく下位要件の過不足が無いかを確認する作業に相当する。
これこそが要件カバレッジだ。
この要件カバレッジ機能を意識して設計すれば、要件を詳細化していくプロセスで、要件漏れや設計漏れをなくして、設計プロセスの品質を高めることができる。

【元ネタ2】
テスト管理のベスト・プラクティス　要件ベースのテストを使用する

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

特に、後者の機能は、要件カバレッジを利用して、バグから本来の要件に遡って、バグが発生した要件に関係する要件から修正対象ソースへ追跡できるという点で重要だ。
この手法は仕様変更にも使えるからだ。

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

【元ネタ3】
＠IT：みんなが悩む要求管理（7） 第7回 要求管理と変更依頼管理の違いを理解しよう

変更依頼管理プロセスと要求管理プロセスの関係の図が素晴らしい。
変更依頼管理や要求管理は最終的には、ITILの変更管理に落ち着く。

大規模プロジェクトほど、ユーザからやって来る膨大な改善要望や障害修正の要求は、一旦溜め込んで、すぐに判断しない。
要件定義や設計チームの代表者が集まった変更審査委員会（CCB：Change Control Board）が、一旦貯めた要求リストから、次バージョンで実現すべき要件を抽出し、優先順位付けしていく。
開発者は優先順位付けされた要件リストに従って開発し、テスト担当者は検証していく。

つまり、上記の計画プロセスと実装・検証プロセスは、ITILの変更管理とリリース管理にピッタリ当てはまる。
要求管理や変更依頼管理は、ITILの変更管理プロセスできちんと追跡できるように管理すべきなのだ。

また、要求を一旦溜め込んで優先順位付けするプロセスは、Scrumのスプリント計画やXPのイテレーション計画に相当する。
すなわち、プロダクトバックログにまずはユーザの要求を溜め込んでおき、どのスプリントで実装するかは保留にしておく。
スプリント計画を立てる時に、プロダクトバックログからスプリントバックログへ実現すべき要求を移す。
これが本来のマネジメント、あるいは要求管理になる。

そして、このプロセスはツールで実現されるべきだ。
大量の要求の一覧を優先順位付けして、どのバージョンでリリースされたか、追跡できるようにするには、Excelで手作業で行うのはもはや難しい。
ツールのサポート無しでは作業漏れも発生しやすい。

このインフラは、おそらくチケット駆動開発で実装できる。
つまり、BTSと要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。

ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。

ソフトウェア開発の諸問題はソフトウェアで解決する

「要件とソースとテストを関連付けて管理する開発保守環境構築をめざしてBy Suzuki 」というスライドを偶然見つけた。
どうやら2005年頃の発表資料らしい。

要件とソースとテストを関連付けて管理する開発保守環境構築をめざしてBy Suzuki

View more presentations from ikuo5710.

課題と今後の目標
* ソースと要件の結びつけはできる
* でも、テストケースとソース、 テストケースと要件の結びつけが できていない
* テストケースのバージョン管理って どうやればいいんだろう？
* ツールは？
* エクセルはもう使いたくない

この回答は僕は持っている。
TiDD＋TestLinkがその答えになる、と。

下記の記事を偶然見つけた。

プロジェクト管理は専用ツールを使うのが鉄則 － TechTargetジャパン

(前略)
プロジェクトマネジャーがプロジェクト管理専用のツールを使わない場合、それは彼らがしかるべき教育と訓練を受けていない証拠なのだ。
　WordやExcelを使ってプロジェクト管理を行うと、間違いなくビジネス全体に悪影響がある。例えば、リソースの利用可能量やプロジェクトの状態、プロジェクトポートフォリオ全体の健全性が見えにくくなってしまう。プロジェクトの観点から見ると、プロジェクト管理ツールを使わないことによる大きな弊害は、きちんとしたスケジュールを持たず、個別のタスクを管理するだけになってしまうことだ。プロジェクトの規模が大きい場合や、リソースに制約がある場合、期限が厳しい場合、作業の依存関係が多い場合には、これではリスキーだ。
(後略)

以前のソフトウェア開発では、期間も長く、資金も潤沢にあった。
そして何よりも、コンピュータ資源のコストが高く、誰もが湯水のように使える代物ではなかった。
だから、ツール無しで開発するのが普通だった。
プログラミングも机上デバッグが普通だったし、プロジェクト管理もマネージャ個人の能力に依存していた。

しかし、現在のソフトウェア開発は短納期で低コストで開発せねばならない。
従来と全く異なる条件は、コンピュータ資源のコスト、プログラミングのコストが劇的に安いことだ。
Webサーバーは素人でも1万円以下で構築できるし、Railsのような優れたWebフレームワークのおかげで、技術力さえあれば簡単にWebアプリを作れる。

現在のソフトウェア開発がSubversionやGit、Mercurialのようなバージョン管理無しで開発できないように、プロジェクト管理もRedmineやTracのようなツール無しではマネジメントの品質も落ちる。
更に、テスト工程におけるテスト計画・実施・集計のようなテスト管理も、TestLinkのようなツール無しでは、プロセスの品質を担保できない。

これらのツールには、マネジメントのベストプラクティスが含まれている。
ツールを使いこなせば自然に誰でもマネージャとして意思決定できる。

昨今のわずか20人月のソフトウェア開発でも、LOCは数万行を軽く超えて、テストケースは数千を超える。
これだけ複雑になったソフトウェア開発のプロジェクト管理を、Excel上でチマチマと手作業で管理するのはもはや現実的ではない。

巷にはソフトウェア開発のプロジェクト管理、テスト管理、品質管理、ソフトウェア工学に関する本が溢れている。
でもそれらは殆どが抽象的過ぎて、実際の現場で運用するにはハードルが高い。
特にソフトウェア工学に関する知識は、とても勉強になるが、実際の現場では使いづらい。
ソフトウェア信頼性モデル、要件カバレッジ、テストカバレッジ、障害管理などいずれの概念も、ツール無しでは実現できない。

ソフトウェア開発の諸問題は、過去の経験から得られたノウハウを専用のツールの機能へ実装して、そのツールで解決していくしか方法がないのではないか？

ツールでプロセスを改善する。
ソフトウェアでソフトウェア開発の諸問題を解決していく。

アジャイル開発のFAQ

アジャイル開発のFAQについてメモ。

【1】アジャイル開発のような繰り返し型開発は、作業やリソースの重複が多くて生産性が低いのではないですか？

【回答】最初のイテレーションは試行錯誤しがちですが、イテレーションをこなすたびに慣れていき、生産性は上がっています。

特にSW開発は常に新技術を取り入れているので、開発者の学習曲線を考慮する必要があります。
アジャイル開発では、開発者の成長を意識的に支援するプラクティスが含まれています。

例えば、イテレーション毎にふりかえりMTを開いてプロセス改善する意識を開発者に植え付けますし、ペアプログラミングで開発者と技術や設計思想を共有するプラクティスもあります。

特に、プロジェクトファシリテーションでは、開発者の成長を促進するプラクティスが多々あるので参考にしてみてはいかがでしょうか？

【2】開発を繰り返すから、コストが高いのでは？

【回答】最初のイテレーションはコストは高いですが、トータルのコストはWF型開発よりも減るはずです。

1，2回目のイテレーションでは、実現できる機能も少なく、開発者も開発よりもリリース作業に手間取って、試行錯誤するので、コストはかかります。
しかし、イテレーションをこなすたびに、リリースのリハーサルを何度もしているので、リリース作業よりも開発に専念でき、開発者もシステム設計や業務に慣れていくので、後工程ほど生産性も上がります。

しかし、WF型開発の場合、仕様変更やリスク対処などの手戻り作業に工数を取られて、後工程ほど本来の作業に混乱が生じがちです。
そして、最後の一発リリース作業でいろんな問題が発見されると大きなコストがかかります。
更には、リリース後の不具合修正や改善要望が膨大に来た場合、更にコストは増えます。

アジャイル開発では、イテレーション単位に開発するため、顧客のフィードバックや障害修正を次のイテレーションで解決する方向へ進めるので、リスクを早期に対処する余地があるのです。

【3】アジャイル開発のような短期間の繰り返し型開発は、何でも早くリリースするから、品質が悪いのではないですか？

【回答】アジャイル開発と言っても、品質管理に奇策はありません。
InfoQ: James Shore氏「アジャイルの衰退と凋落」のように、戦略のない単なる繰り返し型開発は、本来のアジャイル開発ではないのです。
リリースする時点で品質を確保できてなければ、リリース後に山のようなクレームがやってきます。

また、アジャイル開発でもXPは、テスト駆動開発や継続的インテグレーションのように、コードラインの品質管理について、従来の開発にはない観点をもたらしています。

【注意】
アジャイル開発での品質管理は、上記の回答では不十分で、まだ弱点があるように思う。
従来の開発スタイルに比べて、その優位性を明示できていないように思う。
そこに、RedmineやTestLink、Mercurialなどのツールでアジャイル開発を補強できる余地がある。

要件定義の疑問

要件定義や設計という上流工程について以前から感じていた疑問をメモ。

【1】以前から、オブジェクト指向モデリングやらデータモデリングやらビジネスモデリング等の本を漁ってきたけれど、どれもあまり役立たない気がしている。
何故だろう？

モデリングや要求分析が必要になる場面は、新規顧客の受託開発で、顧客からシステムの要件をヒヤリングしたり、その後の仕様確認の時だ。
つまり、設計しながら要件を詰めていく作業で、モデリング技術が必要になる。

しかし、OOAもDOAもあまりピンと来ない。
RUPは確かに勉強になるが、膨大すぎて現場の実践に向かない。

UMLを使ってモデリングするのは確かに思考の整理に役立つが、それはむしろ実装に近いフェーズだ。
概念モデルのクラス図を書いたとしても、ユースケース記述で業務仕様を書いたとしても、何か物足りない。

むしろ、OOAよりもDOAの方が実践的だと感じる時がある。
テーブル設計をしながら、実際に実装している感覚だ。
特に、RailsやSeasarのように優れたフレームワークがあるおかげで、DBの箱さえ決まれば、RubyやJavaで簡単に作ることができる。

でも、DOAのデータモデルパターンは洋書しかなく和書が存在しない。
良書は、渡辺さんの本や「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」などごく一部だけだ。

OOAの本は抽象的過ぎる。
確かにクラス図を描くスキルは上がるが、実装モデルに程遠い。

OOAは最終的にはMDAがやりたいだけなのだろうと思う。
モデルさえ書ければ、プログラムを自動生成してくれるというMDAの発想。
その発想は理想的過ぎるように思う。

顧客の業務のフローやエンティティを導出するのにOOAは非常に役立つが、むしろ、システム設計ではクラス図よりも状態遷移図の方が重要だという気がしている。
我々SEがシステムエンジニアであるという意味は、業務を知ることよりも、業務をシステムへマッピングすることがSEの役割だからだ。

システム化する上で最も重要なポイントは、業務をシステムとみなした場合、システムの状態を導き出し、その遷移を全て記述することだ。
システムの状態とは、そのシステムで最も重要なエンティティの状態を表し、DBに落としたらフラグとして現れる。
そのフラグのCRUDを表した物がシステムの状態遷移図に当たる。

システムの状態遷移図を緻密に描くほど、システムの整合性を考えやすく、そこから要件漏れや設計漏れに気づく。
状態遷移図があれば、それからテストケースを作ることができる。
そして、普通は、システムが大きいほど状態遷移図は複雑であり、状態爆発を起こす。
テストケースは膨大になり、どこまでテストすれば品質を担保できるか、SEとしての技量を問われる。

【2】要件定義でいつも疑問な点は、システム化する技術力よりも顧客へのヒヤリング能力と言う人間関係構築能力の方を重要視されることだ。
昨今の人間系、特にファシリテーションもその一環と捉えることもできるだろう。

しかし、技術力が軽視されていないか？
ヒヤリング能力が重要と言っても、顧客の業務をロジカルに整理して、要件の一覧をMECEで導き出す技術も必要なはずだ。
ヒヤリング能力、ファシリテーションだけでは、要件定義を解決できない。

その点で、清水吉男さんが提唱する派生開発プロセスXDDPに興味はある。
XDDPでは、要求を発見することよりも、要求を表現することに力点を置く。
要求仕様と機能仕様を厳密に区別し、変更理由も書きながら、要求仕様を機能仕様へ階層化しながら詳細化していく手法。
この手法ならば、機能仕様へ詳細化する時に、仕様に漏れがないか、重複がないか、自然に考えれるようになる。

また、XDDPで面白いと思ったのは、要求には機能要件だけでなく、保守性や信頼性、性能要件のような非機能要件も含めるという点だ。

例えば、保守性の要件では、関数の複雑度は15以下とする、など。
信頼性や性能要件でも、ボタン押下後のレスポンスは1秒以内とする、など。

これらの非機能要件は実際のSW開発では設計漏れしがちなのだが、漏れなく仕様化できるプロセスがXDDPにはある。

普通のSW開発では、顧客はSEでないからシステム化の技術に疎く、顧客の言うがままに作ってしまうと、必ず要件漏れが発生する。
要件定義では、要件を漏れなく全てを洗い出すこと(MECE)が重要だと最近は思う。

【3】アジャイル開発は、要件定義に関して一種の諦めがあるように思う。
アジャイル開発における要件定義の特徴は、仮説検証スタイルであることだ。
つまり、短期間のイテレーションを繰り返して開発しながら、顧客のストーリーを少しずつシステム化しては、顧客に確認してもらい、フィードバックを受けながら、更に修正していく。

この繰り返し型開発スタイルは、全ての要件は最初に決められないという仮定の下で、安定した重要な要件から少しずつ開発していくという発想に基づく。
WF型開発のように、最初に全ての要件を決めていくのは現実のSW開発では無理で、すごくリスクがあるという仮定に基づいている気がする。

また、オンサイト顧客というXPのプラクティスでは、顧客を開発チームの近くに置き、常に要件を確認できる状態にする。
実際の受託開発では、顧客を開発チームの内部に配置できないケースも多い。
その場合、顧客と関係が近く業務が詳しい上級SEが顧客の代わりになるという顧客プロキシという手法もある。

また、Scrumのプロダクトバックログというアイデアもある。
顧客の要求を一旦バックログと言う貯蔵庫に貯めて、リリース計画から、そのスプリントで実現する要求をプロダクトバックログからスプリントバックログへ移す。
つまり、要求をリリース計画や優先度に基づいてふるいにかけるというマネジメントが含まれている。

アジャイル開発では、要件定義や開発スタイルに関しても、従来のWF型開発では明示されない解決方法を提示しているように思う。
まさに「1回のリリースは100回のレビューに勝る(プログラマの思索)」。

【4】要件定義や設計プロセスで重要だと思う点は、要件カバレッジと要件の追跡だ。

顧客が提示した要件は、漏れなく全て、仕様書やプログラム、テストケースに反映されているか？
顧客が提示した要件が、どの設計書に仕様化されて、どのプログラムに実装されて、どこでテストされて、どのバージョンのモジュールに反映したのか？

現場では、上記の作業をプロジェクトリーダーやSEが手作業で確認し合っているようなものだ。
だからすごく非効率で生産性が低く、結果的にシステムの品質も低い。

開発プロセスが整っていないプロジェクトでは、要件や仕様にIDが振られていない時が多い。
すると、今どれだけの要件がテストで検証されたか、どこまで要件を網羅しているか、集計できない。

「要求は数えられたら品質が上がる(プログラマの思索)」のだ。

要件にIDが振られて初めて、要件の追跡が可能になる。
現状のチケット駆動開発では、「BTSチケット→SVNリビジョン→Hudsonのビルド番号」までは相互のトレーサビリティを実現できている。
そして、TestLinkでは「要件→テストケース」の相互のトレーサビリティが実現できている。
だから、BTSとTestLinkの間のトレーサビリティを可能になれば、要件やテストケースがチケット経由でビルドモジュールのビルド番号まで追跡可能になる。

このアイデアを膨らませたものが「プロジェクト管理サーバー」。
そのアイデアは「アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索」に書いた。

つまり、「プロジェクト管理サーバー」の最終ゴールの一つは、要件カバレッジと要件の追跡をリアルタイムに集計して、管理作業を減らし、本来の開発作業に専念できるようにすることだと思っている。

SRATSの使い方

ソフトウェア信頼度評価ツールSRATSの使い方がようやく分かったのでメモ。

【元ネタ】
信頼度成長曲線 - Wikipedia

SRATS:Software Reliability Assessment Tool on Spreadsheet Software

SRATSダウンロード

ソフトウェア信頼性評価 における最近の話題

信頼性評価ソフトウェア

ソフトウェア信頼度評価ツール - 脱・下流エンジニア (仮)

Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな？Rubyグループ

SRATSは、広島大学の岡村さんが作ったソフトウェア信頼度(SRM)を評価するExcelマクロ。
バグ情報をCSV形式で用意さえすれば、信頼度成長曲線(SRM)を自動生成することができる。
garyoさんから、このツールの存在を教えてもらった。

信頼度成長曲線が必要な理由は、システムのリリース判定の参考資料として使いたいからだ。
つまり、システムは納品しても大丈夫な品質なのか、その意思決定をする時に数値資料として扱いたいからだ。

SRATSの最大の特徴は、SRATSマニュアルにもあるように、ソフトウェアのMTBFまで計算できる点にある。

・Total: 対象とするソフトウェアに潜在する総フォールト数
・FFProb: 現時点でフォールトがすべて除去されている確率
・MTBF: 次のフォールトが発見されるまでの時間
・Be X Life: 次のフォールトが発見される確率が０．９となる時間（その時間までに１つ以上のフォールトが発見される確率が９割）

情報処理試験の知識によれば、下記の公式が成り立つ。

MTBF＝平均障害故障間隔(人時／件)
故障率＝１／MTBF（件／時間）

HDDや組込み機器では、MTBFやMTBR、稼働率が製品情報として含まれている。

稼動実績からハードディスクドライブ(HDD)の環境別MTBFを割り出す ? SawanoBlog.

例えば、HDDの場合、MTBFが100時間ならば、100台のHDDのうち100時間経つと1個で故障が発生していることになる。

以下、MantisやTestLinkからSRMやMTBFを計算してみたので、その使い方をメモしておく。
僕は、信頼度成長曲線の理論的背景の知識は情報処理試験レベルなのでよく知らないので、あくまでも参考程度にして欲しい。

【使い方1～Mantisからバグ情報を作り、SRATSでSRMを出力する】

Mantisの検索一覧からCSV出力後、下記のgaryoさん作成のRubyスクリプトを使って、CSVを加工する。

Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな？Rubyグループ

そのCSVを開き、累積時間と日別バグ数の表を作る。
注意点は、時間(工数)は累積にすること。

そして、SRATSから、累積時間と日別バグ数のセル範囲を選択して、「Normal SRM」を選択後、Reportボタンを実行する。

すると、上記4種類の数値とSRMのグラフがExcelで出力される。

【使い方2～TestLinkからバグ情報を作り、SRATSでSRMを出力する】

TestLinkCnvMacroのstatisticToSheetから、テスト実施日と失敗数を切り抜く。
Mantisの時と同様に、累積時間と失敗数の表を作る。
そのセル範囲を指定して、SRATSから「Normal SRM」を選択して出力する。

【感想】
SRATSのサンプルでは、MTBFの数値が17.8と出力されて、「該当ソフトウェアは十分な信頼度を達成しているので，追加のテストは必要としない」という結論が出ている。
これでは、システムが稼動する1日を8時間と計算した場合、1ヶ月(160時間)にも満たないから、1ヶ月経つとバグが出る可能性がある。

しかし、Fault-Free Prob.(現時点でフォールトがすべて除去されている確率)は80％以上だったので、品質は確保できたと考えられる。
この結論が組み立てられた詳細な理由が分からないが、他の数値も見比べて、SRMの理論から結論付けられたのだろうと思う。

品質保証部門が社内に存在して、きちんと稼動している会社(特に組込系)では、信頼度成長曲線をリリース判定時の品質チェックに使っていると聞く。
その運用ノウハウを知りたいけれど、おそらく守秘義務としてなかなかオープンにされにくいのだろう。
しかし、昨今はMozillaやEclipseのようにオープンソースのプロジェクトで、BTSデータが公開されているので、それを使って、信頼度成長曲線などのソフトウェア工学の研究ができるようになった流れもある。

また、信頼度成長曲線の見方についても昔から異論がある。
信頼度成長曲線 - Wikipediaにも書かれているように、「収束を見る場合に、横軸に日付を使った場合、テストをしていないからバグが出ないのか、テストをしてもバグが出ないのかの区別がつかないという問題がある。」
信頼度成長曲線そのものが信用できないケースもあるからだ。

しかし、実際の現場ーリーダーならば、開発の現状を知り尽くしているはずなので、信頼度成長曲線の数値に信憑性があるかどうか、リーダー個人で判断できるはずだと思う。

SRATSを使って、どこまでシステムの品質チェックができるか試してみたい。

チケット単位に並行開発する事例

分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。

【事例1】
gitだからこそできるチケット駆動開発のやり方 - kunitの日記

今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。
たとえば会員管理の機能に追加したい場合は以下のような手順になる。
1. 会員管理を拡張したいなぁ
2. じゃRedmineでチケットを切るぞ
3. チケット番号が振られた(たとえば #567 だとする)
4. さぁ、ブランチ切るか(members_567)
5. そのブランチで作業開始！
濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。

【事例2】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

ticket毎に開発作業用branchを作成する
* 同期branchから作成する
* 同期branchから随時rebaseする
* 必ず、同期branchの最新版からrebaseした状態でテストを行う。
* テストが通ったらticket別branchから同期branchにmergeする。その後、同期branchの内容で中央リポジトリにcommitする。
o 同期branchにmerge後、ticket別branchはinactiveなbranchになる

いずれの事例も、作業する時はチケットを作り、trunkから切ったブランチにチケットNoを紐づけて運用する。
つまり、チケット単位にブランチを作り、そのブランチ上でソースの修正を行い、作業が完了したらtrunkにマージしてチケットが終了する。

分散バージョン管理では、ブランチは中央リポジトリではなく、開発者個人のローカルなリポジトリに作られる。
つまり、SVNやCVSのような中央集権的バージョン管理ではローカルの開発環境で作業していたコードラインを、GitやMercurialのような分散バージョン管理では、明示的に開発者のローカル環境のブランチとして作業できる。
その利点は、trunkとは別個に作業履歴を残せること、そして、分散バージョン管理の優れた自動マージ機能のおかげで、trunkにすぐに反映できることだ。

そして、このブランチをチケットに紐付けて、作業ステータスを管理できるようにする。
このやり方をトピックブランチと呼ぶらしい。

SVNなら管理しづらいブランチも、分散バージョン管理では普通の状況であり、その利点をフルに生かしている。
しかも、チケット駆動開発と絡めれば、トピックブランチの作業状態もBTS上でリアルタイムに把握できる。

このトピックブランチは、プライベートブランチ、タスクブランチの一種とも言えるが、チケット駆動開発とかなり相性がよい。
トピックブランチをチケットブランチと言ってもいいくらいだ。

特に、作業者が複数人の場合、更には大規模プロジェクトで並行開発する場合、あるいは、組込製品やパッケージ製品での並行開発で、このやり方は大きな威力を発揮するのではないか？

アジャイル開発が事実上、並行開発せざるを得ないように、チケット駆動開発はソフトウェア構成管理と密接に関係する。
その理由は、チケット駆動開発と並行開発の相性が良いから。

元々、Redmineでは、1リポジトリ＝1プロジェクトの運用思想のため、ブランチ単位にRedmineプロジェクトを作る。
この複数プロジェクト機能を使えば、チケット駆動開発を並行開発のインフラにできる。

普通は、並行する2本のライン(trunk, branch)はプロジェクト単位だが、上記のトピックブランチはチケット単位でブランチを管理する。
つまり、BTSのプロジェクトとチケットで観点を変えて、ブランチを管理すればいい。

分散バージョン管理とチケット駆動開発の組み合わせは、並行開発の管理を劇的に効率化する可能性があると思う。

ブロッキングバグの事例

TestLinkのテスト実行画面には「成功」「失敗」の他に「ブロック」がある。(ソフトウェアテスト標準用語集 日本語版Ver 1.3)
普通は、失敗時に、失敗したテストケースに依存するテストケースをブロックにして、テスト保留にする。

ここで、ブロッキングバグとは、失敗したテストケースの機能のバグのうち、リリースを妨げるような重大なバグを指す。
ブロッカーバグとも言われるらしい。
更に、ブロックしたテストケースの機能は、みなしバグと呼ばれる。

Tracのチケットでは、緊急性が最も高い優先度が「blocker」になっているが、ブロッキングバグはそれに当たると思う。

このブロッキングバグの事例を見つけたのでメモ。

【事例1】
ある会社の新人チームが開発後テスト中にブロッキングバグに遭遇した事例が書かれている。
緊迫した内容がリアルで、とても素晴らしい。

コラム[直し壊しのテストフェーズ]‐株式会社アーツテック[ARTSTECH]

特に、結合テストやシステムテストでは、バグ修正と同時にテストデータの準備や本番環境の構築作業を行わなければならない。
この時に、どの作業を優先して行うか、意思決定が迫られる。

普通は、ブロッキングバグを最優先に直すのが先だ。
理由は、ブロッキングバグが直らないと、未検証の機能はみなしバグの状態になってしまい、テストしても無意味だからだ。
ブロッキングバグはまさにリリース不能にさせるバグ、プロジェクトの動き全体を文字通りブロックしてしまう危険なバグなのだ。

【事例2】
Mozillaが安定していなかった頃のQAメールのやり取り。

もじら組フォーラム [One Topic All View / Re[7]: Mozilla 1.3 for Mac OS X でメールフォルダ名が文字化け / Page: 0]

(前略)
ただですらユーザの少ないMac版のしかも日本語処理のバグなんで声を出さないとなかなか注目を浴びないと思います。
Bugzilla-jpでバグを立てると国内の有志が協力してくれるとしょう。
どちらも内容的にはブロッキングバグになってしかるべきものと思います。
(後略)

もじら組フォーラム [One Topic All View / Re[1]: Mozilla 1.4 リソースリーク? / Page: 0]

(前略)
1.4は1.0.xに変わる安定系という役割なのに、何を焦っているのか、ブロッカーバグをつぶさずリリースしたことが、今回の失態につながっている。
MozillaはともかくNetscape 7.1は大問題だと思う。
これさえなければ、Netscape復活といえる出来なだけに誠に残念。
ショボイOSにも問題はあるが、早急に修正版を出して欲しい。
(後略)

ブロッキングバグを無視してリリースしてしまった為、ユーザから製品に対する信頼を落とした事例として非常に耳が痛い。
ブロッキングバグを残したままリリースした場合、ブロックした機能は未検証のため、品質に疑問符が付いたままになる。

結局、ユーザにブロックしたテストケースを再テストさせているようなものだ。
つまり、みなしバグをユーザがテストして、はっきりとバグと判明させたようなもの。
プロの技術者として恥ずかしいだろう。

テスト管理には、プログラミングとは違った特有の技術があるように思う。

TestLinkの要件管理機能

TestLinkの要件管理機能についてメモ。

【元ネタ】
要件のテスト - watawata日記

TestLinkの可能性: プログラマの思索

要求管理(要件管理)ツール RaQuest

要求管理ツールRaQuest・要求項目の作成

要求管理ツールRaQuest・ツリーと一覧を駆使した要求項目の効率的な管理

要求管理ツールRaQuest・要求の追跡

TestLinkの機能とV字モデルの関係 (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP

テスト管理ツールTestLinkには不十分だが、要件管理機能が付いている。
TestLinkCnvMacroを使えば、TestLink要件をTestLinkキーワードを経由して、TestLinkテストケースとN対Nの関係に持ち込むことができる。

この紐づけによって、要件カバレッジが可能になり、キーワード別にテスト結果を集計できるため、要件が今どこまでテストで検証できたか、を表示することができる。

つまり、TestLinkの要件管理機能を使って、要件定義や設計工程で要件カバレッジを取りながらテスト設計すれば、W字モデルのような開発が可能になる。
すなわち、上流工程でテスト設計の作業ができるので、設計工程の成果物を検証する作業も可能になるだろう。
テスト駆動開発を製造工程だけでなく設計工程など上流工程へ持ち込めるだろう。
特に、要件カバレッジはテストケースの品質に大きな威力を発揮する。

この場合、TestLink要件を顧客の本来の要件と対応させた時、その要件は受入テストのテストケースに対応付けられる。
すると、単体・結合・システムテストのテストケースに相当するTestLink要件は一体何に当たるのか？

そのTestLink要件は、単体・結合・システムテストの上流工程に当たる製造・内部設計・外部設計の仕様に当たるだろう。
各工程の仕様を網羅する観点で、テストケースを作っていけばいい。

すると、各工程の仕様や要件はどのように関連付けられるか？
それは、要件から外部・内部・詳細設計の仕様までの関係、ツリー上に詳細化されていくと考えてよいだろう。
製造工程における仕様は遡れば、要件まで辿りつく。

つまり、要件はツリー構造であるべきだ。
すなわち、TestLink要件は現状のCSV形式の1階層の構造ではなく、TestLinkテストスイートのように階層構造を持つべきだ。
そうすれば、顧客の要件から製造工程の仕様まで追跡可能になる。

更には、TestLink要件の各階層が単体・結合・システム・受入テストのテストケースと対応づけられればよい。
そうすれば、単体～受入テストの各工程で仕様・要件カバレッジが可能になる。

TestLinkの要件管理機能は正直使い勝手が悪く、発展途上の機能。
TestLinkの要件管理機能のあるべき姿は、EnterpriseArchitectの要求管理ツールRaQuestのように、要件の状態管理や履歴管理、要件の追跡機能が実現されることだろう。
そうなれば、要件カバレッジ機能がより簡単に使えて、テストケースの品質アップに大きく貢献するだろう。

オープンソースのテスト管理ツールTestLinkには大きなポテンシャルがあると思う。

XDDPの資料リンク

清水吉男さんが提唱されている派生開発プロセスXDDPの資料がネット上にあったのでメモ。

【資料１】
JaSST2009東京・派生開発における母体に由来するバグとその対応・清水 吉男（システムクリエイツ）

JaSST2007東京・要求の品格1：テストの質を上げるための要求仕様書・清水 吉男（システムクリエイツ）

いずれもJaSST東京(SWテストシンポジウム)で、XDDPの開発スタイルの概要が講演資料として公開されている。
XDDPの成果物の3点セット(要求仕様書・変更設計書・トレーサビリティマトリックス(TM))とそのプロセスが分かりやすく説明されている。

XDDPの一番の肝は、トレーサビリティマトリックス(TM)だ。
TMが変更要求仕様(What)と変更設計書(How)を関連付ける資料となる。
TMで変更要求が機能にどれだけ影響しているか一覧できるので、TMを詳細化するプロセスが自然に仕様化プロセスになる。

【資料2】
SQIP2008・6-1.XDDPによるソフト派生開発のQCD向上活動・加藤 由之（(株)デンソー）

SQIP2008(SW品質シンポジウム)で、XDDPを現場で実践した運用例が経験論文で公開されている。
XDDP運用2年目のプロセス改善の結果が、SQIP2009でも経験論文として掲載される予定だ。

【ツール例】
日々精進 - スパークスシステムズ ジャパン代表のBlog:プロセスフロー図(PFD) - livedoor Blog（ブログ）

Enterprise Architect・プロセスフロー図(PFD)描画アドインについて

つい最近、Enterprise Architectにも、清水さんが編み出したプロセスフロー図(PFD)を描けるプラグインが提供された。
PFDは成果物とプロセスをつないだDFDのような絵。
PMやPLのように、開発プロセスを設計する人達は使ってもいいかもしれない。

『～ It!』シリーズの本は良書

【元ネタ】
エンジニアがタイトル買い、著者買いすべき本 - {Fight the Future => じゅくのblog}

『～ It!』シリーズの本は確かに良書だ。
『～ It!』シリーズの本は3冊ある。

「 Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」は、プログラマが身に着けるべき習慣が書かれている。

「Release It! 本番用ソフトウェア製品の設計とデプロイのために」にあるノウハウは、Webシステムの環境構築やリリース作業で非常に役立つだろう。

「Manage It! 現場開発者のための達人式プロジェクトマネジメント」は、開発者のためのプロジェクト管理、特にアジャイル開発の導入に関するノウハウが書かれている。

後日、読んだ感想を書いてみる。

アジャイル開発が並行開発になる理由

アジャイル開発が並行開発になる理由をメモ。

【元ネタ】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

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

派生開発プロセスXDDPの講演メモ: プログラマの思索

普通の受託案件で、アジャイル開発を実践していて、新規開発中だったと仮定する。
リリース計画としては、最終目的はver1.0をリリースするように作るだろう。
イテレーション計画としては、Ver1.0のイテレーションを作るか、マイルストーン単位に複数のイテレーションを作るだろう。

リリース予定のVer1.0に向けて開発中で、trunk以外にコードラインは存在しないだろう。
開発者は、trunkだけに集中してコミットしていく。

そして、Ver1.0をリリースするタイミングになったと仮定する。
リリース担当者は、trunkからver1.0のtagを切り、ver1.0のリリースブランチを作る。

その後、Ver2.0のイテレーションを作り、開発者は次のバージョンに向けてtrunk上で開発していく。
普通に考えるならば、アジャイル開発もWF型開発も並行開発にはならない。

しかし、実は、リリースしたVer1.0へ障害対応するために、Ver1.1のイテレーションを作り、ver1.0のリリースブランチ上で作業せざるを得ない。
つまり、Ver2.0に向けて機能追加に対応するtrunkと、Ver1.0のバグフィックスに対応するリリースブランチの2本の並行開発が自然に必要になる。

リリースしたバージョンに対するイテレーションは、引き続き保守のためのイテレーションが続いていくのだ。
だから、リリースブランチで本番運用中のソースを保守しながら、裏のtrunkで機能追加のソースをガンガン開発していく並行開発になる。

すなわち、システムはリリースしたら、それで終わりと言うわけではない。
むしろ、システムを育てていく観点が大事だ。

WF型開発は、Ver1.0のシステムをドカーンと一発リリースして、その後、大量のバグ修正や改善要望に忙殺されるのが殆どだ。
WF型開発があまりにも理想的な開発スタイルで現場の運用に馴染まない理由は、Ver1.0だけの開発プロセスに過ぎず、運用保守を含めた全体的なソフトウェアのライフサイクルの観点が漏れていることだと思う。

この並行開発は、組込み製品やパッケージ製品の開発で発生し、その構成管理や開発プロセスが非常に難しくなることは昔から知られていた。

並行開発の難点は二つあると思う。
一つは、1本のコードラインをリリースまで持っていくのも大変なのに複数のコードラインを保守せざるを得ず、品質維持が難しい点。
もう一つは、リリースブランチの障害修正をtrunkへマージする、あるいは、共通ライブラリの修正点を他の製品ラインへマージする作業が発生すること。

この並行開発に対し、SW工学の観点から、SWプロダクトラインが対応しようと試みている。
つまり、共通ドメインのコア資産と各製品特有のドメインをアプリケーション資産に分けて管理する発想。
しかし、並行開発の諸問題を全て解決できたとは聞いていない。

並行開発に関しては、いくつかのアプローチは知られている。
一つは、緊急の機能追加に対応する場合、タスクブランチを活用すること。
やり方は下記に書いた。

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

また、清水吉男さんが提唱する派生開発プロセスXDDPは、追加と変更の2本のタスクブランチを作る。
考え方は下記に書いた。

派生開発プロセスXDDPの講演メモ: プログラマの思索

つまり、いずれも故意に並行開発を選択することで、要求の変更に対応しようとする。
但し、いずれも難易度は高いと思っている。

そして、並行開発が難しいのは、根本的には構成管理の技術に落ち着くと思っている。
ブランチの品質保持とマージ作業の自動化が鍵。
CVSからSubversion、そして、GitやMercurialに至るバージョン管理の技術の流れも、並行開発の観点から整理できると思う。

従来の組込み製品やパッケージ製品だけでなく、昨今はWebシステムやオープンソースでも並行開発が当たり前の状況になったのに、並行開発の諸問題を解決する方法、特に構成管理の技術が意識されていないのは不思議だと思う。

【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」

第4.5回Shibuya.trac に参加して発表してきた。
スタッフの皆さん、ありがとうございました。

その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。
今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。

RedmineとTracの機能比較～TiDDに必要な必須機能

View more presentations from akipii .

SPES2009やSQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。
でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。
関西から八朔さんや小枝さんも来てくれて心強かった。

最後のパネルディスカッションでは、5人のパネラーにTiDDをKPTの観点で経験談や苦労話を語ってもらった。
実際の運用事例を5人の経験の観点から話せたから、とても参考になったと思う。

＃パネルディスカッションの内容は下記で公開されている。
meeting/04.5/PanelDiscussion - Shibuya.trac Wiki - Shibuya.trac - SourceForge.JP

また、僕のBlogをたくさんの人が読んでくれていた事実も気付かせてもらい、更にフィードバックももらって非常に参考になった。

最近思うのは、ノウハウはどんどん公開した方がいいこと。
僕がRedmineやTestLink、そしてMercurialを使って経験したこと、考えたことは基本的にBlogで公開するようにしている。
最初は、Blogに書きながら僕が考えていることを整理しているだけだった。
でも、Blogにコメントがあったり、コミュニティでBlogの記事に関して質問を受けたりして、思索を深める上でとても参考になった。

KOF2008、XP祭り関西2009、ETWest2009の発表資料を公開した時、クリエイティブ・コモンズ・ライセンスにしている。
このライセンスにした理由は、チケット駆動開発の提唱者であるまちゅさんが自分の資料をそのライセンスで公開していたから。
でも、このライセンスにして良かったと思っている。
このライセンスのおかげで、僕が考えたというクレジットを付けてくれれば、誰もが自由に流用でき配布できる。

僕が色々考えたアイデアは、僕がたくさん汗をかいて経験した後で気付いた結果だが、色んな人の影響も受けている。
チケット駆動開発と言うアイデアは僕一人のものではないし、むしろ、興味ある人達がよってたかって知恵として固めようとしている最中。

勝間和代の本に「情報は通貨である」という文言があったけれど、まさに実感する。
ノウハウはお金と同様に、貯めても意味がない。
貯めたお金は投資して、生産性を上げて富を増やして意味をなす。
ノウハウもどんどん公開して、みんなに使ってもらって、フィードバックを受けて、より良いものへ修正していくほど、価値が上がる。

特に技術者にとって、ノウハウを公開して自分の技術力を知らしめることができれば、自然に営業できる。
Blogに記事を書いたり、SourceForgやGoogleCodeでソースを公開すれば、Googleの検索エンジンが拾って関連付けてくれて、一つのノウハウが色んな人達のノウハウと積み重なって、大衆の知恵のように一つのプラクティス、あるいは思想になる。

オープンソース、あるいはBlogと言うからくりは、技術者にとってすごく重要な仕組みだと思う。

この記事を読んでいる人達、チケット駆動開発を実践している人達には、是非、自分の考えを発信して、色んな人に影響を与えて欲しいと思う。

レビューをTestLink＋Redmineで管理できないか？

SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。
＃後でまとめる。

SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。
上流工程の品質UPが鍵を握る。
そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。

しかし、設計レビューそのものの品質が低いように思う。
僕がいつもレビューで問題と思う点は、二つある。

一つは、レビューのプロセスがあいまいできちんと定義されていないこと。
例えば、レビューする際の観点がレビューアによってまちまちだったりする。
レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。

もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。
例えば、レビュー後修正の品質チェックが個人任せで、他人のチェックができていない。
その原因は、レビューアの人数不足でレビューそのものが遅れがち、などがある。

議論を聞きながら思ったことは、「レビューを設計工程のテスト」を考えられないだろうか？
設計書をレビューのチェックリストに基づいて、ウォークスルー形式で検証しているのではないか？
となると、レビュー後修正は、設計のバグ修正に当たるのではないか？

つまり、レビューを設計のテストと考えると、下記の相関関係が成り立つのではないか？

レビューのチェックリスト＝TestLinkのテストケース
レビュー結果＝TestLinkのテスト結果
レビューで指摘を受けた内容を修正＝Redmjneでバグ修正

すると、TestLinkのビルド、ブロックはレビュー工程でどのように対応するのか？
まだ分からない。

設計工程やレビューでいつも腑に落ちないのは、Excelばかり使っていて、作業状態の把握や集計作業が大変なこと。
チケット駆動開発にレビュープロセスをのせることができれば、プロセスをBTSのワークフローで管理できるし、レビューの漏れがなくなるのではないか？

RedmineやTestLink、Mercurialなど各種ツールを使いこなすと、下流工程のプロセスはツールで制御できるようになる。
しかし、上流工程、つまり要件定義や設計をチケット駆動開発が制御するのは不十分。

色々考えてみたい。

派生開発プロセスXDDPの講演メモ

SQIP2009で清水吉男さんのXDDPの講演を聞く機会があった。
アジャイル開発や並行開発、要求仕様と機能仕様の違いについて、とても勉強になったので、メモを公開しておく。
なお、メモ書きなので、分かりにくい部分は、下記の著書を読んで理解してください。

【講演メモ】
◆派生開発の特徴と問題点
保守開発
　JISで定義されている
　派生開発とは似ているが異なる
　　例：携帯電話は、電話以外の機能が次々と追加されている
　　　　保守ではない
→是正保守プロセスで改良保守を行うと問題が発生する

派生開発特有の混乱が生じている
　まずい作業で品質が劣化する

派生開発にはアーキテクチャ設計がなくても開発できる

仕様は設計しないと出てこない
　衝突は仕様レベルで出る

派生開発は新規開発よりも複雑
　追加機能と変更は異なる
　機能追加は、新しい機能の仕様やレビューしかない
　　追加と変更の2本立てにしなければならない

ソースも移植に伴い、拒否反応を起こす
　プログラムは、既存のシステムのために作られた
　しかし、他のシステムへ再利用すると、文化が違うので、拒否反応を起こす
　　免疫、臓器移植と同じ

変更方法も一つとは限らない
　例では3つ方法がある
　どれもテストOK
　しかし、1年後に問題になる
　　何のために要求が来たのか？
　　表示欄が足りないのが本来の要件

一つの変更が複数の機能にまたがる
　機能同士の依存関係
　　データなど
　　気付きやすい
　設計やプログラミングによって影響する
　　設計書に変更内容が反映されていない
　　
　　ネームロンダリング
　　　引数に渡ったデータパターンが悪さする
　　クローンコード
　　　移植するとアルゴリズムは同じだが変数名が変わるので同一ではないと見てしまう

派生開発は「部分理解」の制約が多い
　やっぱり全体を理解していない、という言葉が反省会でよく出る
　皆が納得して終わっている
　　リソースが足りないので全部を調べきれない
　　理解のレベルが曖昧
　　　理解できなかった時の対応方法が考えられていない
→部分理解しかできないのだ、という仮定で進めよう
→どのタイミングでどのようにレビューするか、が非常に重要

派生開発は一人プロジェクトが多い
　一人プロジェクトはやめよう
　　部分理解の罠に陥りやすい
　　　思い込み、勘違い
　擬似一人プロジェクトもある
　　大人数チームでも、担当者一人の作業
　　各担当者が作ったソースを結合して、初めて不具合が分かる

拙速なソース変更が状況を悪化させる
　開発期間が短いため、プレッシャーが大きい
　ソース修正期間が長いため、ながら作業になっている
　　修正方法が異なるやり方で何度もソースをいじって、品質を劣化させる
　　1日500行直したとしても、本来の正しいソースは50行だけかもしれない

バグがいつまで経っても収束しない
　バグ修正で新しいバグを埋め込んでしまう
　　テスト期間がどんどん延びる
　派生開発では、修正した箇所が問題なのに、ソースコードを弄んだために変更した箇所の手がかりを失った
　　バグ修正のプロセスが個人任せ

変更方法に基づくテストが行われていない
　機能追加だけで、変更機能のテストが行われていない

新規開発崩しで公式文書を変更している
　公式文書を削って修正するが、あくまでも作業中
　　最終版ではないので、どれが最新の仕様か分からない
　　→並行開発や五月雨開発の支障になる

そもそも組織には新規開発のSDSしかない？
　SDS
　　ソフトウェア開発スタンダード
　　CMMIの用語
　CMMIの認証は新規開発プロジェクトを対象とするケースが多い
　　派生開発用のSDSが必要
　　→XDDPが売れない理由

要求仕様のFixを要求するのが当然と思っている
　仕様が見えないので、スムーズな合意が形成できない
　　後で動くようになってから、必ず仕様変更が発生する
　要求仕様書の構成が邪魔している

作り方の品質要求が入っていない
　機能仕様書で作ろうとしている
　　機能の概要であって、作り方は書いていない
　要求仕様書を作るべき
　　作り方が入っている
　保守性の観点が漏れている
　　ソースを触るほど品質が劣化する
　　派生開発で、保守性の品質要求が記述されていない

保守性の意味が最近変化している
　Maintainabilityが基本
　しかし、Supportabilityなどが混じっている

作り直しても何も変わらない
　アーキテクチャを作り直しても、派生開発に追われて新しいアーキテクチャを勉強していなかった

派生開発を意識しないと明日はない
　不適切な派生開発プロセスで対応している
　　Faster、Cheaper、Worse！

◆XDDPの解説
XDDP＝USDM＋PFD
　要求仕様の書き方
　　USDM
　プロセスを自由自在に設計する
　　PFD

USDMは表現に重点を置いた仕様化の方法
　最近のモデリング
　　要求の発見を重視する
　　しかし、要求の表現方法はあまり触れていない
　せっかく発見した要求も適切に表現されなければ、仕様が漏れる

USDM
　機能要求は、振る舞いを表現する
　　その中に仕様がある
　要求と一緒に理由を表現する
　　要求の意図や背景を補足する
　　認識のずれを軽減する
　仕様は、要求の中の動詞、目的語にある
　　動詞を的確に表現することで必要な仕様を引き出す
　　→本には触れられなかった
　要求と仕様を階層で表現する
　　要求も2階層で表現したりする

　コミュニケーションの不完全性を相当程度カバーする
　　アジャイル開発で頻出する
　　　「分からないならさっさと作ってリリースした方がいい」という考え方がアジャイル開発

要求仕様書と機能仕様書の違い
　要求仕様書
　　今回のプロジェクトで実現して欲しいこと(Requirement)
　　作ることの関係者が、実現内容について特定(Specify)できている
　　　関係者も特定できている
　　　　作る人、依頼する人、確認する人
　　今回限りのドキュメント
　機能仕様書
　　関係者を特定できないので、表現は均一になる
　　VerUpしていく

プロセスと成果物は表裏一体
　プロセスを変えると成果物も変わるはず
　でも、プロセス改善を叫ぶ所では、30年前の設計書を使っている
　
新規開発
　機能仕様書(企画)がInput
　新規に作る時に、機能仕様書に変身する
　　完成後に機能仕様書に戻り、VerUpしていく
　　要求仕様書は途中で作られる

派生開発
　要求仕様書は2種類必要
　　変更、機能追加
　　要求仕様書は差分の情報だけ
　　2つの要求仕様書に基づいて開発していく
　完成後に、機能仕様書へマージして更新する

追加機能要求仕様書
　追加分＋変更分の2個がある！
　変更分は、BeforeとAfterがある

変更要求仕様書
　変更分

XDDPは2種類のプロセスを並行で動かす
　変更分＋追加分
　追加機能要求仕様書を作成後、変更要求仕様書を作る

変更プロセス
　Input
　　変更箇所の仕様
　　ソース調査
　　追加要求の仕様
　OutPut
　　変更要求仕様書
　　TM(トレーサビリティマトリクス)
　更に、変更設計書を作成する
　　ソースレベルで変更箇所を特定し、修正方針を作る
　ソースコードを一斉に変更する
　　最初のソース調査、変更設計書の作成時、今回の3回もソースを見ているので漏れがない

機能追加プロセス
　機能追加を扱うプロセス
　変更プロセスとの間で、追加機能を受け入れる方法を調整しておく
　　終了したら、そのまま設計に取り掛かる
　変更プロセスと関係なく進める

変更プロセスは3点セット
　変更要求仕様書　What
　TM　Where
　変更設計書　How
↑
アーキテクチャが存在しているため、TMまで作れる！

仕様→設計する→設計書

設計するためにソース調査の観点
　データ構造
　制御構造
　判定構造

XDDPの特徴
　変更と機能追加のプロセスを分ける
　差分で進めるので並行開発が可能
　テスト終了後に公式文書へ反映する

◆追加機能要求仕様書
　普通の新規開発と同じでよい
　要求と仕様を階層化する
　認定仕様の考え方を受け入れる
　　納期を考慮した暫定の仕様

要求の発見
　ユースケース
　　最近は、振る舞いの一部の動作しか表現しない傾向が見られる
　　　動詞が見えづらい
　　ロールに要求があるはず
　状態遷移
　　イベントから振る舞いを表現する
　操作画面の要素
　　画面も一つの状態
　　ボタンはイベント発生源

機能要求は振る舞いと範囲で表現する
　範囲
　　イベントの始まりと終わり
　　　バッチ処理ならジョブ実行のみ
　範囲に注目しよう

要求には理由を付ける
　理由は要求の一部
　理由から代替仕様を提案できる

範囲が広いと仕様が漏れやすい
　隠れた動詞が多い
　動詞を探して時系列に分割する

分割は2階層程度で抑える
　階層化で隠れている動詞を全て洗い出す

分割方法は構造化設計の技術で十分
　モジュールの分割基準

設計しないと仕様が出てこない
　設計とは分割すること
　時系列にシナリオを作ること

仕様とは、要求に含まれる具体的な処理や振る舞いを表現したもの
　仕様はテスト可能
　　検証可能
　仕様は全てソースコードになる
　　実現可能

仕様は階層の中で捉える

認定仕様
　仕様化する必要がない要求
　　既に分かっているなら設計しなくてもいい
　　　工数削減
　　□で書いておく
　　　チェックボックスの代わり
　→要求仕様書だから可能
　　　機能仕様書はこのような記述は認められない
　→邪道らしいが、現実的
　　　XPのシンプルと同じ
　
例：要求＝70個
　　　50個＝認定仕様
　　　　→仕様化する工数は不要
　　　20個＝きちんと作る
　　　　→1120個の仕様が出てきた

必要なら仕様にも理由を書く

仕様のグループ化
　動詞の単位でグループの下に仕様を引き出す

仕様から要求を作る
　みにくいアヒルの子
　　要求と理由があるのに、仕様とマッチしない状態
↓
対応方法：
1・他の要求へ仕様を移動する
2・適切な要求を作り、仕様を移す
3・要求と理由を変更して、範囲を広げる
↓
新しい要求を設定すると、新しい仕様に気付く
　従来の要求仕様書では、このテクニックは使えない

画面配置図の下に仕様化する
　画面仕様書と同じ
　画面操作は1階層で殆ど対応可能

作り方の要求も仕様化する
　保守性などの品質要求も仕様化しないと実現しない
　　XDDP特有の開発スタイル
　検証できるように表現する
　　仕様だから
　　作業者に対する指示書になる
　　　従来の機能要求書には、保守性は書けない
　　　　保守性は機能ではないから
　　保守性も要求である
　　　従来の本には、保守性の要求を表現する技術が書かれていない

「見なす」という文言がXDDPには出てくる
　要求はこれだけの仕様を満たす
　「見なす」には承認作業が含まれている？

問題は要求漏れ
　仕様漏れが原因ではない
　要求を表現しないから仕様漏れと認識される

Excelでは、行を折り畳む機能がある
　要求だけを一覧表示する
　　仕様を隠す
　TMが一番重要
　　行は、要求＋仕様
　　列は、機能
　　変更箇所が交差する所

◆変更要求仕様書の書き方
　全ての変更を扱う要求仕様書
　　変更要求と変更仕様を階層化する
　実現方法まで特定する(Specify)
　　変更仕様はソースコードのレベルで記述する
　　→追加機能の場合と異なる

変更要求の範囲と理由を表現する
　範囲を明確に表現することで、要求になる
　Before、Afterを表現する
　　追加する、削除するには、Before、Afterの情報が含まれている
　Beforeに影響箇所の情報がたくさん含まれている

変更は要求ではなく、仕様で届く時が多い
　問題
　　依頼された箇所を変更するだけでは済まない
　　　そもそも適切な箇所とは限らない
　対応
　　変更仕様から変更要求と理由を探して、改めて変更仕様を探す
　　
　→要求と仕様を区別しない状態では、これが問題と思われない

　機能仕様書などの文書から探す
　　具体例あり
　　　変更仕様だけでは仕様漏れが出る
　　　変更要求と理由を見つけると、新たな仕様が出てくる
　ソースコードを見ながら探す
　　具体例有り
　　　ソースコードを解析する
　　　発見した変更すべき箇所を変更要求の下に書き出す
　　　　すぐにソースを修正しない！

変更仕様はグループ化すると分かりやすい
　抽出された変更仕様が色んな箇所に散らばる場合、グループ化する
　要求仕様：関数の仕様＝１：N
　　XDDPは、ソースコードの変更は、仕様変更と捉える
　　
　変更要求の要求仕様でよい
　　そのままソース修正できる
　要求仕様をさらにばらす
　　関数レベルの仕様まで落とす

機能追加は、2種類の要求仕様書で対応
　追加要求仕様書
　変更要求仕様書

移植は2段階の変更が必要
　移植元での変更要求
　　移植先の状況に合わせるための調整作業
　移植先での変更要求
　　インターフェイスを合わせる

保守性
　機能追加
　　保守性の要求仕様を作る
　変更
　　劣化を防止するのが目的
　　保守性はアップできない

BeforeとAfterの差が見積もりの根拠
　工数が出る

TMを介して変更要求仕様書と変更設計書をつなぐ
　行：変更要求、仕様→What
　列：機能、担当者など
　交差点：変更設計書→How
　→TMでWhereを表現する

変更設計書は変更点だけ
　本当の設計書ではない

正式文書はテスト後にマージする
　公式文書の修正は短期間に行う
　　工数は確保されている
　並行開発や五月雨開発が可能になる

ソースコードは一気に変更する
　4ヶ月前に取り掛かった時と、4ヶ月調査して設計した後は状況が異なる
　プログラミングを単純な変換プロセスにする
　　生産性が高い

バグの原因解析で3点セットが役立つ
　派生開発では、バグは今回変更した箇所に存在する
　　変更箇所は全て、変更設計書に書かれている
　　範囲が絞られる

一人プロジェクトの問題を回避できる
　3点セットがあるから、レビューしやすい

XDDPで生産性向上
　ヒントはソースコード変更の生産性にある
　80～130行/時間　も可能
　設計に時間を費やして、プログラミングの作業時間を減らす

XDDPは、要求の発見よりも要求の表現方法に着目する
　仕様漏れや要件漏れは、仕様化プロセスで発生している
　設計プロセスの品質が悪いから

五月雨開発や並行開発が可能
　trunkの閉鎖期間が短い
　　一般の開発では、ソースの変更期間が長いために、実現できない
　3点セットによって、変更箇所が公開されている

彼女の表情が優しくなった
　3点セットでレビューしやすくなった

仕様変更率を５％以下を目指す
　仕様にまつわる問題が消える
　要件管理もスムーズになる
→CMMIのアセスメントが可能

2種類の生産性を出す
　今回生成したLOC/全体工数
　今回生成したLOC/実装工程の工数

SDSが派生開発の邪魔をする
　組織標準
　　新規開発用
　派生開発にXDDPを入れると、SDSを変更する必要性がある

仕様担当Gがガン
　XDDPでは、仕様担当Gの作業は、最初と最後だけ
　　追加/変更要求仕様書を作る
　　公式文書へマージする

不当支援を禁止する
　XDDPは早く終わる
　ブブカ方式
　　1センチだけ高く飛んで世界新記録
　　創造的無能を装う

【感想】
１・XDDPの良い所は、現場で鍛えられた理論であること。
　経験に裏打ちされている。
　CMMIは上からの開発プロセスだから、現場とマッチしない部分がある。
　要求開発も同様で、内容は素晴らしいかもしれないが、現場では使いづらい。
　実際の現場は、新規開発と派生開発の2種類を暗黙的に使い分けているはず。

２・「ドキュメント修正やソース修正はギリギリまで行わない」意味は、trunkに中途半端なコミットはしない、ということ。
　trunkへ中途半端な修正を入れると、品質が劣化するから。
　だから、タスクブランチを上手に使う。
　「テスト終了後、ソースとドキュメントを一気にマージする」意味は、タスクブランチの作業が完了したタイミングで、trunkへマージする、ということ。

３・追加と変更のプロセスは並行開発であること。
　つまり、trunkから2本(機能追加、変更)のタスクブランチを作る。
　既存の開発と混乱しないと言う理由は、trunkとタスクブランチを分けているから。

　XDDPがアジャイル開発のように思えるのは、並行開発だから。
　並行開発なので自然にアジャイル開発っぽくなる。
　但し、イテレーションを意識しないので、厳密にはアジャイル開発とは言えない。

４・変更要求←TM→変更設計書→ソースコード　でトレーサビリティを実現している。
　つまり、ソースから変更要求まで探すことができる。
　だから、運用保守に強いプロセスになって入る。

５・一人プロジェクトはペアプロで回避できないか？

６・XDDPは非常に面白いのに分かりにくい部分がある。何故か？
　trunkとbranchの違いが明確にされていない。
　実際の運用は、区別されているはずだ。
　変更と追加の2本のタスクブランチ上で作業しているはず。
　構成管理で整理していないので、分かりにくい部分がある。

　XDDPの特徴は、運用保守に強い並行開発。
　並行開発だから、アジャイル開発と相性がいい。
　上流工程の設計プロセスを凄く重視した開発スタイル。
　すごく勉強になった。

SVNリポジトリの管理方法の追記

「SVNリポジトリの管理方法」の記事に関して、良い情報があったのでメモ。

【元ネタ】
ブランチの管理

ベンダブランチの管理方法 - miauの避難所

ベンダブランチ

(前略)
リポジトリがただ一つのプロジェクトを含む場合には しばしば、この三つのディレクトリ(trunk/branches/tag)をリポジトリ最上位に作ります。
リポジトリが複数プロジェクトを含む場合は、プロジェクトごとに レイアウトをインデックス化します。
(後略)

srcとdocフォルダをどのように配置するか？という問題は、一つのリポジトリとして扱うか、別々のリポジトリとして扱うのか、という問題に置き換えられる。
普通の受託開発・パッケージ製品の開発では、ソースコードとドキュメントを納品するタイミングは同じなので、一つのリポジトリとみなした方がいいだろう。

しかし、サードパーティのライブラリのように、ライフサイクルが異なる場合は、別リポジトリとして扱った方がいい。
上記の記事では、「ベンダブランチ」という名前で説明してあり、非常に参考になった。

TestLinkの運用例part2

allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。

【元ネタ】
TestLinkメモ - 科学と非科学の迷宮

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ

allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。
直交表に比べると、テストケース数を少なくできる。

実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。
例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。
業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。

実際の現場では、直交表からテストケースを作ると、ケース数が爆発してしまい、限られた工数ではテストできない時が多い。
その時に、直交表よりもallpair法を使えば、少ないテストケースでたくさんのバグを見つけることができるはず。

TestLinkのテストケースへ出力する方法は、garyoさんが作ったRubyスクリプトを使うのが一番よいだろう。
僕は実際に使ったことがない(使いこなせなかった)が、上記の方は実際に試されているので非常に参考になる。

TestLinkでテスト工程をマネジメントする場合、インプットのデータであるテストケースの品質が一番重要だ。
テストケースの品質が悪く、テストケースの粒度にばらつきがあったり、テストケースそのものに間違いや仕様漏れがあると、TestLinkを使う利点が半減する。
実際、TestLinkの要件カバレッジを使ってみると、テストケースに紐づかない要件がよくあるので、要件漏れが頻繁に発生している時が多い。
すると、テストしていない要件、機能があるため、そこから潜在バグになる危険がある。

結合テスト以降のテスト仕様書は、Excel上で仕様書を見ながらテストケースを増幅して作る時が多く、非常に工数がかかる。

TestLinkを運用するようになって、テストケースはTestLinkのマスタデータなのだ、と思うようになった。
マスタデータが狂っていると、TestLinkでいくらテスト管理を頑張っても効果は半減する。
テスト仕様書は設計書を書いているのと同じレベルなのだ。
だから、テスト仕様書をきちんとレビューしてもらい、間違いや漏れをなくすのが大事だ。

TestLinkが運用しづらい原因の一つは、テストケースと言うマスタデータを作りこむのが大変だという点もあると思う。
テストケース作成技術は、プログラミング技術とは異なる別個の重要な技術なのだ。

チケット駆動開発のベストプラクティスを収集したい

チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。
理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。

僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。
但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。

１・チケット・ファースト(Ticket First)

【説明】
基本は、プロジェクトの作業はチケットを受け取ってから始める。
チケット無しで作業はしない。
また、SVNコミット時に、チケット無しのコミットも不可。

【効用】
チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

また、ソースや設計書などSVN管理下の成果物はチケットと連携しているので、作業の発生源と成果物のトレーサビリティを保障できる。
これによって、運用保守時にパッチの修正理由を探しやすい。
更に、ソースからリバースエンジニアリングする際に、チケットから仕様や要件を作りやすくなる。

BTSとバージョン管理の連携は、Redmine・Trac・Mantis・Jiraなど殆どのBTSで実現できる。

２・チケットで分割統治(Divide and Conquer)

【説明】
複雑なタスク、工数がかかるタスク、遅延したタスクは、追跡可能なタスクまでチケットの粒度を細分化する。
それらチケットを、リリースするバージョン毎にグループ化してまとめる。

【効用】
プログラミング作法の分割統治の概念をタスク管理にも応用する。
つまり、責務の多いクラスは結合度や凝集度の観点で分割するように、担当者一人に責務が集中して進捗が滞りやすいタスクは、分割統治を行い、チケットへばらす。

細分化されたチケットは、イテレーション計画又は、スパンの長いリリース計画に基づいて、どのバージョンでリリースするかという観点でグループ化する。
バージョンをXPのイテレーションに相当するように運用すれば、自然にアジャイル開発になる。

３・小規模リリース(Small Releases)

【説明】
バージョン毎に小さく作って小刻みにリリースする。
リリース結果は終了チケットの履歴として残る。

【効用】
XPの小規模リリースのプラクティスと同じで、チケット駆動開発はその実装プロセスになる。
リリース予定のバージョンと関連チケットの一覧は、BTSのロードマップ機能として表示できる。

そして、リリースしたバージョン、終了したチケットは、そのままリリース履歴として残る運用になる。
RedmineやMantisには、ロードマップと変更履歴(リリース履歴)が機能として存在しているので、自然に小規模リリースを運用できる。

４・ふりかえり(Retrospect)

【説明】
チケット集計結果からワークフローの運用などを次バージョンで改善する。

【効用】
バージョンをXPのイテレーションのように扱うと、自然にアジャイル開発で運用でき、イテレーションの開発リズムが生まれる。
イテレーションをリリースし終えたら、開発チームでKPTでふりかえりを行ってみよう。

バグが多く出たのは何故か？
特定の作業がやりづらかった理由は、ワークフローが現状と合っていないのではないか？
チケットの属性を、開発の現状に合わせて増やしたり削るべきではないか？

など色んな問題点、そして次のイテレーションで試したい事が出てくるはずだ。
このふりかえりプラクティスは、PDCAサイクルのCheck(評価)とAction(対策)に相当する重要なプロセスだ。
このプラクティスが上手く回れば、自然にプロセス改善できる。

でも、この4個だけで十分なのか、正直、自信は無い。
他人の運用例なども聞きながら、オブジェクト指向のデザインパターンのように、現場で役立つベストプラクティス集を作り上げたい。

【補足】
Shibuya.trac第4.5回勉強会～チケット駆動開発とTestLinkによる開発プロセスの改善～で、Shibuya.trac有志の方のおかげで、「TiDDのふりかえり」というパネルディスカッションを開くことになりました。
内容は、Redmine/Trac/Mantisでチケット駆動開発を実践した経験を、KPTの観点でパネラーがふりかえるものです。

そこで、勉強会の参加者からもパネラーへ質問したい内容を募集しています。
興味ある方は、Shibuya.trac第4.5回勉強会～チケット駆動開発とTestLinkによる開発プロセスの改善～のWikiへ直接書き込んで下さい。

入門Mercurialの感想

Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。

【元ネタ】
Mercurial の利用

特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社

スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3)

ダウンロード - TortoiseHg - SourceForge.JP

「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。
平易に書かれていてとても読みやすい。
また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。

エピローグに「あ！構成管理って楽しいんだ？！」という節がある。
MercurialはCVSやSubversionと違って、オフラインのノートPCでも共有リポジトリと関係なくバージョン管理できるおかげで、コミットがすごく楽しかった。
ついに自由を獲得できた、と思った。

そして、構成管理にまつわる問題の本質は、「構成管理が面倒」であることではなく「面倒なツールで構成管理をしていたこと」に気付いた。
そのおかげで、構成管理が楽しい！と思うようになった、とのこと。

経験談としてすごく納得できる。
僕も、TortoiseHgを使い始めて、オフラインのノートPCで簡単にバージョン管理でき、外付けHDにバックアップ代わりにミラーリングできるようになった。
更に、Redmine＋TortoiseHgでプライベートなタスク管理が簡単にできあがった。
だから、作業がすごく楽しくなった。

優れたツールが開発のあり方まで変えてしまう。
ツールがプロセスを改善する。
優れた技術力こそが、SW開発が抱える諸問題の難易度を下げて、一つずつ解決の方向へ進めさせてくれる。

SVNリポジトリの管理方法

かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。

【元ネタ】
Subversion のフォルダ構成 - かおるんダイアリー

Subversionのフォルダ構成 | Ryuzee.com

Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所

InfoQ: 複数のアジャイルチームでのバージョン管理

【問題】
SVN直下のディレクトリは、branch/tag/trunkになっている。
ソースやドキュメントはどこに配置すべきか？

【結論】
管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag　を作った方がブランチを管理しやすいと思っていた。
最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。

でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。
思い出してみたら、下記の方法で僕も運用していた。

root.
├─branches
│ ├─1.0
│ │ └─src
│
├─tags
│ ├─1.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│ ├─1.1
│ │ └─src
│ ├─2.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│
├─trunk
│ ├─doc
│ ├─src
│ └─tools

基本的な考え方は「InfoQ: 複数のアジャイルチームでのバージョン管理」に従えばいい。

【方針】
１・基本は、trunkにソースやドキュメント、ツールなどのフォルダを作り、それぞれを管理する。
PGやPLは、ソース修正やドキュメント修正は、trunkへコミットして、常に最新の状態にする。

２・新規開発中のtrunkからリリースする場合、trunkからtagを作り、tagにはリリースするバージョン(例：1.0, 2.0)を命名する。
この時、ソースだけでなくドキュメントもtagのバージョンに入れる。

更に、trunkからbranchにリリースバージョン(例：1.0, 2.0)を作り、本番運用中のソースは別管理とする。
ドキュメントは最新版だけあればよいプロジェクトだったから、branchには入れない。

３・本番運用中のbranchからリリースする場合、branchからtagを作り、tagにはリリースするバージョン(例：1.1)を命名する。

【注意点】
一つは、基本は、tagにはtrunkにある全ディレクトリにバージョンを付けること。
理由は、tagのバージョンがtrunkのスナップショットだから。
実際、リリース時はソースだけでなくドキュメントも一括納品しているからだ。

もう一つは、branchには派生開発する対象のディレクトリをtrunkから分岐させること。
このやり方はいわゆるメインラインモデル。
trunkは新規開発、branchは本番運用に分けて管理する手法。
僕の場合、ドキュメントは最新版だけあればよかったからbranchに入れないが、SWプロダクトラインのように製品ファミリー単位でドキュメントも管理する必要がある場合、branchに入れた方がいいかもしれない。

branchを作ると、必ずbranch→trunkへマージ作業が発生する。
ソースというテキストファイルなら作業しやすいが、ExcelやWordは正直作業しづらい。
但し、TortoiseSVNならOfficeの差分比較ができるので、マージ作業の難易度は下がっている。

つまり、trunkに成果物を全て配置するやり方がよいと思う。
その理由は、「Subversionのフォルダ構成 | Ryuzee.com」で詳しく書かれている。

実際、trunk/tag/branchに含まれないフォルダは、最新版なのか古いのか分からないからだ。

「Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所」の記事も読み合わせると、ドキュメントもソースと同じライフサイクルで管理した方が良いと思う。
理由は、ドキュメントをリリースするタイミングはソースをリリースするタイミングと同じだからだ。
普通は、システム納品と同時にマニュアルや設計書というドキュメントも納品しているはずだ。
つまり、trunk直下にドキュメントとソースを配置した方がライフサイクルを管理しやすい。

SVNだけでなく他のバージョン管理でも同様の発想をすればいいだろうと思う。

Redmine＋Mercurialの設定方法

RedmineとMercurialの連携の設定をメモ。

【元ネタ】
RedmineでMercurialを使う方法 - 床のトルストイ、ゲイとするとのこと

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

All In One Redmineを見つけた: プログラマの思索

Windows＋Redmine0.8.4＋ToroiseHg0.8.1では2箇所でエラーが発生する。
修正方法は下記の通り。

【修正対象】
lib/redmine/scm/adapters/mercurial_adapter.rb

【修正箇所】
L27
HG_BIN = "C:/Program Files/TortoiseHg/hg.exe"

L40
theversion = "1.3.1"

L27では、元来Unix上のHgのパスをTortoiseHgのパスへ変更する。

L40では、MercuiralのバージョンをTortoiseHgのMercurialのそれに直す。
ソース上では、「hg --version」コマンドを発行してMercurialのバージョンを正規表現で取得しようとするが、TortoiseHgを日本語化した場合、バージョンがヒットしないから。

これによって、Redmine＋TortoiseHgで、ローカルPC上の成果物を管理できる。
TortoiseHgなら、ローカルPC上のリポジトリを他マシンのリポジトリへ簡単にミラーリングできる。
つまり、「hg push」「hg pull」によってリポジトリを更新する作業をバックアップ作業代わりに使える。
更にWinMerge＋xdocdiff WinMerge Pluginを使えば、ExcelやWord、PowerPointの差分比較も可能だ。

Redmineはデフォルトで、MercurialやGit、Darcsにも対応していて、更にリモートSCMにも対応しているから使いやすい。
SVNと同様に、コミットログにチケットNoを書けば、チケットNoとMercurialリビジョンが相互リンクするから、ローカルPC上でもトレーサビリティを実現できる。

従って、ローカルPC上のRedmine＋TortoiseHgによって、テキストだけでなくOfficeのバージョン管理とタスク管理を一括管理できるようになる。

以前に比べると、タスク管理やバージョン管理のツールがお手軽に揃ってきた。
現在、プロジェクト管理の手法が劇的に変わるポテンシャルが出てきているように思う。

チケット駆動開発とアジャイル開発の密接な関連

平鍋さんのコメントに対して回答してみる。

【平鍋さんのコメント】
アジャイルやPFの具体的かつ実践的な回し方、として期待しています。
PF のプラクティスとの相関を一枚で描いてもらえませんか？
僕のスライドで紹介したいです。

【回答】

TiDDとXPの関係

View more presentations from akipii .

上記のように、TiDDとXPの開発サイクルを対比したイメージを強引に書いてみた。

これでイメージが湧くでしょうか？？

チケット駆動開発を日本発のアジャイル開発へ発展させるには？

さかばさんの記事を読んで考えたことをメモ。

【元ネタ】
[TiDD] 小規模開発の難しさを考える: ソフトウェアさかば

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。
しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。
ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。
情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。

その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。
テスト駆動開発を実践するには、JUnitを使いこなさねばならない。
常時統合するには、Hudsonのようなビルド管理ツールが必須だ。
そして、イテレーション単位に頻繁にリリースするには、頻繁に変わるタスク管理を制御しなくてはならない。

アジャイル開発の最大の特徴は、超短期間の繰り返し型開発だ。
頻繁にリリースできる技術力、プロジェクト管理能力があるからこそ、スコープ・コスト・納期の三角形でプロジェクトマネジメントを行えるのだ。
頻繁にリリースしても品質を維持できる技術力がなければ、スコープを制御することは事実上不可能だ。

そして、チケット駆動開発は、まちゅさんがTracのチケット管理をタスク管理に使った所から生まれた。
更に、僕は、アジャイル開発のタスク管理にチケット駆動開発を適用することで、アジャイル開発が非常にスムーズに運用できた経験をした。
それは単に繰り返し型開発ができただけの意味ではない。
イテレーションと言うリズムがあるからこそ、現場リーダーが優先順位付けマシンになり、朝会で各自がタスクを確認し合い、リリース後にKPTでふりかえる雰囲気が開発チームに生まれた。

チケット駆動開発のインフラのおかげで、アジャイル開発がスムーズに運用できて、チーム内に変化が起きて、チームが成長する螺旋構造が生まれた。

そのチケット駆動開発は、BTSという従来のツールを駆使する。
僕の数少ない経験では、RedmineでもTracでもMantisでもチケット駆動開発は運用可能だ。

その中でもRedmineが最もアジャイル開発しやすい理由は、一目で進捗が分かるロードマップ機能と柔軟なワークフロー管理機能の2点にあると思う。

ロードマップこそがXPのイテレーション計画であり、Scrumのスプリントバックログへ適用できるのが一番の肝だ。
そして、リリース後は終了したロードマップはリリース履歴になる。

更に、柔軟なワークフロー管理機能のおかげで、バグ修正だけでなく、インシデント管理や課題管理などSW開発の全てのワークフローをBTS上へのせることができる。
特に、BTSチケットをバグ修正だけでなく仕様変更にも使うことをIssueTrackingと呼ぶ。
これはチケット駆動開発でもすごく重要な機能だ。

このチケット駆動開発を、たくさんの人の事例をプラクティスへ濃縮させて、日本発のアジャイル開発までブラッシュアップしたい。

日本のアジャイラーの第1人者の平鍋さんは、XPから始めて、プロジェクトファシリテーション(PF)を編み出した。
PFのアイデアの影響力はものすごく大きくて、色んな人が知的刺激を受けて、関東や関西、九州でPFPコミュニティが生まれた。
同様に、チケット駆動開発が実際の現場で働く人に刺激を与えて、良い方向に進められればと思う。

TestLinkを運用して気付いたことpart10～テストの制約条件

TEF関西のNakaさんの話を聞いて考えたことをメモ。

【元ネタ】
ソフトウェアテスト標準用語集 日本語版Ver 1.3

普通のプロジェクトは結合テストで火を噴く。
理由は、結合テストで初めて、システムが稼動するのを顧客も開発者も見れるから。
そこで、初めて、要件漏れ、認識相違、仕様漏れに気付く。

でも、それだけの理由だけではないという指摘を受けた。

ソフトウェアテスト標準用語集 日本語版Ver 1.3には「プロダクトリスク」「プロジェクトリスク」の用語解説がある。

プロダクトリスクとは、「テスト対象に直接関係するリスク」。
プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」

実際のテスト、特に結合テスト、システムテスト、受入テストのようにプロジェクト後半になるにつれて、テスターやバグ修正担当者の不足、間近に迫る納期という工数不足、つまりプロジェクトリスクがすごく大きい。
テスト工程はプロジェクト後半のため、元々リソースが少ない。

だからといって、逆にテスターを増やしたとしても、ブロッキングバグが多発してみなしバグが増えれば、いくらテストしても無意味だ。

また、開発が遅れに遅れて、テスト期間がそもそも短い場合、リリースできる品質をテストで確かめることができず、全ての機能をテストできないままリリースせざるを得ないかもしれない。
その場合、リリース後にたくさんの苦情が開発チームに押し寄せる。

つまり、テストには制約条件が非常に多い。

まず、テスト計画を立てた時、与えられた期間と手持ちのスタッフ数から、実施できるテストケース数の上限という制約条件がある。
この上限を超えたテストケースを作った場合、スタッフを増やして徹夜させて納期に間に合わせるか、あるいは、納期を遅らせてテスト工数を確保するか、という選択を現場リーダーは決断せねばならない。
ここで、アジャイル開発を実践しているならば、スコープを削ることで品質と納期を確保する選択肢も取れるだろう。

でも、アジャイル開発であろうとも、残りの期間でテストしてリリース可能な品質を保証できる機能は、上記の上限から限られるのだ。

極端には、テスト計画を立てた時点で、そのプロジェクトは既に死んでいる場合もあるのだ。
つまり、テストケースが多すぎて工数を確保できず、プロジェクトリスクをどうやっても解決できないプロジェクトはありうる。

次に、テストの失敗率から、ブロックされるテストケースが増えすぎてテストできない状態になる上限がある。
つまり、ブロッキングバグがある上限を超えると、殆ど全てのテストケースがみなしバグとなってしまい、テスト不能になる状況が考えられる。

だから、バグを発見したら、どのバグを最優先で直すか、優先順位を付けてブロッキングバグの修正に最優先に対応する。
あるいは、結合テストでそもそもブロッキングバグが出ないように予防しておくべきだろう。

実際は、障害件数をあらかじめ予想しておき、障害修正工数や再テスト工数も予測しておけば、テスト実施のクリティカルパスが見える。
そこから、どのブロッキングバグを最優先で直して、次にどこのテストケースをテストするか、というふうに先を見通して手を打たねばならない。

上記のプロジェクトリスクを解決できずにリリースした場合、顧客からの膨大なクレームや不良品による返品などといったプロダクトリスクで跳ね返ってくる。

テスト工程のプロジェクト管理が上流工程のそれよりも難しいのは、上記のような制約条件に対するリスク管理が非常に難しいからだろう。

TestLinkでは、テストケースのカスタムフィールドに予定工数やテスト実施予定日を入力すれば、テスト計画の総予定工数をあらかじめ予測できる。
また、TestLinkのテストケースの情報を出力してTestLinkCnvMacroに取り込めば、Excelで解析することができる。

そこから、リスクを洗い出し、プロジェクトリスクやプロダクトリスクに分ける。
おそらく、プロジェクトリスクには、アジャイル開発のプロジェクト管理の基本であるスコープ・納期・コストで対応すればいいだろう。
プロダクトリスクには、優先順位付けして最優先で対応する戦略を取ればいいだろう。

テスト工程のプロジェクト管理には、上流工程とは異なる特有のマネジメント手法があるのだと思う。
色々考察してみたい。

チケット駆動開発が進むべき道

さかばさんのBlogにTiDD(チケット駆動開発)の分析が書かれているのでメモ。

【元ネタ】
必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば

TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかば

TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば

[TiDD]チケット駆動開発と見える化: ソフトウェアさかば

[TiDD] チケット駆動開発によるフロントローディング: ソフトウェアさかば

[TiDD] プラクティスから方法論へ: ソフトウェアさかば

TiDDとアジャイル開発に強い関連性があると色んな観点から分析されている。
TiDDはまだ定義すらない曖昧な概念であり、プロセスですらない。
今後進むべき方向は、方法論やベストプラクティス集を定義することだろう。

僕はTiDDを実践してみて、TiDDはアジャイル開発のベストプラクティス集みたいなものだと直感している。
それは丁度、オブジェクト指向のデザインパターンのようなもの。
目に見えないけれど誰もが理解できる抽象概念でありながら、実際のプログラミング言語で実装して試すことができる。

そして、方法論よりもベストプラクティス集の方が現場でははるかに役立つ。
オブジェクト指向の方法論はRUPだと思うが、あまりにも重過ぎる。
確かにその内容は勉強に値するし、なるほどと思う部分は多々あるけれど、実際の現場で試そうとするとあまりにもハードルが高い。

アジャイル開発もウォーターフォール型開発やRUPなどの重厚プロセスのアンチテーゼとして生まれたが、誰にでも使えるように抽象化するほど、現場で運用する時のギャップが大きくなる。
TiDDはBTSというツールに依存しすぎている、という批判を受けた時があったけれど、現場ですぐに実践できるなら、僕はそれでいいと思う。

実際のソフトウェア開発で、目の前にあった問題を解決しようとしたら、RedmineやTestLinkのようなツールが必要だっただけ。
むしろ、それらのツールが持つ機能が一つのベストプラクティスなのだ、と気付き、過去に読んだ本の専門用語が対応する経験を通じて、プロセス改善におけるツールの重要性を感じている。

アジャイル開発がこれだけ注目され、その有効性が理解できているのに実践できないのは、単に技術力がないだけなのだ、と直感している。
ソフトウェア開発の諸問題はTiDDのような技術力で全てカバーできるという確信を更に考察していきたい。

TestLinkを運用して気付いたことpart9～後追いテスト

TEF関西のNakaさんから「後追いテスト」というテストの用語を教えてもらったのでメモ。

【元ネタ】
ソフトウェアテスト標準用語集 日本語版Ver 1.3

まず、ソフトウェアテスト標準用語集 日本語版Ver 1.3には「リスク」「プロダクトリスク」「プロジェクトリスク」の用語解説がある。

テスト工程での「リスク」は「将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。」という意味で定義されている。

プロダクトリスクとは、「テスト対象に直接関係するリスク」。
プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」

つまり、テスト工程のリスクを、プロダクトリスクとプロジェクトリスクに厳格に分けている点が重要だ。
組み込み製品なら1回リリースするために数千～数万のテストケースをクリアする必要があるが、この時のリスクとして、テスターとPGが不足しているためにテストの進捗が悪くなるリスクはプロジェクトリスク。
テストできずにリリースして、後で品質問題に直結するリスクがプロダクトリスク。

ソフトウェア開発の基本は、プロダクトリスクの高い機能を優先して開発することだ。
そして、RedmineやTestLinkなどの各種ツールを駆使して、スタッフ不足や複雑な変更管理などのプロジェクトリスクを技術力でカバーするのが、プロジェクト管理の醍醐味だと思う。

ここで、「後追いテスト」とは「リリース後にプロダクトリスクの低いバグ潰しのテストを行う」意味らしい。

つまり、「リリース前のテストではプロダクトリスクの高いバグを最優先で潰すが、プロダクトリスクの低いバグは残したままリリースせざるを得ない。だから、リリース後の後追いテストで、プロダクトリスクの低いバグを潰していく」意味だと思う。
この手法は、特に新規顧客に対する受託開発の初めてのカットオーバーでよく使われるだろう。

例えば、新規顧客の受託開発を請け負った場合、顧客の要望を吸い取る要件定義がすごく難しい。
理由は、顧客の距離感が分からないからだ。
つまり、顧客が欲しいと思う機能は実際に使ってみたら違っていたり、開発チームが顧客の業務や会社の体制を完全に理解できないために要件を勘違いしたりする場面はいくらでも発生する。
だから、結合テストで実際に動かし、受入テストで顧客に初めて届けた時に、契約していたシステムと違っていた、という場面が多々発生しやすい。

その場合、機能も大事だが納期もすごく重要な時が多い。
特に業務システムは、他の運用中のシステムや会計システムと連動する時が多いから、納期の厳守がリリースの制約条件になる時が多い。

従って、開発方針としては、プロダクトリスクの高い機能を早く開発して、顧客に早めに叩いてもらい、フィードバックしてもらう手法がBetterだろうと思う。
そして、プロダクトリスクの低い機能やバグは、リリース後に後追いテストして、小刻みにリリースしていく開発スタイルになるだろう。
この時に、本番運用と機能追加のコードラインを別々に管理する並行開発が十分に機能すれば、後追いテストという手法を故意に選択することもできるだろう。

TestLinkでは、テスト実施結果をビルド、実施するテストケースをテスト計画という概念で別管理しているため、後追いテストの管理がやりやすい。
例えば、テスト計画に「Ver1.0リリース」「Ver1.1リリース」などのように、後追いテストのテストケースを別途分けたり、リリース済みのテストケースを使ってデグレしないか確認するために回帰テストすればよいだろう。

テスト工程のプロジェクト管理は、アジャイル開発や従来のソフトウェア開発にはなかった特有のマネジメント手法が存在しているように思う。

ドキュメントも構成管理すべきだ

SVNで構成管理する時の良い記事が公開されたのでメモ。

【元ネタ】
Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所

SVNの使い方の記事はネット上にいくらでもある。
しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。

CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。
この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。
つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。

構成管理が変更管理と密接に関係する理由は、上記のような変更プロセスを制御するインフラが構成管理だからだ。

そして、後者のように、ソースだけでなく設計書などのドキュメントも構成管理の配置下に置くべきだ。
理由は、ソースと同様に、ドキュメントを提出するタイミングでバージョン付けする状況が発生するからだ。

SVNはWindowsクライアントTortoiseSVNが非常に優れていて、ExcelやWordの差分表示もできる。
従って、変更理由の検索やマージ作業がやりやすくなる。

また、ロックと言う概念の説明も分かりやすい。
VisualSourceSafe6.0の頃は、VSSの管理下のファイルは全てロックされていたため、安全なように思われていたがむしろ作業に支障をきたす時が多かったように思う。
CVSやSVNのようにロックをかけないチェックアウトの方がやりやすいと思う。

また、trunk/branch/tagの説明も分かりやすい。
SVNが構成管理ツールの中で最も画期的だったのは、ブランチと言う概念を明示的に導入したことだと思う。

実は、昨今のシステム開発は殆どが、SWプロダクトラインのように、trunkとリリースブランチの2本以上による並行開発のはずだ。

例えば、組み込み製品やパッケージ製品の開発に従事する開発者ならば、製品ファミリーの開発を通じて並行開発には馴染みがあるだろうし、その苦労を嫌ほど分かっているだろう。
また、オープンソースで開発しているシステムの殆どは、障害修正だけの保守ブランチと最新機能をどんどん追加するtrunkの2本で開発しているだろう。
そして、昨今の業務系Webシステムでも、本番環境で動くリリースブランチと裏で機能拡張しているtrunkの2本で並行開発しているはずだ。

並行開発の難しさは、コードラインが2本あるためにタスク管理がより増大すること、そして、マージ作業が大変になる2点にあると思う。

そしてこの2点の問題を解決する糸口は、構成管理にあると直感している。
つまり、タスク管理はチケット駆動開発のように、BTSチケットに構成管理情報を付与してタスクを管理しやすくする。
マージ作業は、分散バージョン管理のようにマージ作業をツールで自動化する環境をサポートする。

構成管理はVSSやCVSの頃に比べるとはるかに高機能になり、それにつれて制御できるプロセスの範囲も広がってきた。
特に分散バージョン管理には、構成管理に新しい発想を取り入れているように思う。

構成管理という最も基本的な考え方をIT技術者だけでなく、PCに触る一般人も慣れた方がいいだろうと思う。

TestLinkのFAQ

TestLinkを運用する時のFAQをまとめたみた。
TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。

【元ネタ】
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索

簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社

TestLinkCnvMacro

【テスト計画】
【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？
【回答】
TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。
TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業務シナリオをベースにした結合～受入テストのテストケースやテスト実績を一括管理するのが効果的です。

【2】テスト計画はどんな単位で扱えばいいですか？　テスト計画にリリースバージョンを当てはめていいですか？
【回答】
TestLinkのテスト計画は、例えば「結合テストのPh1」のように、一つのテストサイクルのように扱えばよいでしょう。
つまり、テスト計画はせいぜい数百ぐらいのテストケースにグループ化して、テスト計画を順次テストしいてく戦略を採るのが無難です。

そして、テスト計画を複数回実施した場合、TestLinkのビルドで回帰テストの結果を残す運用にすればいいでしょう。
例えば、全てのテストが終了後、ビルドにビルド番号を振り直す運用にすれば、もっと分かりやすくなるでしょう。

【3】TestLinkをアジャイル開発と連携する時の注意点はありますか？
【回答】
TestLinkのテスト計画をXPのイテレーション又はScrumのスプリントのように扱えばいいでしょう。
例えば、設計から開発・単体テストまでは、1個のイテレーションでアジャイルに開発後、結合～受入テストは別のイテレーションと見なし、TestLinkの「テスト計画」として実施する運用がよいでしょう。

【テストケース】
【4】TestLink上でテストケースを登録するのが面倒です。数百～数千のテストケースを一括インポートする方法はありますか？
【回答】
最もお勧めな方法は、Excelで作りこんだテストケースをTestLinkCnvMacroへコピーして、XML出力後、TestLinkへインポートすることです。
他に、マインドマップで作ったテストケースをMmToTestLinkでインポートしたり、C/Java/Ruby/C#のテストユニットのタグからインポートしたりする方法もあります。

参考：
TestLinkCnvMacro

JavaToXml - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

CToXml - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

RubyToXML - TEF有志によるテスト管理システムTestLink日本語化プロジェクト

【5】TestLinkのテストケースと既存のテスト仕様書の形式が合いません。どのように落とし込めばいいでしょうか？
【回答】
基本は、テストスイートでテストケースを階層化して、上手に分割することです。
結合テスト以降では、一つの業務シナリオに対し、複数のテストケースがあり、それぞれにテストの目的があります。
例えば、下記のような形式にすればいいでしょう。

(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する

【再テストするワークフロー】
【6】テストに失敗した場合のワークフローはどんな流れになりますか？
【回答】
基本は、テストに失敗した症状をBTSチケットに記載し、テストチームと開発チームの間で、BTSチケットをやり取りする運用になります。
テストチームが無い場合は、開発チームのテスターと開発者が連携することになります。

注意すべきポイントは2つあります。
一つ目は、失敗したテストケースとBTSチケットを必ず紐付ける運用にすること。
TestLinkは各種BTSと連携する機能があるため、活用すればいいでしょう。
失敗したテストケースが増えて面倒だったとしても、BTSチケットと連携しなければ、いつ再テストすればいいか分からなくなります。

二つ目は、BTSのワークフロー機能を使って、バグ修正とバグ検証のワークフローを管理すること。
Redmineの場合、ワークフローを柔軟に作れるので、テスターと開発者のそれぞれが作業中のステータスをチケットに追加できるように運用すればいいでしょう。

TestLinkでは、BTSチケットのステータスを一覧表示する機能があるので、再テストするタイミングが分かりやすい利点があります。

【ブロック】
【7】ブロックの使い方が分かりません。どのように使えばいいですか？
【回答】
ブロックとは、事前条件を満足できないためテスト不能な状態を表します。
(参考：ソフトウェアテスト標準用語集 日本語版Ver 1.3)

つまり、「失敗」したテストケースに依存するテストケースに「ブロック」を付けて、テスト保留とします。
例えば、小売系Webシステムでカート画面のDB更新のテストケースが失敗したら、注文フローのテストケースは全て「ブロック」になります。
つまり、ブロックとなるテストケースは、例えば、最下層のテストスイートに含まれる未実行のテストケースや、バグが出た要件に紐づくテストケースなどがあるでしょう。

上記のように、「失敗」したテストケースは「ブロッキングバグ」、ブロックするテストケースは「みなしバグ」と言われるそうです。
つまり、「みなしバグ」はテストしていないから失敗してないし、バグも出ていないが、テストしたらバグが出る可能性が高いことに注意して下さい。
「みなしバグ」のテストケースは一生懸命テストしたとしても、ブロッキングバグが解消されたら再検証する必要があるので、工数の無駄です。

TestLinkでは、ブロックを上手に使うことが大事です。
バグの状況に応じて、テストを中断したり、別のテストを行ったりする意思決定がテスト戦略になります。

【要件カバレッジ】
【8】要件カバレッジの使い方が分かりません。どのように使えばいいですか？
【回答】
TestLinkでは、要件とテストケースを紐づける機能があります。
この機能を使えば、要件カバレッジを行うことができます。
例えば、テストしていない要件がないか、チェックすることにも使えるでしょう。

TestLinkCnvMacroには、要件とテストケースを紐付けてインポートできる機能があるので、それを使えばいいでしょう。
例えば、下記の運用になります。

例：テストケース
(TestProject)小売システム
(TestPlan)結合テスト
(build)9月リリース
(TestSuite1)xx画面
(TestSuite2)姓名の入力チェック機能が正常であることを確認する
(TestCase-ID)テスト仕様書のケースID
(TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。
(TestCase-ステップ)zzボタン押下
(TestCase-期待値)xx画面でE1メッセージを表示する
(keyword1)1-1.1　←要件管理IDを振る

例：要件リスト
要件仕様-タイトル：小売システム
要件仕様-スコープ：小売システムの要件
要件リスト-要件名：1-1.1　(注：要件管理ID)
要件リスト-DOC-ID：1-1.1
要件リスト-タイトル：1-1.1
要件リスト-スコープ：xx画面/姓名は必須で、全角文字40文字まで入力可能

TestLinkでは、テスト実績の要件カバレッジも一覧表示できるので、リアルタイムに要件のテスト網羅率を確認することができます。

【メトリクス分析】
【9】テスト終了後、TestLinkに溜まったテスト実績を分析する方法はありますか？
【回答】
TestLinkCnvMacroを使えば、下記の観点でメトリクスを出力できます。
テストプロセスの進捗や品質について考察する資料になるでしょう。

・テスト結果の推移データ
・要件カバレッジの推移データ
・時間帯別の試験結果データ
・試験結果のピーク時間帯推移データ
・曜日別の試験結果データ
・時間当り実施数推移データ
・試験者別時間当り実施数データ

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

僕はテスト技法を体系的に知らないが、TestLinkを過去1年間実践してみて、テスト戦略やテストケースの作成方法について、ノウハウは色々溜めてきた。

TEF関西のNakaさんからテスト技法の専門用語を教えてもらい、そのノウハウに専門用語が付けられているのを知ったので、まとめてみる。

【元ネタ】
JSTQBテスト技術者資格認定-シラバス（学習事項）・用語集-

ソフトウェアテスト標準用語集 日本語版Ver 1.3

【1】みなしバグとブロッキングバグ

TestLinkのテストケースには「ブロック」という状態がある。

ソフトウェアテスト標準用語集 日本語版Ver 1.3 によれば、ブロックとは「事前条件を満足できないため、実行不能のテストケ－ス」を指す。
つまり、失敗したテストケースに依存するテストケースがブロックの対象になる。
例えば、小売系Webシステムならば、カート画面のDB更新のテストケースで失敗したら、注文フローは全てブロックになるだろう。

Nakaさんによれば、失敗したテストケースのバグを「ブロッキングバグ」、ブロックしたテストケースを「みなしバグ」と言うらしい。

つまり、ブロックしたテストケースは、「ブロッキングバグ」が直らなければ、再テストできない状態にある。
ブロックしたテストケースは「みなしバグ」だから、一生懸命テストしたとしても工数の無駄だ。
実際のテストでは、バグが出るたびに「みなしバグ」のテストケースを判別するのが非常に難しく、テスト工数を無駄に浪費してしまいがちだ。

管理者は、バグが出るたびに依存するテストケースをブロックして、他のテストを指示したり、再テストのタイミングを図る。
TestLinkでは、テスト実績やバグチケットの状態をリアルタイムに表示できるため、再テストの指示がやりやすくなる。

「ブロッキングバグ」は滞留時間が長くなるほど、ブロックしたテストケースのテスト工数も加算すれば、再テスト工数が大きく増える。
テスト工程は普通、プロジェクト後半という時間が限られた状況にあるため、管理者は、再テストのタイミングを図りながら、バグ修正の優先順位付けをする意思決定が重要になってくる。

テストケースをブロックする判定条件は、どんなものがあるだろうか？

TestLinkにはテストスイートという階層構造があり、テストスイートに、システムの機能(大・中・小)・テストの目的・業務シナリオなどの項目を当てはめる。
例えば、結合テストのように業務シナリオや画面遷移のパターンでテストする場合、一つのシナリオに複数のテストケースが属している。
従って、シナリオに含まれる一つのテストケースが失敗した場合、それ以降のシナリオのテストケースは全てブロックになる。

TestLinkでは、テスト実行画面でテストスイートの単位でテストケース数が集計表示されるので、どれくらいのテストケースがブロックになるか、判断しやすい。

しかし、TestLinkのブロックしたテストケース一覧画面には、ブロッキングバグの発生源である失敗したテストケースとリンクする機能が無いのが惜しい。

【2】周辺テスト

「周辺テスト」とは、再テスト時に、ある観点にグループ化されたテストケース群を回帰テストすることを呼ぶらしい。

例えば、小売系Webシステムで、カート画面で商品削除のテストケースで失敗したとしよう。
バグが直っていない場合、カート投入したテストケースは「成功」、カートから商品削除のテストケースは「失敗」、注文フローは全て「ブロック」になっているだろう。

そして、バグ修正して、バグ検証が終わり、ブロッキングバグが解消されたとする。
すると、カートから商品削除のテストケースは再テストして「成功」にできるが、カート投入したテストケースももう一度回帰テストすることを「周辺テスト」と呼ぶ。

「周辺テスト」をやる理由は、ブロッキングバグの修正でデグレしていないかのチェックをしたいからだ。
実際の運用では、シナリオに従って画面からデータを作り直して再テストするから、失敗したテストケースの前に既に成功を確認したテストケースを自然に回帰テストしているだろう。

TestLinkでは、テスト結果の履歴を保持できるため、回帰テストを管理しやすい利点がある。

【3】みなしOK

VerUpしたシステムのテストをする場合、ソース修正されていない機能のテストケースは「みなしOK」として、テストしない判断をする。
おそらく管理者や設計者がその判断を下しているだろう。

本来ならば、ソース修正されていない機能のテストケースも回帰テストでテストすべきだ。
なぜなら、機能追加によって、他の部位にも影響が出てバグが発生しているかもしれないからだ。

しかし、実際はテスト工数を確保できないため、この要件は単体テスト済みなのでテスト不要、とか、このテストはシステムテストでやるから今のテスト計画ではテストしない、などのテスト戦略を採用しているだろう。

あるいは、既に本番稼動して特に問題ないので、この機能は運用品質を満たしているという判断を下す場合もあるだろう。

「みなしOK」の判断はとても難しく、設計者の技量を問われる部分でもある。

【4】テストケースにもクリティカルパスがある

テストに失敗してバグが増えると、ブロックしたテストケースは飛躍的に増える。
すると、テストケースの失敗率のある上限値を超えると、テスト計画に含まれる全てのテストケースがブロックになってしまい、テスト不能になる状況が考えられる。
つまり、テスト不能の状況は、全てのブロッキングバグを最優先に修正しなければ、テストしても無駄な状態を意味している。

TestLinkのテスト計画をXPのイテレーション、Scrumのスプリントのように扱って順次テストしていく戦略を採る場合、テスト工数にバグ修正とバグ検証の工数も考慮する必要がある。
つまり、テストケースにはクリティカルパスの概念がはっきりと存在する。

例えば、テスト計画が小売系Webシステムの結合テストのPh1だったと仮定しよう。
TestLinkのテスト計画をXPのイテレーションに見立てると、２～４週間で全てのテストが終わる前提でテスト戦略を作る必要がある。

ここで、それぞれのテストケースにテスト予定工数を記入しておいたとしよう。
TestLinkでは、テストケースにテスト予定工数のカスタムフィールドを用意すればいいだろう。
すると、テスト予定工数の総和がテスト計画の最低限の予定工数となる。

更に、テストスイート単位の予定工数も計算できるので、ブロッキングバグが発生した場合、再テストの予定工数も計算できる。
この場合の予定工数は、失敗したテストケースの工数、ブロックしたテストケースの工数の和、バグ修正の工数の3つの和になる。
従って、ブロッキングバグのチケット単位で再テスト工数を一覧表示できる。

テストケースは普通シナリオベースのため、先行・後行関係があるから、テストケースのPERT図に再テスト工数を入れれば、そこからクリティカルパスを見出すことができる。

つまり、テスト計画から想定されるバグ数から、再テスト工数も予想で計算できるので、それを足せば、テスト計画の予定工数になる。

バグが頻発した場合、管理者はテストケースの依存関係と再テスト工数の一覧を見ながら、どのバグを最優先で直して再テストすべきか、という意思決定ができる。
あるいは、テストチームは開発チームへ、このバグは再テスト工数と納期を考慮すると、MM月DD日までに修正してもらわないと納期に間に合いません、と連絡することもできる。

これがテスト工程における本来のマネジメントなのだろう。

現状のTestLinkでは、工数計算やスケジュール管理の機能は無く、クリティカルパスを見つけるのは難しい。
TestLinkCnvMacroでテストケースとテスト実績をExcelで出力して、Excel上で解析するしかない。

【まとめ】
オブジェクト指向プログラミングでは、デザインパターンと言うベストプラクティス集がある。
デザインパターンがあるからこそ、他の開発者と概念を共有できるし、プログラムも綺麗になる。

同様に、TestLinkはオープンソースのため、世界中の技術者の要望が組み込まれたテストに関するベストプラクティス集の集まりみたいなもの。
「ブロック」や「ビルド」のように、TestLinkの機能には、先人の知恵が詰まっている。

最近思うのは、RedmineにせよTestLinkにせよ、オープンソースの管理ツールには、ベストプラクティスがたくさん詰まっていること。
Redmineにある「ワークフロー」の柔軟な機能を上手に使えば、ITILの変更管理に似た運用ができる。
更に、Redmineを使いこなせれば、チケット駆動開発を実践できて、自然にアジャイル開発になる。

同様にTestLinkも使いこなせれば、テスト技法の理論を試しながら、テスト技法の経験を積むことができるだろう。

【告知】Shibuya.trac第4.5回勉強会で発表します

ソフトウェア品質シンポジウム2009で講演するために上京する際に、Shibuya.trac有志の方のおかげで、下記の勉強会を開催して頂ける事になりました。
僕も、チケット駆動開発とTestLinkについて発表するので、ご興味のある方はご参加下さい。

【内容】
Shibuya.trac第4.5回勉強会

日時: 2009/9/11(金) 19:00-21:00
場所: 未定(都内を予定)

１・タイトル：「RedmineとTracの機能比較～TiDDに必要な必須機能」
概要：RedmineとTracの機能を比較した後、チケット駆動開発に必要な機能を提示してみます。

２・タイトル：「TestLinkを運用するための6つの方法」
概要：TestLink運用のハードルを下げるための6つの実践ノウハウを説明します。

などその他。

チケット駆動開発のFAQ

チケット駆動開発についてのFAQをまとめてみた。

他に聞きたい質問があれば、コメントして下さい。
チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

TiDD：チケット駆動開発: ソフトウェアさかば

RedmineとTracの機能比較: プログラマの思索

脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

Tracのワークフロー: プログラマの思索

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

[TiDD]チケット駆動開発と見える化: ソフトウェアさかば

【プロジェクト】
【Q1】Redmineにある複数プロジェクト機能はどのように使えばいいですか？

【回答】
複数プロジェクトを使う目的は、タスク管理を分割統治する点にあります。
チケット駆動開発では、メンバーが5人以上のチームの場合、チケットが多すぎて管理が大変になります。
だから、チケットを管理しやすい範囲になるように、プロジェクトでタスク管理のスコープを分割します。

例えば、「大規模プロジェクトにおけるサブチーム単位」や「ブランチやtrunkのようなコードライン単位」、「warやjarなどのコンポーネント単位」でプロジェクトを作ればいいでしょう。

【Q2】大規模プロジェクトでもチケット駆動開発を運用できますか？　運用上の注意点はありますか？

【回答】はい、大規模プロジェクトでも運用できるはずです。(私も経験ないですが)

今考えられる注意点は、最低限、下記があげられるでしょう。

一つ目は、サブチーム単位でプロジェクトを作り、プロジェクト内部でタスク管理することです。
Q1のように、5人以下でタスク管理することを勧めます。

二つ目は、チケット管理専門の担当者を置くことです。彼の役割は、全てのプロジェクトのチケット管理の最終責任者です。
複数のプロジェクトをまたがったチケット管理は、彼が課題管理会議(CCB)の議長になって、チーム間の調整をすべきでしょう。
そして、課題管理会議(CCB)は最低、週1回は開催して、チケットの棚卸しをすべきでしょう。

【ワークフロー】
【Q3】RedmineやTracでは、課題管理や顧客の問合せ管理がやりにくいです。いい方法はありませんか？

【回答】RedmineやTracは本来は障害管理ツール(BTS)なので、バグ修正が基本フローです。
そのフローだけでSW開発の全ての作業を管理することは元々おかしいです。
課題や問合せ用のワークフローを作るべきでしょう。

Redmineなら、トラッカー(チケットの種類)ごとに新しいワークフローを簡単に作れます。
例えば課題ならば「新規→設計中→問合せ中→回答済み→解決→終了」のようなワークフローが考えられるでしょう。

Tracのワークフロー: プログラマの思索

Tracなら、trac.iniを修正してみて下さい。

ワークフロー機能のカスタマイズ方法 - かおるんダイアリー

そろそろTracのワークフローについて語っておくか - almost nearly dead

【チケット】
【Q4】チケットは仕様書ですか？　チケットには何を書くのですか？

【回答】チケットは仕様書ではありません。チケットにはタスク(作業又は課題)を記入します。
チケットにタスクとその履歴を記録することで、タスクのステータスや進捗率、実績工数を管理することができます。

つまり、チケットをXPのタスクカードをデジタル化したものと見なせば分かりやすいでしょう。

※従来のBTSを拡張した上記のような管理手法をIssue Trackingと呼ぶ場合もあります。

【Q5】チケットはどれくらい詳細に書くべきですか？　チケットの粒度はどのように決めたらいいでしょうか？

【回答】チケット駆動開発にある「チケットファースト」の原則に従うと、チケットは「一つの成果物を一人の担当者が１～５人日以内で完成させる作業」まで細分化します。

但し、バグ修正はテスターと開発者が相互にチケットをやり取りし合うように、複数人が一つのチケットを連携する場合もあります。
ワークフローによってチケットを変えましょう。

【Q6】チケットを乱発したり放置してしまいがちです。どのようにすればいいですか？

【回答】まず、チケット駆動開発では、チケットがいつも最新化されている状態が大事です。
チケットの内容が古いと、リアルタイムに保守されないExcelの進捗報告と何ら変わりありません。
現場リーダーがチケットを最新に保守する最終責任者です。

チケット駆動開発 - Live a meaningful Life

チケットが乱発されやすい理由は、チケット登録のルールが決められていないからでしょう。
最初は、現場リーダーがWBSに落としたタスクをチケットに登録することから始めればいいでしょう。
チケット登録できる権限をサブリーダーまでに制限したり、開発者がチケット登録できる種類はリファクタリングやバグのみに限る、などのルールを作ってもいいでしょう。

また、リリース時期が不明なチケットを登録したい時があります。
例えば、リスクや将来の課題という優先順位の低いチケットがあるでしょう。
このチケットは、「内部課題」という特別なイテレーションで管理するなど、優先順位の低いチケット群として別管理したらいいでしょう。

Redmineを使って気付いたことpart7～イテレーションで追跡する: プログラマの思索

また、チケットが放置されやすい理由は、チケットの粒度が大きい場合があります。
成果物が最初は不明なチケットの場合、あるいは、最初に登録したチケットが予定工数よりも大きくかかる場合、一人の担当者だけでは解決できないと後で分かる時はよくあります。
遅延したチケットは、更に分割して、複数人の開発者で担当するように運用すればいいでしょう。

Redmineを使って気づいたことpart3～チケット分割のタイミング: プログラマの思索

【イテレーション】
【Q7】Redmineではマイルストーンはどれですか？　マイルストーンとバージョンの違いは何ですか？

【回答】Redmineでは、マイルストーンとバージョンは同一の概念になります。
Tracの場合、マイルストーンとバージョンは異なる概念として存在します。

マイルストーンは進捗報告のタイミング、バージョンはリリースするタイミングと区別されます。
普通は、一つのバージョンに複数のマイルストーンが含まれる運用になるでしょう。

Redmineでは、リリースのタイミング(バージョン)とマイルストーン(開発の一つの区切り)を故意に同一視することで、XPのイテレーションのように扱えます。
これによって、Redmineの方がアジャイル開発を自然に運用できるようになります。

【Q8】チケット駆動開発をアジャイル開発のように使うには、どの点に気をつければいいですか？

【回答】「イテレーションをどの単位で扱うか？」が一番のポイントです。
Redmineならバージョン、TracならマイルストーンをXPのイテレーション、Scrumのスプリントのように扱えばよいでしょう。
普通は、イテレーションを２～４週間の単位で区切り、そのイテレーションでリリースできる機能にシステムを分割し、その機能を実装するチケットをイテレーション(バージョン又はマイルストーン)に登録します。

2番目のポイントは「小規模リリースを実現する」ことです。
つまり、一つのイテレーションに含まれるチケットが全て終了ステータスになったら、そのイテレーションをリリースし、終了チケットはリリース履歴として残す運用になります。

アジャイル開発の最大のポイントは、スコープ・工数・納期の三角形でプロジェクト管理を行うことです。
チケット駆動開発では、一つのイテレーションで実装できないチケットは、次のイテレーションへ延期するか、却下することで、スコープと工数・納期のバランスを取る戦略になります。

つまり、プロジェクト管理をチケットの取捨選択に置き換えることで、マネジメントを見える化しているのです。

【ソース管理】
【Q9】チケットとソースをリンクさせるにはどうすればいいですか？

【回答】Redmineでは、SVNコミットログに「refs」や「fixes」を付けると、チケットにソースのリビジョンが相互リンクされます。
この方法を徹底できると、運用保守で過去のチケットからパッチの理由を推測することができるので、リバースエンジニアリングしやすくなる利点があります。

この手法をチケット駆動開発は重視しており、提唱者のまちゅさんも「チケット無しの成果物のコミットは不可」というルールで呼んでいます。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

【Q10】RedmineではSVNコミットログにタグ(「refs」「fixes」)を付けると、チケットとソースが連携できると聞きました。「refs」と「fixes」の違いは何ですか？

【回答】Redmineでは「refs」を付けると、チケットとソースのリビジョンが単純に相互リンクされるだけです。
「fixes」を付けると、チケットとソースが相互リンクさせるだけでなく、リンク先のチケットのステータスを「解決」、進捗率を「100%」へ自動更新します。
つまり、「fixes」を使えば、SVNコミット後にチケットを更新する手間が省けます。

また、SVNコミットのタイミングで、バグを確実に修正できた場合は「fixes」、全機能は実装できていないが一部機能は実装できた場合は「refs」のように使い分けると、SVNコミットログからコミット履歴を検索しやすくなるでしょう。

【レポート】
【Q11】MSProjectの進捗管理とチケット駆動開発のタスク管理が連携しにくいです。何故でしょうか？

【回答】MSProjectとチケット駆動開発で進捗管理の視点が異なるからです。

つまり、MSProjectは顧客向けの進捗報告であり、管理者の視点で機能別、工程別に進捗を管理しますが、チケット駆動開発は開発チーム内部の進捗管理であり、開発者の視点で作業別、成果物ベースで管理しているからです。

すなわち、MSProjectはXPのストーリーカード、チケット駆動開発はXPのタスクカードの観点で進捗管理していると考えれば分かりやすいでしょう。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

【Q12】毎月の工数を集計した顧客向けの月次報告をチケット駆動開発のツールから生成できますか？

【回答】Redmineは運用＋カスタマイズするしかありませんが、Tracならクエリを上手に使えば生成できるでしょう。

TracからRedmineへ移行しない、たった一つの理由 - almost nearly dead

基本的アイデアは、一つのストリーカードを複数のタスクカードに分割し、そのステータスと工数、開始・終了日をストーリーカードの単位で集計すればいいでしょう。

つまり、顧客価値に相当する要件(ストーリーカード)と成果物ベースの作業(タスクカード)を相互リンクさせる構造をチケット管理に取り込むのがポイントです。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

アジャイル開発はツールに依存している～SW構成管理を再考しよう

アジャイル開発とSW構成管理に関する記事を見つけたのでメモ。

【元ネタ1】
Kent Beck VSTSのホワイトペーパーの日本語訳

(前略)
アジャイル開発はツールに依存します。特にツールが異なる開発サイクルに合わせて最適化されている場合は依存度が高くなります。
(中略)
アジャイル ソフトウェア開発は、ツールを抜きにして語ることはできません。俊敏なプロジェクトでは毎日の作業量が非常に多く、以前は手動で行われていた非常に多くの手順が短い期間で繰り返されるようになるため、適切なツールが不可欠です。
(中略)
アジャイル開発は既に開発ツールに影響を与えています。
(中略)
今後もソフトウェア ツールに影響を与える傾向は、絶えず短くなっているリリース サイクルです。
以前はリリースに数年かかっていましたが、ますます多くのソフトウェア製品の新機能が、月単位、週単位、日単位、またはさらに頻繁に運用環境にリリースされるようになっています。
各フェーズが順番に実行されることを暗に想定したツールは、並行した (非常にすばやく切り替わる) 作業をサポートするツールに取って代わられるでしょう。
作業間のより頻繁な移行をサポートしようとする傾向は、今後も続くことが予想されます。状況は大きく変化せず、サポートされる作業の数が増加します。
(後略)

短いイテレーションによる繰り返し型開発では、高度な管理ツールを必要とする。
従来の手作業によるプロジェクト管理、チマチマとしたExcelによるタスク管理では、アジャイル開発をいくらやりたくても実現できない。

頻繁なリリースに耐えうるプロジェクト管理手法こそ、チケット駆動開発が目指す開発スタイル。

アジャイル開発をサポートするツールは最終的に、作業の透明化を目指す。
つまり、誰がどんな機能を実装してコミットしたか、誰がどんな仕様変更や障害対応でパッチを当てたのか、という作業を、他人にも自分にも説明できるように明確化すること。

デスマーチ・プロジェクトや風通しの悪い大規模プロジェクトでは、誰が何の作業をしているのか、メンバーだけでなくリーダーも、トップの管理職も把握できていない。
特に大規模プロジェクトになるほど、進捗管理という名のマネジメント工数が大きくなる理由がそこにある。

その工数は本質的に無駄だ。
その作業を自動化できるなら、マネジメント工数も、そして進捗管理だけしか脳のないリーダーも不要になる。

この考えを推し進めると、優秀なプログラマと優秀なテスターがいれば、マネージャ無しで開発できるようになるはず。

【元ネタ2】
大規模組織のためのアジャイルな構成管理 : 1～9
大規模組織のためのアジャイルな構成管理 : 10～14

次に、「構成管理」について説明します。これは「品質」と同様に定義の難しい概念で、以前から複数の異なる定義が存在します*1。
構成管理とはシステム内の項目を識別し、特定の項目とシステム全体の両方に対して変更管理を行うことであるというのは、誰もが同意するところでしょう。
構成管理を極めて狭義に定義すれば、「一般的な任意のソース管理システムを実装し、適切に使用すること」を指します。
逆に、極めて緩やかに定義すれば、「プロジェクト・チーム全体とそのすべての成果物」を指します。
成果物には、システムのあらゆる部分の正常動作を保証するためのすべてのコードやアクティビティー、すべての変更管理アクティビティー、さらにはチームの日々の手順における変更追跡などが含まれます。
この記事では、中間的なアプローチを採用し、構成管理の定義として、システムの各部品を整理し、システムの状態を常に把握し、その変化を管理し、開発プロセス全体を通してシステムの継続的かつ正常な機能を保証するためにプログラマーが行う作業を含めることにします。

変化を制御するためにツールが必要。
構成管理は、変更管理のインフラを提供する。

XPが優れているのは、ソース共同所有・テスト駆動開発・継続的インテグレーション・小規模リリースなどのように、ソフトウェア開発のインフラの自動化に着目した点にある。
チケット駆動開発もその流れにあると言っていい。

アジャイル開発の構成管理において、今の僕が思っている課題は、ビルドの並行化。
テスト駆動開発を実践すると、全てのJUnitを走らせるだけで何時間もかかり、結局デイリービルドできない。

下記のように、JUnitでテストクラスを並列に実行できるならば、見かけ上のビルド時間は半減できるはずだ。

JUnit4でテストクラスの並列実行 - cactusman日誌

おそらく、Hudsonによる並行ビルドとVMWareによるテスト環境の仮想化をうまく兼ね合わせないと、最終的にこの課題は解決できないと思っている。

GitやMercurialのような分散バージョン管理、Hudsonによる並行ビルド、VMWareによる本番環境の仮想化などのように、構成管理の技術はまだ進化の途中。

昨今のアジャイラーは、プロジェクトファシリテーションのように、人間系・マネジメント系の方面に目が行きがちだが、構成管理という基本的な技術をもっと洗練させないといけないのではないか？

システム開発に必要な役割

プログラマやテスターの能力に関して考えたことをメモ。

【元ネタ】
小野和俊のブログ:1・10・100、それぞれの力

小野和俊のブログ:プログラマー風林火山

プログラマと呼ぶ時、すぐにイメージするのはGoogleのように独創的なプログラムを書く人をイメージする。
しかし、実際の現場では、色んな役割の人達が必要になってくる。

新規顧客の新規開発の場合、初めてのフレームワークを元に、スクラッチで作っていく。
最初に必要な人は、何も無い所から動くものをまず作る役割。
このタイプは、新しい技術の飲み込みが早く、試行錯誤するのが好き。

新しいフレームワーク、新しい言語を使う場合、独特のプログラミングの書き方がある。
その作法に慣れるまでに、普通の開発者は時間がかかる。
だから、最初は、新物好きの技術者にプロトタイプを作ってもらい、そのサンプルを真似ながら、普通の開発者は作っていく。

そして、システムにどんどん機能追加されて、一つのシステムとして稼動するようになった時に必要にされる人は、テスターの役割。
バグを発見し、バグを検証し、一つずつ積み重ねながら、品質を上げていく。
このタイプは、設計書をこまなく読んで理解でき、丁寧に、地道な作業ができる人。

実際の開発では、結合テストやシステムテストでこの役割の人が重要になってくる。
この工程で初めて、開発者も自分たちのソースが動く所を見れるから、初めて実装のミスマッチに気付く。
テスターは、プログラマが何もない所で切り開いた道をなだらかにする。

RedmineやTestLinkを運用していると、プログラマとテスター、設計者の連携作業が実はボトルネックだったという事実によく気付く。

例えば、仕様変更があったとしても、アサインしたタスクに漏れがあったりする。
あるいは、せっかくバグ修正したとしても、たくさんのバグを発見しすぎて、バグ検証が遅れたりする。
又は、一つのバグを見つけたら、それに関連する機能や要件はテスト不要なのに、無駄にテストしてしまう。

チケット駆動開発やテスト管理のツールは、この連携作業をサポートするのが一番の目的だ。

そして、アジャイル開発は、システムを小刻みにVerUpさせる戦略を意図的に採用することで、品質維持と機能拡張という矛盾する目的を実現しようとする。
このアジャイル開発のタスク管理やテスト管理をサポートするツールが、Redmineであり、TestLinkであったりする。

色んな役割の人達が集まったチームに対し、開発インフラを提供し、そのコミュニケーションを支援するのが、チケット駆動開発であり、プロジェクトファシリテーションだったりする。

色々試してみたい。