チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
八朔さんによるチケット駆動開発の運用例をメモ。 【元ネタ】 チケット駆動開発 - Live a meaningful Life プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。 プロマネらしく、チケットの構造が上手だと思う。 このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。 【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。 アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。 顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。 そうでなければ、開発者が作業するレベルにならないからだ。 後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落
6. 『チケット駆動開発』とは？ チケット駆動開発 (ticket-driven development; TiDD) とは、 プログラム開発手法の一種。 作業をタスクに分割しBTSのチケットに割り当てて管理 を行う開発スタイル。 参考：http://ja.wikipedia.org/wiki/チケット駆動開発 7. チケット？ 「行うべき作業」を記録したもの。 例： 「○○画面設計」 「△△バッチの不具合の修正」 「●●環境で動作するか検証」 ステータスあり。 開始日・終了日あり。 担当者欄あり。 見積もり工数を入れるのも可。 8. チケット『駆動』？ その１ 「はじめにチケットありき。」 「チケットなしの作業禁止。」 チケットがない作業は闇作業。 「チケットなしのコミット禁止。」 チケットがないコミットは闇コミット。 チケットにより作業のインプット・原因・「なぜ」を 明確にする。 作業
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Redmineのリビジョン 2711 についにチケットをグループ化する機能が追加された。 似たようなプラグインも開発者の有志からパッチが提供されている。 【チケット一覧にグループ機能】 Redmine - Feature #2679: Ticket grouping Redmine - リビジョン 2711 Features: * Issues/Ticket grouping * Introduced queries categories, and grouping by them in sidebar * Queries in sidebar now shows count of issues in they * Group saving in queries 【チケットをグループ化するプラグイン】 Redmine - Ticket grouping plugin 上記の機能を見ると、右
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
Redmineでチケット駆動開発を始めて、チケットの発生源について考えてみた。 以下ラフなメモ書き。 【1】チケット駆動開発では、タスクをチケットに起票してから作業を始める。 イテレーションに含まれるチケットは限界があるから、１イテレーションで実現できる機能は限定される。 しかし、１イテレーションに入り切らないぐらい膨大なタスクが発生する時がある。 そうなってしまうと、もはやチケット駆動開発だろうがアジャイル開発だろうが、タスクは発散しがちでプロジェクトは壊れた飛行機のようにふらついているだろう。 そうならないために、プロジェクトリーダーは、チケットの発生源をいつも気にする必要がある。 チケットの発生源はタスクの発生源であるから、タスクを増やさないためには何を処方したらよいか、というリスク管理につながる。 【2】チケットの発生源は、SW開発の工程によって異なる。 例えば、動くプログラムも無
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 Martin Fowler's Bliki in Japanese - 支払利息の見積もり PERFORCE ソフトウェア構成管理の高度な実践方法（ベストプラクティス） 【1】登録したチケットを分割するタイミングがある。 WBSから初期スケジュールを作成した時、機能追加だけの実装内容のチケットの工数は3人日を見積もったとする。 しかし、実際にチケットを担当した開発者の実績は5人日をオーバーする時がある。 何故遅延しているのか、開発者に聞いてみると、機能追加する前のリファクタリングに時間がかかっている。 理由は、元々のソースはロジックが余りにも入り組んでいるため、リファクタリングしないと機能追加できないから、と言う。 そんな時、僕は、そのチケットからリファクタリングだけの目的の別チケットを新規登録し、リファクタリングは別チケット
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く