DevLove HangarFlight -SpringBomb-

とある会社のTrac事情～不具合管理からタスク管理へ

DevLOVE HangarFlight - Spring Bomb -

始める前に


質問です


Trac


redmine


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


注意事項!

�この発表は私の所属する

特定の団体

特定の企業

を代表したものではありません。

�この発表は私見に基づくものであり、

実践の結果について保証しません。

�過去、あるいは現在においてたまたま実

在する人物、団体、出来事と類似してい

るかもしれませんが、それは偶然です。


本日のアジェンダ

�自己紹介

�今に至る歴史と事例

�おわりに


自己紹介


Shibuya.tracから来ました


かぬhttp://d.hatena.ne.jp/kanu-orz

http://twitter.com/kanu_


職種は管理職


最近は基本的にプロダクトコードは書いてません


初めて見るよ?


ネット上の知名度は


ある日Twitter上でのやりとり


・・・


非常に丁寧なお返事が・・・


□谷さん


って説明されるぐらいの


知名度ですw


そんな私ですが、一応・・・


KanonとTracLightningのコミッタやってます


訂正


Kanon

は

ラボメン

厨二病を患ってます


次に出すTracLightning 3.1.2(かな?)のリリース担当です


DevLoveとはCIの時に


さぼてんまんさん


を受けて


hud美http://d.hatena.ne.jp/kanu-orz/20090803/1249225200

注：絵師は私でなく虎塚氏です。


なことして、絡みましたが


でも実は


初参加！


初登壇！


やさしくしてくださいやさしくしてくださいやさしくしてくださいやさしくしてください

http://www.flickr.com/photos/66263770@N00/124555575/


自己紹介は

ここまで

ながい


1.Excelから脱却


2004年頃の話です。


関係会社に籍を置いて、

顧客向けサービスの発注元として

自社の開発部隊とやりとりしてました。


ある日のこと・・・


開発とExcelのやりとりが

面倒だから何とかしたい！


何とかしたかったこと

� 週に一度の進捗報告が嫌

� 伝えた不具合の修正進捗が知りたい。

� 不具合票をExcelで書いてメールで送るのが嫌

� 更に一覧表と単票のダブルメンテが嫌

� 今の残案件の状況が把握したい。


そこで見つけたのが影舞

� 特徴

� Rubyで動く

� RoRではない

� DB不要

� MySQL/PostgreSQL

� 簡単設置

� Apache+mod_rubyでOK

� 起票するとメールが飛ぶ


自由になるApacheがあったので

即採用決定


発注元としては非常に便利だったので

自社復帰するまで使ってました


2.出逢い


2006年に自社に復帰

発注する側から、される側へ


開発してた後輩が一言


良いよ良いよって、

めっちゃ勧めますけど

実は結構大変なんすよ

注：画像はイメージです。後輩はヤンキーではありません


影舞の問題点

� メールの延長でしかない

� 修正したコードと不具合が紐付かない

� 影舞の記録から修正対象が漏れる

� cvsのバージョン番号書くルールにしてました。

� 修正対象をデプロイし忘れる

� 工数管理が面倒(事実上不能)

� 項目は追加できるが、集計はExcel

� 入力が面倒だし忘れる

� 要望や不具合の集計が面倒


変わる何かを・・・

� 調べた結果(2006年7月当時)

� Bugzilla� Mozillaのバグトラッキングシステム

� 超有名

� Scarab� Java製のバグトラッキングシステム

� 日本語書籍もある

� Mantis� PHP製のバグトラッキングシステム

� 日本語のサイトが充実していた。

� CSV/Word/Excel形式での出力が可能

� CVSとの連携も可能


充実したサイト豊富な統計資料

Excel,Wordでの出力CVSとの連携


Mantisに決め掛けてましたが・・・


自由になるサーバも無くApache/PHP/MySQL

を入れる先が無かったので保留(入れるのがめんどくさそう)


AllAllAllAll----InInInIn----One One One One TracTracTracTrac



AllAllAllAll----InInInIn----One One One One TracTracTracTracのののの特徴特徴特徴特徴� 楽々インストール� Windowsインストーラで簡単インストール

� 楽な認証設定� Apacheの.htaccessを利用した

Trac/Subversionの一括認証

� 使いやすいコマンド� Apache/Trac/Subversionをラップした

コマンド群が提供

� クライアントソフトが同梱� Subversionを利用するための

TortoiseSVN/Subclipse/Ankhsvnが同梱

� Subversionのドキュメントが同梱� 「Subversionによるバージョン管理」が梱包


でもでもでもでも・・・・・・・・・・・・� All-In-One Tracは

� バージョンが0.9

� 既に0.10がリリースされていた

� 同梱のSQLiteが一世代前だった

� 作業時間を記録するプラグインが動かない

� プラグインが沢山あるのは発見したが・・・

� 使いたいものの殆どが動かない(涙)(2007年の時点でさえ)


別れ


結局、Pythonから入れて

一から0.10の環境を構築(安定的に動かすまで一ヶ月くらい・・・)


頑張って構築したのに

ひと月後にTrac月の登場(現在のTracLightning)


構築構築構築構築のののの際考慮際考慮際考慮際考慮したことしたことしたことしたこと� コミットしたらチケットに内容が反映すること

� 影舞では漏れることも多かった、修正内容と要求の関連付けの自動化

� ソースと不具合票の両面からのトレーサビリティの確保

� 作業時間の集積の簡素化� コミット時にコミットコメントに作業時間を

入れることによって作業負荷の軽減を測る。

� 報告の負荷の軽減� 機能追加を含めた進捗の確認をチケットで行う

� チケットから各種報告書を出力することより、管理部門からの要求されていたExcel作成の廃除


3.部署での展開


担当してたシステムの機能追加ラッシュが終わり、開発主体の部署から保守メインの部隊へ異動・・・


インシデント・問い合わせ管理

� 単票の問合せシートを起票

� エクセルで送られてきたり

� 電話・メールを元に自分で書いたり

� 月に一度、社内報告

� 問合せ一覧

� 保守作業実績一覧

� 作業時間の突き合わせ

� 作業時間と作業管理システムの時間突き合わせ


問合せシート� 問合せシート

� 良くあるエクセル

� 作業報告書兼用


問合せ一覧

� 問合せシートをマクロ+手で転記


作業実績一覧� 保守作業実績一覧


最大の問題点


対象システム


約システム


一覧作成と

実績の集計に


丸1日!(労務系のシステムとの突き合わせ含む)


orz


2007年4月


保守サポートの一元化


保守サポートデスク業務の一元化

� 内容

� 一次受付(電話・メール)を輪番制にする

� 必要だったこと

� 一次受付の一元管理

� 問合せに関する顛末管理

� 問合せする作業時間管理

� 問合せ情報の共有


やらないか？


必要なことの殆どをTracで実現

� 保守サポートデスク業務の一元化

� 問合せに関する顛末管理

� 問合せに関するする作業時間管理

� 問合せ情報の共有

� 保守部隊のポータル

� 対象システムの情報集積

� 各種know-howの公開


作業実績 (現行版)

� 対応時間、件数の

推移グラフの表示

� ReportIncludeプラグイン利用

� 価値の追求

� 対比がしやすい

� 時期的な傾向の把握が容易


4.本丸


開発部隊への展開


保守を中心に展開するうちに幾つかのことに気付きました


気づき

� 不具合や問い合わせは重要度を加味した、優先順位順にチケットを処理する

� 追加開発や派生開発についても日常の不具合チケットに混じって作業する。


もやもや


「masuidrive的プロジェクトの方針」がオレンジニュースで取り上げられる


masuidrive的プロジェクトの方針http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/

� 全てはSubversionで管理し変更履歴を残す

� 口頭で依頼があってもチケットがないと受けない

� 議事録や仕様はすべてWikiに書く


なるほど全部チケットでいいじゃん!


だったら実践！

� Excel → Ticket

� 管理者(PM)が確認してチマチマExcel直さない

� 作業者自身が進捗更新

� 成果物がある場合は、コミット時にリンク

� チケットから成果物が確認できる

� 開発ドキュメントもSubversionへ

� TortoiseSVNを使えば簡単コミット

� Excel/Wordの変更差分も見られる


が、見事に普及に失敗！


失敗原因

� Tracのマイストーンの表示

� レポートでの進捗把握の難しさ

� マイルストーンはシンプルすぎるのでレポートでと思ったがタスクの一覧での把握は難しかった。

� 進捗を推し量るのは、やはりガントチャート

� 二重メンテは辛いとの声


で、対策


こんな感じ


バーンダウンチャート


現在は・・・


タスク数のバーンダウン


見積もり時間と作業時間のバーダウン


各チャートの数字化


マイルストーン


ごく最近使ってるパターン


ガントチャートは・・・


ガントチャート


良いですね、ガントチャートw


このページは意図的に空白になっています


これらを実施しながら全プロジェクトで常識になるまでに


3年


最後に


大事なこと

Photo by Joe Shlabotnik (CC)http://www.flickr.com/photos/joeshlabotnik/3461132240/


道具を使うことが目的ではありません


本来の価値を生む作業に

集中するために使うのが道具です


価値あるシステムを継続的に

顧客へ提供し続けることが


開発者のミッションです


計画を適切に見直すことで、

持続可能なペースを保ちましょう


道具に使われるのではなく

道具を上手く使って


価値を生むこと

推し量ることに

注力しましょう


顧客も開発者も

共に

幸せになれるように...


もしも道に迷ったら



チケット駆動開発宣言

私たちは、ソフトウェア開発の実践あるいは実践を私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。見つけだそうとしている。この活動を通して、私たちは以下の価値に至ったこの活動を通して、私たちは以下の価値に至った ::

#1#1 共用フォルダーよりも共用フォルダーよりもバージョン管理システムバージョン管理システムをを

#2#2 口頭による指示よりも口頭による指示よりもチケットでの依頼チケットでの依頼をを

#3#3 個人のドキュメントよりも個人のドキュメントよりも wikiwikiでの協調での協調をを

#4#4 書き直すよりもを書き直すよりもを他人の褌で相撲他人の褌で相撲をを

価値とする。すなわち、左記のことがらに価値があることを価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。認めながらも、私たちは右記のことがらにより価値をおく。


ご参考


可視化に使っている主なプラグイン



� TimingAndEstimation

� 時間の積算用

� タイムトラッキング

� 可視化に当たっての基本的なプラグイン

� Web-Query UIコンポーネント

� Queryの結果の数字部分の中合計大合計が表示されるようになります。

http://trac-hacks.org/wiki/TimingAndEstimationPlugin



� QueryChart

� チケットのステータス変動の日付の記録

� 日付を元にバーンダウン/アップチャートの表示http://weekbuild.sakura.ne.jp/trac/wiki/TracDoc/QueryChart

� ReportInclude

� TracReportをWikiに表示させるためのプラグイン

� Ticket/Milestone/Report などで利用可能

� Reportだけではなくグラフの表示も可能

� 棒グラフ/積み上げ棒グラフ/折れ線グラフhttp://fr.sourceforge.jp/projects/shibuya-trac/wiki/plugins%2FReportIncludePlugin



� ExtendedVersion

� Milestoneをversionでまとめる為のプラグイン

� MilestoneをTimeBox化して利用する際に、全体を見渡すのに非常に便利。

� 表示の形式はMilestoneとほぼ同じ

http://trac-hacks.org/wiki/ExtendedVersionPlugin

Technology

DevLove HangarFlight -SpringBomb-