[TiDD] チケットの粒度に気をつける

チケット駆動開発の特徴は、管理的でなく自律的にプロジェクトを管理できることです。チケット駆動開発を実践すると、作業の抜けをなくそうと開発メンバー自身が進んでチケットを登録し、日々残チケットを確認しながら作業します。細かな作業ももれることがなく、きちんと行えます。

チケットに登録することは、作業工数が小さければ小さいほど有効です。大きな作業を忘れることはあまりありませんが、小さな作業は「うっかり」が発生しやすいからです。

管理者は全体の進捗と残業時間を管理するだけで日々の作業が進んでいきます。しかし、順調に進んでいるからとチケットを見ていないと危険な場合があります。

それはチケットの粒度がそろっていないとき、つまり作業時間のかかるチケットが混在するときに生じます。小さなチケットがたくさんあるとき、開発者は日々チケットをチェックして、作業対象と順序を決定して作業を進めます。しかし、作業時間のかかるチケットがあると、日々の作業のリズムが崩れます。作業工数の大きいチケットだけを気にするようになり、細かな作業のチケットがなおざりになりがちです。

チケット駆動開発は作業の抜けをなくします。しかし、チケットの粒度に気をつけなければうまくいきません。もし、細かなチケットに分けることが難しいなら、細かな作業のチケットを忘れていないか管理者が気をつけなければならないでしょう。

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-

あきぴーさんと書いた論文が公開されました(2-1、今週公開されたようです)。

引用していただける場合は、こんな感じでどうぞ。

小川明彦, 阪井誠, チケット駆動開発 - BTSでExtreme Programmingを改善する-, SQiP2009, 第28回ソフトウェア品質シンポジウム2009発表報告集, pp.93-96, 日本科学技術連盟, 2009.

<')))><

[TiDD] チケット駆動開発は見える化でもある

チケット駆動開発にはいくつかの側面があります。

開発者にとって大きいのは、ToDoリストとしての側面でしょう。忘れてしまいそうな細かな作業を、どんどんチケットにすることで忘れずに作業をすることができます。

以前、ある人が「備忘録」言われた際には、正直なところ抵抗を感じました。しかし、開発者が積極的にチケットを起こす動機は、やはり抜けなく作業をしたいと言うことに尽きると思います。

チームとして考えると、チケット駆動は見える化でもあります。チケットの発行は、これから解決しないといけない問題点(issue)を共有し、明らかにする行為です。

チケットによってプロジェクトの現状が明らかになり、コミュニケーションが向上します。また、だれが何をしているかも管理が容易になり、必要なフィードバックが可能になります。

作業の見積もりがきちんと行われているならば、アジャイルで必要となるタイムボックス管理も可能になるでしょう。

チケット駆動開発は見える化でもあるのです。

<')))><

[TiDD] チケット駆動開発の最初の一歩

チケット駆動開発で最初にすることは、「上司への報告！」というねたは終わったので、具体的に進めましょう。

前回書いたように、どのようなものをチケットにするかプロジェクト内で決めておくことはもちろん、チケットを参照する環境を整えなければなりません。

たとえばtracなら、既存のレポートをコピーして修正するだけです。とりあえず以下のようなレポートを作成してはいかがでしょう。

　　- bugのみ
　　- taskのみ
　　- その他

当初、品質管理用にbugのみを作成しましたが、すぐに作業管理がしやすいようにtaskのみというものを作りました。そうすると、抜けができるので、残りのみを参照する「その他」を作りました。抽出条件(WHERE句のところ)や表示項目(前に"_"があると表示されない)は自由に変更できますので、プロジェクトによって用意されると良いでしょう。

また、tracの権限の設定が堅いので、チケットを修正できるようにメンバーに権限を追加すると良いかもしれません。私のプロジェクトでは、memberにTICKET_ADMINの権限を与えました。それなりのリスクもありますので、よく検討して設定してください。

[TiDD] チケット駆動開発はじめました

あきぴーさんと共著で発表活動をしていますが、これまではチケット駆動開発の経験はありませんでした。とはいえ、今世紀の初めからBTSを遣っていますし、アジャイル開発の経験もありますので、あきぴーさんの経験を聞きながら一度はチケット駆動開発をしてみたいと思っていました。

しかし、現在のプロジェクトはウォータフォールで開発していますし、メンバーは7人と試行するには中途半端な規模、個人の趣味で仕事をするわけにもいかないので、あきらめていました。しかし、その時は突然訪れました。

プロジェクトはオープン系の事務システムで、外部システムとの連携があることもあり、色々と予想外のことが起きていました。これまでもWBSを変更することが多かったのですが、それはシステムテストの時期になってもおさまりそうにありませんでした。

ハンフリーさんは「TSPガイドブック：リーダー編」で、アイアコッカの言葉を引用して「ボスのスピードがチームのスピードだ」(p.9)と書かれています。また、司馬遼太郎さんの「龍馬がゆく」には、北辰一刀流の「気は早く、心は静か、身は軽く」と言う言葉が載っています(あんまり関係ないですが、、、）。

現状を見極めると、今こそチケット駆動開発を実践を決断するときだと思いました。不具合だけでなく、*新たに*必要となった作業は、必ずチケットに登録して作業することにしました(全ての作業をチケットにしないことで、チケット数を減らしました)。

実際にやってみると、結構使えます。日々新たに発生する作業が、手に取るようにわかります。メンバーも作業を忘れないようにと、進んでチケット登録をしてくれます。予想外の変化を抱擁しながら、管理が一元化され、コミュニケーションが効率的になり、そしてメンバーに適時支援(フィードバック)が可能になりました。勇気を持って導入してよかったと思います。繰り返し開発こそしていませんが、まさにアジャイルな開発です。

ただ、一つだけ失敗したことがあります。それは上司に報告していなかったことです。上司にtracのメールを流さなければよかったのですが、何も知らされない上司に「tracのメールが急に増えたけど品質は大丈夫？」と確認されました。

これからチケット駆動開発を始めようとするあなたに言っておきます。上司には必ず報告してください。

「チケット駆動開発はじめました」

と。

＃それって冷麺じゃないの？　いや、冷やしシャンプーのパクリです(笑)

<')))><

[TiDD] 小規模開発の難しさを考える

もう20年以上前になりますが、私がソフトウェア業界に就職したとき、最大10人程度の小規模プロジェクト(当時は間違いなくそういわれていました)に配属されました。

当時はいかに大規模開発を管理するかと言うことが注目されていて、各社で開発標準が決められつつあったころです。当時、小規模プロジェクトの管理はあまり注目されていませんでした。大規模プロジェクトが不採算になると会社がつぶれますが、小規模プロジェクトの不採算なら何とか耐えられたようです。

大規模プロジェクトが難しいのはだれもが認めるところでしたが、小規模プロジェクトにもそれなりの難しさがあり、当時、それはなぜか、どうすればよいか、と考えていたことを覚えています。

時代は移り、大規模プロジェクトではプロセス改善に費用をかけることで、比較的安定した開発が行われるようになりました。特にTSP/PSPでは階層的な管理が行われ、個人からチームへと積み上げによって高い精度で定量的な見積もりと管理ができるようになりました。プロセス改善を進める企業においては、その枠組みに入りきらないようなプロジェクトが企業の利益を圧迫するとまで言われています。

一方、小規模開発に関しては、アジャイル開発があるものの、高い能力を持つ技術者が必要とされていて、全ての小規模プロジェクトを救えるかどうか、難しいところです。

さて、ここで小規模プロジェクトはなぜ難しいかを考えて見ます。規模の大小にかかわらず、外部環境の変化による業務要件の変更、外部仕様の決定遅れ、ミドルウェアなどの開発基盤により生じる問題、は同じように発生します。

リスクは一般に問題の大きさとその発生確率で表現されます。大規模プロジェクトでは、それらを乗じた予算をあらかじめ用意しておくことで、問題が発生しても解決できます。これはリスクが統計的に扱えるほどに、プロジェクトの規模に比して小さいからです。

小規模プロジェクトあるいはプロジェクトの規模に比べて大きなリスクの場合は、問題が発生することで危機的な状況に陥ります。品質低下、予算超過やスケジュール遅れ、といういわゆるQCDが守れなくなるからです。

リスクが問題化したプロジェクトを健全な状態に戻すには、
(1)発生している問題をきちんと把握する
(2)優先順位を決めて作業手順を定める
(3)全ての問題を確実に解決(あるいは対処)する
ということが実施できなければなりません。

これは、まさにチケット駆動開発(TiDD)が支援することです。ソフトウェア開発集に生じた問題や予定していない作業をすべてチケット化し、優先順位を決めて、確実に作業する、TiDDのプロセスそのものです。

このように考えると、TiDDは小規模プロジェクト、特に、仕様変更の多いプロジェクト、細かな仕様が多いプロジェクト、予想外の問題や作業がが生じやすいプロジェクト、に向いていると言えるでしょう。

[TiDD] プラクティスから方法論へ

「チケット駆動開発」というキーワードで検索すると、名古屋で勉強会が開かれていたり、実際の仕事で試されている方がおられたり、色々なところで注目されていることがわかります。

そんな中で気になったのが、「チケット駆動開発の研究と実践http://blog.livedoor.jp/techblog/archives/64874955.html」(livedoor 開発Blog)です。ここでは、チケットによる見える化http://sakaba.cocolog-nifty.com/sakaba/2009/07/tidd-1b90.htmlや達成感というメリットのほか、こんなデメリットも書かれています。

「チケットを発行するときは楽しいのですが、クローズしたりステータスを変更するときはチケットが多いほど手間がかかります。」

そして、管理者をつけたほうが良いとのこと。確かに、たくさんの作業を見える化できることがTiDDの特長ですが、管理作業そのものは従来と同じですし、全体の状況となるとチケットを容易に増やせる分だけわかりにくくなるかもしれません。

実は関連する議論をしたことがあります。題して「TiDDは方法論か、プラクティスか」。アジャイル開発やテスト工程などでTiDDをプラクティスの一つとして用いるならば、大きな効果を挙げると思います。しかし、方法論として考えると、チケット駆動開発の基本である「チケットなしではコミットを許さない」というルールだけでは規模が大きくなると開発できません。

そのような現実から考えると、厳密にはTiDDはプラクティスと言えると思います。では、みなさんはどうされているかというと、あきぴーさんなどは上流はウォータフォール、製造はアジャイルをベースにTiDDを用いられているようです。

では、あきぴーさんの開発方法はTiDD開発方法論であるかというと、そうでもあるし、そうでもない。本人がそうだといえばそうなるのかもしれません。しかし、詳細が定まっていないものを方法論というのもおこがましいので、私とあきぴーさんで外部発表した際には「TiDDをアジャイル(あるいはXP)に適用した」という表現を使っています。

方法論とするには、いくつかの定義が必要だからです。具体的には

チケットの管理の方法：ワークフローの一般化。役割と作業の詳細な定義が必要です。また、チケットの統合や分割の定義も必要です。

作業の管理：チケットと紐づいた作業を日々どのように管理するか。作業が増えた際にどう管理するか。

要件あるいはストーリカードとチケットの関係：チケットをXPのタスクカードとするならば、ストーリーカードはどうなるのか。何らかの参照が必要なことはわかりますが、具体的な方法を示さなければなりません。

ほかにも色々あると思います。実際には、現実のプロジェクトが目の前にあるのですから、色々工夫をしながら具体的な事例積み重ねることだと思います。そしてそれらを元に、まとめていければと思っています。

(事例の提供者おられませんか？もし、論文を書きたいのなら、お手伝いならしますよ～)

[TiDD] チケット駆動開発によるフロントローディング

カイゼンといえば「フロントローディング」という言葉もありますね。後工程で見つかる問題をなるべく早い工程で摘出することで、手戻りを減らすことです。リアクティブな活動からプロアクティブな活動への移行と言っても良いかもしれません。

TiDDではBTSを使いますので、障害情報と同じように「どの工程で問題が組み込まれたか」、あるいは、「本来はどの工程で摘出すべきか」、といった情報をチケットに登録しておけば、どの工程をカイゼンすればよいかが明らかになります。レビューの強化、ツールの導入、教育、などによって、あらかじめ不具合を作り込まないようにします。

西先生いわく、「武士道の究極は刀を抜かずに人を切る、テスト道の究極はテストをせずにバグをなくす」、まさに名言だと思います。

また、TiDD良いところは、作業漏れが生じた際にチケットを発行してから作業をするところです。どのような作業が考慮されていなかったか、一目瞭然です。類似の開発を行う際に、抜けていた作業をあらかじめ考慮すれば、問題の発生を減少させることや、見積もり精度を高めることができます。

このようにTiDDを用いることで、プロセス改善を行うことが可能です。それも、チケットによって、隠れていた情報が見える化されるからです。でも、TiDDを実践したけれども、難しい点もあるといわれる方もおられます。次回はその点に触れてみたいと思います。

[TiDD]チケット駆動開発と見える化

トヨタ式のプロセス改善でいう「見える化」というと

「見える化は一言で言えば，問題点が常に「見える」ようにしておく工夫のことである。正常と異常の違いがすぐに分かる仕事場とか，仕事するうえであれこれ迷わずに済む現場のことを指すと言ってもいいかもしれない。 」(ITpro)

というように、問題を発見する環境作りをさすことが多いと思います。

トヨタ式の工場では整理整頓が徹底されていて、ごみ一つ落ちていません。そうすれば、本来留めなければいけないネジが落ちていたらすぐにわかりますし、作業の流れが滞ったり、無駄な移動があればすぐにわかるからです。

チケット駆動開発(TiDD)も見える化を促進しますが、以下の3種類があります。

　　・情報共有
　　・問題の発見
　　・作業状況

TiDDでは、BTSを使って作業を管理します。それは全ての開発者が使うものですので、プロジェクトの作業の進み具合をみんなで共有することができます。開発中はついつい自分の担当している作業だけに注目しがちで、他の人と助け合わなくなりがちです。開発者全員でプロジェクトの状況を共有しますので、自然と協力し合う雰囲気ができるでしょう。

チケットは作業の一覧として見るだけでなく、BTSによってはガントチャートなどのグラフ化も可能です。遅れている作業や、作業負荷の偏りも容易に発見できるでしょう。

作業がBTSのチケットになっているのですから、未完了作業の状況を一目瞭然で管理できます。全ての作業がチケットとして登録されていますから、それぞれの作業のステータスを管理することができます。また、様々な条件で抽出できますから、担当者毎の作業状況も容易に管理できます。

このように、TiDDでは従来の見える化を超えた見える化が可能です。これらはアジャイル開発だけでなく、ウォータフォール開発でも、効果が期待できるものです。

[TiDD] チケット駆動開発とXPの共通点

あきぴーさんがチケット駆動開発(TiDD)をXP(eXtreme Programming)に適用された結果を元に、共著で論文を書いて外部発表をしています(SPES、SQiP)。これらは、アジャイル開発を改善するためにTiDDを適用した論文ですが、なぜそのようなことが可能なのかを考えてみました。

実はチケット駆動開発とXPには共通点があります。それはXPの4つの価値です。それは、

- コミュニケーション
- シンプルさ
- フィードバック
- 勇気

です。この4つの価値がXPのプラクティスに影響を与えています。

TiDDの効果を考えると、このうち2つの価値を支援することがわかります。そもそもの提案者である、まちゅさんによるとTiDDの効果の一つは「開発メンバの仕事が把握しやすくなる」というものです。

全てのソース更新作業がチケットと関連付けられることで、どのような作業が残っているか、プロジェクト内で明確になります。これは、TiDDがプロジェクト内のコミュニケーションを改善するということです。

さらに、まちゅさんはもう一つの効果として「ソースコードのコミット単位が明確になる」とされています。これは、チケットなしのコミットを許さないことから来るもので、開発作業をシンプルにしたことによる効果です。

この二つの価値に対してXPでは、作業をタスクカードに割り当てるというシンプルなルールをつくり、そのタスクカードをタスクボードという掲示板に貼ることでプロジェクト内で情報を共有してコミュニケーションの向上を図っています(もちろん共同のプラクティスもコミュニケーションに重要です)。

ちなみに、フィードバックというのは、繰り返し(イテレーティブ)開発などによって、補正(フィードバック)をしつつ開発することができます。また、勇気というのは積極的な開発プラクティスの実施や担当作業のコミットメントなどによって実現されます。

このように考えるとTiDDはXPと矛盾しないだけでなく方向性が共通しています。繰り返し開発や開発プラクティスを導入すれば立派なアジャイル開発になりそうです。実際にXPJUG関西のTiDDの議論の中では「TiDDによってリズム感が生まれてアジャイルがわかった」という感想さえ出ていました。現実の現場では実現しにくかったXPが、より効果的に実現できるようになる、そんなパワーがTiDDにはあるようです。