無料ブログはココログ

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

[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性

プロセスモデリングの目的は、プロセスを他の人に示し、伝達し、教育することです。また、モデルを元に問題点を明らかにして改善することができます。また、シミュレーションによる予測も可能になります。チケット駆動開発におけるBTSのチケットは、タスクの計画であり、履歴です。この情報は非常に価値のあるものです。

近年、注目されている研究分野にリポジトリマイニングというものがあります。リポジトリとはソフトウェアの開発基盤のデータのことです。具体的には構成管理ツール、障害管理ツール(BTS)、メールサーバなどのデータを分析する研究です。ソースコードのメトリクスを元に障害の含まれていそうな(フォルトプローン)モジュールを探す。構成管理ツールのコミット履歴から、別の障害と関連(ロジカルカップリング)するモジュールを探す。あるいは障害履歴からプロジェクトの今後の予測を行う。など、多くの研究が行われています。

1990年代半ばにプロセスモデリングの研究が盛んなころ、タスクの分割や新たなタスクの追加、あるいはタスクの削除などはプロセスの動的な変更と呼ばれ、それをどのようにモデリングするかが研究の対象でした。そのゴールはシミュレーションでしたので、すべてを記述できる必要があったのです。

しかし、記述力やシミュレーションといった研究を目的とした場合、実際の履歴データを利用する際に変換が必要です。なにか機械的に変換できる方法があればよいのですが、そもそも履歴を収集する方法がありませんでした。

プロセスの動的な変更にはノウハウの素が詰まっています。プロセスを動的に変更するということは、何らかの計画外の事象が発生したということで、追加されたタスクはその解決法と予想できるからです。

かつて私は、この動的な変更を収集しようと試みたことがあります。その際はデータを収集するために週報をすべて読んで、手作業で収集しました。

多くのノウハウを得ることができましたが、いつ使われるかわからないノウハウ収集を日常的に実施することは現実的ではありませんでした。

ところがチケット駆動開発をしていると仮定したなら、すべてのタスクはチケットに記録されています。さらに原因となった問題のほか、解決に至る議論、そして解決法を実践した具体的な成果であるソースコードに関連付けられています。

それらはノウハウそのものです。しかも、それらを無理に変換する必要はなく、利用可能です。知りたいノウハウがあれば、そのキーワードを元に開発中に発行されたチケットを検索すればよいのです。それだけで過去の課題や議論、具体的なソースコードまで入手できるのです。

貴重なデータを入手できるようになるのですから、研究的には色々と可能性が考えられます。チケット駆動開発のリポジトリは研究に必要な情報が記録されていて、マイニングの対象として向いていると言えるでしょう。そして、その研究成果はプロセスモデリングが目指していた課題にも生かせます。

このように、チケット駆動開発が今後のプロセスモデリングの研究を大きく変えることになる可能性を感じています。

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



[#TiDD] チケット駆動開発はプラクティス?プロセス?それともアジャイル?

チケット駆動開発はプラクティスですか?プロセスですか?アジャイル開発ですか?

そういった疑問を抱かれる方もおられるでしょう。この答えは人によって違います。これをテスト駆動開発(TDD)の例を使って説明してみましょう。

テスト駆動開発はJUnitを用いて開発する方法(プラクティス)です。実行コードを書く前にテストコードを書くことで、テストが実行された実行可能なコードを徐々に増やしていく方法です。テスト駆動開発は従来型の開発においても有効で、多くの開発現場で利用されています。

ここで、JUnitがCIツールの機能が追加されたことをイメージしてください。JeninsのようなCIツールは、TDDの単体レベルのテストを常に実行できるほか、結合テストや静的解析、デプロイまでできます。もちろん、従来型の開発においても有効ですが、アジャイル開発の様に繰り返して開発やリリースを行うことで、より効果を実感することができるでしょう。このようにツールが多機能になればなるほど、プラクティスというよりもプロセスに近くなります。

これと同じ混乱がチケット駆動開発にもあります。チケット駆動開発はBTSのチケットを利用してタスクを管理する方法です。このチケットは構成管理ツールと関連付けられています。

ここまでの説明は比較的単純です。しかし、実践してみると、チケットの利用だけを捉えても、WBSとして利用も可能ですし、それをガントチャートで示すこともできます。

個人の忘備録としても使えますし、本来の機能であるプロジェクトの課題や不具合を管理することもできます。また、一覧はタスクボードですし、バーンダウンチャートを示すプラグインもあります。

さらに便利なことに、BTSには複数回のリリースを想定したマイルストーンやバージョンと呼ばれる属性があります。

このように、チケット駆動開発は従来法からアジャイル開発に至るまで、様々な利用が可能です。このため、プロセスを補完するプラクティスでもありますし、プロセスの根幹をなす仕組みとしても利用可能なのです。

さらに、アジャイルの定義は人それぞれです。もちろんアジャイル宣言がアジャイルの定義であることは誰もが認められるところです。しかし、アジャイル宣言の背景にあるものを満たしていれば、必ずしもすべてを満たしていなくてもアジャイル開発と呼ばれているのが現実でしょう。

そこにもまた幅があり、ユーザへの価値の提供、ビジネスモデル、オフェンシブな開発、さらにはソウル、ロック、パッションという言葉でアジャイルを語る方もおられます。このような幅がアジャイルの議論を混乱させる要因ではありますが、この幅こそがアジャイルのすそ野を広げることになっているとも思います。

チケット駆動開発をどう定義するか、それは難しい問題ですが、必ずしも解決しなくてよい問題だと思います。できればそのままに広く情報交換して、それぞれのプロジェクトにふさわしい形でチケット駆動開発が実践できるようになればと思っています。

[#TiDD] プロジェクトを成功に導くチケット駆動開発のビジョン

巷では「ソフトウェア開発では○○%のプロジェクトが失敗している」と言うことが語られることがあります。ありがちな成功の定義では、QCD、つまり、品質が高く不具合の数が見積もり以下、予算内で収まる、納期までにリリースできる、といったところでしょうか。請負開発はもちろんのこと、準委託であっても、予め計画される場合ならば、発注元の観点からはこのような基準かもしれません。

一方、アジャイル開発では顧客の価値を生み出すことが目的ですから、より顧客のビジネスに利益をもたらせるソフトウェアをリリースできたか、信頼性ではなく広い意味の品質という意味のQとして、より良いQCDのバランスが取れたかどうかによって、成功を判定すべきでしょう。

しかし、これらの成功の基準はプロジェクトをブラックボックスとして見た場合のものです。実際のプロジェクト(開発の現場であるリーダーやメンバ)にとっての成功とは必ずしも一致しません。プロジェクトの成功とは、開発者の能力を最大限に発揮できたかどうかではないでしょうか?

この「開発者の能力を最大限に発揮する」というのは、プロジェクトファシリテーションの目的そのものですが、チケット駆動開発の求めているものもこれだと思っています。

成功したプロジェクトを見ていると、そこに共通するチケット駆動開発のビジョンがあると思います。それは、ツールの導入や型にはめるのが目的ではなく、プロジェクトの問題を明確にした上で、ツールを道具としてふさわしいプロジェクトを目指していることだと思います。

チケット駆動開発の導入によってできることは、だいたい以下のようなものでしょう。

・プロセスの自動化(チケットと更新の関連付け)
・プロセスに制約を加える(ワークフロー)
・オンライン化による情報共有とコミュニケーションの迅速化
・問題点とゴールの見える化による安心感の増加(バージョンやマイルストーン)
・変更の節目を作ることによる作業への集中

これらをどのように取り入れるか、そこにはとても大切な視点があります。一つは、上述のようにプロジェクトの問題を明確にして解決することです。その際に重要なもう一つの視点は、オスターワイル氏が言ったように「プロセスはソフトウェア」であると考えることです。コードをレビューするときの様に、シンプルでわかりやすく、論理的かつ合理的で、必要不可欠なものでなくてはなりません。運用ルールを決めたり、場合によっては今までの文化に合わせることも必要かもしれません。

つまり、開発者を疲弊させず楽にする、単純な仕組みでリズムを与える、割り込みをコントロールする、不安感を減らしてゴールを明確にする、運用ルールを明確にして作業に集中できる、そんなプロセスを実現すること、それが大切なビジョンだと思います。


[#TiDD] アナログ重視のアジャイルとチケット駆動開発の違い #RxTstudy

Redmineとタスクマネジメントの勉強会であるRxTstudy第3回勉強会に参加しました。

「Redmineプラグインの作り方(仮)」:@agilekawabataさん
残念ながら懇親会費の集計やお釣りの準備などで、川端さんプラグインのお話はあまり聞けませんでしたが、キチンとフックを使ってプラグインが完成したようです。あとでお勉強しようと思います。

webサイト「Redmine.JP」 4年4ヶ月: 前田 剛さん
2番目の前田さんは、私も色々とお世話になっているRedmine.jpというサイトのお話でした。アンオフィシャルではありますが、多くのRedmineユーザがお世話になっていると思います。 nanocというテキストベースのCMSで管理されているそうです。Redmineの普及とともにドンドン稼いでいただいて、今後もさらに良いサイトにしていただきたいと思います。

Backlog の開発で大事にしていること:@tksmdさん
どのようにより良いUiを作るか、「仕事を楽しくして何が悪い!」と、どのように開発者の能力を発揮させるかという熱い発表でした。技術者として、より良いものを作るという姿勢がうらやましく思えました。発表の中でサブタスキングの要望に対して、説明できないものは導入しないとの姿勢でしたが、Rubyの松本さんの名言「ある種の制約は自由を増す」という側面もあるのではないかと思いました。

チームにRedmineを適用せよ:@daipresents 藤原 大さん
先日も品川Redmineで発表された藤原さんですが、今回は別の内容でお話ししていただけました。今回は品川で、疑問だったRedmineのタスク管理をやめてアナログにされたことについて、ヒントをいただきました。Scrumを進めているうちに、Redmineのチケットがの更新が負担なったこと、タスクは2-3日ぐらいの粒度にそろえているというお話でした。あと、Doingのチケットは2枚までにされているとのことでした。

メリットから考えるアジャイルとチケット開発の違い

チケットの粒度は良く議論されるところです。私は細かなチケットがBTSへの依存を増し、仕事のミスを減らしてくれると思っています。XPJUG関西で議論した際も、チケットは付箋、備忘録のように使う、という議論がありました。これは、ライフハックのGTD(リンク先はWikipedia)のような考え方です。作業の大きさではなく、リスクに気付けば、チケットを切り、プロジェクトのリスクを共有していく開発法だと思っています。

一方、Scrumのようなアナログ重視のアジャイル開発ではタスクの粒度をそろえて、プロジェクト全体を見渡せるようにします。プロジェクト全体でゴールを共有し、作業を進めていきます。

チケットあるいはタスクカードの粒度を除けば同じようなことをしているのですが、重視するものが違うように思います。タスク(チケット)の粒度をそろえられるということは、そこに含まれる細かな問題は把握されていることがある程度前提とされていると思います。つまり経験値の高い熟練者なのでできると思います。もちろん、細かな問題はあるでしょうから、それは、それは早めに小さく失敗するということなのでしょう。

一方のチケット駆動開発は、そんなに安心できない未経験なことが多く発生するプロジェクトに有効です。わからないことが多いから気付いた人がチケットを登録し、問題点をを皆で共有し、協力します。これは次々と色々なアプリケーションを色々な環境で開発する独立系の会社や、新規性の高い戦略的な開発などに有効なのかもしれません。

この辺りは懇親会で皆さんと議論していたところなのですが、残念ながら藤原さんとはあまりお話しできなかったので、いつか議論させていただきたいと思います。

Agile Japan 2012でお話しします。

さて、3月16日(金)に大阪のATCホールでAgile Japan 2012が開催されます。これまでAgile Japanは東京で開催され、大阪はサテライトの扱いでしたが、今年は初めて大阪で開催されます(RxTstudyも後援してます)。

この中のセッション「チケット駆動開発の課題と展望」で、小川(あきぴー)さん、中村 洋さんと共にお話しさせていただきます。チケット駆動開発の背景にあるビジョンについてお話しするつもりですので、今回の議論にも少し触れると思います。

なお、今回のキーノートスピーカーは、アジャイルサムライのJonathan Rasmussonさんです。ぜひお越しください。 


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