先日、2013/3/23(土)に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください(※アトラシアン製品関連のイベントです)。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS(Bug Tracking Syste
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ~チケット管理システム大決戦 第二弾~で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
開発チームとしてやるべき事は、大きなものから小さなものまで全てTracのチケットに放り込んで作業を進めている。目的は下記の通り。 作業量の顕在化 チケットの更新状況を見れば、チームとしてどんな作業を進めており、どのくらいの分量が残っているのか一目瞭然だ。 作業遅延の顕在化 各チケットには期日があるし、タイムラインにはチケットの更新状況が出てくるので、作業が予定通りに進んでいるのか、遅れているのか直ぐに分かる。 作業漏れの顕在化 やるべき事は全てチケットに入っているはずだが、ふとした会話の中で、これ以外に問題が見つかることが珍しくない。このような誰にも気付かれずに存在していた問題こそが対処を要するものだ。 チケットに記載するということは「やるべき事を明確に定義する」という事に他ならない。「仕事をする」ということは実際のところ曖昧模糊としていて「やるべき事を忘れていた」とか「誰かの作業がいつの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く