無料ブログはココログ

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

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

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

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

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

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

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

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

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

<')))><

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

と。

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

<')))><

[TiDD] BTSによるコミュニケーションの効率化

BTS(Bug Tracking Tool)は、その名のとおり障害を管理するツールですが、その効果を考えるとコミュニケーションツールと言えるほど、プロジェクトのコミュニケーションを効率化します。

BTSを用いると、どのような状況にあるかを一覧で確認できるのは紙やエクセルで管理しているのと同じです。大きく異なるのは、メールやRSSで最新情報が通知できる点です。

まず、エクセルで管理している場合を考えましょう。大体こんな感じでしょうか?

1) 障害を発見する
2) 障害票を作成する
3) 上司に報告する
4) 担当者に連絡される
5) 欠陥が除去される
6) 障害票に追記される
7) 再確認
8) 完了

一連の流れにどのくらいかかっているでしょうか。仮に3の上司への報告が朝会などだと1日や2日はかかりそうですね。特に別グループの不具合だと調整に時間がかかり、その不具合に関係するテストは中断して、別の作業をしないといけないでしょうね。

実は現在私が管理しているプロジェクトでは、同じことが起きかねない状況でした。少人数の2つのグループに分かれて作業をしていたのですが、席の配置の関係でどうもコミュニケーションが悪い。見ているとメンバー間のコミュニケーションがIP Messenger中心で、グループでもプロジェクトでもなく、個人間で情報共有が行われていました。仲が悪くはないのですが、全員の一体感がない状況でした。

そこで、開発者全員のメーリングリスト(ML)を作成して、共有すべき情報はMLに流すようにしました。少しはコミュニケーションが改善したようですが、グループ間の調整になると、グループ長であるサブリーダを介して行われていました。

そして、いよいよシステムテストが迫ってきました。これまでの類似プロジェクトでは、エクセルで障害管理され、ファイル共有されていました。でも、上記のような流れで作業すると他グループの不具合の解決に、1日以上かかる危険性がある。これは危険です。

もう悩むことはありません。社内でtrac環境を支援してくれていましたので、それを使いました。ある程度はメール文化がありましたので、どんな障害でも強制的に全員に配布するようにしました。

効果は突然現れました。それは、ある障害が別グループの問題で発生したときのことです。私が障害通知のメールを見たときは、上記の1から4までに相当する作業が完了し、グループ内で打ち合わせがすでに行われていました。そして、障害通知から20分もしない間に問題は解決され、障害対応は完了しました。

簡単な設定の問題でしたが、この問題が解決しないとシステムテストが継続できなくなり、グループミーティングを経て、作業の入れ替えをする必要がありました。たとえ10分の打ち合わせであっても人数分の工数がかかります。2つのグループの打ち合わせ、サブリーダ2人の打ち合わせ、それが早くて半日、下手をすると2日欠けて行われるのです。考えるだけで恐ろしくなります。エクセルにしなくて本当に良かったと思いました。

<')))><

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