無料ブログはココログ

« 2010年8月 | トップページ | 2010年10月 »

[#TiDD] チケット駆動開発の本質は任せる(楽をする)こと

平鍋さんの「リーンの本質は考えること」という記事を読んで、アジャイルの第一人者である平鍋さんの言葉に、確かにリーンではどのようなリスクで、どのように対処するか考えることが大切だ。などと思いながら、シンプルな言葉で説明することの重要さを感じました。

そこで、チケット駆動開発の本質を考えたところ、

 「TiDDの本質は任せること」

だと思いました。チケット駆動開発には様々なバリエーションがありますが、基本は任せることです。

  • 忘れそうな作業を覚えることを任せる
  • 抜けなく確認する段取り(ワークフロー)を任せる
  • ソースを作業と関連付けることを任せる
  • 日々の作業の一覧表示を任せる
  • プロジェクトの見える化を任せる
  • 各種ツールとの連携を任せる

などです。チケット駆動開発はこのように、不安になることや、難しそうなこと、大変そうなことを、RedmineやTracといったBTSを中心としたツールに任せて楽をするのです。

ツールに任せて楽をするのですから、ミスが減り、信頼性が向上し、生産性が向上するのはあたり前です。

私が初めてチケット駆動開発を始めたときもそうでした。仕事に趣味は持ち込まない主義ですので、私が入るまでの開発方針で進めていましたが、どうも危ない、大変そうだ。これだったらチケット駆動開発を入れるほうが良い、と判断して始めました。

当時はtracを使いましたが、その環境も会社が用意してくれるものを使って導入工数を減らし、絶対うまく行くとの自信を持って始めました。今から考えれば、工数をかけてRedmineを入れても十分元が取れましたが、楽をするのが目的ですので、それでよかったのです。

ポイントは、トータルで楽ができることです。無理なチケット駆動開発は不幸を生む可能性があります。はじめのうちは、許された範囲で、広い目で考え、思い込みをせず、に実施するのが良いでしょう。

具体的には、以下の点に注意すべきだと思います。

1.ルールを守る

仕事として行うからには、勝手なことをしてはいけません。上司の許可を得て、客先との契約上の問題にならない範囲ですべきです。

2.局所解に陥らない

ソフトウェアの寿命は長いものです。開発リポジトリの維持の考慮しなくてはなりません。目先の利益だけでなく、広い視野で、ツールや運用方針を決めなくてはなりません。

3.非忠誠

リンク先の平鍋さんの記事をぜひ読んでください。非忠誠とは頑固な原理主義ではなく、現実を見つめた柔軟な対応をすることです。どこかでうまくいったからといって、それがそのまま通用するとは限りません。何をツールに任せるべきか、どうすれば楽になるか現実的な解決法を選ばなければなりません。

意地を張ったり、目先のことだけを考えて、勝手なことをするのではなく、正しく理解した上で、信じられるものに任せることが大切なのだと思います。

# Turn away from your sins and believe the Good News!
# Mark 1.13 (T.E.V.)

[Redmine] チケット更新のチェック (Mylinの設定あり)

「竜馬が行く」に載っていた北辰一刀流の極意に 

 気は速く、心は静か、身は軽く、技は激しく

という言葉がありました。常に備えながらも落ち着いて、いざという時には素早く効果的に行動するということなのでしょう。これは、ソフトウェア開発にも言えると思います。

Redmineには、Webでチケットの更新を確認するだけでなく、以下のような方法でチケットの更新を即座に知ることができます。

1. メール

もっともオーソドックスな方法です。チケットの更新内容を読めますので、メールを常に読める環境では有効でしょう。

2. RSS

メールの環境を整えることが困難な場合、RSSはリーズナブルな選択でしょう。RSSリーダーのほか、メールツールやWebブラウザでもチェックできます。更新内容全文が通知されるわけではないので、ブラウザの併用が必要です。

3. Mylin

eclipse環境の方はこれが便利でしょう。Redmineにソフトをいれる方法もありますが、入れなくてもWebテンプレートによって接続できます。

確認できたのはAll in One Eclipse3.6です。3.5はエラーが出ました。

  1. WebテンプレートをEclipseにプラグインする (アップデートサイト)http://download.eclipse.org/tools/mylyn/update/incubator
  2. その後の設定についてはhttp://www.memorycraft.jp/2009/06/mylyn-redmine.htmlの「タスクリポジトリ追加」以降を参照する。ただし、「拡張構成」の部分だけはこのサイトの通りではうまく動きません。
  3. 「拡張構成」の設定内容はhttp://www.google.co.jp/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&url=http%3A%2F%2Fwww.redmine.org%2Fwiki%2F1%2FHowTo_Mylyn&ei=TIqRTKGXK8fIcdWRkOkG&usg=AFQjCNFkampcHB4OmeisifnC78ug73NmoA&sig2=gxHxxi_UL_PfLv607TafiA を参考に

日本語入力とダーツに造詣の深いgoldbachさん(勝手に名づけました。すみません)に教えていただきました。感謝!

このほかにもREST APIを使うことも可能でしょう。パワーのある方は試してみてください。


#気をつけて、目を覚ましていなさい。
#その時がいつなのか、あなたがたには分からないからである。
#(日本聖書協会新共同訳 マルコ13・33)   

[#TiDD] やっぱり好調!中堅向け実践書「Redmineによるタスクマネジメント実践技法」

中堅技術者は実践的な本を欲していると思います。あきぴーさんと共著の「Redmineによるタスクマネジメント実践技法」は、アマゾンのランキングでコンピュータサイエンス1位のあとも好調です。他のオンライン書店で予約を受け付けた後も、既刊書を含むランキングでも6位からランク外をうろうろしています。

新刊書だけのランキングを見ると、この本が好調なのが良く分かります。

科学・テクノロジーの新着ニューリリース1位
Newsci1img

コンピュータ・ITの新着ニューリリース3位(雑誌を除くと1位)
Newit3img

となっています。Redmine人気、チケット駆動開発への興味、あきぴーさんのブログの人気、などもあると思いますが、書店に並ぶ前からこんなに人気が出るのは、やはり中堅技術者向けの実践的な本が不足しているからだと思います。

出版不況といわれる中で、しっかりした本は洋書中心で、多くが入門書です。また、雑誌も速報性を追っているのか、薄い本にたくさんの記事が詰め込まれています。

日経ソフトウェアの10月号の「読者の声」に、そんな私の要望が載りました。編集部のコメントで、実は出版社の方ももっと濃い内容を伝えたいということが分かりました。出版もビジネスですから、利益を追求しないといけないと思いますが、中堅向けにもっと実践的な本がたくさん出てほしいと思います。

電子書籍は在庫リスクが少なくなるので、本格的な普及期に入ればもっと深く濃い電子本が出版されるようになるのでは、と期待しています。そんな時代を迎えるためにも、この本が売れてほしいと思っています。

[Redmine] 基本操作:三角と十字をクリックしてみよう!

TIPSと言うほどでもない基本の操作です。

右向きの三角や十字のマークを見つけたらクリックしてみましょう。
隠れている機能が出てきます(バージョンによって表示される内容は異なります)。

右向きの三角
Option1

右向きの三角を押すと、
Option2_2

十字
Bug1

十字マークを押すと、
Bug2

# 探しなさい。そうすれば、見つかる。
# 門をたたきなさい。そうすれば、開かれる。
# (日本聖書協会 新共同訳 ルカ11・9)   

[Redmine] あれっ!と思いがちな基本TIPS

初めてRedmineを使ったときや、久しぶりだと、「あれっ!」と思いがちな基本TIPSです。

トラッカーの修正

  • チケットを「移動」します。

題名・説明の修正

  • 「更新」画面で「続き」(上の方、プロパティの変更のすぐ横)をクリックすると編集できます。

別チケットを元に作成

  • 「複製」すると複製されたチケットの編集画面になります。チケットの関連は複製されません

まとめてコピー

  • 「コピー」コマンドを使います。別プロジェクトにコピーもできます。

チケットの相互リンク

  • 「関連する」で指定する。

チケットの終了の前後関係

  • 「ブロックする」で、終了や却下の条件となるチケットを指定する

チケットの期間の前後関係

  • 「先行する」で、そのチケットの期日までは開始日とされたくないチケットを指定する。
  • 「後続する」で、そのチケットの開始日までを期日としたいチケットを指定する。
  • (普通に思う逆だと覚えてください)

チケットを○○ごとに見る

  • リリースするバージョン毎ならロードマップで、Wikiと共に見えます。
  • 0.9以降では、オプションの「グループ条件」でそれ以外の属性も指定できます。

よく見るチケット一覧(カスタムクエリ)

  • チケットの一覧で、フィルタオプション、ソート順(タイトルをクリック)を決めた後、保存します。
  • 0.9以降では、保存時にソート条件を3つまで指定できます。

[#TiDD] 出版裏話4:「チケット駆動開発+テスト工程管理のAtoZ」

来月発売の「Redmineによるタスクマネジメント実践技法」の表紙が翔泳社オンラインショップで公開されました。

TiDD book

表紙を見てお気づきのように、本のタイトルにならなかった「チケット駆動開発」という言葉が載っています。この「チケット駆動開発」という言葉には、私もあきぴーさんも思い入れがあり、本の内容の多くは「チケット駆動開発」が中心になりました。執筆開始当初は1部のタイトルも「BTSによるソフトウェア開発の作業管理」となっていたのですが、収まりが悪くなり、ついには「チケット駆動開発技法」となりました。

Redmineのチケットを使ってタスク管理する本としては前田さんの「入門Redmine」や倉貫さんらの「Redmine -もっと手軽にプロジェクト管理!」、ファーエンド株式会社の「オープンソースによるプロジェクト管理入門」があります。これらの本はいずれも良い本で、プロジェクトでRedmineを使う場合に非常に役立つと思います。

しかし、チケット駆動開発をさらに実践するには、チケット駆動開発の背景や歴史、アジャイル開発との関係、チケット駆動開発のプラクティス、Redmineのプラグイン、ツールとの連携など、さらに多くの知識が必要です。そこでこの本には、あきぴーさんと私の経験談をはじめ、多くのノウハウを詰め込みました

だからこそ、表紙に「チケット駆動開発」の文字が入っていることがとてもうれしいのです。

目次は以下のようになっています。

第1部 チケット駆動開発技法 ─BTSによる作業管理─
 第1章 障害管理ツール(BTS)
 第2章 BTSとツールの連携
 第3章 チケット駆動開発 .チケットによるタスク管理.
 第4章 チケット駆動開発(TiDD)のはじめかた

第2部 Redmine によるタスク管理
 第5章 Redmine の運用方法
 第6章 Redmine の高度な使い方
 第7章 チケット駆動開発の実践的な運用方法
 第8章 チケット駆動開発を発展させるアイデア

第3部 RedmineとTestLink の連携
 第9章 TestLink の運用方法

ブルーレイディーガDMR-BWT1100-KとシンプルリモコンDY-RM10

ついに買ってしまいました。地デジ対策にチューナ、ブルーレイ再生にPS3などと考えていましたが、ダビング10に未対応で家族が操作できないVARDIA RD-S300をTVチューナがわりとし、ブルーレイDIGAを買いました。3D対応ながら値段もこなれてきたほか、シンプルリモコンが使いやすいと聞いて決断しました。ちなみに我が家には3DTVはなく、国産最後(?)のハイビジョンブラウン管TV(TH-28D50V)での感想です。

ブルーレイディーガDMR-BWT1100-K

シンプルリモコンの使える新機種は6タイプありますが、ダブルチューナを選ぶと、3Dブルーレイが付いてきます。その中では無線LANの有無、容量、で3タイプに別れ、最上位のものはプレミアムタイプになっています。買い替えするとしても大きなTVは買わないし、有線LAN、小容量(といっても500GB)で十分ですので、このタイプを選びました(比較表)。

Diga1 奥行きはDVDケースサイズ

ダンボールに入った状態でそのコンパクトさに驚きましたが、出してみてびっくりです。DVDのケースの高さとDIGAの奥行きが同じです。VARDIA RD-S300と重ねてみると、一回り小さい程度ではなく、容積で1/3ぐらいです。

Diga2

セットアップは音声ガイド付き

セットアップを始めると、女性の声で説明してくれます。予想外だったので驚きました。説明中に操作すると、説明が止まる場合と、続ける場合があり、ここまで作りこんでいるのかと感心しました。

さすがブルーレイ

最初に見るべきDVDは「ダーククリスタル」と決めていたのですが、諸般の事情で「アバター」を見ました。ハイビジョンだから地デジやひかりTVぐらいだろうと思っていました。実際に見てみてその美しさに驚きました。帯域が広いからか、優れた回路が入っているからか、スカパーのパーフェクTV!とSky TVぐらいの差を感じました。

操作性はさすがDIGA

かつてのHS2に比べると画質の種類が増え、地デジもあるので複雑にはなっていますが、そこはDIGAです。こだわる人向けでなく、家電向けの操作性にうまくまとまっているように思いました。

Digarm シンプルリモコンDY-RM10

このリモコンはただのリモコンではありません。このリモコンを使うことで、DIGAの標準リモコンとは異なる画面が登場します。3000円以上しましたが、専用インタフェースソフトが付いていると考えると、高くはないでしょう。

これまで使っていたVARDIAはマニア向けのインタフェースが特徴で、家族に教えても操作を覚えてくれませんでした。ビデオを見るときは「見るナビ」を選べばよいのですが、メニューやらXXナビが多すぎて、おぼえる気にならなかったようです。ボタンを減らしたリモコンもあったのですが、ボタンを減らしただけだったので、使いやすいものではありませんでした。

このシンプルリモコンDY-RM10は、覚える必要がありません。ユーザインタフェースの設計では、既存の知識を利用して学習を容易にすることはあたり前ですが、このリモコンは

  • 知識でなく操作性

を使います。かつてのビデオデッキのようなイメージです。しかも、すべての操作が

  • トップダウンかつ手順的

ですので、覚える必要がないのです(ウィザード方式といえば伝わるでしょうか。ここに紹介があります)。これまでのように、

  • メニューや再生ボタンを押してもDVDに切り替わっていて、録画した番組が見れない。

とか、

  • 地デジを見るつもりがBSのままチャンネルを変えていた。

ということがありません。しかも、ビデオデッキのような操作性でありながら、予約の候補として番組名が表示されるので、間違いもありません。

ちょっと残念なところ

操作を簡単にするためだと思われますが、

  • シンプルリモコンではシンプルリモコンで予約した番組のみ再生できる

という仕様になっています。あらかじめ家族用に決めておいた番組ならそれでよいのですが、シーズンの途中から家族も見るようになった番組は、シンプルリモコンで予約をやり直さなくてはなりません。

あともう一点、

  • 昔のHS2は再生ボタンを押すと自動的にTVの入力切り替えをしてくれました

が、HDMIのTVが前提なのかできなくなっていました。標準のリモコンはTVの操作ができるので良いのですが、シンプルリモコンはTV操作できないのでチョット不便です。これは古いTVの我が家だからこその問題なのですが、良い製品だからこそ残念に感じるところです。

結論

予想以上です。大満足です。

追記

3D版アバターBDプレゼント中ですが、クラブパナソニックで製品番号を登録する際にFirefoxだとエラーになりました。IEだと大丈夫なようです。ご注意ください。

[#TiDD] チケット駆動開発は従来型開発とアジャイルの隙間を埋める

従来型のウォーターフォール開発アジャイル開発のWin-Winプロセスについて語ってきましたが、結論は20年以上前から変わっていません。

ソフトウェア開発に銀の弾丸はない(リンク先はWikipedia)ということです。暴れる狼男なら銀の弾丸を撃ち込めば撃退できますが、ソフトウェア開発に絶対のプロセスなどないのです。よりふさわしいプロセスを参考に、アプリケーションの要件、開発組織の文化、開発メンバーにあわせて、プロセスはテーラリングしなければならないのです。

これまでは、従来型の開発プロセスでは、ビジネスの変化、技術の変化、より高度な要求に答えるのは、難しいと思っていました。しかし、最近は顧客重視のマインドを持っているならチケット駆動開発で何とかなるのでは、と思っています。

もう、半年以上前のことになりますが、とある居酒屋であきぴーさんとチケット駆動開発を方法論にする方法を議論したことがあります。タスクを管理するだけでなく、ストーリーカードに相当する内容をどのようにチケットにするかを議論しました。その内容の一部はプログラマーの思索に載っています。

チケット駆動開発では、従来型のエビデンスを必要とするプロセスであっても、必要な情報をチケットやその関連として残しておくことで、既存のルールに対応できます。これまではアジャイル開発でないと難しかった、変化への対応やスコープの変更を支援してくれます。

かつてXPJUG関西でCMMIのプロセスに、XPをあてはめる努力がなされました(さかばも少しだけ参加しました)。チケット駆動開発は、そのようなアジャイルの実践が困難な組織での解決法の一つになりうると思っています。

チケット駆動開発は、このように従来型プロセスでの有効な開発法であると共に、アジャイル開発に様々なツールを取り込んでいく上でも役に立つものです。また、他組織と連携する際のコミュニケーションツールとして、Win-Winプロセスの実現にも役に立つでしょう。

アジャイルだとかウォーターフォールという2言論的な捕らえ方は、その概念が普及する上では役に立ちましたが、もうその時代は終わりつつあると思います。様々な開発法がある中で、どのようなプロセスで開発するか、具体的な実践技術が求められていると思います。

来月発売の「Redmineによるタスクマネジメント実践技法」では、そんな思いで従来型プロセス向けに、さかば担当で書いきました(あきぴーさんはアジャイル向けの部分を執筆されています。分量的にはあきぴーさんの執筆が大半です)。

Win-Winプロセス(アジャイル編)

アジャイル開発の場合でも、プロセスのテーラリング(カスタマイズ)は必要です。Win-Winを実現するには、以下のような点を考慮すべきだと思います。

1.あらかじめアーキテクチャの検討をする

規 模が大きくなる前に全体を統一できるアーキテクチャがあると、開発が進めやすくなります。アーキテクチャはいくらでも発展する余地があるので、シンプルか つ効果的なものを追求しないと、UNIXの反面教師になったMULTIXや、消えていった多くの基盤ソフトウェアのように肥大化してしまいます。とはい え、中途半端だと役に立ちませんので、バランスが大切です。

2.決定権のない人の意見には依存できない

決定権のない、あるいは、調整能力のない担当者が近くにいても手戻りが発生するので、担当者の意見に依存できません。そのような場合は、担当者の根回しが容易になるように、資料やプロトタイプを用意するほうが現実的です。

3.他組織と連携する場合は、リリースタイミングを同期させる

ハードチームとの連携、別業務との連携など、協調開発が必要な場合は、計画的なイテレーションが必要です。アジャイルリリーストレインやスクラムオブスクラム(リンク先はプログラマの思索)の考え方が参考になると思います。

4.必要なドキュメントを作成する

3の場合など、実装重視でインターフェースを作成するだけでなく、隠れた制約などは厳密に定義すべきです。無駄なドキュメントは良くないですが、必要なドキュメントは積極的に作るべきです。あまり体裁を気にしないことがポイントかもしれません。

5.微妙なアジャイルもある

全 体はウォーターフォールで製造工程だけをアジャイル開発で、という表現をたまに聞きますが、それは、変化がない中で技術要件のリスクを下げているだけなの で、分割リリースやプロトタイプじゃないのか、と思わなくもないです。ただし、UIの仕様決定や細かな仕様の調整などがあれば、アジャイルかもしれませ ん。

6.基本ポリシーを決めておく

イテレーション中の仕様変更をどうするかのポリシーが明確でないと、もうリリースが最後な のでどうしてもと言われると、無理をしてでも実現したくなります。また、イテレーションをいつ終わるかのポリシーがはっきりしていないと、いつまでも終わ らないイテレーションが終わらなくなります(内製ソフトなど、終わらなくて良いようなアプリケーションが向いているという考え方もできるかもしれませ ん)。

アジャイル開発には

  • 変化が前提
  • スコープで調整
  • 軽量プロセス

といった特徴が確かにあります。しかし、Win-WInプロセスを考えたなら、基にするプロセスの議論よりも、どのように効果的なプロセスにするか ということの方が、大切だと思います。ソフトウェアプロセスもソフトウェアであり、プロセスも実装が重要です。あらかじめきれいに作るのではなく、ある程 度見えてからリファクタリングしても良いのではないでしょうか。

そんな、Win-Winプロセスの実装にはケット駆動開発は非常に有効だと思っていますが、眠くなったので、また次回としたいと思います。

Win-Winプロセス(ウォータフォール編)追記

どんなプロセスがベースになっていようと、Win-Winプロセスはある程度可能だと思っています。

生き字引を目指していますので、これを機会に悪行を告白することにします。従来型(ウォーターフォール)プロセスをベースとする場合は、このような感じの事をしていました。

  • 技術的な課題、ユーザインタフェースの確認はプロトタイピングにより、問題をなくす。
  • アーキテクチャの開発は先行して行う。
  • 仕様未確定な部分があるとき、すべての機能を実装すれば納期に収まらないときは、分割リリースする
  • 開発環境やツールを用意・開発して、開発効率を高める
  • 変更の予想されるところは局所化し、最後に開発する。また、テーブル化、インタプリタ化する。
  • 可能なら詳細設計書は開発後に作成する。許されない、あるいは、問題が生じそうな場合は、なるべく開発につながるように作成する。
  • 仕様変更はQCD(スコープ、予算、スケジュール)を客先と調整する

そんなことを80年代から、やっていました。このようなことをやっていると、結構アジャイルに近いメリットを得ていたと思います。これがウォーターフォールかと問われると「どうなのでしょう」とも思いますが、ガチガチの管理主義の人からは悪行ではありますが、ソフトウェア工学で昔から言われていることを、あたり前にやっているに過ぎません。例えば、以下があげられます。

  • ウォーターフォールの期限といわれるロイス氏の論文などの議論(名古屋アジャイル勉強会)
  • ウォーターフォールがベースといわれるハンフリー氏の「プロセス成熟度の改善」(不安定な要求の節、スパイラルモデル)

(局所化の文献はすぐには思い浮かびませんが、昔から良くあるテクニックです)

まあ、そんなにするならアジャイルにすれば良いという意見もあるでしょうが、

  • 複数組織で並行開発が行いやすい
  • 外注が容易になる
  • 優秀なアジャイラーとは言えない要員が活用できる
  • 何より既存プロセスの変更がいらない

といったメリットがあります。最近なら、アジャイルと規律のように部分的にアジャイルを導入する方法もありますし、既存のプロセスにチケット駆動開発を導入すればアジリティを高めることができると思います。

アジャイルベースのWin-Winも書きたいのですが、風邪気味なのでやめておきます。

2010年9月23日追記:

「可能なら詳細設計書は開発後に作成する」とは、お客さんが説得できればという意味ではなく、次工程への前提でない*かつ*技術的に問題がないなければという意味です。詳細設計というのは会社や時代によって大きく異なります。80年代は200ステップ程度の関数がごろごろある時代で、上流で関数の外部仕様(インタフェース+機能)を定義しておいて、詳細設計ではステップとほぼ1対1のフローチャートやPADを書く企業などが存在していました。小規模な関数にきちんと分割していれば、詳細設計がなくても十分やっていける時代でした。

[iPhone4] 980円の手帳型ケース

あるところにはあるもので、iPhone4用の980円の手帳型ケースを買いました。

Case980

買ったのは大阪梅田のラジオショック、ドスパラのビルにあるちょっとディープなレア物系のショップです。イヤホンの4P->3P変換ケーブルが180円、予備バッテリーが1000円、iPhone 3Gのチープなケースが3百円代であるお店です。

操作性

カードの入っているところを折り返すと、なんとか右手でも操作できます。しかし、液晶面を覆っている部分が分厚いので、境界部分の上のタイトルバーなど片手操作がしにくくなります。

品質

展示サンプルはちょっと縫製が攣(つ)れたような感じがあったのですが、購入品はそうでもなかったです。外観はOK!値段以上と言えます。

その反面、カード部分の仕上がりがイマイチです。写真の白いカードが見える部分にICカードとPIT-Mobileを入れています。そこは特に問題はなかったのですが、上のカード入れのところに問題がありました。写真のカードは購入したままでは入りませんでした。どうも接着剤が必要以上に塗られていたようで、カードが引っかかりました。「ものさし」を中に入れて、ゴシゴシやって接着剤のかたまりが取り、すこし皮を伸ばすようにすると、薄いカードなら入るようになりました。

総合評価

全体の質感は高く、ICカードが入るので、満足しています。接着剤の件も楽しみのうちでしょう。液晶面が隠れますので、保護シートが不要になり、見やすくなりました。反面、片手操作はやりにくくなりました。ICカードを入れる必要のない人は、同店で縦開きタイプも980円でしたので、そちらが良いかもしれません。

[#TiDD] RedmineとTracの入力項目「バージョン」

あきぴーさんの「Agile開発の肝はイテレーションにあり」を読んで、Redmineがなぜバージョンとマイルストーンの区別がないかを考えてみました。

簡単に説明すると、Tracでは、マイルストーン単位でチケットが分類されますが、標準のクエリーではバージョン単位では分類されません。一方のRedmineは、ロードマップ画面でバージョン単位でチケットが分類されて表示されますが、マイルストーンは存在しません。その違いに気付かずに、あきぴーさんはTracでのチケット駆動開発ベースのアジャイル開発がうまく行かなかったとのこと。

マイルストーンというのは基準点ですから、実際には一次リリースなどの「マイルストーンまでの作業」で分類するということなのでしょう。一方の「バージョン」とは、RedmineにしろTracにしろBTS(障害管理システム)ですので障害の発生したプログラムのバージョンのことです。

では、バージョンとは何かというと、構成管理ツールによって扱いが異なります。

Subversion以前のCVSやRCS、SCCS(古い!)などは、ファイル単位のバージョン管理です。なのでBTSにバージョンとあれば、バグの発生したアプリのバージョンか、バグの入っていたファイルのバージョンでしょう。そのように大きすぎる単位、あるいは、細かすぎる単位というのは、プロジェクト全体の管理対象としては扱いにくいので、Tracなどではマイルストーンが用意され、「どのマイルストーンまでの作業であるか」を管理しているのでしょう。

Subversionなら、管理対象全体(チェンジセット)で共通のバージョンを持っています。SubversionのバージョンをBTSに記入することは開発中の状態、つまり「どのマイルストーンまでの作業であるか」をも表すことになります。Redmineは、そのようなバージョンの概念であればマイルストーンがなくても十分だと考えたのでしょうね。

そんな風に想像しましたが、実際のところはどうなのでしょうか?ご存知の方がおられたら教えてください。

アジャイルかWFかの議論はやめよう。大切なのはWin-Winの実現

ソフトウェア開発はお客さまあってのもの。これだけ社会の変化が激しければ、仕様が変わっても仕方がない。直接変化がなくても、短期間の商品化を実現するために並行開発を推し進めるなら、予想外のこともあって当然だろう。

中間であれ、最終であれ、リリース後に変更を受け入れれば、複数リリースになる。また、リリース前であっても、最初のリリーススケジュールの変更なしに機能追加をするなら、一度にすべてをリリースできなくなるので、これも複数リリースになる。

このように、変更を受け入れるとリリースが複数になり、結果的にアジャイルの定義としてよく言われる繰り返し開発になる。

アジャイルの定義には、このほかにも要求が変化した際にリリース時期をずらさずに、スコープを変更すると言われることがある。これも、アジャイルだけの話ではない。

開発の予算があらかじめ決められていることは、よくあることである。大きな会社なら普通のことと言っても良いだろう(予備費を取っておいたり、別の予算を回すということはあるだろうが、それは別予算のプロジェクトを実施すると考えても良いだろう)。

予算が限定されていれば、2つの方法しかない、外注先に無理を言うか、優先度の低い機能を減らしてスコープを変更することだ。

このように考えると、仕様変更を受け入れるとアジャイルの要素が生まれる。もっと言うなら、仕様変更の発生時のプロセスを形式化、軽量化して、変化を前提にしたものがアジャイル開発ということになる。

このように、アジャイルと従来型の開発に切れ目はない。あらかじめどれだけ見込んでおくかということと、繰り返しの期間の長短だけである(それも、アジャイルと呼んでも良い境界を示せといわれると難しい)。

大切なのは、お互いにWin-Winの関係でいられるように、顧客満足度を高める計画が立てられるかどうかだと思う。

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

[#TiDD] プラクティスにあだたぬチケット駆動開発

坂本龍馬が脱藩したとき、「土佐にあだたぬやつ」と評されたそうです。あだたぬとは、「収まりきらない」という意味です。

チケット駆動開発に対して「チケットでタスクを管理する」だけと考える方も多いでしょう。しかし、プラクティスというものは、目的の定まった解決法です。チケット駆動開発は昨日の記事のように

  • 開発者の能力を最大限に引き出す

という目的のほか、

  • コミュニケーションの潤滑化
  • 履歴の保存・管理
  • 仕様変更の管理を厳密化する
  • バージョン間の同期を取る
  • 進捗のリアルタイム管理
  • 定量的なデータ収集基盤

などなど、運用方法によって多くの目的を実現できます。

チケット駆動開発はソフトウェア開発の基盤プロセスであり、多くの目的を達成できる方法論なのです。

[#TiDD] チケット駆動開発を開発のツールとするために

リーダーの重要な仕事の一つは

「与えられた人的リソースで最大限の効果を出すこと」

だと思います。

チケット駆動開発はその意味で、リーダの仕事を支援します。もちろん、チケット駆動開発はプロジェクト管理を容易にしますが、それは副次的な効果です。

チケット駆動開発は、開発現場から生まれた方法論です。ふさわしい運用をすれば、効率の良い開発を実現できます。

ふさわしい運用とは、プロジェクトによって異なります。XP祭り関西2010で発表した分類で言うと、

  • 開発メンバーの能力が高く、自由な雰囲気の方が能力を発揮するなら、チケットの発行やクローズが誰でも可能な「オープン型」
  • 一貫性などワークフローで解決すべき問題が重要な場合には、権限を厳密にした「ワークフロー型」を限定的に実施する

が、ふさわしいでしょう。このほか、開発者の意見を生かしてプロセス改善をするには「ふりかえり」の実施が有効です。プロセス改善によって、開発者のストレスも低減するでしょう。

チケット駆動開発を管理のツールとして考えると、使い勝手が悪くなりがちです。現場で生まれた開発のツールである点を重視して、ふさわしい運用を実施したなら、開発者の能力を最大限に引き出して、効率的なプロジェクト運営が実現できると思います。

[#TiDD] 出版裏話3:中堅技術者向けのRedmine&TiDDの本

来月発売の「Redmineによるタスクマネジメント実践技法」を書く際には、中堅の技術者を対象としました。

中堅というのは、こんな感じの方です。

・自分で調べ、考えて、行動できる
・ヒントやきっかけがあれば、自分で発展させて考えられる
・何かを得たいと考えている

そこで、以下のように構成しました。

・まどろっこしいチュートリアルはない
BitNami :: RedmineRedmineLEなどすぐに使える方法を示し、インストールは説明しない
・基本的な考え方やキーワードは盛りだくさん

このようにして、濃い内容の本にしたのですが、それでもあふれたので泣く泣く章単位で削除もしました。

この本は、あきぴーさんの人脈で、多くの有名人にレビューしていただいたことも特徴です。当初、中堅技術者向けということで、いきなり専門用語がたくさんでてくるなど、多くのご指摘をいただいて書き直しました。そんなこんなで、近頃にない濃い本になっているつもりです。

なんか、裏話ではなく宣伝になってしまいました。すみません。

[#TiDD] まさかのカテゴリ1位「Redmineによるタスクマネジメント実践技法」

来月発売の「Redmineによるタスクマネジメント実践技法」が、瞬間最大風速ながら、アマゾンのコンピュータサイエンスのランキングで1位を記録しました。ご予約いただいた皆様、ありがとうございました。

Amazon

発売前ながら、多くの予約をしていただけるということは、Redmine人気のおかげという側面もあると思いますが、チケット駆動開発や、近頃少なくなった実践的な書籍にも需要があると言うことだと思います。

[#TiDD] 出版裏話2:大人の事情で「タスクマネジメント」

来月発売の「Redmineによるタスクマネジメント実践技法」のタイトルには、チケット駆動開発という言葉が入る予定でした。

しかし、出版社によると「XX駆動開発」には食傷気味だとのこと。googleで検索すると
「駆動開発」に関連する検索キーワードにはチケット駆動開発以外に

テスト駆動開発、モデル駆動開発、ビヘイビア駆動開発、ドメイン駆動開発、振舞駆動開発、ユースケース駆動開発、ページ駆動開発、煩悩駆動開発、ユーザー機能駆動開発

など重複や良く分からないものもありますが、モデル駆動開発やユーザー機能駆動開発(FDD)などは有名ですね。そんなこともありましたし、チケット駆動開発は私も最初は良く分からなかったぐらいですから、別の名称を考えました。

普通に考えるなら「プロセス改善」「プロジェクト管理」という言葉が選ばれるのでしょう。しかし、チケット駆動開発はこれらにキーワードの内容も含まれますが、トップダウンの管理だけでなく、個人のタスクの管理を中心にボトムアップにプロジェクトが運営され、プロセスが改善していく点が特徴です。ちょっとイメージがあいませんでした。

また、チケット駆動開発はプロジェクトのアジリティを高めますし、アジャイル開発とも親和性が高い(リンク先はまちゅダイアリー)ので「アジャイル」なども候補でしたが、チケット駆動開発はアジャイルだけでなく通常の開発でも有効であること、なによりアジャイルの本が多く、これも食傷気味ということから、採用されませんでした。

ということで、「タスクマネジメント」という言葉になりました。チケット駆動開発はタスク管理だけではないもののイメージしやすく、管理的なイメージよりも技術的なイメージで「開発現場で生まれた方法論」の雰囲気を感じてもらえればと「タスクマネジメント」としました。いかがでしょうか?

[TiDD] 出版裏話1:没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -

来月発売の「Redmineによるタスクマネジメント実践技法」の「はじめに」は、実は第2バージョンです。

最初の「はじめに」は、若干ドラマ仕立てになっていました。

1.チケット駆動開発を始めて聞いたときは「ネタ」だと思ってたこと
2.あきぴーさんが「アジャイルがわかった!」と興奮していたこと
3.実際にやってみると良かったこと

と書いていたのです。

しかし、あきぴーさんに確認したところ、たぶん2の「興奮」という描写についてだと思いますが、かなり脚色が入っていることもあって「恥ずかしい」とのこと。力作はあえなく「ボツ」になりました。

このボツ原稿の内容で、書いておきたいのは、

  なぜ「チケット駆動開発」と言うのか

ということです。例えば、こんな名称も考えられるでしょう。

・チケット・ベースド・マネージメント
・BTSによるプロジェクト管理
・タスクカードの電子化

本当のところは提唱者のまちゅさんに聞かなければわかりませんが、ライトニングトークなので、若干のウケ狙いでもあったのかも知れません。今一度、まちゅさんのチケット駆動開発の最初の発表を見てみると、チケットが障害管理、構成管理、コミュニケーションや作業分担、進捗管理の中心になっていて

・チケット中心開発

と言ても良さそうな印象も受けます。実際、あきぴーさんとSPES論文を書く際には「チケット駆動開発」以外の名前を検討するべく提案しました。

しかし、あきぴーさんの答えは明確で「チケット駆動開発」は譲れないとのこと。当事は、しぶしぶながら承諾しましたが、この理由は、のちに私がチケット駆動開発を実践してみて、ようやく分かたのでした。それは

  チケットがプロジェクトをテンポ良く推進してくれる

ということです。本の中では「リズム」と言う表現をしていますが、チケット駆動開発を実践していると、

 朝:チケット一覧を見て、作業計画を立てる
 昼:チケットの作業を順にこなしていく
 夕:チケットの進捗を登録する(完了チケットのクローズ)

という、開発パターンに体がなじんで、プロジェクトがリズミカルに進んでいきます。これは、体験してみないと分からない感覚でした(もし、チケット駆動開発を実践しているのに感じられないなら、備忘録のような細かなチケットをもっと発行してみてください)。

この「リズム」を感じる個人のプロセスは、チケット駆動開発のアジリティとも関係する大切なものです。ぜひ、チケット駆動開発を実践して体験してみてください。

[TiDD] 速報!史上初の「チケット駆動開発」の本が出版に

来月、いよいよチケット駆動開発の本が出版されます。そのタイトルは

  「Redmineによるタスクマネジメント実践技法」

です。大人の事情でタイトルにこそ入っていませんが、表紙にはしっかりと「チケット駆動開発」の文字が入る予定です。まだ1ヶ月ほど先になりますが、すでにAmazonでは予約受付されています。

この本は、チケット駆動開発に関して精力的に活動されているあきぴーさんの多くの実践ノウハウを中心に、私(さかば)と共著で書きました。もちろん良書の条件を満たすべく、チケット駆動開発の歴史や背景も書いています。もちろん、Redmineのノウハウも詰まっていますし、TestLinkも説明しています。

中堅の技術者をイメージして書いていますので、近頃にない内容の濃い本になっています。目次は以下のようになっています。ご期待ください。

第1部 チケット駆動開発技法 ─BTSによる作業管理─
 第1章 障害管理ツール(BTS)
 第2章 BTSとツールの連携
 第3章 チケット駆動開発 .チケットによるタスク管理.
 第4章 チケット駆動開発(TiDD)のはじめかた

第2部 Redmine によるタスク管理
 第5章 Redmine の運用方法
 第6章 Redmine の高度な使い方
 第7章 チケット駆動開発の実践的な運用方法
 第8章 チケット駆動開発を発展させるアイデア

第3部 RedmineとTestLink の連携
 第9章 TestLink の運用方法

[TiDD] チケット駆動開発によるプロジェクトの活性化

SPI Japan 2010でチケット駆動開発の体験談

「チケット駆動開発によるプロジェクトの活性化 - 見える化と運用ポリシーがプロジェクトを変えた -」

を発表します。ご興味のある方はぜひお越しください。

これから作成するスライドはJASPICで公開されますし、後日公開するつもりですが、ひとまず応募した内容をslideshareに置きました。

[TiDD] 制約とチケット駆動開発

前回は、ソフトウェア工学の歴史が、ソフトウェア開発に制約を与えることで高品質なソフトウェアの開発を実現してきたと説明しました。今回は、チケット駆動開発がこれまでの技術と同じように、ソフトウェア開発に制約を与えることで高品質なソフトウェアの開発を実現するものの、これまでの技術とは異なる特徴のあることを説明します。

それは、コミュニケーションに制約を与える点です。もちろん、

こともチケット駆動開発の特徴ですが、ワークフローや作業指示の形式化によって、新しい制約を与えることは他にない特徴です。

チケット駆動開発(TiDD)は「No ticket! No commit!」つまり、チケットのないソース更新は許さないという基本ルールも「制約」ですが、あきぴーさんと共著のSQiPの論文(PDF)に書いたように、ソースコードの2重管理をワークフローによって間違いなく実施することが可能です。このワークフローは、チケット駆動開発がコミュニケーションに与えるもっとも大きな制約と言えるでしょう。

このように書くと、チケット駆動開発は厳しい制約によって、形式的なコミュニケーションを与えるものだと思われる方もあると思います。しかし、XP祭り関西で発表したように、それはチケット駆動開発の管理方法によって変わるものです。

チケット駆動開発のもう一つの制約は、チケットそのものです。作業指示を口頭からチケットに形式化するという制約を与えることで、

  • 言葉ではうまく指示できない場合も、明確に指示できる
  • チケットは公開されているので、人に見られる前提で対応する

という2つの効果が現れます。このことを利用すれば組織体制にそった正常な業務の運用が可能になります。具体的には

  • 作業分担の混乱(押し付け合いや譲り合いによるデッドロック)が生じにくくなる
  • 遠慮がちな指導者も明確な指示ができる

というメリットが生まれます。11月のSPI Japanではそのような(XP祭り関西で紹介した)プロジェクトの背景について紹介する予定です。

ところで、チケット駆動開発による見える化に関しては、さらなる期待もあります。トレーサビリティの確保ができるほか、作業のエビデンスにもなるので、信頼感の向上や裁判対策といったStagEプロジェクトが狙っているような成果が期待できると思います。

また、チケットを上流から使うことができれば、CMMIで求められるトレーサビリティマトリクスをチケット間の関係から作成できるのではないか、などと妄想しています。

[#TiDD] 良いソフトウェアを作るためのメトリクス

私は駆け出しのプログラマーだった頃に結婚しました。式の最中に、司会をお願いした友人から「どのような仕事がしたいか?」と突然質問されました。ふと出た言葉が「だれもが使いたくなるようなプログラムが作りたい」でした。ソフトウェア開発は「超マシン誕生」のように無から有を作り出すセクシーな仕事だと思いますし、今も良いソフトウェアを作りたいと思っています。

昨日の記事「リスクベーステストを考える」を書きながらも変なことを書いている気がしていました。今日になってJSTQBのサイトなどを眺めながら思ったのは、

「テストは品質保証という管理行為であり、(今のところ)信頼性の底上げに重点が置かれている」

ということでした。これは、私の学んだソフトウェア工学にも感じていた違和感です。

もちろん、ユーザビリティテスティングもありますし、各種レビューによって良いソフトウェアを作る努力はされていますが、フィードバックでなくフィードフォワード、つまり作りこむことが大切だと思うのです。

テストやソフトウェア工学の技術は重要ですし、間違っているとも思いません。しかし、現場で作りこむ技術がどうも少ないように思います。これは、製造を外注していることや、そもそもソフトウェアの価値はユーザにとっての価値であることによるのでしょう。

もちろん、やっているところではきちんと作りこみが行われているのでしょうけど、その技術があまり出てこない。ノウハウとして隠しているのなら良いのですが、標準プロセスで定めれたゴールを目指して汲々としているのが現状ではないでしょうか?

製品としての品質や、リスクベースの合理的な品質も大切です。しかし、開発者に必要なのは、自分の開発結果を明らかにする見える化です。その意味でfailure(障害、結果)ではなくfault(欠陥、原因)のデータで管理がしたいと思ったわけです。

さて、昨日はこのfaultのデータを収集するには、試験項目の結果に対して、マージや分割が必要だと書きました。しかし、構成管理上の更新(バージョン)を、仕様変更と障害に分けることができればよいことに気付きました。チケット駆動開発を行っていれば、チケットの簡単なルールを定めるだけで、簡単に集められそうです。


リスクベーステストを考える

リスクベーステストとは、リスクの大きい部分を重点的にテストする方法です。

 リスク=影響×発生確率

ですので、予想される被害が最も少なくなるようなテスト技法と言えるかもしれません。

しかし、合理的なテスト方法ではあるものの、本来すべき必要最低限のテストを行わずにテストを手抜きすることにつながってしまう可能性も感じてしまいます。

昨日、SEA関西の勉強会で「セーフウェア」を輪講していて、その答えを見つけたような気がしました。この本の中では、一般的なソフトウェア工学の言葉の定義でもある

 エラー(error): 欠陥の元になる間違い
 欠陥(fault)  : プログラムの誤り(原因)
 障害(failure): 欠陥によって生じた正常でない動作・状態(結果)

    *引用ではなく、分かりやすい表現にしています。異なる和訳もあります。

が説明されています。そして、リスクとはハザードと事故との関係と定義されており、

 ハザードレベル:ハザードの過酷度、ハザードの起こりやすさ
 ハザードの暴露:ハザードにさらされること(あるいは継続時間)
 ハザードが事故に至る可能性

の3つがあげられ、広い意味でリスクが使われていました。ハザードとは

「事故をもたらしうるシステムの状態または一定の条件」

なので、ハザードレベルとは原因(fault)のリスク、事故に至る可能性とは結果(failure)のリスク(の確率)といえると思います。このように、リスクに関してもfaultとfailureに分けて考えられるのだと思いました。

そこで、最初の議論に戻って考えると、

・リスクベーステストのリスクとはfailureのリスク
・必要最低限のテストの目的はfaultの軽減

ではないかと思いました。つまり、リスクベーステストはリリース後に起こりうる被害を最小限にする方法であり、failureの影響度と発生確率で語られるべきものである。最低限のテストを考えるならfaultをベースに考えるべきで、品質は規模あたりのfaultで語られるべきではないかと思いました。人間は一定の比率でエラーを起こすと考えられるので、エラーによって生じるfaultを管理することで、最低限の品質が確保できると考えられるからです。

ここで、現場の品質がfailureで管理されていることが気になりました。テスト項目が不合格と言うのは一般にfailureあり、その規模あたりの比率と人間の発生するエラー確率とは必ずしも比例しないと思います。同一のfaultによるものは束ねて、複数のfaultによるものは分けて、規模あたりのfaultの比率で管理すべきかもしれません。

これまでのテストは、faultに基づくべき最低限の品質とfailureに基づく被害を考慮した品質をまぜて考えていたので、結果的に実用的な品質が確保されてうまく行っていたのでしょう。しかし、リスクベーステストを導入するのであれば、効率化と最低限の品質の維持を両立するために、他のテストはfaultベースで管理した方が良いかもしれません。

高品質であれば、fault数≒failure数になるような気もしますので、要らぬ心配かもしれませんが、、、

« 2010年8月 | トップページ | 2010年10月 »