無料ブログはココログ

« リーンを考える - 無駄と必要なアソビ - | トップページ | 自動化による信頼性向上 - オブジェクト指向とアジャイル開発 - »

[#TiDD] カードかチケットか、タスクボードかBTSか

アナログが良いかデジタルが良いか、そんな答えはありません。それぞれに長所も短所もあります。プロセスは各プロジェクトで異なるので、必要な方法を実施すれば良いのです。

大切なのは、今のプロジェクトの問題が何で、その解決法は何かという事です。以下にタスクカードなどのアナログのカードと、チケット駆動開発(TiDD)で用いられるBTSのチケットの特性をまとめました(BTSではなく他のタスク管理ツールでもおおまかな傾向は同様でしょう)。

カード チケット
コミュニケーション 自然と目に入る リモート、リアルタイム
情報量 壁は大きなタスクボード 膨大な情報の検索と表示
起票の容易さ 簡単 工夫が必要
履歴の利用 困難 容易
情報交換の方法 話し合い中心 文字中心
作業配分 分担的 やや分業的


コミュニケーション

カードの特徴はタスクボードなどに貼られる事で、自然と目に入って情報共有できる事です。アナログ情報は大まかな情報認識に有利で、今どのような状況にあるか大まかに知る事ができます。

チケットは意識的に見る必要がありますが、更新の通知を常に利用するツール、例えば、メール、webブラウザなどのrssリーダー、プラグインによるEclipseへの通知などによって、日常的に確認する事ができます。また、物理的なボードは使いませんので分散開発であっても利用する事ができます。

情報量

タスクボードにホワイトボードを使うと物理的な制限があります。しかし、壁を利用する事ができたなら物理的な制限があまり気にならないでしょう。タスクボードは情報を提供するだけでなく、コミュニケーションの場を提供します。昔の喫煙室のように何気ない「うまく行ってるようだね」「大変そうだね」から始まる状況の確認、苦労話、ノウハウなど情報交換が行えます。以前紹介したXP祭り関西2012の田口さんの発表(Spring of Wisdom − XP祭り関西2012(3))では、複数チーム間でそれを実現されています。タスクボード物理的制約に縛られますが、その制約を除ければ大きな可能性があるのです。

一方のチケットには物理的な制限がなく、様々な検索や表示が可能です。緊急度の高い作業や個人の作業の検索やキーワードの検索、マイルストーン単位の一覧やガントチャートでの表示も可能です。

起票の容易さ

多くの方が、カードの起票が容易であると言われます。手書きで主な情報だけを書く事ができるからです。すべてのタスクのカードを作るなら、明らかに有利でしょう。

チケットの記入は時間がかかるというほどではありませんが、後々参照される者ですからきちんと書いておく必要があります。しかし、あまりにも同じようなチケットばかりだとやる気がなくなってしまいます。そこで、上流においては共通で利用するチケットを用意したり、あまり厳密に構成管理と関連付けない様にします。

履歴の利用

カードにおいても写真を撮る事である程度は履歴を管理できます。カードのデータを電子化してから印刷するようにすれば電子データを残す事ができますが、文字や書き方でパッとわかるというアナログの良さが半減してしまいます。

チケットであれば議論も残せますし、構成管理とも連携して記録できますので、非常に効果的です。先日ご紹介した赤羽根さんのIT統制のお話は、とても良い応用例だと思います。

情報交換の方法

カードを作成する際には多くの情報交換が行われ、ゴールが共有されます。カードでは多数決のような決定も行われますが、まず情報交換が行われて多くの決定が進められます。しかし、意見を主張する事が苦手な人もいます。

チケットには電子化によるコーチング的な効果があるので、ある程度緩和される可能性があります。

作業配分

カードの起票や管理は基本的にチームで行われ、各人のコミットメントに従って作業が分担されていきます。アジャイル開発の目指しているサーバント・リーダーシップの発揮しやすい環境です。

チケットを用いる理由の一つとして、ワークフローがあります。作業者の役割ごとに権限を分けて、チケットの状態を遷移させる人を限定するのです。この方法は作業の一部を分業する事になります。管理的ならないように気をつけるべきでしょう。

おわりに

コミュニティで経験談を聞いていると、チケット駆動開発から始めてアナログなアジャイル開発に進んだ例を聞く事があります。

アジャイル開発に比べると物理的な制約が少なくて導入が容易なチケット駆動開発から初めて、アジャイル開発の成果を上げた上で、アナログのメリットを把握した上で、アナログなアジャイル開発に移行されるでしょう。もし、分散拠点での開発や管理上の理由、メンバーの適正など、チケット駆動開発の必然性のあるプロジェクトであったなら、ずっとチケット開発を続けられたでしょう。

最近、アナログなアジャイル開発が実現する「自律的で攻撃的な開発」で成功されている組織の、ある特徴に気づいきました。このような組織は、積極的な経営を実施し、元気な人を集めているイノベーティブな企業が多いのではないでしょうか?それがすべての企業に当てはまるかどうかは、十分に検討する必要があるでしょう。

もちろん、どのような会社も自律的で攻撃的な開発を目指すことで、新しいマーケットが生まれるかもしれません。しかし、アジャイルサムライに書かれているように、アナログなアジャイル開発をすべての人が気に入るとは限りません。組織に既に居る人に合わせた、よりふさわしいプロセスを用意する方が効果的ではないでしょうか。

今回書いたチケット駆動開発の本には、チケット駆動開発のバリエーションを踏まえてテーラリングについて書きました。アジャイル開発を導入する場合にも、組織やマーケットに会わせたテーラリングが必要だと思っています。

« リーンを考える - 無駄と必要なアソビ - | トップページ | 自動化による信頼性向上 - オブジェクト指向とアジャイル開発 - »

チケット駆動開発」カテゴリの記事

コメント

なるほど、良いところ悪いところを検討する必要がありますね。

この記事へのコメントは終了しました。

« リーンを考える - 無駄と必要なアソビ - | トップページ | 自動化による信頼性向上 - オブジェクト指向とアジャイル開発 - »