チケット駆動開発の第三のツール～ candycane

RedmineのPHPクローンであるcandycaneのソースが公開されたというアナウンスがあったのでメモ。

CakePHP版redmine candycaneのソースを公開しました - yandodの日記

現在、チケット駆動開発を実践しようとした場合、一番やりやすいのはRedmine、2番目にTracだと思う。
そして、今3番目の選択肢として、RedmineのPHPクローンcandycaneも出てきた。
このツールの利点は、RubyやPythonに比べると、PHPの方がはるかにWebサーバーに乗せやすい所だと思う。

上記のBlogや、それに反応する人達のBlogを読みながら、さかばさんの下記の文章が強烈に響く。

TiDD：チケット駆動開発: ソフトウェアさかば

(中略)
「チケット駆動開発」を育てたのは、技術に対して貪欲で、意欲的な人たちです。
いまやアジャイル開発も普通のことになりましたが、数年前までは目新しい概念でした。
どの程度役に立つのか、あまりわからない状態でしたが、現場に問題を抱えていた技術者たちはアジャイラーになりました。
そして進んで実践し、問題にぶつかり、チケット駆動開発を見出したのです。

私が「チケット駆動開発」に魅力を感じるのは、そんな技術を実践する人たちが育てているからかも知れません。
オブジェクト指向も、アジャイル開発も、そんな人たちが育てたから、良いものになりました。
きっと「チケット駆動開発」も良いものに育っていくだろうと思っています。

大手SIerのプロジェクトマネージャが叫ぶプロセス改善と、開発の現場で、目の前の問題点に対し、プログラミング技術で貪欲に対処する過程で作り上げたチケット駆動開発の概念は、やはり違う。

オブジェクト指向と同様に、チケット駆動開発も、現場のたくさんの人達の英知を集めて、一つの概念に到達するに違いない。
それは、大衆の知恵みたいなもの。
インターネットがそれを助けるだろう。

女性はテストエンジニアに向いている？

下記の記事をメモ。

【元ネタ】
息の長いエンジニアでゆこう: 女性の直感力が生きるIT分野 －テストエンジニア－

女性の方がテストエンジニアに向いていると思う時がある。
普通の男性は、特に開発者は、自分がかっこよくプログラミングしている場面を見てもらいたい気持ちがある。

普通の女性は、特に謙虚な人は、ふりかえりMTでも自分から積極的に発言することもしない。
真面目にコツコツと仕事するタイプが多いから、テストのように地味であっても重要な仕事で輝く時がある。

でも、本来は、設計者であるSEがテストエンジニアであるべきだと思う。
PGが実装してバグ修正も行い、SEがその元ネタである設計を起こし、設計書通りかテストして、バグを検証する。
テストエンジニアがいるからこそ、システムの品質を確実に保証してくれる。

テストエンジニアとプログラマはペアで作業すべきなのだ。
ペアプロは最終的には、開発者とテスト担当者のペアであるべきだと思う。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ

随分前だが7月初めにPFP関西WS#19が開かれた。
ワークショップの内容は「ファシグラ」。

【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。
ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。

議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。
議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。
アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。

そんな時にファシグラはすごく有用だ。
僕が改めてファシグラの威力を感じたのは、えと～さんが実際にファシグラを使っている場面を見た時だ。

ミーティングで到達すべきゴールは既にメンバー全員で共有しているが、ゴールにたどり着くまでにどんな議論が必要なのか、見えない状況だった。

そんな時、大量のA4用紙を元に、プロッキーで議論からラフな概念イメージやフローを描いていく。
一人の頭にあるアイデアを紙に書くことで、全員がそのアイデアを共有できるだけでなく、刺激を受けて、更にそのアイデアを補強したり膨らませることができる。

えと～さんも言っていたが、ファシグラをやると、自然に「問題 vs 私たち」という構造になる。
つまり、問題がファシグラで描いた紙に書かれていくから、メンバー全員がその紙を見ながら、問題点を探るので、同じベクトルへメンバー全員が自然に向くようになる。

更にファシグラの利点は、ファシグラで描いた紙を組み合わせると、紙芝居になることだ。
例えば、10枚描いたファシグラのA4用紙をあるストーリーの元に並べれば、自然にプレゼン資料になりうる。
つまり、ミーティングの終わりに、一つのプレゼン資料が出来上がるため、それをPoerPointへデジタル化すればいいだけになる。

【2】ファシグラだけでなく、タスクかんばんなどプロジェクトファシリテーションのツールは非常に面白い。
だが、最近思うのは、プロジェクトファシリテーションはIT企業の中間管理職研修で使われる内容と一致するような気がする。

実際、IT企業の中間管理職研修では、チームビルディングを主体としたワークショップ形式が主流だ。
理由は、実際の開発現場では、現場リーダーの必須技術の一つが、寄せ集めの開発者たちをすぐにチームとして機能させることだからだ。

最近のソフトウェア開発は、プロジェクト単位にメンバーを集めて、短い期間で開発していく。
しかもそのメンバーは自社とは限らず、他の会社の見知らぬ開発者と組んでいる時が殆どだろう。
その初対面のメンバーとすぐに信頼関係を築き、チーム内の役割のバランスをすぐに作るというチームビルディングの技術が重要になって来る。

特に、最近のWebシステム開発はメンバーの出入りが激しいため、チームビルディングを上手に機能させないと、チームが機能しないだけでなく、開発プロセスの品質が下がり、最終的にはシステムの品質にも響く。

このファシリテーションの技術は、リーダー特有の資質や経験に依存するものと従来は考えられていたが、最近は、意識的に育成できる技術の一つと捕らえる傾向にある。

そのファシリテーションの技術をIT業界に特化させたものが、プロジェクトファシリテーションと言えると思う。

数年前からアジャイル開発からプロジェクトファシリテーションへトレンドが移りつつある理由は、プロジェクトファシリテーションのマーケットが発見されたからだと思う。
そのマーケットこそが、IT企業の中間管理職、つまり現場リーダーなのだと思う。

だから、開発チームを統率し、システム開発というプロジェクトをやり遂げる役割でなければ、プロジェクトファシリテーションの発想は響きにくいかもしれない。

逆に言えば、チームビルディングが必要な人には、喉から手が出るほど、アイデア豊富な技術が揃っているため、非常に面白いと思う。

【3】アジャイル開発を実践しているチームならば、リリース計画やイテレーション計画を作る時や、イテレーションの開始・実行中・終了後にプロジェクトファシリテーションのプラクティスを使うと、効果的だと思う。

少なくとも、朝会やふりかえりは、アジャイル開発とすごく相性がいい。
もちろん、チケット駆動開発とも相性はよい。

例えば、タスクかんばんは、チケット駆動開発では作業ステータス毎のチケット一覧でデジタル化できる。
バーンダウンチャートは、チケット駆動開発ならば、イテレーション単位の残チケットの集計結果でデジタル化できる。

チケット駆動開発は、プロジェクトファシリテーションをデジタル化するツールと捉え直すこともできるだろう。
そのアイデアも考えてみたい。

チケット駆動開発のモチーフ

さかばさんの記事を読んで感じたことをメモ。

【元ネタ】
TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば

チケット駆動開発(Ticket Driven Development:TiDD)は、まちゅさんが、Tracのチケット管理をプロジェクト管理に使おうという発想から生まれた。
TiDDは元々、タスク管理の改善がモチーフだった。

でも、僕は、アジャイル開発を現場で実践しようとしても運用のハードルが高い事実にいつも苛立っていた。
その時に偶然、RedmineというBTSをタスク管理に使ったら、プロジェクトが大幅に改善されただけでなく、アジャイル開発のプロジェクト管理に使えることに気づいた。

Redmineを使わなかったら、アジャイル開発の肌のぬくもりをきちんと感じ取れなかったと思う。
イテレーションと言うリズムが自然に生まれ、そのリズムがあるからこそ、朝会も自然に運営され、リリース後にKPTでふりかえりをしたいという気持ちがメンバー全員に生まれた。
そのふりかえりの結果や改善点を次のイテレーションに反映して、そのチーム独自のプロセスを作りこんでいった。

その経験から、気付いたことをBlogに書き散らしている。

多分、日本でも世界でも、BTSがアジャイル開発のタスク管理に有用であるという経験に気づいた人はたくさんいるし、実際に試されているだろう。
そんな人達は、さかばさんの言うように、研究所の人達ではなく、実際の開発現場で問題意識を持って技術で解決しようという人達が中心なのだろうと思う。

オブジェクト指向もその由来を辿れば、現場の開発者の試行錯誤の後で、オブジェクト指向プログラミング言語が生まれて、一気に普及したように思う。

同様に、チケット駆動開発もアジャイル開発も、現場で試行錯誤しながら、そのアイデアを抽出しで使いやすいように改善して具体化するというループを繰り返しながら、一つの完成物になっていくに違いない。

プロジェクト管理サーバーのメトリクスは教科書みたいだ

プロジェクトが一段落したから、メトリクスを出力してみた。
その時に気付いたことをメモ。

【元ネタ】
プログラマの思索: プロジェクト管理サーバーとは
プログラマの思索: アジャイル開発の弱点をプロジェクト管理サーバーが助ける

【各種ツール】
BitNami :: Trac
All In One TestLink JP
TestLinkCnvMacro
StatCVS - Repository Statistics
StatSVN - Repository Statistics

Tracから、カテゴリ、マイルストーン、解決方法、種類などの観点のチケット集計結果。

TestLinkにあるテスト実績からTestLinkCnvMacroを使って、テストケースの成功・失敗・ブロックの累積グラフ、曜日別・時間別・ピーク時間別のテスト実績、そしてテスター毎の生産性グラフ。

SVNリポジトリやCVSリポジトリから、StatSVNやStatCVSを使って、システム全体・サブシステム毎のLOCの累積グラフ、プログラマ毎の生産性グラフ。

これらのメトリクスは、上記ツールですぐに出力できる。
そのメトリクスを印刷して、メンバーにメトリクスの意味を説明したら、「まるで教科書みたい！」と言われた。

理由は、基本・応用・高度情報処理試験でSW工学や信頼度成長モデルの問題が出てくるが、実際の現場では今まで使ったことがなかったから、とのこと。

メンバーのその言葉を聞いて、SW工学の座学だけ知っていても、実際の現場で使えなければ無意味なんだな、と思った。
普通の現場にいるSEやPGは、基本・応用・高度情報処理試験の知識をどれだけ現場で使いこなせているのだろうか？
実際は、それらの知識は殆ど役立っていないのではないか？

普通の現場リーダーは、コストと納期に追われて、従来と変わらないKKDのプロジェクト管理しか知らない。
だから、現場で得られたメトリクスとSW工学の知識を組み合わせて、事実に基づいた意思決定を行うというマネジメントの基本スキルを普通の現場リーダーは知らない。

チケット駆動開発は、メトリクス出力を背後で自動集計する機構があるから、このメトリクスを正しく分析することで、効果的な意思決定を行うことができる。

更には、僕が考えるプロジェクト管理サーバーのインフラがあれば、プロジェクトマネージャにとって必要なマネジメント情報はいつでもすぐに得られるし、そこから良質の意思決定ができるようになるだろう。

TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理

TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。
TestLinkでテストしていきながら感じたことをメモ。

【1】ウォーターフォール型開発では、下流工程にテストが来る。
単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？

テストは基本的に、V字モデルの左側の工程の検証作業になる。
単体テストは開発工程の検証だが、結合テストの違いは何だろうか？

単体テストは、最低限動作することを保証すること。
Exceptionが発生するようでは話にならない。
ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。
だから、コードカバレッジが非常に重要になる。

結合テストは、複数のモジュール同士を結合して動作するのを検証する。
普通のプロジェクトでは、結合テストで火を噴くことが多い。
理由は、結合テストになって初めて、顧客だけでなく開発者も、実際にシステムが動くのを見れるからだ。
システムは、いくら設計をやったとしても、動かさないとイメージが湧きにくい。
そこで初めて、設計漏れ、要件漏れに気づくことも多い。

【2】Webシステムならば、結合ストで、複数の画面の間で遷移するテストになる。
結合テストでは、単に画面遷移するだけでなく、画面の状態のパターンに対してテストする。
つまり、システムの状態遷移図に従って、正しく遷移するか、おかしな遷移はしないか、を確認することになる。

結合テストで火を噴きやすい理由は、システムの状態遷移図に設計漏れがあったことに初めて気付く工程だからだと思う。
状態の数がわずか数個でも、その状態遷移のパターン数はすぐに爆発する。
全ての状態遷移を設計し尽くすのは、かなりの労力がかかるし、高度なモデリング力を必要とする。

例えば、Amazonのような小売系Webシステムの結合テストを考えてみよう。
商品は、会員によって商品検索で発見され、カート画面に入って、注文フローを通って注文完了されて、ようやく終わる。
その間の商品のステータスは、「カート」「注文中」「注文完了」が最低限あり、それらのステータスを結ぶと、状態遷移図が出来上がる。

この状態遷移図から結合テストのテストケースを作る時、「カート→注文中→注文完了」だけでなく、「カート→注文中→カート→注文中」「カート→注文中→カートから削除」など、フローを逆に戻るようなケースも必要だ。
この時に、実装漏れ、設計漏れが判明しやすい。

更に、注文完了後に、商品の配送前に注文取消ができる要件があったとしよう。
すると、「商品の配送前に注文取消できる」「商品の配送後は注文取消できない」というケースも出てくる。
この2個のケースに上記のケースも組み合わせると、テストケースは指数関数的に増えていく。

結合テストでは、他のステータスも考慮するから、画面に出てくるオブジェクトのステータスが多いほど、テストケースは爆発的に増えるから、納期までにテストを終えるのは高度なプロジェクト管理能力が必要になってくる。

【3】そして、システムテストでは、時間軸に沿って、業務シナリオに従ってテストする。
販売期間中の商品を注文した場合、商品をカートに入れたまま放置して販売終了になった場合、など、色んなフローを時間軸と絡めてテストケースを作る。

システムテストでは、システム間同士の結合テストも含まれる時がある。
特に、フロントのWebシステムと、バックエンドで動くバッチあるいはメインフレームのインターフェイスを確認する時が多い。
ここでも、初めて稼動するのを開発者も見るから、初めて仕様の本来の意味が分かる時も多い。

そして最後は、顧客が実際に使えるかどうか、受入テストを実施する。
このテストケースは今までのテストケースがほぼ流用されるが、顧客はこの工程で初めて触れるから、本来の要件がずれているのを初めて気付いたり、やっぱり使いやすくして欲しい等と言った仕様変更が大量に押し寄せる時がある。
特に、新規顧客で、第1次開発案件で最初のリリースでは、開発チームと顧客の距離感が分からないため、要件の認識相違が非常に多い。

【4】それぞれのテスト工程では、テストの目的は大きく異なる。
だが、一番注意すべき工程は、僕の経験では、結合テストだ。
その結合テストで一番の肝は、システムの状態遷移図を漏れなく、整合性を取りながら書ききれるかどうかにかかっている。

そして、その結合テストでもう一つ重要なのは、要件カバレッジだ。
実際は、仕様を全てテストで検証されているか、仕様のカバレッジを考慮しているか、ということ。
実際の現場では、そもそも要件や仕様にIDが振られておらず、テストケースはどんな背景から作られたのか、という作成理由が曖昧なまま作る時が多い。
すると、必ずテストされていない仕様や要件が出てきて、そこが潜在バグになる。

TestLinkを運用して使いこなしていくと、テストケースそのものの品質が重要になってくる。
テストケースがシステムの状態遷移を全て網羅していないならば、テストされない遷移からバグが出る。
テストケースが全ての要件や仕様を網羅していないならば、テストされない要件からバグが出る。

TestLinkでは、要件管理の機能があり、テストケースと要件を紐付ける機能がある。
この機能を使い要件解析すると、テストされていない要件を簡単に探すことができる。

また、TestLinkのテストケースは階層構造にできるため、状態遷移図のステータスやフローの種類でグループ化することができる。
これによって、テストケースを管理しやすくなる。

運用保守では、リアルタイムに保守されない仕様書よりも、過去に使われたテストケースの方がはるかに重要だ。
テストケースこそが、仕様そのものだからだ。
そのテストケースを再利用して回帰テストを行えば、デグレ防止にもなる。

【5】現場リーダーも開発者も、要件定義から開発までの上流工程のプロジェクト管理に関心が行きがちだが、実は、下流工程に当たるテスト工程のプロジェクト管理の方がはるかに難易度が高い。

TestLinkを運用してから、テストの進捗管理やバグ修正＆検証フローが非常に管理しやすくなり、テスト工程のプロジェクト管理がものすごく見える化できるようになった。
他にも考えてみたい。

業務システムと法律の関係性

業務システムの仕様を突き詰めると、法律にぶち当たることが多い。
特に、会計システムや勘定系システムの場合、金融に関する法律のために、込み入った仕様になっている。

J-SOXも然り。
法律のために業務システムが作られる。
コンプライアンスを実現するために、業務システムが作られる。

業務システムを作る理由は、定型化されたワークフローで人を動かすためにあるのではないか？
ルーチン化された業務は、業務システムでカバーした方が安上がり。
人数の多い会社ほど、手動によるワークフローの管理はミスが多く、手間もかかるのだろう。

特に金融系のシステムの仕様は、法律の塊だ。
複雑な業務システムの背後には法律があるのだろう。

相殺フィードバック

TSPの本で「相殺フィードバック」というフレーズがあったのでメモ。

【1】フィードバックは、マネジメントの基本技術の一つだ。
フィードバックがあるからこそ、PDCAのうちCheckとActionが稼動する。

フィードバックはゴールまでの進捗を表す。
フィードバックを受けて、ゴールまで後どれくらいあるか、自分のポジションが分かる。

しかし、フィードバックは諸刃の剣でもある。
相殺フィードバックとは、フィードバックを受けると、問題がどんどん吹き出す現象を指すらしい。
つまり、フィードバックを受けて改善しようとしても、問題が多すぎて制御できない。

TSP本で面白かったのは、IT業界は相殺フィードバックが多いという指摘だ。
よくある例は、結合テスト工程でバグを見つけ始めたら、どんどん膨れ上がってしまって、品質はおろかバグ修正の制御もできなくなってしまうことだろう。

あるいは、顧客からフィードバックが寄せられるけれども、改善要望や障害報告が多すぎて、どれから手をつけたらよいか分からない状況もあるだろう。

特に、ウォーターフォール型開発では、フィードバックに対応する手戻り作業を制御するのはそもそも難しい。
フィードバック作業を裏プロセス、あるいは裏で動く並行プロセスとして隠して実行するしかない。

【2】アジャイル開発では、フィードバックを受け入れる余地がある。
むしろ、顧客からのフィードバックに対応することを、一つの戦略として取り入れている節もある。

でも、アジャイル開発であろうとも、無制限なフィードバックは受け入れがたい。
うまく制御できなければ、単に混乱しているだけだ。

アジャイル開発では、イテレーションあるいはスプリントというタイムボックスで対応できる範囲内でしか、フィードバックを受け入れないようにする手法がある。
この手法のおかげで、イテレーションで実現すべきフィードバックを優先順位付けして、ふるいにかける。
これが本来のマネジメントなのだ。

SW開発で特にフィードバックプロセスを制御しにくい理由は、変更管理というプロセスの難易度が高いからだと思う。
改善要望や障害報告と言う要件から、仕様化して、実装して、テストして、要件が実現されたことを追跡する仕組みが非常に難しいのだ。

チケット駆動開発は、この変更管理プロセスを補完してくれるだろうと直感している。
単にチケットでタスク管理できるだけでなく、チケットを経由して要件からタスク、ソースまで追跡できる仕組みがあるからこそ、フィードバックを追跡できる。

【3】アジャイル開発から派生したプロジェクトファシリテーションでは、KPTというフィードバックプロセスがある。
これは、Keep・Problem・Tryと言う観点でフィードバックを促すプロセスだ。

フィードバックの質を高めるために、KPTを使うのはすごく有効だと思う。
イテレーションの単位でKPTを開発者と行ってみると、イテレーションをこなすたびに、KPTにあるイシューが変化しているのが分かる。

KPTがうまくいっている時の流れは、Problemにあがった問題点がTryの対策に変わり、その対策が成功したら一つのノウハウとしてKeepに現れること。
現場リーダーとしては、この流れにのせるためにフィードバックを使いたいのだ。

でも、KPTがうまくいかない場合は、Problemにいつも同じ問題が滞留したり、Tryに実現不可能な対策、あるいは忙しくて忘れ去られた対策が放置されがちになる。

現場リーダーは、フィードバックプロセスが何故うまく稼動しないか、観察しなければならない。

XDDPと言う派生開発

初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。
本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。
以下、メモ書き。

【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。
ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。

駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。
影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。

清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。
人体でも、風邪を引いた場合、抗生剤を飲む。
しかし、抗生剤は人によっては免疫機能が働いて拒否反応を起こす危険なもの。
そうでなくても、抗生剤は、悪玉だけであく善玉の細菌まで殺してしまう。

ソフトウェア開発でも、機能追加は慎重に行わなければ、既存の機能の品質まで劣化させてしまう。

そうなってしまう理由は、SW開発の殆どは、既存のソースに機能を追加してVerUpしていくスタイルが多い事実を見落としていないか？

SW開発のその特徴を類推すると、VerUpしていくたびにテストケース数が単調増加していく事実もあげられる。
過去の機能が正常動作する保証の元に、追加した機能のテストも行う。
影響範囲をきちんと見極めないと、既存の機能まで壊してしまう。

XPならば自動テストのプロセスがあるため、回帰テストによって、既存の機能の正常動作を保証できる。
しかし、そのプロセスがなければ、回帰テストのコストが大きすぎるため、デグレの危険をいつもはらむ。
デグレは、顧客の信用を激しく落とし、開発者自身のモチベーションも大きく落とすとても危険な現象だ。

【2】XDDPには、要求と仕様を厳密に区別し、変更管理をきちんと追跡していくプロセスがある。

要求と仕様の一番の違いは、要求は1回限りだったりするけど、仕様はVerUpしていく、という話にすごくピンと来た。
この話によれば、仕様書もソースと同じく構成管理の下に置くべき対象なのだ。

駄目なプロジェクトでは、中途半端に仕様書を直しては、設計漏れが出るたびに仕様書を修正するパターンの繰り返しだ。
XDDPでは、変更管理プロセスがしっかりしているため、CCB(変更管理委員会)の決定やレビューが終わらない限り、仕様書に修正が入ることはない。

清水さんは、この特徴があるおかげで、並行開発や五月雨式開発が可能になる、と言っていた。
例えば、組み込み製品ならば、普通は、似たような仕様を持つ製品ファミリーがたくさんあり、それぞれが並行開発されている。
機能追加が起きると、全ての製品ライン上でマージ作業を行わなければならない。
だから、変更管理プロセスを制御することで、デグレが起きないようにするのがポイントらしい。

僕は清水さんに、ブランチを巧く使えば制御できるのではないか？と質問したら、ブランチからマージするのは大変ではないですか？と切り換えされた。
確かに、タスクブランチは現実的な解決方法の一つであるが、制御するのが難しい技術の一つだから。

また、要件からテスト仕様書が作られる。
XDDPでは、要件仕様書がしっかりしているため、受入テストのテストケースを作るのがかなり楽になる印象を受けた。

TestLinkでテスト管理し始めてから、テストケースの元ネタである要件の重要性を痛感している。
テストケースを作る場合、一番重要な観点は、全ての要件を網羅できているか、という要件カバレッジだ。
実際にテストケースを作ってみると、テストで確認しない要件がポロポロ出てくる。
つまり、テストがMECEでないのだ。
そこから、検証できていない機能が発生して、潜在バグが生まれる。

実際は、全ての要件をテストでカバーするのは非常に面倒な作業だ。
一つのテストケースには複数の要件が混じっていたり、要件を検証するステップを追加するたびにテストケースは肥大化しがち。

そもそも要件IDが振られた要件定義書が存在しない場合もある。
そのプロジェクトは、テストケースの品質が非常に低いといえるだろう。

幸いなことにTestLinkでは要件解析の機能があり、テストしていない要件、要件に紐づかないテストなどをリアルタイムに一覧表示できる。
この要件解析の機能をフルに使うと、テストケースの品質を向上させることができる。

【3】清水さんの本にもあるが「SEはプロセスを自在に設計する能力が必要だ」というフレーズが僕は好きだ。
プロジェクト毎にそれに合った開発プロセスを設計して運用する能力がPLには必須。
そのためのツールがDFDっぽいPFDというツールらしい。

XDDPがアジャイル開発と似ている印象を持ったのは、SW開発の殆どは機能追加という保守開発である、という認識を前提として、ソースからリバースエンジニアリングで設計しようという開発スタイルだからだ。
XPは仕様書よりも動くプログラムを重視するが、XDDPも既存のプログラムを分析するのを重視する。
ウォーターフォール型開発のような上からの開発ではなく、下からの開発スタイル。

清水さんの話の中で「一人プロジェクトは危険だ」というフレーズがあった。
つまり、一人で設計し修正しテストして終わる作業は非常に危険だということ。
一人だけの作業は思い込みが生じたりして、品質が安定しない恐れがあるから。
大人数のチームであっても、運用保守の作業はコストをかけられないため、一人プロジェクトになっている時も多い。
だから、アフターケアやレビューの重要性を言っていた。

これは、XPのペアプロの発想に似ている。
一人だけでバグ修正してバグを検証すればOKというわけではない。
二人の目を通した作業の方が、時間はかかっても品質は安定する。

XDDPは運用保守に強い開発スタイルのような印象を持った。
色々調べてみる価値はある気がする。

プロセス改善に対する違和感

＃まとまっていないけどメモ書き。

日本の大手SIerのマネジメント層は「プロセス改善」という言葉が好きだ。
特にメーカー系SIにあるSEPG、SPI、PMOのような組織では、プロセス改善、ないしそれを行うマネージャ層をサポートする役割が与えられている。

そのプロセス改善の内容は、マネジメント力の強化に力点が置かれて、何かしら違和感がある。
確かに、現場リーダーのプロジェクト管理能力にばらつきがあるために、SIとして利益が上がらない点は多々ある。
品質がソフトウェア開発にはとても重要だし、その品質管理に力を注ぐのも分かる。

でも、ソフトウェア開発に従事する者として、現場の開発者の意欲や動機、あるいはソフトウェア開発の特徴が何か漏れている気がしている。

ソフトウェア開発では製造業よりも破壊的イノベーションを生み出す個人に特に依存しているのではないか？
その観点が、プロセス改善を声高に主張する人たちに欠けていないか？

今の日本が世界に誇れる技術として、RubyやSeasarがあると思う。
特に、Rubyは草の根で広がっているし、Ruby on Railsという優れたWebフレームワークはJavaよりもはるかに生産性が高いと言われている。

それらは、日本のIT産業の主流から離れた所で、優れた開発者のイノベーションから生まれている。
プロセス改善という発想の元にそれらの技術は生まれていないと思う。
ワークバランスの取れた環境で、自由な発想や思索から生まれたはず。

開発者の意欲や動機をサポートするだけでなく、新しい技術を奨励する環境も大事。
開発者が強固な組織の中で、破壊的イノベーションとなる技術を作り出すのは、おそらく矛盾している。

仮説検証スタイルとアジャイル開発の関連性

勝間和代の本を読みながら、アジャイル開発との関連性についてメモ。
＃ラフなメモ書き。

【元ネタの本】

昨今、外資系コンサルタントやMBAホルダーの思考スタイルであるフレームワーク思考、仮説検証スタイル、ロジカルシンキングなどが流行している。
それらの本を読んでみると、確かに実際の仕事で役立つ。

これらの本で興味深いと思ったのは、限られた情報の中で、精度の高い意思決定をする技術の重要性だ。
つまり、鮮度はいいけれど正確さが多少悪い判断の方が、遅くて正確な判断よりも重要である、と。

この意思決定のスキルは、中間管理職よりも経営者のように上級マネジメント職での基本技術のように思える。
実際、経営者は、動きの激しいマーケットの中で、素早く正しい舵取りを要求されている。

この意思決定の構造は何か？
それが仮説検証スタイルなのだろう。

つまり、限られた情報から、論理的に整合性が取れている仮説を一旦作り、それから行動すべき対策を導き出すことだ。
勝間和代の本では、この構造を「空-雨-傘」フレームワークと呼んでいる。

空は客観的な事実。
雨は人の解釈、主観。
傘は解釈に対する行動、対策。

「空-雨-傘」やロジックツリーなどのフレームワーク思考で、限られた情報から推論して一つの仮説を作る。
仮説があるからこそ自信を持って実行できる。

実行した結果を仮説から導き出される結果と比較して評価する。
それが検証プロセスになる。
その評価によって、仮説を更に修正して強化していく。

いわゆるPDCAサイクルにおけるCheckとAction。

この手法はアジャイル開発に似ている気がする。
アジャイル開発では、イテレーション又はスプリントと言う定期的な期間の中で、実現すべき要件をシステム化していく。

要件であるストーリーは、システムの観点から眺めれば曖昧であり、実装前にいくらきちんと設計しても、システムとして動作しなければ分からない所もある。
また、ストーリー通りに作ったとしても、顧客が受入テストで動かしてみたら、障害があるだけでなく、些細な機能を変更したい、などの改善要望も出てくるだろう。

開発者の戦略としては、与えられた要件から論理的整合性に矛盾なく動作するシステムをまずは作り、早くリリースしていく。
そして、顧客のフィードバックを受けて、仕様変更を受け入れる余力を保持できるように、設計も実装も開発チームの体制もあらかじめ作っておく。

与えられた要件のうち、一部は間違っていたり、あるいは、開発者が要件をきちんと認識できていなかった部分もあるかもしれない。
でも、間違った認識に基づいたとしても、ロジカルに設計して実装できたならば、後から修復は可能だと思う。

「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」でも、下記の一節がある。

意思決定前における彼のロジックや思考プロセスがしっかりしていたのであれば、そのロジックと思考プロセスは意思決定後であっても、変わらずしっかりしているはずです。

つまり、意思決定のプロセスが正しく進んでいるならば、限られた情報で誤った方向に進んだとしても、検証プロセスを速める事によって、正しい方向へ軌道修正できる能力がある。

アジャイル開発へ仮説検証プロセスを意識的に取り入れたならば、現場リーダーは自信を持って意思決定できるのではないだろうか？

TortoiseHgの日本語化メモ

TortoiseHgでVer0.8がリリースされたので、さっそくインストールしてみた。
しかし、パス名やファイル名に日本語があるとコミットすらできない。

下記で色々調べてみた。

【元ネタ】
2009-06-27 - 負けないように頑張る日記
2009-06-15 - 負けないように頑張る日記
2009-07-02 - 負けないように頑張る日記

kuy / thg-ja / wiki / Japanese ― bitbucket.org

物置にあるノート: fixutf8を使うために設定しないといけないこと

TortoiseHg で日本語ファイル名 - あすかぜ・ねっと

methane / hg-fixutf8-jp / overview ― bitbucket.org

hg-fixutf8 更新 - methaneの日記

結論は、TortoiseHg で日本語ファイル名 - あすかぜ・ねっとによると下記の通り。

2009/07/05 現在、TortoiseHg 0.8 ではダメ文字を含む日本語ファイル名はコミットできないようです。
どうしても日本語ファイルを使いたい場合は、 TortoiseHg 0.7 + hg-fixutf8 の組み合わせか、 TortoiseHg 0.6 + win32mbcs の組み合わせを使いましょう。
CUI では、Mercurial 1.3 + hg-fixutf8 の組み合わせで動作するようです。

TortoiseHg 0.8でメニューも日本語化されるが、日本語を含むパスやファイルはコミットすらできない。
残念で仕方ない。

分散バージョン管理はGitやBazaarなど色々あるが、MercurialはSubversionやCVSに似ていて使いやすいように思う。
MercurialのWindowsクライアントTortoiseHgはまだ実用に耐えないが、じきに普及してくるはずだ。

Subversionがバージョン管理のデファクトスタンダードになった理由は、WindowsクライアントであるTortoiseSVNが使いやすいからだ。
ExcelやWordの差分機能、BTSチケットと連携のように、昨今のアジャイル開発のトレンドをうまく取り込んでいるように思う。

同様に、CVSのWindowsクライアントTortoiseCVSもある。
Eclipseのような重厚なツールは必要ない。

昨今のソフトウェア開発では、メインラインモデルのように複数のコードラインによる並行開発が一般的になった現状がある。
分散バージョン管理は、そのWindowsクライアントがキラーアプリになるだろう。

TortoiseHgのバージョンアップを切に望む。

バグはマインスイーパーみたいだ

「品質がスケジュールよりも優先される理由: プログラマの思索」を書いた後に思ったこと。
バグはマインスイーパーみたいだ。

1個のバグが出るたびに、周辺の機能は正常動作が確認できなくなる。
わずか10％のバグが出たとしても、殆ど全ての機能がみなしバグになってしまい、テストしても無意味になる。

ほんのちょっとの地雷があるだけで、その周辺の広範囲は地雷原になってしまう。

ハードウェアでは、ある程度の不良品を出さなければ、逆にきちんとテストできているのか、不審がる。
信頼度成長曲線のような品質保証のモデルが既に理論的に作られている。

でもソフトウェアでは、バグはなるべく出さない方がいい。
バグが少ないほど、品質は安定し、スケジュールも短縮化し、工数も少なくなる。

品質はスケジュールよりも優先する。

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

CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。
mgさんのコメントを書きながら、考えたことをメモ。

【元ネタ】
アジャイル開発は受託開発の方が向いている: プログラマの思索

「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。
第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。

SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。
設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。

仕様変更が来たけれど、バグ修正を優先すべきか？
バグ修正よりも、目先のタスクをこなすべきか？
全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？

今、僕はTestLinkで結合～受入テストを管理していて、「品質がスケジュールよりも優先する」の原則の重要性を改めて感じている。

TestLinkでは、テスト実施結果をリアルタイムに表示できるので、テスト実施数だけでなく、成功ケース数、失敗ケース数、ブロック数を毎日集計できる。

仮に、テスト中のテスト計画にあるテストケース数が500ケースあったと仮定しよう。
開発チームあるいはテストチームは、500個のケースをこなしていくと、必ず失敗するケースが発生して、バグが出てくる。

この時に、テストケース同士で依存するケース数が平均10個だと仮定しよう。
例えば、Amazonのような小売系Webシステムならば、カート画面のテストの次に注文画面のテストケースがあるから、カート画面と注文画面のテストケースは依存していることになる。

すると、テストケースが1個失敗するたびに、バグが1個増えて、依存するテストケース10個が「ブロック」になる。
理由は、依存するテストケースは、テストしたとしても必ずバグが出る「みなしバグ」だからだ。
つまり、ブロックしたテストケースは、一生懸命にテストしたとしても工数の無駄だ。
バグが修正されなければ、テストしても無意味なのだ。

今、仮に、テスト計画の全テストケースを実施して、失敗率が5％だったと仮定しよう。
すると、失敗ケース数やバグ数は25件あり、依存するテストケースは250件だから、ブロックするテストケース数は250件になる。
つまり、500件のテストケースのうち45％しかテストで「成功」、つまり、品質が確保されたに過ぎず、残りの55％はテストで確認すらされていない状況になる。

更に、失敗率が10％だったと仮定しよう。
すると、失敗ケース数やバグ数は50件になり、ブロックするテストケースは単純に数えると500件になる。
つまり、10％以上失敗したら、殆ど全てのテストケースが「みなしバグ」の状態なわけで、もはやテストしても工数の無駄。

結局、テストよりもバグ修正を優先しなければ、テストすら終わらない。
バグ修正よりも仕様変更を優先したとしても、みなしバグが多発した状態で機能追加したとしても、状況は一段と悪化するだけだ。

「ソフトウェアでビジネスに勝つ」本では、品質が良ければテスト工程が短縮されてスケジュールは前倒しになる、と書かれているが、おそらく上記のような事実を指しているのだと思う。

TestLinkの良い所は、上記のような事実を過去のテスト実績から集計して分析できることだ。
過去のテストから、バグが頻発した要件は注意したり、あるいは、過去の開発でバグが多発した要件のテストケースを再利用して、念入りにテストするといった戦略を取る事もできる。

アジャイル開発というよりもソフトウェア開発のプロジェクト管理が、品質・コスト・納期の三角形ではなく、スコープ・コスト・納期の三角形でマネジメントする理由も同じだ。

ソフトウェアの品質を優先すれば、自然にコストは下がり、スケジュールも短縮できる。
「品質がスケジュールよりも優先する」原則をIT技術者は再考すべきではないか？

Redmine -もっと手軽にプロジェクト管理!

下記の本が7月末に発売されるらしい。

著者の一人である倉貫さんはXPJUG代表であり、Rails製SNSであるSKIPの開発者でもある。
実際、SKIPのタスク管理が行われているRedmineは公開されている。
SKIPと絡めた運用プロセスが解説されるのだろう。

SKIP - 概要 - SKIP - Redmine

目次を読んでいたら、さっそく読んでみたくなってきた。。

クラウド時代のビジネスモデル

クラウド時代のビジネスモデルについてメモ書き。
＃きちんと理解できてないので後でまとめる。

【元ネタ】
クラウドコンピューティング - Wikipedia

知られざる先進業界「地銀」に見るシステム共同化の真実 - ITPro

【1】クラウドコンピューティングには下記3種類がある。
1-1.SaaS(Software as a Service)
インターネット経由のソフトウェアパッケージの提供。
例えば、Salesforce CRM。

1-2.PaaS(Platform as a Service)
インターネット経由のアプリケーション実行用のプラットフォームの提供。
例えば、GoogleAppEngine。

1-3.IaaS(Infrastructure as a Service)
インターネット経由のハードウェアやインフラの提供。
例えば、AmazonEC2.

これらの特徴は、ハード不要、サーバー不要であること。
ユーザにとって、ITは利用するものである。
ITシステムはユーザ企業にとって資産ではない。
データセンターを維持する運用コストは馬鹿にならない。

技術の特徴は、ハードの仮想化だ。
特にGoogleAppEngineは、ユーザから見れば、アプリケーションをデプロイすればすぐに起動できる。
VMWareも同様の技術の流れ。
本番環境もアプリケーション実行環境も全て仮想化してしまった方が、後で安くつく。

【2】クラウド化が進むとビジネスそのもの大きく変化する。
ITはサービスであり、利用料さえ払えば誰でも使える。
ハードもソフトもシステムも自前で保有する必要はない。

そもそも受託開発は必要ないのでは？
SaaSを利用して、ERPやSNSを社内に展開すればいい。
膨大な運用コストはユーザ企業は必要ない。
この場合、ソフトウェアをクラウド上で利用する。

あるいは、ユーザ企業にSW開発の能力があるならば、ユーザ企業自身が自社開発すればいい。
自分たちが業務や問題点を一番よく分かっているのだから、自分たちの業務改善のために自社システムを作ればいい。
その場合、インフラやプラットフォームとしてクラウドを利用すればいい。

すると、ソフトウェアシステムこそが、ユーザ企業のビジネス上の競争優位の源泉という発想になるはず。

【3】IT化よりもクラウド化が最も進んだ業界がある。
それは銀行。
知られざる先進業界「地銀」に見るシステム共同化の真実 - ITProによれば、特に地方銀行がそうだ。

地方銀行の事務を支えるシステムは、複数の銀行による共同利用になっている。
システムは共通だから、銀行の独自性は、使うパラメータが微妙に違ったり、帳票出力する項目が微妙に違ったりするだけ。
地方銀行の事務はどこも殆ど共通なのだ。
つまり、銀行の看板が違うだけで、銀行の業務は全く同じ。

だから昨今、銀行の統合再編がやりやすいのだろうと思う。
米英が最近まで、金融とITで産業再生して高成長した理由は、上記にあるのかもしれない。

ところで、銀行に勤めている人に聞くと、昔と比べて仕事が面白くないと言う。
昔は、銀行独自の仕組みやシステムがあったので、この帳票のこの項目は、こういう業務から発生してきたんだな、と言うのが、経験するにつれて分かってきたけれど、今はシステムがブラックボックスのために全く分からない。
しかも、昔は預金や融資が主な業務だったのに、今は投資信託などのように高度な専門知識が要求されるため、昔のスキルが全く通用しない、と。

システム化、クラウド化が進むにつれて、ホワイトカラー、特に事務員の仕事は単純労働に近くなっている。
SEもIT土方と言われているし。

おそらく、今後、工場のようなハードに依存しないサービスを中心とした業界は、上記のようなクラウド化が進んでいくのではないか？
すると会社の看板が違うだけで、中身はどこも同じではないか。

そして、クラウド化が進むにつれて、IT業界も半導体業界のように、大量の投資資金を持つ会社しか生き残れなくなるだろう。
大規模なデータセンターを運用できる資金力と、常時稼動し続ける耐障害性や膨大のトランザクションをさばききる技術力がなければ、もはや生き残れないのでは？

今はIT業界は、技術革新が盛んで、個人でもプログラミングスキルに秀でていれば、世界を変えることもできる。
でも、じきに半導体業界のように、膨大な投資を延々と続けることができなければ、じきに淘汰されるのでは？

チケット駆動開発はツールによる改善か、プロセスによる改善なのか

チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。
「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？　それともプロセスで改善したのですか？」

質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。
そのプロセス改善はツールに依存しすぎではないか？
ツール無しの開発プロセスにできるのか？
チケット駆動開発は、BTSがなければ運用できないのか？
と。

この質問は今の僕が抱える問題点の一つを持っている。
それについては後でまとめる。

【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。
すなわち、障害だけでなく要望なども取り扱う。

この方法は、Issue Trackingとも呼ばれている。
つまり、障害修正のワークフローをSW開発における全ての作業の管理に拡張しようとすることだ。

SW開発の作業は、バグ修正というプログラミングだけではない。
ビルド環境を作ったり、リリース作業、テストデータの流し込みもある。
仕様変更によって設計書を直し、ソース修正もする。
お客から電話やメールで依頼される調査もある。
現場リーダーならば、スケジュールを作ったり、上司や顧客へ報告書を作ることもある。

それら全ての作業をチケットに登録して、進捗や作業状態をチケットで追跡していく。

すると、このようなプロジェクト管理は、BTS無しでも、PostItのようなカードでも運用可能だろうと推測できる。
実際、XPの計画ゲームを第三者が見ると、チケット駆動開発と何ら変わることはない。

でも、さかばさんによると、チケット駆動開発をアナログでやりたければ、PostItに判子の欄やチェック欄を追加すればいいでしょ、と。

例えば、チェック欄は、その作業のワークフローにおけるステータスが完了したかどうかに使う。
判子の欄は、その作業のステータスが完了した場合、現場リーダーやテスト担当者がレビューしたり検証して、承認したら判子を押す。

つまり、PostItにワークフロー管理機能を追加した点がチケット駆動開発が強調した点の一つ。
しかし、アナログのPostItは管理が面倒だ。
ホワイトボードや模造紙で、かんばんの上にPostItを貼り付けるのがPFのプラクティスの一つでもあるが、PostItは紛失しやすい。
また、集計しにくい。

マネジメントという作業の基本スキルは、予定と実績の比較にある。
PostItによるアジャイルな運用は、実績管理しかできない。
この点がBTSを使う利点の一つ。

現場で開発者の感想を聞くと、チケット駆動開発を自分のToDo管理に使っているようだ。
例えば、日々のタスク管理をCheckPadやRememberTheMilkのようにWeb上で行う感覚。

このやり方を推し進めると、チケットでリスク管理や課題管理も自然に行うようになる。

例えば、開発者がリファクタリングすべき作業ではないか、と気になった箇所は、優先順位の低いチケットとして登録しておく。
このチケットはすぐに作業する必要はないが、このチケットに絡む作業が発生した場合、その時点で作業の一部として取り込む運用もできる。

管理者としては、このチケットは将来のリスクの一つ。
3人日と見積もったチケットが実は5人日もかかってしまった理由の殆どは、リファクタリングの作業工数をあらかじめ見積もりできていなかったからだ。

この運用を始めて、開発者は積極的に、ソースで不安な所、コーディングルールに則っていない所をチケットに登録してくれるようになった。

あるいは、設計書に従って実装して、設計時の仕様漏れや仕様の不明点を質問が出た場合、課題としてチケットへ登録する。
このチケットは、障害修正と異なり、設計者や顧客へ問合せを行うワークフローで管理する。
つまり、このワークフローは変更管理、あるいは、インシデント管理の一部なのだ。

このチケット管理がおそらくIssue Trackingの発端ではないかと推測される。
課題のチケットは、上手に運用しなければ、単なる質問に過ぎなかったのに、仕様漏れとしてテスト工程で工数が大きくかかってしまう危険がある。

だから、チケットで質問と回答を履歴として残し、テスト工程や運用保守で追跡できるように記録しておく。

【2】チケット駆動開発の定義によれば、チケットとソース管理の連携というもう一つの特徴がある。
これこそが、従来のアジャイル開発のタスク管理になかったもの。

この運用ルールに開発者が慣れてしまうと、チケット無しでソースをコミットするのが不安で仕方なくなる。
チケット無しのソース修正をしてしまうと、変更理由が後で自分でも分からなくなるからだ。
特に、昨今のSW開発は開発者の出入りが激しいため、去ってしまった開発者のパッチの修正意図はすぐに分からなくなる。

これは後々の変更管理で大きくリスクとして響く点の一つ。
ソフトウェアは常に手入れしなければ、雑草が生えた公園のように、すぐにエントロピーが増大して品質が劣化していく。

【3】チケット駆動開発はウォーターフォール型開発でも運用できるだろうと思う。
しかし、アジャイル開発のプロジェクト管理に特化できる点が大きな特徴だと思っている。

現場で、Redmineにおける開発者の使い方を見ると、最初はチケット一覧で自分の担当チケットだけフィルタリングして、ToDo管理している。
しかし、僕が朝会などでRedmineのロードマップ画面を見ながら説明するうちに、開発者も自然にロードマップ画面を中心に見てくれるようになった。

理由は、自分のタスク状況だけでなく、チームの進捗がRedmineのロードマップ画面で一目で分かるからだ。
やっぱり、自分の作業、自分の役割がプロジェクトでどんな役割を担っているか、を開発者も知りたいらしい。

Redmineと比較して、Tracのロードマップは機能が貧弱だ。
終了チケットの進捗率しか表示してくれない。

ロードマップこそがアジャイル開発の肝だ。
ロードマップでプロジェクトの進捗、更にはプロジェクトのゴールが見えるし、そして、マイルストーンをXPのイテレーションとして運用すれば、自然にアジャイル開発になる。

Redmineでは自然にアジャイル開発できたのに、過去の僕が、Tracではチケットを乱発したり放置されがちに運用してしまったのは、Tracのロードマップやバージョン、マイルストーンを上手に運用できなかったのが理由だと思っている。

だから、Tracを運用して一番不満な点、そしてTracの最大の弱点の一つは、ロードマップ機能だと思っている。

逆に言えば、Redmineのチケット管理をアジャイル開発のプロジェクト管理に応用できた経験のおかげで、TracやMantisでも、チケット駆動開発できるようになった。

つまり、チケット駆動開発は、Redmineでなければできないわけではない。
数少ない経験から、BTSならば何でも可能だという気がしている。

【4】実際の現場で運用して、今はツールとセットでプロセス改善している、と回答せざるを得ない。
でも、RUPやCMMIのように、管理者からプロセスを開発者へ押し付けて、上からプロセス改善するよりも、ツールを使っていたら自然にプロジェクトの生産性がアップしていた、という方が、現場では使いやすい。

XPやアジャイル開発のように、チケット駆動開発も下からプロジェクトを改善していくのだ。

チケット駆動開発の運用例part2

八朔さんによるチケット駆動開発の運用例をメモ。

【元ネタ】
チケット駆動開発 - Live a meaningful Life

プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。
プロマネらしく、チケットの構造が上手だと思う。

このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。
【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。

アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。
顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。
そうでなければ、開発者が作業するレベルにならないからだ。

後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落とす所まで考えておられた。
つまり、テストケースは、要件とストーリー(ユースケースぽい業務シナリオ)のマトリクスで作れるはず、と。

そうすれば、チケット(要件)→テストケース→バグ→ソースコミット　という形で追跡可能になる。
僕は今、TestLink上で要件管理とテストケース管理を紐づけているが、最終的にはRedmine上で要件管理も行いたい。
その方が、スケジュール管理や工数管理もやりやすいからだ。

昨日のPFP関西WSでは、Redmineをタスク管理に実際に使っているという人もチラホラいた。
今、チケット駆動開発は熱いのかもしれない。

チケット駆動開発の運用例

チケット駆動開発の記事があったのでメモ。

【元ネタ1】
チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead

kanu_orzさんによるTracのチケット管理の運用例。
インシデント管理や問題管理にTracを下記で運用していると思われる。

・チケットをExcelで一括インポート
・Tracで工数を入力、集計
・チケット集計結果をExcelで出力

特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。

これは、いわゆるエンドユーザコンピューティングかもしれない。
つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に帳票(ここでは月次報告用の工数集計)出力する
のは、Tracで行わず、ローカルPC上で作業しているから。
何でもかんでもシステムで作業してもらう必要はなく、スキルがあれば、元ネタから自分で作ればいい。

また、興味深いのは、インシデント管理と問題管理を分離しようという問題意識を持っていること。

「インシデントからそのまま問題管理へ移行してしまうので、初期対応状況の進捗把握が難しい。」
「他からみた場合、対処せず放置しているように見える。」
という指摘は、そうだと思う。

障害修正の発生源を探ると、顧客からのクレームや問合せが発端だった、という時は多い。
チケット駆動開発では、インシデント管理と問題管理のチケットを混在させると、ワークフローやチケットのライフサイクルが異質なため、扱いづらい弱点がある。

だから、ワークフローの単位でプロジェクト別に分けた方が、おそらく運用しやすいのではないかと思う。

僕の少ない経験では、チケット駆動開発のワークフローは、ITILの言うインシデント管理・問題管理・変更管理・リリース管理の4種類にまとめ上げられると思う。
つまり、SW開発や運用保守の日々の作業は、上記の4種類のいずれかのワークフローに帰結すると考えている。

【元ネタ2】
redmine勉強会に参加してきました－実践redmineカテゴリ設計にご用心 - かたるほどでもない技術系ブログ

20090612 実践Redmine @ Redmine勉強会

6月に開かれたRedmine勉強会でのRedmine運用例。
興味深いのは、「各画面で利用できる分類まとめ」のページ。
このページで、Redmineのチケットが各画面からどのように参照されるのか、が一目で分かる優れもの。
チケットという一つのインスタンスをこれだけ多くの観点から集計したり参照できるのだから、Redmineは優秀だと思う。

読んでみて、感想をメモ書き。

「なぜかバージョンに対してwikiが設定できる」とあるが、その理由は、バージョンをシステム開発のマイルストーンと考えれば、そのマイルストーンまでにやるべき作業の詳細や一覧をWikiに書きたい要望があったからではないか、と推測する。

「トラッカーはどの画面でも現れる。ただ、権限設定とセットとなっているので管理には注意が必要」という指摘は、トラッカー(チケットの種類)がワークフローそのものだからだ。
Redmineのトラッカーと言う概念は、Tracにおけるチケットの種類に相当するが、Redmineの方がはるかにワークフローという概念がはっきりしている。

「バージョンはプロジェクト毎に自由に設定でき、なおかつロードマップを利用されるために欠かせない分類」という指摘は、Redmineのバージョンが、XPのイテレーションやScrumのスプリントに相当するものだからだ。
Redmineのバージョンの概念は、Tracのマイルストーンやバージョンに相当するが、Redmineの方がはるかにアジャイル開発っぽいように思う。

「ステータスはあくまで状態でしかなく、後の分類には利用不可能」の指摘は本来の意図がよく分からなかった。
ワークフローの観点では、ステータスは非常に重要だ。
Redmineサマリでは、ステータスごとにチケット数を集計してくれる重要な機能だ。
だからこそ、進捗報告の資料の元ネタにもなりうる。
おそらく別の文脈で話されたのだろうと思う。

「カテゴリは、プロジェクトごとに柔軟に運用可能」の指摘は、参考になった。
RedmineのカテゴリはTracのコンポーネントと同じく、システムの機能の単位だ。
例えば、Javaのパッケージの単位、バージョン管理のtrunkやbranchのようなコードラインの単位、あるいは、jarやwar、DLLというコンポーネントの単位が相当するだろう。
だが、上記の例から離れて、成果物の単位、工程の単位、あるいは、1つのワークフローにおける種類にしてもよいと思う。

つまり、「新規→修正→解決→検証→完了」という問題管理のワークフローがあった場合、そのワークフローは障害修正だけでなく、新規開発やレビュー工程でも使える。
だから、例えば、「問題管理」というトラッカーがある場合、そのトラッカーには必ず「バグ修正」「新規開発」「レビュー」のカテゴリをアサインする運用があってもよいと思う。

他の人のチケット駆動開発の運用例は非常に参考になるので、共有していきたい。

第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』

先週に開催された第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』がとても素晴らしいのでリンクしておく。

第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 from Ryo RKTM

上記の資料では、下記の点が非常に分かりやすい。

１・チケット駆動開発におけるワークフローを、チケットやプロジェクトのフロー図で説明している、
２・チケットとバージョン管理の連携による利点である変更管理を強調している。

「バージョン管理ツールとチケットの連携。チケット駆動開発では、OUTPUT（コミット）と INPUT（チケット）が紐付く。」という指摘こそが、チケット駆動開発の核心だ。
プロセスの入出力が、チケットとソースコミットに対応するという指摘は非常に鋭い。

補足すれば、チケット駆動開発は、上記のワークフローを透過的に行っているのも利点の一つだ。
つまり、開発者のToDo管理を通じて、ワークフローと言う概念が上からではなく現場で根付いていること。
RUPやCMMIのように、上からの押し付けのプロセス管理は、開発者の作業効率を落とす。
しかし、チケット駆動開発ならば、開発者は作業報告を気にせずに作業できる。

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