賢者はRedmineを使い、愚者はSpredsheetを使う

こんにちは、空飛ぶRedmine教団の末端信徒、kappaLabです。最近ようやく拙僧がjoinしているプロジェクトがRedmineベースに移行され、SpredSheetと縁を切る事ができそうです。

タスクの作成から、担当者/優先度/期日の設定、仕様の策定など諸々をRedmine上に集約して運用してます。まーどこでも普通にやってる事を普通にやろうぜって話なんですが、やっとここまできました。

では今までどうやっていたのか、何が悪かったのか、以下に列挙しましょう。



  • タスクをSpredSheetで一覧化、各自修正

  • 上記リストにステータスや、期日を記載

  • タスクに関する仕様は別途SpredSheetを用意(いいのそれで?)

  • 上記リストにカラム追加、仕様のurl記載

  • 上記リストにカラム追加、チケットのurl記載(なんの冗談?)

  • 上記リストをQAチームに投げて動作検証

  • QAチームから動作項目明記しろってクレーム(当たり前)

  • 上記リストにカラム追加、動作項目記載(どこまでいくんだ)

  • 上記リストにカラム追加、不具合項目記載(もうやめて)

  • 差し戻った上記リストはもちろんカオス

みたいな感じ。このフローを持ってマネジメントとほざくPMは万死に値するだろう。

これ、全部Redmineでやればいいから。なんならTracでも良いから。QAもデベロッパーもデザイナーもみんな不幸になるから。


チケットドリブン


ではどうやってSpredSheet地獄から抜け出したかというと、単純にチケットを切って、情報を集約させただけ。

例えば、PMから「進捗をSpredSheetに記載してちょ」と依頼があったら、「チケットみてちょ」と返す。(決して記入してはならない)

あるいはデザイナーから「画像名どうしたらいい?」と聞かれたら「#xxxのチケットに記載してるよ」と返す。(決してチャットで返信してはならない)

あるいはPMから「QAへの確認事項一覧を(ry」と依頼があったら、「確認事項のチケットまとめたチケット作ったから、そのままQAに投げれば良いよ」と返す。

スケジュールに関してはガントチャート見れば良いし、次期バージョンの機能一覧とかリリースノートはロードマップに記載すれば良い。


とまあ、そんな感じでRedmineの権化の様に過ごしていたら、少しずつRedimineベースというかチケットドリブン開発っぽくなってきた。


ちなみに、開発会社によっては(特に大手SIerとか?)チケットの消化数で個人の人事評価につながる場合もある。このKPI測定みたいなやり方が良いか悪いかはともかくとして、一つの目安にはなるだろう。

また、過去に参加したPJでは、議題を設定してMTGを行い、承認を得る事でタスク完了としてKPIを測定、チーム内でマンスリーのMVPを選出していた。これは完全にチケットでやるべきだったな、と今にして思う。

さらに、とある大規模開発では、子会社のQA専門会社に数百件あまりの「確認待ち」チケットを投げた際、「経験則からn%のチケットは差し戻しになる、従って現状のリリーススケジュールは全く現実的ではない」と返答があったらしい。これには舌を巻いた。


賢者は歴史に学び、愚者は経験に学ぶ

表題はご存知オットー・フォン・ビスマルクの格言である(今ググったけどね)。ところで歴史はしばし改竄される。当然ビスマルクさんもそんな事は百も承知で、直訳は以下の通りだ。


愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

wikipedia


これには二つの教訓が含まれていると思っている。

  • 主観的事実より、第三者視点(客観的事実と言い換えたい)から学べ
  • 前例を有効活用しろ、既出の失敗を繰り返したり車輪の再発明をするな


客観的事実に関しては先に述べたQA専門会社からの「経験則からn%のチケット〜」が好例だ。我々は自らのチケットおよびスケジュールの信頼性を他者(QA専門会社)の経験と知見によって審査する事ができたからだ。

車輪の再発明に関しては、既存のソリューション使えばいいです。もちろん、冗長だったり、かゆいところもあるでしょう。完全なフィットは望めないと思います。

でもね、多くの場合は独自方法の構築と学習コストより、既存ソリューションの導入の方がコストパフォーマンスが良いはずです。新しく入ってきたチームメンバーもキャッチアップしやすくなります。むやみに「ぼくのかんがえたさいきょうのマネジメント方法(もちろんSpredSheetさ!)」を導入すんなって話です。


まとめ

長々と書いてきたけど、注意すべきはたった二点。

  • 情報の集約
  • 既存システムの有効活用

これだけだ。念のため断っておくがRedmineに拘る必要はなくて、情報を一カ所にまとめて運用できるシステムがあればなんでもいいと思ってる。個人的にはgithub/gitlabが今後、どこまで開発管理機能を搭載するかに興味がある。

Trackback

http://memo.kappa-lab.com/mt-tb.cgi/359

Leave your comment :

(いままで、ここでコメントしたことがないときは、コメントを表示する前に承認が必要になることがあります。そのときはしばらくお待ちください。)




RSS + Contuct

  • rss
  • email

Credit

Copyright (C) 2007 kappa-lab.com.
All Rights Reserved.