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
を入れる先が無かったので保留
(入れるのがめんどくさそう)


All-In-
All-In-One Trac


All-In-
All-In-One Tracの特徴
Tracの
楽々インストール
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 共用フォルダーよりもバージョン管理システムを
#2 口頭による指示よりもチケットでの依頼を
#3 個人のドキュメントよりも wikiでの協調を
#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


DevLove HangarFlight -SpringBomb-

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie DevLove HangarFlight -SpringBomb-

Ähnlich wie DevLove HangarFlight -SpringBomb- (20)

Mehr von Kanu orz

Mehr von Kanu orz (9)

DevLove HangarFlight -SpringBomb-