« 2009年2月 | トップページ | 2009年4月 »

2009年3月

2009/03/30

テスト実績を見える化する

西山さん作成のTestLinkのExcelマクロがVer2.8へアップグレードしたので使った感想をメモ。

【元ネタ】
ニュース - EXCEL試験書からのXMLファイル変換マクロ(ver.2.8)をリリース TEF有志によるテスト管理システムTestLink日本語化プロジェクト


【Ver2.8で追加された機能】
テスト結果の統計データのエクスポート  

・指定された期間のビルド単位の試験結果の推移をグラフ化できます。
・試験者を指定した試験結果の推移をグラフ化できます。
・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。


上記の機能のおかげで、TestLinkにたまったテスト結果をExportした後、上記のExcelマクロで取り込むと、実施日ごとに、試験数、成功数、失敗数、ブロック数の推移をグラフ化してくれる。

アジャイル開発とTestLinkを組み合わせた場合、TestLinkのテスト計画が一つのイテレーションに対応するように運用するだろう。
つまり、TestLinkのテスト計画にあるテストケース数百件~数千件を全て「成功」にしなければ、リリースできないようにする。
すると、システムをリリースする前に必ず、TestLinkのテスト計画の単位で、そのイテレーションの受入テストをクリアする運用になる。

この運用を開始してから、複数のテスト計画の実績がTestLinkにたまったわけだが、上記のマクロでグラフ化すると、受入テストでどれだけ苦労したかがすぐに分かる。

テスト計画の進捗グラフを見ると、例えば、最初はテストはスムーズで成功の件数が増えるが、ある時点から失敗とブロックが増えて、実質のテスト進捗が芳しくない時があった。
この場合は、バグが出ると、途端に関連するテストケースも失敗で更新されてしまい、そのシナリオに続くテストケースは、バグが直らないとテストできないので、ブロックにして保留にしていた。

あるいは、失敗やブロックの件数が増えても何とか潰して残り数ケースになったのに、全てのテストケースが完了するまで数日かかっている時もあった。
この場合は、バグを潰したものの、再テストすると又他のバグが出てしまい、なかなかテストが収束しない時だった。

そんな経験も踏まえて、リリース後にメンバーとKPTしたら、多くの気付きが得られるだろう。
また、複数のテスト計画をこのマクロできちんと分析すれば、テスト工数の見積の精度が高くなるだろう。

ただ、ここまでテスト実績が数値やグラフとして出力されると、テストの見える化を通り越して怖いと思うときがある。
もしTestLinkが開発チーム内部だけでなく、会社の上層部、あるいは、顧客と共有していたら、彼らは、テスト実績をこのマクロでテスト進捗をグラフ化するだろう。
すると、テストが遅れていたら、何故なんだ!対策は取っているのか!と開発チームに詰問してくるだろう。


TestLinkにたまったテスト実績には、たくさんのポテンシャルが秘められていると思う。

|

2009/03/26

TestLink1.8 正式リリース!

ついにTestLink1.8が正式リリースされたというアナウンスがあった。

【元ネタ】
ニュース ~TestLink1.8.0正式リリース- TEF有志によるテスト管理システムTestLink日本語化プロジェクト


新機能の詳細はニュースを見て欲しいが、僕が一番気になる機能は、次の二つだ。

* (実験的に)GUIからのテスト自動化をサポート。
* テストを優先度を設定することが可能です。


前者は、PHPやRubyプログラムからXPL-RPC経由でTestLinkを操作できる機能(だと思う)。
この方法を使えば、TestLinkを受入テストで使うシナリオベースのテストケースだけでなく、JUnitのテストケースも入れて、テストの自動化を行うこともできる。

TestLink日本語分科会の人達のツールを使うと、Hudsonのビルド番号を取得してTestLinkのビルドへ設定する作業も自動化できるらしい。
つまり、TestLinkで回帰テストを自動化することが可能。


後者は、テストケースに優先度とマイルストーンを組み合わせて、テストの進捗を測定する機能。
実際のイメージは、川西さん提供の下記画像を見て欲しい。

【画像】TestLink 1.8RCにおける優先度ごとのテスト進捗結果


川西さんによると、下記の説明になる。

TestLink 1.8では、テストケースに優先度を設定できるようになる予定です。 また、マイルストーンには、いつまでにどの優先度のテストを何% 完了させるかという目標が 入力できるようになります(今でも入力だけは出来ますが......)。

そうするとレポートにもこの情報が反映されて、各マイルストーンで目標が達成されたかどうかを表示させることができます。

以下の画像の例だと、マイルストーン「優先度中のテスト完了」(二段目)に対して、「優先度【高】のテスト100%完了」という目標を達成しているのでグリーン、「優先度【中】のテスト100%完了」という目標を達成しているのでレッド、になっていると思います。

# beta 3ではこの機能にまだバグが残ってしまっているようです。
この例だとマイルストーン「優先度高のテスト完了」の表示がおかしい......
正式版では直るでしょう。

この機能を上手に使えば、マイルストーン毎にテストの予定・実績の比較ができるため、テストの進捗報告で威力を発揮するだろう。

残念ながら、v1.8.0は日本語化が不十分なので、v1.8.1まで待った方が安全だろう。
とはいえ、早くTestLinkの新機能を使ってみたい。


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

2009/03/25

チケット駆動開発はプロセス改善を含む

チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。
以下メモ書き。

【元ネタ】
朝会について - sakuramateo.

朝会のパターン:立ってるだけじゃないよ

プロジェクトファシリテーション実践編:朝会ガイド

初めてのプロジェクトリーダー(6)
「ふりかえり」でプロジェクトを改善する

オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」

【1】駄目な開発チームは、コミュニケーションが無い。

例えば、開発者はPCに座ったまま、一言も喋らずに黙々と作業するだけ。
設計から開発と単体テストまで順調であっても、結合テストで必ず火を噴く。

その時に、お互いのプログラムのインターフェイスが合っていないことが判明して、たくさんのバグが出て、そして収拾がつかなくなる。
責任のなすりあいに陥ったりする。

そういうチームは、フィードバックのプロセスが無い。
技術ノウハウや仕様のノウハウをためていくプロセス、問題を皆で解決していくプロセスが無い。

例えば、一人の開発者が問題を抱えている時、その問題を解決する作業をサポートする人がいない。
最終的には現場リーダーがサポートすべきだが、大規模プロジェクトほど数多くのメンバーを抱えて手一杯で、目が行き届かない。

フィードバックプロセスがあるチームは、コミュニケーションが活発。
一人のメンバーに問題が出ると、既に他のメンバーが解決方法を知っているならば、解決方法を共有することができる。
実装上の問題は、他のメンバーが既に解決方法を知っている場合は結構多い。

フィードバックプロセスの本質はプロセス改善。
つまり、プロセスは螺旋構造をなす。
問題解決の数をこなすほど、そのチームは成長していく。

【2】チケット駆動開発とプロジェクトファシリテーションのプラクティスである朝会・ふりかえりは相性がよいと思う。

朝会で最も大事なことは、各自が自分のタスクと役割を認識すること。
朝会が無いチームは、チームとしての一体感が無い。

ソフトウェア開発は、設計する人、プログラミングする人、テストする人、サーバーを構築する人など、色んな役割が必要。
その役割を各自が自覚して、チームとして成果物を出すことが大事。

朝会では、Redmineのロードマップ画面を見ながら、メンバー全員のタスクを確認する。
昨日の実績、今日やるべきタスクは、ロードマップやフィルタリングしたチケット一覧ですぐに分かる。
ロードマップ画面を見れば、チームの進捗が一目で分かるし、何が問題なのか、は一覧にあるチケットから分かる。
チームがイテレーションが終わる日までにタスクがどれだけ残っているか、という毎日の実績が一目で分かることは、チームがソフトウェア開発をコントロールできる自信につながる。

【3】ふりかえりで最も大事なことは、チームやメンバーが問題を解決する能力を保持し続けること。
ふりかえりが無いチームは、何度も同じようなミスを繰り返すから成長が無い。

リリース後にRedmineでサマリや工数レポート、リポジトリ統計、変更履歴などのチケット集計結果を見ながらKPTでふりかえる。

過去のイテレーションでリリースしたチケット数の差から、何故今回はこんなにチケットが多かったのか、どんな作業が多かったのか、などを自然にメンバーが考える雰囲気になる。
また、Redmineサマリ画面で、メンバーごとに起票数、担当数が変わるから、メンバーの貢献度合いも分かる。

僕がチケット駆動開発を運用してみて気付いたことは、Redmineのバージョンで区切られたイテレーションをリリースし終わった後に、自然に今回のリリース作業をふりかえる雰囲気が出てきたことだ。
どうやら、自分たちはこれだけのタスクをこなした、よく頑張ったぞ、みたいな雰囲気みたい。

チケット駆動開発では、チケットの種類に応じてステータスが異なるから、ワークフローをすごく意識する。
基本はバグ修正のフローで、開発者とテスト担当者が交互にチケットをやり取りする。
二人の目を通した成果物は少なくとも品質は確保できる。
つまり、XPのペアプロに似た作業をしているのに気付く。

すると、KPTしたら、メンバー毎のKeep・Problem・Tryの観点が大きく違ってくるのが面白い。
もし、今のワークフローではチケットをこなすのがやりにくかった、というProblemがあがったら、それについて皆で議論して、あるステータスを追加してみよう、などの解決方法に集約されて、Tryになっていく。

例えば、僕のチームでは、TestLinkによるバグ出しとバグ検証をRedmineチケットを紐付けた場合、どのように連携したらやりやすいか?というProblemがあがった。

つまり、Redmineのバグ修正のワークフローは「新規→担当→解決→終了」のため、TestLinkでバグ検証するステータスが無いから不便だ、という意見があがった。

結局、KPTを発端として議論した結果、「新規→担当→解決→検証中→検証完了→終了」のワークフローでTestLinkとRedmineをやり取りすることに落ち着いた。
そして、実際に運用した後のKPTでは、このワークフローで良かったという評価が得られた。

上記の経験は、チケット駆動開発を実践して、メンバー自らがワークフローを編み出し、プロセスを改善した事例の一つだと思う。


チケット駆動開発と朝会、ふりかえりを上手に組み合わせれば、開発プロセスの種類を増やせるし、色んな場面でワークフローを切り替える運用を開発チーム自身が学習する。
プロセス改善とは、そういうことも含むのだろうと思う。

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

2009/03/24

見かけ上の進捗

【1】進捗報告のスタイルは色々あるだろうが、最も簡単な進捗報告は、完了ステータスと未完了ステータスの数値を先週・今週・来週で集計すること。

普通は、機能とステータスのクロス集計で、先週・今週・来週の数値を表示しているだろう。
この場合、「未着手→作成中→テスト中→レビュー中→完了」のワークフローにあるステータス毎に集計する。

前者と後者の違いは、実質の進捗と見かけ上の進捗の違い。
前者は、完了ステータスの数値=実質の進捗。
後者は、未完了ステータスが「作成中」「作成中」「テスト中」「レビュー中」の4種類に更に分けて、見かけ上の進捗を集計している。

何故、後者のような見かけ上の進捗が必要なのか?
理由は、実質の進捗が芳しくない場合、開発チームが今どのような状態であるのか、を追跡したいからだ。

すると、部長クラスの人は、見かけ上の進捗の報告書を見て、ステータスごとの数値の差から、今チームがどんな状況なのか、を探るのが非常に巧みだ。
いわゆる計数管理が部長クラスの人は得意。

よくある例は、数少ないレビュー担当者とレビュースケジュールを調整できず、機能を実装してテストまで進むが、レビュー中で滞留してしまっている時がある。
この場合のボトルネックは、レビューの停滞だから、部長クラスの人は、レビュースケジュールを調整する対策を採ろうとする。

【2】Redmineのロードマップ画面では、バージョン毎の進捗バーが緑色と黄緑色の2色で表示される。
これは、緑色は実質の進捗、黄緑色は見かけ上の進捗を表す。

つまり、緑色は、ステータス=終了のチケット累積数から実質の進捗を計算している。
逆に、黄緑色は、全チケットの進捗率から見かけ上の進捗を計算している。

だから、Redmineのロードマップを見れば、緑色が短く黄緑色が長ければ、完了間近の仕掛かり中の作業が多いのだろうと推測できる。

Tracのロードマップでは、実質の進捗しか表示しないため、開発チームの本当の進捗が分かりにくい弱点があると思う。

【3】同様にテスト工程でも、テストケース数が数千~数万以上の桁になるほど、実質の進捗と見かけ上の進捗による管理が重要になってくる。

TestLinkのテスト結果画面で「全ビルドステータス」画面では、「成功」「失敗」「ブロック」「未実行」のステータスごとにテストケースの進捗率を表示する。

テスト工程では、実質の進捗は、「成功」ステータスのテストケース数になる。
但し、「成功」テストケースは、1回目のテストで成功した場合だけでなく、1回以上失敗してバグ修正した後に成功になった場合も含まれる。

では、テスト工程の見かけ上の進捗とは何か?

テストの場合、テストケースの失敗が頻発した場合、いくらテストケースをこなしても、実質の進捗は進まない。
だから、テスト工程の進捗の本当の状態を知るには、「実施済み」のテストケース数を集計することが重要になる。

「全般的なテスト計画のメトリクス 」画面にある「完了率」は、実施済みのテストケース数の割合を表示していて、これが見かけ上のテスト進捗になる。
だから、実施済みのテストケース数が多くても、成功率が低ければ、バグが多いと予測できる。

【4】チケット駆動開発やTestLinkの利点は、見かけ上の進捗や実質の進捗を自動集計する機能があることだ。
RedmineやTestLinkでチケット管理やテスト管理の運用を徹底できれば、見かけ上の進捗や実質の進捗をリアルタイムにモニタリングできる。

進捗報告やテスト結果の数値から開発チームの状況や傾向を読み取る能力は、特に経営者に近い管理者は非常に得意だ。
チケット駆動開発やTestLinkの運用は、下流工程の構成管理だけでなく、プロジェクト管理全般の生産性向上にも非常に役立つはずだ。


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

2009/03/21

リファレンスモデルの重要性

渡辺さんの本を読んで、昨今の業務システムの開発におけるボトルネックは、プロジェクト管理でもなくプログラミング技術でもなくオブジェクト指向技術でもなく、実はデータモデリングではないか、と思った。
その時に、有用な設計モデルにリファレンスモデルが不足している理由について優れた指摘があったのが面白かったのでメモ。


【元ネタ】
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - HOME


【1】ソフトウェア開発の歴史をさかのぼると、色んな設計手法が提唱されているにも関わらず、ソフトウェア開発がエンジニアリングと言えるレベルまで達していないように思える。

土木建築・工業に比べると、DOA・OOA・POAなどの方法論が乱立しているけれども、実際の現場ではどれも中途半端にしか適用していないのではないか?
だから、いつまで経っても同じような失敗を繰り返し、デスマーチを繰り返しているのではないか。

渡辺さんによると、システム設計で方法論が百家争鳴な理由はリファレンスモデルが欠如しているのではないか、と指摘する。

つまり、建築デザインや工業デザインでは、方法論と膨大な具体例がセットされて提示されている。
例えば、ピラミッドやローマの建築物から現代の高層マンションと併せて、その設計図が有償無償で手に入る。
音楽ならば、記法である楽譜とその手法がペアで提供されている。

しかしながら、業務システム開発では、例えば小売業界向けの業務システムのようなパッケージ製品(ERP)のリファレンスモデル(設計図)が提供されておらず、個人が入手するのは非常に難しい。
業務システムを設計するには何が必要か、その手法に関する書籍や情報があったとしても、そのサンプルが公開されていないのだ。

だから、いつまで経っても上流工程のスキルを身に付けるのが難しく、上流工程の作業に普通のPGがキャリアアップの中に組み込むのが難しい現状がある。

この状況に比べると、プログラミング技術は、そのライブラリと記法が書籍やネットなど、あるいはオープンソースで公開されており、やる気さえあれば個人がそのスキルを身に付ける事ができる。
普通は、サンプルソースや似たようなライブラリを真似ながら、プログラミング技術を身に付けて行く。
ゼロから書いていくスタイルは、もはや現代では少ないだろう。

実装技術としては、RailsやSeasarのような優れたフレームワークのおかげで、プログラミングのコストは非常に安価になった。

しかし、業務システム開発は、いつも最初からスクラッチ開発が多い。
肝心の業務モデリングという設計技術は今も昔も変わらない。
だから無駄が多く、同じ失敗を何度も繰り返しているように思える。


【2】渡辺さんの指摘で面白いのは、リファレンスモデルが欠如している理由の一つが、従来のパッケージ製品にある設計仕様をベンダーが公開しにくいから、という点。

理由は、実装コストがどんどん下がっている現状では、設計情報を下手に公開すると、最新のオープンソースのフレームワークで簡単に安く実装されてしまう危険があるからだ。

従来のパッケージ製品は、その時代の技術で実装しているため、オブジェクト指向やRailsなどのような最新の設計思想が取り込まれていない古い技術の塊。
中身のソースは非常に汚いだろう。

更には、特にベンダーのパッケージ製品は、多くの顧客でカスタマイズできるように膨大なパラメータで調整できるようになっている。
そのために複雑な設計でカスタマイズしにくく、公開したとしても割に合わないだろう。

だから、オープンソースで提供されるパッケージ製品は、ソースの中身が公開されているという特徴だけでなく、設計仕様そのものも公開されているという点で、重要な意味を持つ。

大抵のオープンソースのパッケージ製品は、シンプルな仕様で作られてるから可読性も高く、誰もがカスタマイズしやすい特徴を持つ。
たった一人のユーザ、あるいは会社が必要とする機能を実装した業務システムを、数多くのユーザが使って、バグを発見したり、UIや機能の改善要望を出す。
それらのバグ修正や機能改善を取り込んで、更にシステムがより良く育っていく。

業務システムは、たくさんの人に使ってもらえるほど知名度も上がるし、数多くのテストをユーザが自ら行ってくれる。
熱心なユーザの改善要望は、貴重な要件だ。
そのようなシステムのライフサイクルは、特にオープンソースの開発例でよく見られる。


【3】渡辺さんの指摘で面白いと思ったもう一つの点は、実装技術が安価になっていくのは必然であり、その結果、MDA(モデル駆動アーキテクチャ)も発展していくだろうということ。

実際、アセンブラやパンチカードの頃に比べると、今はTDDなどの開発技法、RailsやSeasarなどのフレームワークのおかげで、実装技術は非常に効率が高い。
これは、詳細設計とプログラミングが統合されていく傾向にあることを示している、と。

すると、設計モデルさえあれば、プログラムを自動生成する流れへ開発も向かうだろう。
実際、Railsの設計思想の中核をなすCoCなどは、まさにそれに当たるだろう。
これが、MDAの発想。

モデルもプログラミング言語で書いてしまえ、というMDAの発想は、Rubyのようにメタプログラミングの強い言語で威力を発揮すると思う。
いわゆるDSLはRubyの得意分野の一つだし。

渡辺さんの指摘で気付いたのは、MDAが実現できれば、開発者が昔から悩んできた「仕様書の保守問題」も解決されること。
設計モデルとプログラムが同期されているならば、動くプログラムを正として、リバースエンジニアリングすればいいだけ。

渡辺さんの言う通り、「仕様書の保守問題」は実装技術が発展途上だったが故に発生した現象だといえるだろう。


【4】MDAが今後の主流になっていくだろう、と言われても、肝心のモデルを作らなければ、実装できない。

渡辺さんは自身のHPで、「財務管理」「科目履修管理」「販売管理」「生産管理」「自治体」の5つの業務モデルを公開されている。
渡辺さん自身が作成された設計ツールXeadと併せて見ると良いだろう。

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル

非常に参考になるので、渡辺さんの本と併せて読むのを勧めたい。
昨今なら、上記のリファレンスモデルでテーブルが定義されているから、RailsやSeasarを使えば一瞬で実装できるはずだ。


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

2009/03/20

チケット駆動開発は進捗報告作りをどのように解決しようとするか?

【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。

まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。
そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。

しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。
当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。

スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。
MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。

そのスケジュールを管理者が常に保守し続けなければならない理由は二つあると思う。
一つは、顧客や上層部へ進捗を報告する元ネタになるから。
もう一つは、プロジェクトのリスクがスケジュールでしか見えないから。

前者の作業は、保守されたスケジュールにあるWBSを、顧客向けの観点で集計し直す。

週次報告のために、毎週、その集計用のExcelを作る時も多い。
その場合、機能単位で、ステータス(未着手・作成中・レビュー中・テスト中・完了)ごとのクロス集計を作り、先週・今週の実績・来週の予定を作ることが多いだろう。

更に、ステータス(作成中・レビュー中・テスト中)ごとのスケジュールを作り、別のExcelで管理する時も多い。
何故なら、レビューのスケジュール、テストのスケジュールも別途必要だからだ。

すると、一つの作業のステータスを確定するために、作成中・レビュー中・テスト中の3つ全てのスケジュールを開かないと分からない。

駄目な管理者は、作業のステータスを管理するためのファイルをあちこちに分散して作ってしまったり、忙しくなるとそのファイルさえも保守しなくなる。
結局、プロジェクトの現状を的確に現す資料がなくなる。

デスマーチ・プロジェクトは特にこのような状況になりがち。
火消し役で入った現場リーダーは、まず現状の作業の棚卸しから始めることが多い。
それは即ち、全ての残タスクの洗い出しと現状の作業のステータスを確認すること。

いかに、スケジュール保守が難しいか、という観点を示していると思う。

後者は、タスクの遅延や、開発速度の変化、開発者ごとの生産性の変化などから、今後大きな問題に発展しそうな現象を確定し、現場リーダーが判断する必要がある。

しかし、上記のように、プロジェクトの現状をリアルタイムに把握できる資料がなければ難しい。
その資料は、ステータスごとの進捗の集計や要件ごとの進捗の集計だったりする。

それらは、元ネタとなるスケジュールから、それらの観点で集計する。
だから、元ネタとなるスケジュールが毎日の作業進捗をリアルタイムに反映して精度が高くなければ、集計結果の数値も当てにならない。

【2】チケット駆動開発を運用してみて気付いたことは、進捗報告は手作業で集計してExcelに綺麗にまとめる必要は無いこと。
進捗報告はチケットのステータスを自動集計してくれるインフラがあるから。

例えば、Redmineでは、開発者が自分担当のチケットを1日の終わりに更新すれば、サマリ欄で集計結果を見ることができる。
更には、工数レポート画面で、バージョンと月別のクロス集計で実績工数を表示できる。

例:
SKIP - サマリ - Redmine

Ruby 1.9 - サマリ Ruby Issue Tracking System

つまり、チケットを自動集計するインフラがあるから、チケットへ毎日の作業状態を入力する運用が徹底できれば、プロジェクトの現状をリアルタイムに把握できる。
Redmineのサマリはバージョン・トラッカー(ワークフロー)・カテゴリ(機能)の単位でステータスごとに集計してくれるので、そこからリスクを嗅ぎ取り、リスク対策を取ることができる。

【3】しかしながら、顧客向けの進捗報告は、Redmineサマリをそのまま出すことはできない。
理由は、チケットがタスクカードの観点で作られているから。

つまり、チケットは、アウトプットを作るための作業を管理するために作られているから。
一つの機能をリリースするまでに、複数のチケットが必要。
顧客向けの進捗報告は、ストーリーカードの観点で作成すべきなのだ。

TracやRedmineでプロジェクト管理を始めると、進捗管理がやりにくいという話が出る。
話を聞くと、顧客向けの進捗管理と開発チーム内部の進捗管理を分けているかららしい。
どうやら、MSProjectで顧客向けスケジュールを作っているが、そのスケジュールとRedmine/Tracのスケジュール管理の間で同期を取りにくいようだ。

僕としては、MSProjectとTrac/Redmineで進捗管理の視点が異なるのは、下記の理由で当たり前だと考える。

3-1・管理者(PL)の視点
→ストーリーカード
→フィーチャー(機能)、工程、WBS
→MSProject

3-2・開発者(PG)の視点
→タスクカード
→成果物に対する作業
→Trac/Redmine

チケット駆動開発は、あくまでも開発者のタスク管理をサポートする。
開発者が作業する成果物(タスクカード)の進捗がチームの実質の進捗でもあるから、プロジェクトリーダーにとっては非常に重要と考える。

理由は、ストーリーカードの進捗は、個々のタスクカードの進捗の合計ゆえ、顧客向けの進捗報告の元ネタは、タスクカードの進捗管理にあるべきだから。

現状では、Redmineのデフォルト機能には、ストーリーカードを表現する機能はないが、ストーリーカードを同様にチケットとして扱うことはできる。

この時、ストーリーカードをチケットで表現した場合、ストーリーカードとタスクカードには下記の制約が少なくとも発生する。

3-3・ストーリーカードの開始・終了日は、タスクカードの開始・終了日のUnionである。
3-4・ストーリーカードのステータスは、タスクカードのステータスの共通集合である。
3-5・ストーリーカードの工数は、タスクカードの工数の合計である

これらをTrac/Redmine上で表現できれば良い。
つまり、1つの機能という実体をストーリーカードとタスクカードの別々の観点で進捗管理できればよい。

【4】今僕がRedmineの運用で現実的と考えるやり方は下記の通り。

4-1・ストーリーカード(顧客向け)とタスクカード(開発チーム向け)の2個のプロジェクトを作る。
4-2・ストーリーカードには、顧客向けに報告する単位の機能をチケットへ登録する。
4-3・タスクカードには、開発者が作業する単位、あるいは成果物単位でチケットへ登録する。

4-4・タスクカードの属性に、タスクの発生源であるストーリーカードのチケット情報を登録しておく。
 ストーリーカードには、派生したタスクカードのチケット情報を関連づけておく。
4-5・タスクカードが更新されるたびに、発生源であるストーリーカードの実績工数・ステータスなどが更新される。

4-6・顧客向けの進捗報告は、ストーリーカードのRedmineサマリから集計する。


ストーリーカードとタスクカードで別々に管理するのは、観点が違うから。
Redmineではプロジェクトの親子関係やプロジェクトをまたがるチケットの関係を簡単に設定できるので、特に問題無い。

【5】だが、ストーリーカードとタスクカードの関係については、さかばさんの指摘もあるが、いくつかの疑問点が残る。

5-1・複数のイテレーションをまたがるストーリーカードはあるのか?

→ストーリーが一つのイテレーションで実装できない場合、そのイテレーションはリリース可能なのか?
イテレーションはリリースできる単位と定義すると、ストーリーカードはイテレーション期間で実現できるサイズまで分割する必要があるだろう。


5-2・ストーリーカードにビルド環境構築のような非機能要求は入るのか?

→顧客から見ると、ビルド環境構築のような開発内部の作業は価値がない。
 顧客が知りたいのは、機能(要求仕様)の進捗だから。

ストーリーカードは顧客価値を表す。
顧客向けの進捗報告はストーリーカードの集計結果になるように、ストーリーカードのチケットを作るべきと考える。

しかし、このやり方では、ストーリーカードに含まれないタスクカードが存在できてしまうため、顧客向けの進捗報告にある実績工数と、開発チーム内部で把握する実績工数に狂いが出てくる。

おそらく、「その他」「内部課題」のような特殊なストーリーカードでビルド環境構築のようなタスクカードを管理するなどして、ストーリーカードとタスクカードが必ずリンクする方法の方が運用しやすいだろうと考える。


チケット駆動開発は、進捗報告作りをチケットの自動集計という機能で置き換える。
その意義はとてつもなく大きいと思う。


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

2009/03/15

SW開発で火を噴くパターン

【1】SW開発ではいつも結合テスト以降で火を噴く。
設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。
例えば、下記のような問題がいつでもどこでも噴出するのではないか。


設計書には、複数の画面遷移による業務フローが考慮されていなかった。
業務のインターフェイスがシステムとして整合性が取れていなかった。
シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。
つまり、設計漏れ。

実際に結合テスト環境で動かそうとすると、そもそも動かない。
実は、DB環境にViewやプロシージャがもれていた。
あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。
モジュールをビルドして、Webサーバーを再起動する作業が手順化されておらず、手間がかかる。
しかもリリース漏れなどのミスも多い。
つまり、環境構築やリリース作業漏れ。

特に帳票やPDF出力は、非常に重要な要件にも関わらず、実際に環境を構築して動作させないと、性能がボトルネックになるのが後になって気付くと致命的だ。

設計書に従って作ったのに、顧客に使ってもらうと、本来の要件は実は異なっていたらしい。
要件定義書や設計書は顧客から承認されたはずなのに、双方が誤解していたらしい。
つまり、要件漏れ。

あるいは、顧客が、本当はもっとこういう風に使いたい、と仕様変更を言い出してきた。
顧客との関係、顧客との要件定義をコストとビジネス要件の観点から、きちんとコントロールできていなかった。


【2】いつも思うのは、SW開発の失敗パターンは上記のように大体決まっている。
なのに、同じような失敗を何度も繰り返す。

問題の本当の原因は、技術にあるのか?
それともマネジメントにあるのか?

チケット駆動開発を1年間実践してみて、SW開発は高度な技術と高度なマネジメントを必要とすることを改めて経験した。
僕が思うに、高度な技術とはアジャイル開発とSW構成管理、高度なマネジメントとは真の意思決定ということ。

【2-1】アジャイル開発のおかげで、ビルド作業漏れは、1回目のイテレーションでリリースする時に判明する。
要件漏れ、設計漏れも、初めてその機能を実装するイテレーションか、そのイテレーションのリリース後に顧客が使う段階で判明する。

早めに失敗した経験を生かすことで、次のイテレーションでは同じミスはしなくなる。
顧客にシステムを少しずつ使ってもらいながら、顧客が求める本来の要求を開発チームも少しずつ理解しながら、システムのグランドデザインの精度を少しずつ上げていく。

これはプロセス改善とつながるはずだ。

【2-2】XPが提唱するSW構成管理のプラクティスは、チームに必要な技術を示唆してくれる。

最初は、凝った機能を実装する必要は無く、シンプルな設計でまず実装して、顧客に早く提供しよう。
それからフィードバックを受けて修正すればいい。
その時に、リファクタリングでプログラムの構造を綺麗にしてから、機能追加する。

テスト駆動開発のおかげで、プログラムの単体テストの品質はクリアできる。
ソース共同所有のおかげで、いつでも誰でもすぐに障害を修正できる。
継続的インテグレーションのおかげで、コミットしたコードラインは常時リリース可能になる。

これらのインフラがあるからこそ、アジャイルに開発できる。

更にチケット駆動開発のような強力なタスク管理があれば、アジャイル開発の弱点だったプロジェクトマネジメントの観点を強化してくれる。

TestLinkのようなテスト管理ツールも、結合テスト以降のシナリオベースのテスト工程を一括管理してくれるので、テスト工程の効率化に非常に役立つ。
システムの品質(特に信頼性)は結局、テストケース数の多さと要件カバレッジでしか顧客へ説明できないから、テスト工程の効率化は品質強化に直結する。

SW構成管理はSW開発プロセスの一部に過ぎないけれど、プロセスを回すインフラそのものだと思う。

【2-3】チケット駆動開発を実践して気付いたことは、SW開発のマネジメントがシステムの品質に大きく左右されていることだ。

アジャイル開発は、品質・コスト・スケジュール(QCD)の三角形から、スコープ・コスト・スケジュールの三角形へプロジェクトマネジメントのパラダイムを転換させた。
この意義は、常に品質が保証されたシステムでなければ、機能追加したり、人員を増やしたり、納期を延ばすといういずれの意思決定も役立たないということだ。

アジャイル開発のマネジメントで最も重要な点は、スコープの調整にある。
機能を追加したいなら、コストやスケジュールも変更しなければならない。
しかし、SIerの普通のビジネススタイルでは、コストやスケジュールはほぼ固定のため、スコープで調整するしかない。

だから、ビジネス要件の優先度、機能仕様の優先度、チケットの優先度を順位付けする意思決定が必要になる。
その意思決定を行うには、顧客の業務を把握する業務能力、更には、機能追加によってシステムがどれだけ影響を受けるかという設計能力、そして、どれだけ工数がかかるか細部まで知り尽くしている開発能力が必要だ。

管理者は単に開発スケジュールを保守するだけの、タイムキーパーのような役割だけでは務まらない。
あるいは、顧客から大きな開発案件を受託する営業マンのような役割だけでは務まらない。


SW開発で火を噴くパターンは、「アンチパターン―ソフトウェア危篤患者の救出」や「デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか」の本のように、昔から既に知られている。
そろそろ同じようなミスを繰り返す状態から脱却しよう。

そのために必要な解決方法を自分なりに、自分のチームなりに見出そう。

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

2009/03/14

レビューはペア作業であるべき

SW開発でいつもボトルネックと感じる工程がレビュー。

僕が経験した過去のどのプロジェクトも、レビュー工程は効果的と思えなかった。
少なくとも、開発者の立場では、レビューは嫌なもの。
自分の成果物にケチをつけられ、何度も直しては叩かれる。

今、管理者の立場でレビューに携わっているが、レビューが成果物の品質Upになっているとはとても言えない。

設計レビューは、設計の元ネタとなる要件定義と化している。
レビューアーにひたすら質問しまくって、本来の仕様を聞き出す。

ソースレビューは、コーディングルールの徹底と化している。
CheckStyleで十分なのに、レビューワーは業務ロジックまで分からないから、ただ直すだけ。

いつも思うのは、レビューはペアプロ、ペア作業であるべきだ。
レビューワーが、レビューイーの席の隣に座り、レビューイーのPCで成果物を見ながら、間違っている箇所はその時その場で即修正する。
その方が効率的だし、レビューワーと情報共有しやすくなる。

ペアプロをレビュー工程の代替手段として捉えられないか?

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

2009/03/10

TestLinkのテストケースを一括変換するマクロ

TestLinkのテストケースをローカルのExcelマクロで一括変換するツールが公開された。

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

v151a_TestLinkCnvMacro - TestLinkTools - SourceForge.JP

テストケース修正の流れ図の表示 - TestLinkTools - SourceForge.JP


そもそもの目的は、TestLinkに取り込んだテストケースを一括置換したい場合があること。
しかし、TestLinkにはテストケースの一部の文字列を一括置換する機能はない。
そこで、上記のExcelマクロを使うと、下記の手順で、テストケースを一括修正できる。


1.TestLinkから該当のテストスイートをXMLで出力する

2.ExcelマクロへXMLをインポート(「caseToSheet 」シートで「XMLtoSheet」を実行)

3.Excel上でテストケースを編集(テストケースIDは変更しない)

4.ExcelマクロでXMLを出力(「caseToSheet 」シートで「MakeXML」を実行)

5.TestLinkで"XML_CHANGE_testcase"としてXMLインポート

つまり、TestLinkにあるサーバー上のテストケースを一度ローカルに落とし、ローカル上で編集して、もう一度TestLinkへ上書きインポートする方法で実現する。

手間はかかるが、DBにあるテストケースをSQLで変更するのは危険だし、ローカルのExcelならば、一括置換に失敗しても、Undo&Redoを何度でも試せる。

また、XMLを取り込んだローカルのExcelにあるテストケースはテストケースIDを必ず持ち、そのテストケースIDがTestLink上でユニークなので、テストスイートやテストケースの属性を好きなように後から変更できる。

更に、テストケースに紐づくキーワードも一括編集できるため、テスト実施中に仕様変更が生じて、要件とテストケースの紐づけも修正したい場合が発生しても、キーワードと要件の紐づけを修正すれば、いくらでも変更できる。
この変更で重要な点は、一括置換後にテストケースを取り込んだら、キーワード別テスト結果集計に要件カバレッジが即座に反映されることだ。

設計漏れや仕様変更によってテストケースの変更が、テスト実施中やテスト実施後であろうとも、TestLinkへリアルタイムに反映できるから、アジャイル開発と組み合わせれば、受入テストも楽になる。

まとめると、下記のイメージのようになる。

Testlink_diagram







変換1:
v151a_TestLinkCnvMacroを使って、Excel→XML→TestLinkの順にテストケースをインポートする。
数千~数万のテストケースでも一括インポート可能。

変換2:
v151a_TestLinkCnvMacroを使って、TestLink→XML→Excelの順にテストケースをコンバートする。
このExcelは最終的には、納品用テスト仕様書になる。


TestLinkを使いこなせば、テスト工程をもっと楽にできるだろう。


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

2009/03/06

TestLinkによる要件カバレッジ

TestLinkへテストケース、要件、テストケースと要件の紐づけの3種類をインポートするExcelマクロが公開された。
さっそく使ってみた感想をメモ。
#作者の西山さん、ありがとうございます。

【元ネタ】
v10_TestLinkCnvMacro - TestLinkTools - SourceForge.JP

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

TestLinkTools運用の流れ図の表示 - TestLinkTools - SourceForge.JP


管理者の目的では、TestLinkを受入テストのテストケース管理として使いたい。
TestLinkのおかげで、テスト結果をリアルタイムにモニタリングできるため、進捗管理しやすくなる。
上記の要件カバレッジの機能があれば、どの要件は進捗が遅れているか、どの要件でバグがたくさん出ているか、を追跡することができる。

実際、バグが出る要件、テストが失敗しやすい要件は偏りがあるため、それらを数値として出力できることは、プロジェクトマネジメントの観点から非常に重要。

TestLinkで結合テストやシステムテストを代用する場合、数千~数万の桁のテストケースを作る必要がある。
それだけのテストケースをWeb上から逐一入力するのは手間がかかりすぎ。
そのため、上記のExcelマクロを使えば、数千~数万のテストケースも簡単に一括インポートできる。

上記のExcelマクロでは、要件とテストケースの紐付けデータもインポートできる。
すると、要件カバレッジをリアルタイムに見ることができる。

実際の画面キャプチャを見てみよう。

上記のExcelマクロでは、要件をテストケースの属性であるキーワードに紐づける。
この仕掛けのおかげで、テスト実行画面、テスト結果画面で、キーワードでフィルタリングすればよい。

テスト実行画面で、キーワードをフィルタリングした結果は下記の通り。

Testlink_exec_2






テスト担当者に使い方を聞いてみたら、アサイン=自分、結果=未実行でフィルタリングして、担当のテストケースを消化していくのが多いみたい。

テスト結果画面は下記の通り。
管理者はこの画面で、テスト結果をリアルタイムに進捗確認する。

Testlink_result_all





テスト結果画面のキーワード別結果は下記の通り。
キーワードが要件に相当するため、どの要件で失敗ケース数が多いか、確認できる。

Testlink_result_keyword






テスト結果画面の失敗したテストケース一覧は下記の通り。
最終的には、失敗テストケース数=0にしなければリリースできない。
納期1ヶ月前に失敗テストケース数が50ケース以上ならば、おそらく納期までに間に合わないだろう。

Testlink_result_fail_list






テスト結果画面のバグ一覧は下記の通り。
「オープン」は未解決バグ数、「解決済み」は解決バグ数を表す。
最終的には、オープンのバグ数=0にしなければリリースできない。

Testlink_result_bug_list






バグが50件以上ならば、システムの品質に問題があるだろう。
しかし、テストケース数が数千~数万の桁の場合、設計や単体テストの品質が良くなければ、バグは簡単に50件を超えるだろう。


TestLinkを運用して気付いたことは、テスト戦略の重要性だ。
数千~数万のテストケースのうちどれを優先してテストするか、バグが出た場合どのバグを優先して解決するか、という判断をいつも迫られる。
TestLinkは、管理者が考えるテスト戦略を見える化しているのだ。


|

2009/03/04

関数脳のつくり方

関数型言語の特徴について、牛尾さんが良い記事を書かれていたのでメモ。

第7回 関数脳のつくり方 First Season:ITpro

 関数型の言語では,リストがとても強力なので,ループをまわしてと考えるのではなく,まず元になるリストを作るという発想をして,そこに「関数」を適用するというイメージを持つことを繰り返し強調しておきます。
 そういうスタイルでコーディングするので,ループカウンタや,一時変数のように途中の値を保持するようなコーディングは基本的に行いません。

元となるリストを作り、それに関数を適用するやり方は、まさにブロックそのもの。
イテレータと同じ。

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

2009/03/03

変更要求に対する選択肢

成功する要求仕様 失敗する要求仕様」で、変更への対応に関する選択肢の解説がとても素晴らしいと思ったのでメモ。
#ラフなメモ書き。


開発プロジェクトは、現在、Ver3.0へ向けて開発中で、その次のリリース予定のバージョンは4.0であると仮定する。
この時に、突然、顧客から大きな変更要求が提示され、どうしても対応せざるを得なかったと仮定する。

成功する要求仕様 失敗する要求仕様」では、下記の9種類の選択肢を比較検討している。
この解説が非常に面白い。

1・変更を受け入れて、Ver3.0に組み入れて、スケジュールや予算は現状のまま変更しない
2・変更を受け入れて、Ver3.0に組み入れて、リリース日を遅らせる

3・変更を受け入れて、Ver4.0に組み込む計画を立てて、Ver3.0のリリース日を確実に守る
4・変更を受け入れて、Ver3.1という新たなVerを作り、変更をVer3.1に組み込む計画を立てる
5・変更を受け入れて、次のトリアージ会議で、将来のリリースのどこかのVerに組み込む計画を立てる

6・変更を却下する
7・変更を受け入れて、Ver3.0に組み入れて、Ver3.0のリリース計画に含まれている重要度の低い要求を削除し、スケジュールや予算は現状のまま変更しない
8・変更を受け入れて、Ver3.0に組み入れて、スケジュールを遅らせないように、開発プロジェクトへリソースを追加する
9・現行の開発プロジェクトを中止し、最初からやり直す


1と2、そして7、8を選択した場合、そのプロジェクトはデスマーチに追い込まれるだろう。
1は、スコープが増えたのに、スケジュールやコストを増やさない訳だから、バランスが既に崩れている。

2は、スコープが増えたので、スケジュールを遅らせるわけだが、その分、当然コストも増える。
SIerがビジネスしている限り、非常にリスキー。

8は、スコープが増えたので、スケジュールを守るために、リソースを増やすやり方は、人月の神話のように既に破綻すると経験的に知られている。

7は、スケジュールとコストを変えないように、増えたスコープを優先順位付けして整理し直そうとするやり方で一見、正しそうに見える。
しかし、実際は、優先順位の低い要求を捨てて、作業工数を確保しようとしたとしても、工数は簡単な引き算と足し算で解決はできない。
例えば、40時間の作業工数を削減して確保し、その工数を増えた要求に対応したとしても、その工数に関わるメンバーは、疲労していたり、増えた要求を理解するために時間を取られることが多いだろう。

6と9は、顧客とSIerのパワーバランスで、選択できるかどうか決まる。
普通はこの選択肢はありえない。

3、4、5は、増えた要求を新たなバージョンに組み込んで、別に独立してリリースすることで対処しようとする。
これは、いわゆるタスクブランチで解決するやり方だ。

僕が最も現実的と考える選択肢は、4のようにVer3.1のタスクブランチを作ることだ。
理由は、顧客満足度をクリアできて、かつ、開発チームがリリースを制御できるには、開発中のVer3.0と次回のVer4.0の間に、Ver3.1というイテレーションを組み込むのがBetterだと考えるからだ。

3は、増えた要求が納期にそれほどこだわらない場合に選択できると考える。
例えば、品質を重視するために、スケジュールが1年後では困るが、時間がややかかっても良い場合など。

5は、一部のマネージャや現場リーダーの判断では決めることができず、変更管理会議(CCB)のように開発プロジェクトに関わる全てのステークホルダーに参加してもらって、議論して決める場合に選択するだろう。


アジャイル開発を実践できる開発チームならば、イテレーションという短いサイクルで小刻みにリリースできる開発プロセスを持っている。

だから、突然振ってきた変更要求をきちんと仕様化して設計さえできれば、新たなVerに対応するタスクブランチを作り、それをリリースすることで変化に対応できる。

そんな開発プロセスを実現するには、継続的インテグレーションやメインラインモデルなどのような高度なSW構成管理と、チケット駆動開発のような強力なタスク管理(変更管理)の仕掛けが必要だと思う。

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

2009/03/01

Redmine運用例

Redmineの運用例をリンクしておく。
一つは、Ruby1.9の開発。
もう一つは、SKIP(Rails製SNS)。

【SKIP】
SKIP ... 情報共有ソーシャルウェア

SKIP - 概要 - SKIP - Redmine

SKIP - ロードマップ - SKIP - Redmine

SKIP - 変更記録 - Redmine

SKIP - サマリ - Redmine

SKIP - 経過時間 - レポート - SKIP - Redmine

Redmineで最も重要な画面は、サマリの画面だ。
そこからバージョン項目の右にある虫眼鏡をクリックすると、ステータスごとのチケット集計数が表示される。

SKIP - サマリ(バージョン単位) - Redmine

面白いと思うのは「実装完了」というステータスがあることだ。
他のチケットの状態遷移の履歴を見ると、下記のフローが正常フローのように見える。

新規→担当→解決→実装完了→終了

「実装完了」ステータスの意味を第三者の視点で考えると、「開発もテストも終わったが、リリースしていない」状況と考えられる。
おそらく、本番リリースしたかどうかを区別するために作られたのではないかと思われる。

この手法は実際の開発現場ではよくある。
開発チーム内部でバグ修正とその検証が完了してビルドできたとしても、顧客が確認できる環境へリリースしなければ、本当に完了したことにはならない。
つまり、開発完了と本番リリース完了にタイムラグがある場合は、それに応じたステータスを作って管理したいものだ。

【Ruby1.9】
Ruby 1.9 - 概要 - Ruby Issue Tracking System

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

Ruby 1.9 - サマリ Ruby Issue Tracking System

Ruby 1.9 - 変更記録 Ruby Issue Tracking System


同様に、Ruby 1.9 のバージョン項目の右にある虫眼鏡をクリックしてみる。

Ruby 1.9 - サマリ(バージョン単位) - Ruby Issue Tracking System

面白いと思うのは、「Fixed(解決)」ステータスが無く、「Third Party's Issue」ステータスがあることだ。
他チケットの正常フローの履歴を見ると殆どが「New(新規)→Closed(完了)」になっている。

第三者の視点でワークフローを類推すると、登録されたチケットは自発的に誰かが解決してCloseされていくようだ。
そのチケットが環境の不具合と判明した場合、「Third Party's Issue」ステータスに振られているようだ。
つまり、他のステークホルダーへ確認あるいは担当してもらう場合に特別なステータスをアサインしていると考えられる。

この手法は、変更管理やインシデント管理でよく現れる。
特に変更管理では、変更要求(RFC)に対し、方針が決定されるまで、色んなステークホルダーとやり取りして仕様を固めていく必要がある。
その場合に、他のステークホルダーがチケットを担当している状態を明確化するために、ステータスを作る時が多い。


上記のようなワークフローは、実際の現場で運用しながら作られたものなので、どんな開発プロセスや開発体制になっているのか、を考える参考資料になりうる。

ワークフローこそ厳格にプロセス管理すべき対象。
ワークフロー管理がプロジェクト管理の要だと思う。

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

« 2009年2月 | トップページ | 2009年4月 »