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

2009年2月

2009/02/28

プロジェクトの失敗は見積もりの失敗

プロジェクトの失敗とは見積もりが失敗しているのだ、という下記Blogを読んで考えたことをメモ。
#以下はラフなメモ書き。

【元ネタ】
Agileが根付かないもう一つの理由 - masayangの日記(ピスト通勤他


【1】SW開発のプロジェクトは規模が大きくなるほど、失敗する確率も高くなる。

SIerならば、成功の基準は、黒字だ。
そして、IT業界にいる人なら誰でも、「黒字=納期に間に合う=品質が良い」という等価な式が成り立つことを経験的に知っている。
失敗に至るプロジェクトのパターンはいつもワンパターン。

要件定義、設計と進みながらも、システムのスコープや細部を詰め切れず、裏ではRailsやSeasarなどの新技術を取り入れて実装を並行開発する。
そして、殆どの画面を作った後も仕様変更が五月雨式に落ちてきては手直しし、結合テストやシステムテストで初めて稼動させた時に、大きな穴に気付く。
いくらテストしてもバグが落ち着く傾向も無く、延々と残業と休日出勤が続く。
品質が安定しない状態のまま、最後は納期も遅れてしまい、投入した人員では足りず、火消しやヘルプの人員をどんどん投入して、何とか鎮火させる。

WF型開発による失敗はいつもパターンが決まっている。

【2】上記の記事では、見積もりが失敗しているのだ、と指摘する。
つまり、上記のような失敗パターンに陥るなら、成功する確率の高い見積もりを提示すればよいだけだ、と。

しかし、見積もり工数を120%とか150%の水増しで顧客へ出したとしても、いつも遅れてしまう。
その理由は、TOCを由来とするクリティカルチェーンの話にある、学生症候群や遅延の伝播が優先されるなどがあるだろう。
いつも、バッファをすぐに使い切ってしまう。
また、技術上の難点を正確に見積もることは正直難しい。特にリファクタリングの作業も必要になるような技術的負債がある場合は尚更だ。

【3】僕はまだTOCの理屈が何となく分かる気はするけど、体ではまだ分からない。
でも、チケット駆動開発でアジャイル開発を実践してみて、見積とはそもそも何なのか、という疑問を感じるようになった。

XPを代表とするアジャイル開発は、2~4週間のイテレーションで小刻みにリリースしていく。
そのイテレーションで何を開発して、どんな機能を顧客へリリースするのか、イテレーション計画をまず立てる。
その時に、見積もりをする。

アジャイル開発の最大の利点は、早期のリリースで重大な問題に気付くことだ。
つまり、早く失敗することで、リスクを早く検知し、早期に是正対策を取ることができる。

最初の数回のイテレーションがどれもリリースに失敗したならば、そのプロジェクトは大きな赤字になるまでに却下されるだろう。
WF型開発のように最後の1回のリリースまでに、メンバー全員が疲弊しきってしまうこともなくなる。

【4】アジャイル開発の見積では、工数による見積よりも、機能の大きさや機能の難しさなどをまず考える。
特によく考えることは、1プロジェクトを数回のイテレーションで分割リリースするならば、どの順番に機能を作ったらよいのか、という機能の優先順位付けとその関係図(概念モデル)だ。
例えば、Amazonのような小売系Webシステムを請け負ったならば、下記のような順番で実装するようにイテレーションに分割していくだろう。

1・会員登録、商品検索などのユーザ向けの基本機能
2・会員保守、商品保守などの管理者向けの基本機能
3・注文フローを保守する管理者向けの重要な機能
4・カート画面、注文画面などのユーザ向けの重要な機能
5・帳票出力や会計システムと連動する機能

上記は、データのCRUDの観点から、システムをいくつかのサブシステムへ分割し、そのサブシステムを少しずつ開発していく考えだ。
つまり、アジャイルに開発するには、高度な設計技法、モデリング技術を必要とする。

システムをサブシステムへ分割し、更に機能分割していくと、精度の高い見積を行うことができる。
この時に、ファンクションポイントやユースケースポイントなど昔から知られている技法を使えば、より精度の高い見積もりができるだろう。

【5】1イテレーションには、設計、開発、単体テストだけでなく、結合テスト、受入テストもある。
アジャイル開発といえども、受入テストは当然あるし、その工程が最も大変であることは変わりない。
設計書をいくら書いたとしても、単体テスト済みのプログラムであっても、結合テストで初めて判明するバグはたくさんある。
ユーザに使ってもらって、初めて理解できる要件や仕様もある。
だから、そういうリスクを早めに出しておけば、残りのバッファで対処することもできる。

数回のイテレーションを実施してみて気付いたことがある。
それは、プロジェクト特有、あるいは開発チーム特有の開発速度(ベロシティ)がある。
1イテレーションで実装できる機能の数、あるいは機能規模は、ある程度平均している。

開発速度と言う場合、それは工数ではないと思う。
開発速度は、生産性そのものだと直感している。

工数は、同じ機能の実装であっても、開発者ごとに大きく違う。
でも、チーム全体で開発できるサイズは上限があり、ある一定の幅の中に納まる。

実際は、チームでもメンバーの入れ替えは時々あり、入れ替えた直後は開発速度は落ちる。
とはいえ、チームのルールや技術に慣れれば、チーム全体の開発速度は平均の前後で落ち着く。

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」では、ベロシティによる見積もりとコミットメントによる見積もりの2種類のうち、後者を推奨している。

前者は、平均の開発速度(ベロシティ)から、そのイテレーションに入れられるサイズを決めて、そのサイズに入るようにストーリーを取捨選択する方法。
後者は、イテレーションに入れるストーリーをチームメンバー全員に「コミット(契約・約束)できるか?」と尋ねて、ストーリーを優先順位付けして取捨選択する方法。

後者を推奨する理由は、開発速度という概念を見積もりに使うにはあまりにも曖昧だからだ。
確かに、開発速度に当てはまるようにストーリーの数を制御しても、開発速度はそもそも最小値と最大値の範囲内にある平均だから、多少の誤差が発生する。
ソフトウェア開発がビジネスである以上、多少の誤差も命取りになりうる可能性はあるから。

でも、開発速度という概念は僕は上手に言えないけれど重要だと考える。
見積もりは多分、開発速度の概念と密接に絡んでいるから。
つまり、見積もりは絶対的な数値ではなく、ある一定の範囲内の平均の数値。
だから、実際にやってみないとどれだけ工数がかかるか分からない。

もう少しまとめてみる。

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

2009/02/25

XP祭り関西2009の講演資料リンク

XP祭り関西2009の講演資料をリンクしておく。

XP祭り関西2009詳細 - XpjugWestWiki

他にもありましたらご連絡下さい。

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

2009/02/23

チケット駆動開発の論文

さかばさんがチケット駆動開発の論文を書かれたのでリンクしておく。

【元ネタ】
ソフトウェアさかば: TiDD:チケット駆動によるアジャイル開発法


さかばさんの論文の主張を抽出すると下記になる。

1・TiDD(Ticket Driven Development)は、古くからある障害管理ツールなどを包括的な構成管理ツールへ拡張し、それらのツールに合わせた開発プロセスである。

例:
バージョン管理(ソース管理)→Subversion
障害管理→Redmine
単体テスト→テスト駆動開発
自動ビルド→継続的インテグレーション

2・アジャイル開発を運用する上での難点の一つである進化的保守は、TiDDでは、プロジェクト管理をチケット管理で置き換えることで解決しようとする。

3・二つ目の難点である並行開発は、メインラインモデルとチケット管理の組み合わせで解決しようとする。

4・3つ目の難点である頻繁なリファクタリングによる品質劣化のリスクは、チケットとリビジョンの関連付けによって、変更理由を追跡できることで解決しようとする。

5・チケット駆動開発をRedmineで実践した場合、ロードマップをイテレーション計画、チケットをタスクカードで運用することで、アジャイル開発を可能にする。


アジャイル開発を運用するのは何故難しいのか、そして、チケット駆動開発がそれらをどのように解決しようとしたのか、を論理立てて書かれている。
僕が言いたかった内容はこういうことだったんだな、と思う。


【参考】
情報処理推進機構:ソフトウェアエンジニアリング・EPMツール

easeプロジェクト

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

2009/02/21

【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」

XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」を公開します。
CC Attribution ライセンスとします。

【元ネタ】
チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

プログラマの思索: 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」

まちゅさんはTracのチケット管理を元に「チケット駆動開発(Ticket Driven Development)」を提唱された。
僕は、Redmineによるプロジェクト運営でプロジェクト管理が劇的に改善した経験を昨年のKOFで話してみた。

KOF講演後、興味を持ってくれた人達からのフィードバックを受けて、更にそのアイデアを用いて、アジャイル開発を補強する方向へ持っていけないか、自分なりに思索してきた。
XP祭り関西2009の講演資料は、KOF講演資料の内容と重複部分は多いですが、チケット駆動開発を定義してみる等ブラッシュアップした内容にしています。

XP祭り関西2009の講演後、初対面の人達からたくさんの質問やフィードバックをもらって刺激を受けました。
更にチケット駆動開発のアイデアを洗練させていきたい。

コメントがあれば嬉しいです。

【補足】
関西でTiDD勉強会を開催しています。
興味がある方はどうぞ。

TiDD勉強会 | Google グループ







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

裏プロセスは並行プロセス

萩本さんの記事を読んだ感想をメモ。

【元ネタ】
「現状のソフトウェア開発は間違っていないか?」(プロセス編) - @IT自分戦略研究所


【1】大規模プロジェクトほど、WF(ウォーターフォール型プロセス)になりやすい。
膨大で複雑な仕様を開発するには、工程ごとに仕様の大枠を決めて、後戻りしないように確定しないと、開発速度は上がらない。

しかし、SW開発には、仕様変更が付き物。
更に、バージョンアップしながらユーザビリティを上げていく戦略が多い。
だから、WFでは、手戻り作業ばかりやって、結合テストで火を噴くパターンが多い。

大規模プロジェクトで一番嫌なのは、イテレーションと言う概念が無いこと。
WFはリリースが最後の1回だけ。

最後にリリースするまで、どう動くのか分からない。
イテレーションと言う開発のリズムが無いから、最後にリリースするまで、延々と残業や休日出勤が続く。
そしてリリース後も、顧客の苦情や膨大なバグが押し寄せて、ひたすら延々とバグ潰し。
ワンパターンすぎる。

【2】大規模プロジェクトの開発プロセスの特徴は、並行プロセスだ。
つまり、サブシステム毎に開発チームがあり、それらのチームが並行作業で設計して開発していく。

当然、最初は、サブシステムの連携の仕様が曖昧で、設計時には全てを突き止められない。
全てのチームが実装し終わって、統合して初めて、こういう風に動くんだ、と気付いて、パッチを当てていく。
しかし普通は、ビックバン統合になっているから、膨大なバグを潰して品質を確保するのが非常に難しい。

上記の記事に出てくる裏プロセスも、実は並行開発。
WF型開発を表で実行しながら、裏では、要件やアーキテクチャの検証をやっている。
つまり、裏プロセスで、設計や開発のリスクを早めに感知して、早期に是正対策を採っている。
WFが抱えるリスクを裏プロセスが吸収しているのだ。

上記の記事の指摘のように、これは反復開発ではない。
つまり、イテレーションと言う概念が存在しない。

XPが言うイテレーションの定義ははっきりしている。
計画→設計→実装→テスト→リリースの一連のサイクルのこと。
つまり、受入テストをクリアしないイテレーションはありえない。
そんなシステムは品質がボロボロで、顧客が使える代物ではない。

並行プロセスでは、マイルストーン時に、複数の開発チームの設計が終わっているだけ、単体テストまで終わっただけ、などのように各工程が完了しただけ。
リリース可能な動くモジュールができているわけではない。
これは、少なくともXPが言うイテレーションではない。

本当は、機能1を稼動するイテレーションの後に、機能2を作り始めたい。
そうすれば、まず機能1が動くシステムがあるから、開発者も顧客もイメージが湧く。

開発者は、少しずつ動かしながら、機能追加していくので、リスクが少ない。
顧客は、動かしながら、予期しない操作で欠陥を見つけたり、改善して欲しい機能をフィードバックする。
つまり、イテレーションを繰り返していくうちに、少しずつ機能もユーザビリティも向上していく。
例えば、オープンソースのツール群はこのような開発スタイルが多く、バージョンが上がるたびに機能が洗練されていく。

大規模プロジェクトでアジャイル開発を選択できない最大の理由は、機能分割するモデリング力が足りないからではないか、と推測している。
イテレーション毎にリリースしていくには、膨大で複雑な業務を、イテレーションが定める期間内かつリリースできる単位に機能分割して仕様へ落とさなければならない。
そこまで辿り着けないからではないか?


XPを代表とするアジャイル開発は、その概念が広く知られてきたとはいえ、運用のハードルはまだまだ高い。
アジャイル開発を実践し、運用して根付かせるには、何が必要か?
もっと考える必要がある。

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

2009/02/15

Hudsonの使い道

Hudsonの面白い使い道についてメモ。

【1】Trac Lighting付属のHudsonをCI以外の目的で使ってみる - almost nearly dead

HudsonをWindows上でバッチ処理として定期実行するやり方。
上記では、Tracのバックアップに使っている。

Unix上ならcronで行うやり方もあるが、Hudsonの利点は、GUI上で複雑な設定や管理ができること。
バッチ処理はCobol時代から存在するアーキテクチャだから、Hudsonをビルド以外にバッチ処理として使うやり方は、非常に興味深い。

更に興味を持つのは、検索エンジンHyperEstraier用のIndex作成処理にHudsonを使っていること。
昨今、SVNにソースだけでなくExcelやWordの仕様書もバージョン管理しているため、HyperEstraierでそれらをWeb検索できるなら、要件管理や設計工程で非常に役立つ。

TracLightningにはHyperEstraierのプラグインもあるため、TracLightningはバージョン管理や仕様書管理も含む包括的なプロジェクト管理ツールだと言える。


【2】Subversion と Hudson の連携-その1 Subversion リポジトリのソースをビルドする - かおるんダイアリー

Subversion と Hudson の連携-その2 Subversion リポジトリのコミットをトリガにソースをビルドする - かおるんダイアリー

SVNコミットしたタイミングでHudsonをビルドさせる設定方法。
TracLightningに付属しているSVNのpost-commit.batを編集しているが、Unix上でも同様にできる。

継続的インテグレーションを突き詰めると、SVNコミットした時点で、最新モジュールがビルドされるのが好ましい。


【3】Hudson で分散ビルドのためのスレーブ設定 - かおるんダイアリー

Hudsonで分散ビルドするための方法。
キャプチャ画面入りの説明で分かりやすい。
このやり方で、複数のプロセスを使ってビルドできるため、ビルド時間を短縮できるはず。

かおるんさんが考える開発環境ごと(VS2008用、VS2005用、特殊なビルドシーケンス用)に分散ビルドを使うやり方も興味深い。
同様のやり方は、JDKやTomcatのバージョンが異なる場合に同じタイミングでビルドする時にも使える。
あるいは、ソフトウェア・プロダクトラインのように製品ファミリーの開発をしている場合、仕様が微妙に異なる複数の製品を同じタイミングでビルドする時にも使えるだろう。


上記はいずれもTracLightningに含まれるHudsonをWindows上で使っている。
プロジェクト管理や構成管理の一環としてHudsonを使っているのは、TracLightningが使いやすいからだろうと思う。

最近欲しいのは、AllInOneRedmine。
Redmine+Subversion+Hudson+TestLinkを一体化したツール又はVMイメージがそろそろ欲しい。
SW開発のプロジェクト管理は、TracLightningやAllInOneRedmineで行うのが今後普通になるかもしれない。

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

2009/02/14

アジャイルごっこ

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。

【元ネタ】
続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium : テクモラトリアム

DeclineAndFallOfAgile - アジャイルの衰退と凋落

【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。

XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。
しかし、その効果はいずれ限界が来る。
結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。
このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」と呼んだ。

この指摘はあまりにも痛烈だ。

僕が今実践しているチケット駆動開発は、SW開発のどのプロジェクトでも適用できるし、実際の開発プロセスを大きく改善してくれることを経験している。

少なくとも、プログラマの受けは非常に良い。
彼らは、チケットを自分たちのToDoやリスクとして登録してくれるし、何よりもソースとチケットの紐づけによって、自分たちで変更管理のプロセスを発見してくれる。

プロジェクトリーダーにとっても、Redmineロードマップを見ながら、イテレーション計画を実施することで、プロジェクトのスコープとスケジュールを開発の現実と調和するように軌道修正できる。
このおかげで、アジャイル開発の最大の利点であるイテレーティブな開発プロセス、更には短いサイクルで小刻みにバージョンアップする小規模リリースを実現できる。

しかしながら、顧客を含めた開発体制がアジャイル開発にマッチしなければ、壁にぶち当たる。
特に大規模開発で複数の開発チームが存在する場合、一つの開発チームがスコープとスケジュールを調整できる範囲は限られる。

チケット駆動開発は開発現場の状況をリアルタイムに見える化するため、溢れたタスクや品質の悪さを常に公衆の面前にさらす。
タスクが溢れすぎてチーム自身で制御不能な場合は、もはや意味を成さない。

スコープとスケジュールを調整可能にして初めて、価値あるソフトウェアを育てていく開発を実現できるはず。

【2】かと言って、エンジニアリング無しのアジャイル開発もありえない。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきには、こんなことが書かれている。

「アジャイルの衰退と凋落」の記事のように、ビジネスの要請に基づいて、短いイテレーションと頻繁な計画作りだけを導入しても、プロジェクトを疲弊させるだけだ、と。

XPが提唱する技術的プラクティスは、実はSW構成管理に関する内容が多いというのは注目に値すると思う。
ソースの共同所有、テスト駆動開発、継続的インテグレーションなどのプラクティスがあるおかげで、メインラインモデルのように、複数のコードラインによる並行開発を運用可能にする。
つまり、アジャイル開発は高度なSW構成管理を必要とする事実を、XPは示唆した。

一部では、Gitなどのような分散バージョン管理も普及し始めている。
ソース管理という最も基本的な技術は、まだ技術革新の途上にある。


【3】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」には、イテレーション計画の作り方とその基盤を与える見積もりについて有用なノウハウがたくさん書かれている。
アジャイル開発を実践しないプロジェクトリーダーであっても、バッファの取り方などは参考になるはずだ。

RedmineのScrumプラグインを入れると、「StoryPoint」(規模の大きさ)、「Velocity」(開発速度)の概念が具現化される。
この概念を使えば、イテレーション計画の精度は高くなるはずだ。
特に、見積もりとは平均の開発速度でありコミットメントではない、という指摘は僕は凄いと感じた。


アジャイル開発は、品質・コスト・納期の三角形からコスト・納期・スコープの三角形へプロジェクトマネジメントのパラダイムシフトをもたらした。
このパラダイムシフトを理解し、実践できなければ、アジャイル開発とは言えない。

技術とビジネスをいかに調和させるか?
チケット駆動開発に、開発速度やストーリーポイントなどの概念を注入して、アジャイル開発を更に強化できないか?


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

2009/02/10

RedmineへScrumのアイデアを注入

Redmineフォーラムで、Scrumのアイデアを実現しようと議論して、実際にプラグインが公開されていたので試してみた。

下記は、RedmineへProdctBackLog、SprintBackLog、TaskBoard、バーンダウンチャートの機能を追加しようとする野心的なプラグイン。
その時の画面をキャプチャしてみた。

【元ネタ】
Redmine - Agile methodologies and Redmine

【RedmineへProdctBackLog、SprintBackLog、TaskBoardを追加するプラグイン】
scrumalliance's redmine at master - GitHub

【Redmineへバーンダウンチャートを追加するプラグイン】
scrumalliance's redmine_burndown at master - GitHub

【1】ProductBackLogは、XPのストーリーカード一式。
下記の画面では、ストーリーをチケットで追加して表示したもの。
#但し、現在のソースでは、Add Stroy押下後に落ちる。

Productbacklog






【2】SprintBackLogは、XPのイテレーション計画そのもの。
イテレーションに含まれる全てのタスクカードをフィルタリングして表示する。

興味深いのは、右欄に「StoryPoint」「Hours」という数値と「Velocity」というグラフがあること。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」によれば、StoryPointは規模の大きさ、Hoursは工数、Velocityはイテレーション単位の開発速度である。

従って、SprintBackLogから、予定・実績の工数比較や開発速度を見ることができる!!




Sprintbacklog





【3】タスクボードは、PFで出てくるタスクかんばん。
タスクカードに相当するチケットが、イテレーション単位で、ステータスごとに表示される。



Taskboard





【4】バーンダウンチャートは表示できなかった。
多分APIが足りないのだと思う。



Burndown



SVNリポジトリと連携させれば、「ストーリー→チケット→ソース」まで一貫して追跡できる仕組みが整う。
Scrum、あるいはXPを実践して開発するには最低限十分なインフラ。

世界中の一部の開発者たちも、このScrumのプラグインに興味を持っているみたい。
Redmineで上記の画面を見ると、アジャイル開発はこうやってやるんだ!というのがリアルで感じられる。



|

TestLinkの可能性

「塹壕よりScrumとXP」の「15.1. 多分受け入れテストフェーズは回避できない」を読んで、TestLinkを受入テストで使うアイデアをメモ。
以下メモ書き。

【元ネタ】
塹壕よりScrumとXP(日本語訳PDF)

第1回:テスト設計の必勝テクニック:ITpro

TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト


【1】TestLinkをSW開発のどの工程で使うべきか?
TestLinkは受入テスト(あるいは結合テスト以降のテスト)で使う。

XPが生み出したテスト駆動開発によって、プログラムは単体テスト品質をクリアするようになった。
継続的インテグレーションによって、コミットしたコードラインは常時リリース可能になった。
しかし、それらのプラクティスだけで、開発したらすぐに顧客へ納品可能か?

答えはNo。
受入テストをクリアしなければ、納品可能な品質にはならない。
#XPにも受入テストのプラクティスは当然ある。

受入テストと単体テストには大きな違いがある。
単体テストはホワイトボックステスト。
受入テストは、業務インターフェイスが正常動作するか確認するテスト。

つまり、単体テストはプログラムの正常動作を保障する目的に対し、受入テストは、設計した仕様の正常動作を保障する目的。
間違った設計書、考慮漏れの設計書から作られたプログラムは、単体テストではバグを検知できず、受入テストで初めて検知できる。

受入テストのテストケースのベースは、シナリオやユースケース。
受入テストのテストケースとして、SeleniumやFITを使おうとしたが、結局使いこなせなかった。
どうしてもExcelのテスト仕様書に頼ってしまう。

理由は、技術上のハードルが高かったこともあるが、テストケースが要件をすべて網羅しているか、という観点が薄かったから。
受入テストのテストケースを自動化するよりも、要件カバレッジの観点の方がはるかに重要だ。
つまり、業務の理解、モデリング力をどれだけ持っているかがSEに試されている。
質の高いテストケースを作る方がはるかに大事。

システムを納品するまでの全テストケース数は、単体テストから受入テストまで数千~数万ケースにのぼるのが普通だろう。
これだけの膨大なテストケースをこなして、プロジェクト後半と言うリソースも限られた期間にバグ修正するのは至難の業。
プロジェクト管理は、実はテスト戦略が大半を占めるのではないか?

受入テストはどうしても手動のテストにならざるを得ない。
僕はそれでも良いと思う。
但し、TestLinkで受入テストの生産性を上げることはできるはず。

【2】TestLinkならExcelのテスト仕様書をWeb化でき、更に計画から実行、メトリクス採取まで一貫して管理できる。
TestLinkに大きなポテンシャルを感じる点は二つ。

1.W字モデルのような使い方。
要件定義や設計のような上流工程で、テスト計画も同時に作る。

例えば、要件カバレッジを使って、要件をカバーするテストケースが必ずあるか、これらのテストケースで要件を全て網羅しているか、を確認していく。
そうすれば、新たな要件が見つかったり、矛盾する仕様が見つかる時もあるだろう。

仕様漏れ、仕様の認識相違を早い工程で検知したい。
設計もテスト駆動開発のように、テストケースを考えながら検証可能な仕様へ落としていく。

上流工程の品質UpにTestLinkを使えないか?

2.テストケースとバグ修正の連携。

TestLinkでNGのテストケースが発生した場合、RedmineなどのBTSのチケットに紐付ける。
TestLinkでは、「各テストケースの全バグ」欄で、NGのテストケースとバグチケットの一覧が表示される。
しかも、バグチケットのステータスがチケットのタイトルに表示されるので、テスト担当者はチケットが解決されたかどうか、リアルタイムに確認することができる。

この機能のおかげで、テスト担当者と修正担当者がペアプロのように作業できるため、管理者は作業状態さえモニタリングすればよい。

TestLinkでは「ビルド」と呼ばれる機能があり、これは組込製品なら製造番号、あるいはビルド番号に相当する。
つまり、TestLinkのテスト計画に紐づいた全テストケースを回帰テストで使った場合、TestLinkのビルドにモジュールのビルド番号を入れておけば、どのビルドモジュールでNGのテストケースにが出たのか、という判別に使える。
TestLinkを使って、アジャイルにテストするインフラが整う。

【3】TestLinkで数千~数万の受入テストを実施した経験から気付いたことがある。
1回のビルド(TestLinkのビルド)で、NGのテストケースは全体の何%だろうか?

もし5%以上なら、そのシステムは品質が悪い。
1千件のテストケースなら50件のバグ、1万件のテストケースなら500件もバグが出たことになる。
例えば、納期まで残り1ヶ月で上記の状態になったら、手遅れだろう。

バグの原因は単体テスト漏れもあるだろうが、設計漏れや設計ミスもあるだろう。
受入テストが業務のインターフェイスのテストであるならば、単体テストで判明しなかったバグはまさに設計ミスそのものだろう。

つまり、受入テストを実施しなければ判明しなかったバグは、業務を正常稼動するためのインターフェイスが間違っていた、あるいは漏れていたわけで、実はとても重大で危険。
そんなバグは早めに検出しておきたい。

TestLinkで、受入テストで判明する全てのバグを検出できるわけではないが、バグ出しとバグ修正のワークフローを一貫して管理できるため、生産性を上げることはできる。


TestLinkの最新Ver1.8には、XML-RPC経由でTestLinkを操作するAPIが公開予定。
このツールを使えば、TestLinkで受入テストを自動化することも理論的には可能なはず。

TestLinkには大きな潜在性があると思う。

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

2009/02/08

イテレーション毎の開発速度

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を早速購入して読み始めた。
全部読んでないけど、考えていることをメモ書き。

【1.元ネタ1】第8回 チームの開発速度を計測してリリース・プランニングに役立てる:ITpro

TRICHORDの開発チームによるアジャイル開発の実践例。
イテレーション単位で開発可能な機能(ストーリー)の数から開発速度(velocity)が算出される。
つまり、この数を平均化すると、そのチームが1イテレーションで開発できる見積もり工数になる。

アジャイル開発では、最終リリースまでに複数のイテレーション単位でリリースしていくから、そのたびに実績工数を測定できる。
イテレーションを経験するたびに、以前のイテレーションの開発速度から、どれだけの機能を開発可能か分かる。
理論上では、経験したイテレーションの数が多いほど、精度の高い開発速度が得られるから、後のイテレーションほど、精度の高いイテレーション計画を作ることができる。

【2.元ネタ2】塹壕よりScrumとXP
Scrum and XP from the Trenches v.2.2(上記の日本語訳PDF)

--↓引用開始↓---
13. リリースの計画と価格確定させた契約をどうするか

通常、僕たちのリリース計画は、この質問に答えるよう試みることだ。「この新しいシステムのバージョン1.0 を、最も遅い場合、いつ納品することができるのか」

もしリリース計画について真剣に学びたいのなら、この章を飛ばして、代わりにMikeCohn の著書「Agile Estimating and Planning」を購入することをお勧めする。
僕はこの本をもっと早く読んでおきたかったと心底思う(僕がこれを読んだのは、僕たちが身をもってこの内容を理解した後だった…)。
リリース計画の僕バージョンは、ちょっと安易なものだけど、良い取っ掛かりとなる筈だ。

--↑引用終了↑---

この記事は、Scrum+XPの実践例。
イテレーション計画で工数見積するなら、まず「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」を読めと言っている。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」では、こんな端書がある。

計画作りは価値の探求なのだ。

顧客とネゴして作った要件定義書からシステムを作っておしまい、という開発スタイルは、サービス業と化したSIerにはありえない。
開発中に仕様変更と称した変更要求が、五月雨式に開発チームに必ず降ってくる。
あるいは、リリース後に機能改善と称した膨大な変更要求がやって来ることもある。

結局、システム開発は顧客と一緒に、どんなシステムが顧客にとって価値があるのか、を探検するプロセス。


従来型の計画作りの問題点は、プロジェクトのチームやステークホルダが見積もりをコミットメントと捉えてしまうことだ。
見積もりは(見積もった時間内に作業が完了する)確率だが、コミットメントは確率ではない。

つまり、見積もり工数は、平均の開発速度。
必ずその工数で完了できるコミットメントではない。
アジャイル開発ならば、複数のイテレーションを経験することで、平均の開発速度の精度が上がるので、実現可能性の高いイテレーション計画を作ることができるはず。


【3】Redmineにはレポートという機能があり、実績工数を表示する。
この機能は、時間トラッキング機能と関係している。

Redmineの時間トラッキング機能は、作業分類というチケットの属性で制御する。
作業分類は、例えば、設計・実装・テスト・管理などに分類できるから、チケットの実績工数を入力する時、作業分類によって実績工数を色付けできる。
この機能のおかげで、設計・開発・テストの各工程の実績工数を測定できる。

Redmineのレポート機能では、バージョンと月別のクロス集計を表示できる。
この集計結果から、1イテレーションにかかった実績工数がどの期間で発生したか分かるので、イテレーション単位の開発速度を測定できる。

但し、Redmineでは、予定・実績工数比較の機能が弱く、バージョン画面でしか見れない。
本当はもっと色んな角度から予実比較を見たい。
それができれば、プロジェクトのリスク管理がやりやすくなる。
例えば、この機能のテストで意外と時間が取られたのか、などの気付きが出てくる。

Redmineに、このアジャイル開発における開発速度の概念を注入して、チケット駆動開発のアイデアを強固できないか?

それから、「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」だけでなく、09/2/18発売予定の「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング」も必読だ!

【参考リンク】
続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium : テクモラトリアム

[本]アジャイルな見積りと計画づくり 安井さんとのやりとり - hiro_eの物事(楽しい物や思ったこと)



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

るびまにて関西Ruby会議01@関西-KOF2008を公開

るびまに昨年の関西Ruby会議01@関西-KOF2008の記事が公開されました。

Rubyist Magazine - RegionalRubyKaigi レポート (03) 関西 Ruby 会議 01

るびまと言えば、日本のRubyの総本山。
何か恐れ多いです

なお、Ruby1.9.1の開発はRedmineで管理されています。
Redmineを使った開発の例として参考になります。

Ruby Issue Tracking System

Ruby1.9のロードマップは下記の通り。
開発の進捗がリアルタイムに分かります。

Ruby 1.9 - ロードマップ - Ruby Issue Tracking System

Ruby1.9のチケット集計結果(サマリ)は下記の通り。
過去、現在そして将来のバージョンやチケットの動向をリアルタイムに把握できます。

Ruby 1.9 - Ruby Issue Tracking System サマリ

Ruby1.9のリリース結果は下記の通り。
変更記録はChangeLogそのものなので、どのバージョンにどんなチケットが反映されているか追跡できます。

Ruby 1.9 - Ruby Issue Tracking System 変更記録

Ruby1.9のリポジトリ統計は下記の通り。
開発者毎の貢献度合いや開発の活発具合を見れます。

Ruby 1.9 - リポジトリ - 統計 - Ruby Issue Tracking System

Rubyの実際の開発が見える化されているので、興味深いです。

個人的には、TracよりもRedmineに大きなポテンシャルを感じてます。


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

2009/02/07

Redmineを使って気付いたことpart7~イテレーションで追跡する

チケット駆動開発でアジャイルに開発しながら、「チケットではなくイテレーションで進捗やリスクを追跡する」意味が何となく分かってきた。
それについてメモ。

【1】チケット駆動開発の基本は、チケットファースト。
チケットがXPのタスクカードに相当する。

担当者は、チケットへ作業内容を記入してから、作業を開始する。
開発者は実際、チケットをToDoカードのように用いている。

SW開発のタスクは単にプログラミングだけではない。
お客様へ納品する設計書を作ることも必要だし、テスト仕様書を作ることも必要。
更には、ビルド環境を作ることも必要だし、テストデータを準備することも必要。

すると、チケットは終了するペースよりも登録する方がどんどん増える。
何もしなければ、チケットは乱発されて、放置状態になり、収拾が付かなくなる。

僕が初めてTracを運用した時、マイルストーンやバージョンが曖昧なままチケットを登録していたから、チケットが膨大に登録されて放置されてしまって、コントロールできなくなった苦い思い出がある。
Tracでは、マイルストーンやバージョンの本質が分かっていなかった。

Redmineを使い始めて、バージョンとマイルストーンを一致させるRedmineの思想に触れた。
Redmineでは、チケットをバージョン単位でグループ化して、小刻みにバージョンアップしていく。
つまり、Redmineのバージョンは、システムのバージョンであり、開発チームにとってリリースのマイルストーンでもある。
この運用で、初めてアジャイル開発の肝が分かった気がした。

【2】チケットをイテレーション単位でグループ化するのがチケット駆動開発の最大の肝なのだが、僕はこの運用に更に手を加えている。

普通、新規開発時は、管理者がWBSから洗い出したタスクをチケットとして一括登録していく。
この時のチケットは、一つの成果物を作る作業になる。
例えば、機能実装、設計書作成など。
そして、これらチケットを閉じた大きな機能単位として、イテレーション単位でグループ化して、小刻みにリリースしていく。

しかし、実際のSW開発では、上記以外のチケットが発生する。
開発者は、この機能はバグがあるかも、とか、ロジックが共通化されていないからリファクタリングしたい、などの不安をいつも抱えている。
僕は、それら開発者の意見も全てチケットへ登録し、内部課題と言う特別なイテレーションで管理している。

理由は、リスク管理の一環として。
実際のシステムは、開発者しか知らない仕様やバグは結構存在する。
それらは、情報共有されなければ、必ず問題として現れて、迅速に対応できる準備が無ければ、必ず火を噴く。
だから、管理者は、開発者が気付いた課題(まだ問題として顕現されていないもの)をチケットへ仮登録して、課題を見える化しておく。

システムはハードウェアの製品よりも非常に繊細。
特にリファクタリングが必要なロジックは、ファウラーが言う技術的負債に当たる。
技術的負債の工数を把握しておかないと、機能追加の工数見積で大きく狂う危険が高まるから。

但し、それらのチケットは、内部課題という特別なイテレーションへ入れて、終了期限を無しにしている。
理由は、将来問題として現れる可能性はあるが、今最優先で対処する課題ではないから。

この運用をし始めて、開発者は気付いた課題や不安を積極的にチケット登録するようになった。
管理者である僕は、それらチケットをいつも精査して、どのイテレーションで混ぜるべきか、どのチケットと関連しているか、見極めるようにしている。

そして、内部課題に挙がったチケットに手を付ける時、進行中のイテレーションに混ぜ込んで、終了したらそのイテレーションでリリースする。
理由は、そのリリースモジュールに、内部課題のチケットが反映されているから。
実際、Redmineでは「変更記録」というリリース結果のChangeLogに、内部課題のチケットも終了チケットとして表示される。

しかし、内部課題のままチケットを却下にする場合もある。
定期的に内部課題のチケットは棚卸しして、対処する必要が無くなれば、却下にしてCloseしていく。

これが「チケットではなくイテレーションで進捗やリスクを追跡する」意味。
この運用を始めて、チケットの取捨選択がアジャイル開発の肝なのだ、と強く痛感した。

チケットは単なるタスク管理ではない。
チケットへ将来発生するかもしれない課題も登録して、リスク管理として使う。
Redmineロードマップに現れたチケットは、単なるタスクだけでなく、プロジェクト内部で気付いたリスク全ても含む。

リスクの見える化は、管理者だけでなく開発者にも良い影響を与える。
一人の開発者の不安は、実は他の開発者が既に解決した内容の場合もあるから、お互いに情報共有し合う糸口にもなる。
特に新しいフレームワークを使った開発の場合、最初に誰かが人柱になってノウハウをためる。
そのノウハウを共有化するインフラもチケット駆動開発は与えてくれる。

【3】だが内部課題というイテレーションで解決できない問題も実際ある。

例えば、重大なセキュリティホールが判明して、フレームワークやハードウェアをVerUpしなければならないとしたとしよう。
あるいは、SQLインジェクション対応のために、システム全体をリファクタリングしなければならないとしたとしよう。

この場合、もはやイテレーションと言う短いサイクルでは開発を制御することは難しい。
そこで、Redmineの場合、子プロジェクトを新規に作り、セキュリティ対策用のプロジェクトにする。
そして、このRedmineプロジェクトへ、trunkから分岐させたbranchと紐付け、ソース修正用のチケットをどんどん追加していく。

これはいわゆるタスクブランチの発想。

理由は、このプロジェクトは、現行のtrunkのプロジェクトのライフサイクルと異なるから。
trunkへセキュリティ対策用の修正ソースや設定ファイル修正を混ぜたら、システムが不安定になる。
だから、別ブランチ上で、パッチが有効か試したり、フレームワークやハードのVerUpで解決できるか検証していく。

実際のシステムは、ミドルウェアやハードのVerUpが意外に多い。
VerUpしなければ、長く運用できないのがITの宿命。
しかし、VerUpは、システムが不安定になるリスクをいつも抱えている。
そのリスク検証のために、別プロジェクトで管理する。

他の場合では、インシデント管理もtrunkの開発とは異なる別プロジェクトで管理する。
顧客からの問合せやFAQ、ベンダーへの問合せなどは、SW開発とは異なるライフサイクル。
同じRedmineプロジェクトで運用すると混乱する。

初めてTracを使った時、Tracでは複数プロジェクトで管理ができないから、運用が異なるチケットを全て一つのプロジェクトに入れてしまい、混乱してしまったのだと思う。

【4】TracとRedmineではイテレーションの概念が大きく異なるように思う。

その違いは、イテレーションを管理者の立場で見るか、それとも、開発者の立場なのか、にあると思う。
管理者は、毎週の進捗報告のためにイテレーションを使いたい。
開発者は、リリースするまでのタスク管理のためにイテレーションを使いたい。

Tracのマイルストーンは、管理者が進捗報告のために区切った観点。
Tracのバージョンは、リリースモジュールのタグなので、開発者の観点のマイルストーン。

Tracに対してRedmineのバージョンは、リリースするシステムのバージョンなので、開発者の観点。
更に、バージョンの期限はマイルストーンでもあるから、管理者の観点でもある。

Redmineロードマップは、バージョン単位に終了と作業中の2種類の進捗率を表示するため、管理者の観点では、実質と見かけの2種類の進捗管理に使える。
Tracのロードマップは、終了チケットの進捗しか表示しないため、実質の進捗しか見れない。

Tracは、管理者と開発者の観点が同等。
TracよりもRedmineの方が開発者の観点が強い。

管理者の観点のマイルストーンは、開発中で完了していないイテレーションのスナップショットにすぎず、プロジェクトで最も大切なリリースの観念が弱い気がする。
そもそも、チケット駆動開発では進捗をリアルタイムに見れるため、毎週の進捗報告用のマイルストーンは不要だ。

イテレーションは単なるタイムボックスだけではない。
イテレーションはリリースする機能が入ったタイムボックスなのだ。
Tracは、イテレーションはリリースする単位であるという思想がRedmineほど徹底されていない気がする。
とはいえ、Tracでも同様に運用できる。


チケット駆動開発は、チケットへ登録してから全てが始まる。
しかし、進捗やリスクはイテレーションやプロジェクトと言う一つ上のレベルで追跡するのが肝なのだと思う。

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

2009/02/05

チケット駆動開発は中身は古いが新しい衣を被ったアジャイル開発

さかばさんの記事を読んで思ったこと。
#ラフなメモ書き。

【元ネタ】
ソフトウェアさかば: 必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-

■[ソフトウェア開発]ツールばっかりでどうなっているんだ - torutkの日記


上からのツールは使いづらい。現場の作業とマッチしていない。
例えば、Rational製品。

Clearcaseは、Wordの差分表示もしてくれるが、重すぎて使いづらい。
どの製品も高機能だが、重過ぎて実用的でない。

下からのツールは現場のプラクティスが盛り込まれている。
例えば、Subversion、Redmine、TestLink。

オープンソースのツールは、世界中の開発者の要望やベストプラクティスが詰め込まれている。
ツールを運用して慣れていくうちに、良い習慣が身に付いていく。

これらのツールは、Ajaxのように、昔から使われていたツールを改良して、現代風のSW開発にアレンジしたもの。
チケット駆動開発(Ticket Driven Development:TiDD)は、中身(BTS)は古いが新しい衣(TiDD)を被ったアジャイル開発。

ソフトウェア工学は、計算機科学と違い、社会科学のように、SW開発の現場から長年得られたノウハウを理論化したもの。
上記のツールに隠されたアイデアも、ソフトウェア工学のように、いつでも誰でも扱える理論として抽象化できないか?

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

2009/02/04

Redmineを使って気付いたことpart6~チケットの発生源

Redmineでチケット駆動開発を始めて、チケットの発生源について考えてみた。
以下ラフなメモ書き。

【1】チケット駆動開発では、タスクをチケットに起票してから作業を始める。
イテレーションに含まれるチケットは限界があるから、1イテレーションで実現できる機能は限定される。

しかし、1イテレーションに入り切らないぐらい膨大なタスクが発生する時がある。
そうなってしまうと、もはやチケット駆動開発だろうがアジャイル開発だろうが、タスクは発散しがちでプロジェクトは壊れた飛行機のようにふらついているだろう。

そうならないために、プロジェクトリーダーは、チケットの発生源をいつも気にする必要がある。
チケットの発生源はタスクの発生源であるから、タスクを増やさないためには何を処方したらよいか、というリスク管理につながる。

【2】チケットの発生源は、SW開発の工程によって異なる。

例えば、動くプログラムも無い状況で開発し始めた場合、殆どのチケットは要件定義書に基づいた機能の新規実装であり、おそらくスケジュールに引かれたWBSから作られるだろう。
この場合のチケットのトラッカー(種類)は、新規実装とか、エンハンスメントとか呼ばれるものに相当するだろう。
発生源は、要件。
つまり、ウォーターフォール型の開発に似ている。

あるいは、動くプログラムが殆ど出来上がり、結合テストからシステムテストに至るまでの工程では、TestLinkによるNGのテストケースがRedmineチケットの発生源になる。
つまり、テストしたらNGでバグが出たら、チケットをバグ報告票として起票して管理する。
この場合は、まさにバグ管理システムとしてRedmineを使っているだろう。
発生源は、テストケース。

更に、1次開発のリリース後、システムが本番運用されると、パスワードを忘れた、とか、あの業務をこの画面でやると動作がおかしい、などの問合せが顧客から来る。
すると、それぞれの問合せに対して、チケットへ起票して、一時的な対策を施したり、根本原因を調査して是正対策を行うなどの処置が必要になってくる。
発生源は、インシデント。

現在の自分の環境では、TestLinkからRedmineへの連携はスムーズのため、バグチケットの発生源がTestLinkのどのテストケースなのか、は追跡できる仕掛けになっている。

これによって、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース」まで追跡できるから、その発生源の付近に他にどれだけのチケットがあるか、とか、発生源を解決する別の対処方法を更にチケットへ起票する、などの対策を取れる。

【3】チケットの発生源とトラッカー(チケットの種類)は密接に関係する。
要件、テストケース、インシデントの発生源に対し、それぞれのトラッカーがマッピングされて、それぞれのチケットは特有のステータスの遷移で制御される。

おそらく、発生源がテストケースの場合は追跡のインフラを作るのは簡単。
何故なら、テストNGによるバグ解決フローは、バグ管理システムの基本フローそのものだから。
むしろ難しいのは、要件管理とインシデント管理。

XPのタスクカードがチケットであるならば、要件管理は結局、XPのストーリーカードは構成管理インフラのどの機能へ配置されるべきか、という問題に辿り着く。

TestLinkの要件管理機能が使えるならば、「ソース→SVNリビジョン→Redmineチケット→TestLinkテストケース→TestLink要件」まで追跡可能で、要件カバレッジという新しい観点でシステムの品質をチェック可能になる。

インシデント管理は、チケットの状態遷移が異なるため、どのようなワークフローで制御すべきか、という問題に辿り着く。
更に、インシデントから抜本的対策が必要だと意思決定した場合、新たな変更要求が生まれ、そこから2次開発につながっていくだろう。

つまり、インシデント→変更要求→新規実装のような流れ。
従って、親チケットはインシデント又は変更要求、子チケットは複数の新規実装、のようなチケットの親子関係が発生する。
子チケットにある全ての新規実装のチケットが完了して初めて、親チケットの変更要求は終了になるなどの制約条件が更に発生する。


上記の例のように、チケットの発生源は多岐に渡る。

チケットからその発生源へ追跡できる環境があれば、チケットに書かれた作業の根本的な対策は何か?を担当者自身が考えるきっかけになりうる。

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

2009/02/02

Redmineを使って気づいたことpart5~イテレーションの概念

XPのイテレーションの概念はTracRedmineで微妙に異なる。
それについてのラフなメモ書き。

【元ネタ】
Redmine.JP | プロジェクトの設定
バージョン

Trac Lightningで始めるチケット式開発「電撃」入門 (3/4) - @IT
マイルストーンの設定、バージョンの設定

【1】XPやScrumを代表とするアジャイル開発で最も重要な概念は、イテレーションだと思う。
理由は、イテレーションがあるからこそ、繰り返し型開発が可能になり、そのイテレーションのサイズを小さくすることによって、XPのプラクティスの一つである小規模リリースも可能になるから。

イテレーションは、大ざっぱに喩えるならば、PDCAサイクルのプロセス。
イテレーションは、XPでは2~4週間、Scrumなら4週間のサイズで、計画からリリースまでのプロセスを含む。

TracRedmineによるチケット駆動開発を実践してみて、イテレーションをコントロールするツールが今まで無かったから、アジャイル開発のプロジェクト管理が難しかったのだと気付いたこと。

頻繁なタスク変更をリアルタイムに保守するインフラがチケット駆動開発で提供されて初めて、アジャイル開発はより身近になったように思う。

チケットはXPのタスクカードをデジタル化したもの。
SW開発のタスクは、管理可能かつ追跡可能なサイズまでチケットを分割する。
そして、そのチケットは、イテレーション単位にグルーピングされる。

この時、イテレーションの概念の根本は何なのか?
僕は下記2つの意味を持つと考える。

一つは、リリースする時のスナップショット。つまりタグ。
もう一つは、ステークホルダーが要件や仕様で合意したベースライン。
このベースラインは、例えば、顧客から開発者へ設計書が渡る時や、開発者からデータセンターへモジュールがリリースされる時に発生する。

前者は、プログラマの観点では、システムのバージョンに相当する。
後者は、管理者の観点では、改定履歴のバージョン、つまりベースラインに相当する。

【2】上記のイテレーションの概念から、僕はアジャイル開発の特徴を二つ経験した。

一つは、早期リリースによる重大な問題の検出。
2~4週間毎のリリースは、実際のSW開発では正直しんどい。
システムを稼動させることは、単にプログラムを書けばよいものだけではない。
ビルドを通し、DBやWebサーバーも含めた環境で安定動作させるのは、実際に動かさないと分からないものだ。

また、要件漏れや設計漏れも、実際に動かして、顧客からフィードバックをもらわないと分からない。
設計書を書くという伝言ゲームだけでは、動くプログラムがないから、考慮漏れがすごく多い。
また、設計書通りに作ったとしても、実際に動かしてみると使い物にならず、他のやり方の方がいいというフィードバックも実は結構多いものだ。
SIerが顧客志向というサービス業であるならば、顧客のフィードバックを受けやすい開発スタイルは、顧客満足度を大きく左右させる。

もう一つは、平鍋さんの言うタイムボックスと言う発想。
2~4週間のイテレーションに含められるチケットの数は、正直限られる。
わずか10日~20日で作れる機能は、たとえチームのサイズが大きかろうとも、そんなに作れないものだ。

だから、チケットの取捨選択というマネジメント能力が管理者に大きく要求される。
基本は、優先度の低いチケットは捨てる発想が重要。

顧客のビジネス要件から、どの機能を実装するチケットが優先されるのか?
開発者の工数見積から、実現可能なチケットはどれなのか?
そのバランスで、イテレーションに入れるチケットは決まる。

イテレーションを思い通りにコントロールできれば、アジャイルに開発できるし、更に開発が楽しくなる。
月1回は必ずリリースがあるというリズムは、ゴールが見えず延々と残業が続くデスマーチとは違うプロジェクトになるだろう。


【3】このイテレーションの概念がTracRedmineでは考え方が微妙に異なる。

Tracのチケットの属性には、「マイルストーン」「バージョン」の二つがある。
「マイルストーン」は、プロジェクトの区切りであるマイルストーンと同値。
管理者なら、週次報告で進捗を報告するだろうから、毎週の報告日が相当するだろう。

Tracの「ロードマップ」では、「マイルストーン」単位にチケットがグルーピングされる。
だから、Tracの「マイルストーン」はイテレーションに相当する。

更に、Tracチケットの「バージョン」は、リリース時のモジュールのバージョンに相当する。
これはプログラマの観点なら、リリース時に付けたタグと同じ。

しかし、Redmineでは、Tracの「マイルストーン」「バージョン」が故意に同一視されて、「バージョン」と呼ばれる。
Redmineの「バージョン」は、マイルストーンでありシステムのバージョンでもある。
Redmineチケットでは、ターゲットバージョンという項目でプルダウンで設定できる。

Redmine「ロードマップ」もTracと同様に、「バージョン」単位でチケットをグルーピングする。
しかし、Tracよりも終了チケットと進行中チケットの2種類の進捗を緑色の濃淡で表示してくれるので、より的確に進捗を把握できる。

僕は、Redmine「バージョン」にグループ化された全チケットがCloseされてリリースされたら、その直後に、Redmine「バージョン」へリリースしたモジュールのバージョンを付ける運用にしている。
理由は、そのイテレーションに名前を付けたいからだ。

この運用をし始めてから、僕は、Redmineの「バージョン」と言う概念が好きだ。

ターゲットバージョンという言葉は、例えば、

次のリリースバージョンは1.1だ! 
それに向けて頑張るぞ!

という場面を連想させてくれる。
何かワクワクしないかな?

Tracの「マイルストーン」「バージョン」は確かに区別すべき概念であろうが、Redmineの「バージョン」のようにイテレーションの概念として同一視した方が、チケットの運用はやりやすい。
イテレーションをリリースする時、リリース対象はモジュールだけでなく、仕様書も納品物の対象である場合が殆どだ。
だからこそ、プログラムだけでなく、仕様書にもタグ付けするし、そのために仕様書も構成管理の管理下に置く。

我々開発者にとって、「マイルストーン」も「バージョン」も同じ意味を持つ目標だから。

Redmineには「変更履歴」という画面があり、終了したイテレーションの履歴そのもの。
それはChangeLogと同じ。
我々開発者は、この「変更履歴」を残すために仕事しているようなものだ。

イテレーションのライフサイクルは、当初はリリース計画であり、開発中は2~4週間のPDCAサイクルであり、リリース後は、ChangeLogとして公開される。
そして、リリース後にそのChangeLogを開発者全員でふりかえりをすれば、次のバージョンで改善すべき内容が出てくるだろう。

イテレーションこそがアジャイル開発の肝。

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

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