無料ブログはココログ

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

TiDD:チケット駆動によるアジャイル開発法

3月6-7日にあるソフトウェア信頼性研究会の第5回ワークショップ(申込み締め切りが2月20日まで延びました)に参加します。良い機会なので、チケット駆動開発(TiDD)についてまとめてみました。

TiDD:チケット駆動によるアジャイル開発法」(PDF)

文字ばかりのポジションペーパーですが、コメントがいただけるとうれしいです。

このエントリーをはてなブックマークに追加

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-

XP祭り関西2009でもっとも興味深かったのはチケット駆動開発(TiDD)です。関連する発表としては中西さんの「ゼロ機能リリースのもうひとつの側面」とあきぴーさんの「チケットファーストでアジャイル開発!」がありました。

中西さんの発表はサブタイトルが「ワーキングスタイルを変える開発基盤をまず構築しよう」ということで、開発を始める際に機能のない(ゼロ機能)ものをリリースできるようにビルド環境を整えるという「ゼロ機能リリース」で、どのような環境を整えれば良いかというお話でした。

具体的には

  1. Tracなどのチケットを用いて、要求から発生するタスクや、バグの管理をする
  2. 構成管理ツールでバージョン管理する
  3. ビルドを自動化する

の3点でした。

まず、1.はチケット駆動開発をしようという意味で、チケットファーストにすることで

  • 無駄が排除できる
  • コミュニケーションプロセスが改善できる
  • 成果物による進捗管理できる
  • 問題が早期発見できる(問題の大きさではなく滞留時間で管理できる)

という効果を述べられました。

次に、2.の構成管理については、メインラインの開発からリリース(メンテナンス)ラインのブランチをリリースごとに起こしていくことや、機能追加、バグ修正、コードのクリーンアップなどタスクレベルでコミットすること、を話されました。

最後の3.ビルドの自動化では、システムの要のテストであるスモークテストは日中のビルドで行い、細かな回帰テストはナイトリ・ビルドで行う、また、必要にプライベートシステムビルドを行うとのこと。

Q&Aでは、チケットに関する質問がありました。マイルストーンは3カ月程度、チケットはなるべく小さく2時間単位でも良いが、分類する必要がある。管理者が閉じることができるマスターチケットと、各開発者が閉じられるタスクチケットに分類すれば、分類してレポートできるようになるとのこと。

これらの一連の自動化を見ていると、新しいことなのに当たり前のような、凄く良いアイデアのようなのに「そうしなければならない」という印象を受けました。

それは、あきぴーさんの発表で意味がわかったような気がします。あきぴーさんのサブタイトルは「チケットに分割して統治せよ」で、TiDDの歴史、背景と効果、経験を語られました。この中で、「TiDDはWeb2.0のようなもの」と言われました。古い技術を使って新しいことをするという意味で言われていたのですが、これが実はTiDDをよく表していると思います。

上に書いたように、TiDDはある意味「当たり前のことをしていったら、こうなった」という印象があります。でも、何か新しく、開発の苦しみを和らげてくれそうな魅力を感じます。

その意味を考えているうちに、かつて川端さんにお願いしたソフトウェアシンポジウムのチュートリアルを思い出しました。このセミナーはXP入門ということでお願いしたのですが、実際はEclipseの実習が中心でした。これは、少人数でソフトウェア開発に向き合うと、ツールを中心に効率化を図るしかないということを意味しているのだと思います。

TiDD(チケット駆動開発)は、その背景の思想から生まれたものではなく、ツールを用いながらプロセスを改善していったら、必然的にそうなったものだと思います。かつての方法論が、背景の思想を元にツールを開発したために実践する際にやりにくい点が生じたのに対し、実践している中で生まれた方法論は、その体系をきれいにまとめられれば従来にない力を発揮できると思います。

今後、そのあたりをまとめたいと思いました。

プロジェクト型でない開発 - XP祭り関西2009 その2-

XP祭り関西2009の2番手は土屋さんの「マネジメントから自律へ」でした。

日ごろの開発はプロジェクトとしてやっているが、実はプロジェクトの前提にあっていない、とのこと。確かに、ゴールも明確にではないし、人もゴールに合わせて集めるのではなく、そこにいる人でやっています。そのために、毎回ドメイン知識の学習や、最適解の模索に多くの時間を使っています。

プロジェクトは形式知を元にゴールを目指しますが、プロジェクト型でないので、共通の目標を持つチームが暗黙知で迅速な対応をする方が良い。技術を磨くと言いますが、磨くとは削ることで、それは無駄をなくすこと。アジャイルのライトウェイトとも一致するとのこと。それは、仕事に合わせて人を集めるのでなく、人がいるところに仕事が運ばれてくるようにすることで実現できるようです。

プロセス改善の目的は良い物を早く作ることで、アジャイル開発ではない。PDCAサイクルにアジャイルのプラクティスを取り入れて、短周期で、回せばよいとのこと。アジャイルかウォータフォールかの議論ではなく、実際の問題に合わせて良い物を取り入れることが現実的な改善であると思いました。

ところで、同じ人の所に仕事が来るというモデルですが、これはかなり効果が上がると思います。昔ながらのプロジェクトでは、途中で人をどんどん追加して、製造が終わるとどんどん減らします。これは、大きな負担だと思います。人が入るたびに説明をするのも大変ですし、担当に合わせて最低限の説明をしているつもりが不十分だったり、議論の度に背景の説明が必要になります。せめて、工程単位、できれば早い時期から同じ人間で開発できれば、非常に効率よく開発できると思います。

アジャイル開発は予算とスコープのトレードオフ - XP祭り関西2009 その1-

ことしのXP祭り関西は、塚口で行われました。キーノートは平鍋さんでAgile2008の報告でした。

まずはAgile UXの話題から。UXはuser experienceの意味で、UIよりも上の概念らしい。ユーザからフィードバックをもらわないと良いユーザインタフェースはできない、とのこと。当たり前といえば当たり前なんですが、アジャイラーからではなくUIの分野で開発法を探したらアジャイルにぶつかったとのこと。会場でUXが実践されている様子が色々と紹介されていました(その一部が平鍋さんの記事に紹介されています)。

また、トヨタ式のカンバンについてもWIP(Work in Process)の観点で説明されていました。WIPにある(つまり開発中の)カンバンの数を制限することで、工程中の物を少なくできるとのこと。これは、いわゆる後工程の引き取り、すなわち使われるものだけを作るということで、アジャイルでいうところのYAGNI(You Aren't Going to Need It )と共通する。さらに鎖のメタファで、後ろから押すと途中で溜まってしまうが、前から引っ張るとスムーズにいくと言われていました。なるほど。

あとは、Dear XPを外人さんと共に英語で歌ったことの報告と、木下さんの飛び入り発表がありました。木下さんは発表だけのつもりだったのに論文を書くことになって急遽書かれたらしい。やりますね。木下さんの発表はいつもながら面白かったです(関西人への期待値が上がりすぎるのではないかとの若干の心配も感じました:-)。木下さんのスライドはslideshareで見ることができます。

色々と興味深い発表でしたが、最も印象深かったのはQ&Aでした。一つ目は日本と海外との違いです。欧米では本などで知っている人が多く、採用は25%ぐらい。ビジネスと作る人との距離が近く、同じリスクをとる、また、コンサルタントも多い。一方、日本は40-50%ぐらいはアジャイルを知っているが、5-10%しか採用しない。これは、ビジネスと作る人の距離が離れているので、ウォーターフォールの方が発注しやすいからだそうです。

二つ目の質問は発表内容と関係なく、たぶん平鍋さんだからこそ出た質問だと思うのですが、アジャイルがうまくいくイメージがわかないので教えてほしい、とのこと。アジャイルは顧客とゴールを一緒に持ち、それぞれの利益の綱引きでなく、運命共同体になっている。作っても使われないものや、うまくいかないものより、コスト削減や新ビジネスなど、うまくいくものを作る。まず、予算と期限を決めて、予算とスコープとのトレードオフで決定していく、との回答でした。

なるほど、と思いました。従来の方法では、スコープが先にあり、無理な予算でも一度決めたら変更せず、ずるずるとリリースが遅れるのでしょうね。

Googleに警告されました:-)

Googleがおかしくなりました。
何を検索しても

このサイトはコンピュータに損害を与える可能性があります。

と表示されます。試しにこのブログを検索するとこんな感じです。

Warning

何を検索しても同じ表示であること、海外でも発生していることから、世界共通で組み込んだサイトチェックプログラムのようなものがあり、何らかの不具合が生じているのでしょうね。

Googleの発表によると、ブラックリストに間違えて「/」を登録してしまって、すべてのURLに一致するようになったみたいです(2/1 11:16追記)。

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