チケット駆動開発のアンチパターンpart2 - プログラマの思索
チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは
チケット駆動開発はツールによる改善か、プロセスによる改善なのか - プログラマの思索
チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？ それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の
redmine勉強会に参加してきました−実践redmineカテゴリ設計にご用心 - かたるほどでもない技術系ブログ
redmine勉強会に参加してきました。 会場を提供してくれたトライコーン株式会社ありがとうございます。 実は、自分の会社から１０分ぐらいというご近所さん。今回はとっても楽でしたー 不謹慎にも、次回のredmine勉強会もトライコーンさんで・・・なんて期待をしてしまいます。 とりあえず、自分のメモをコピペ。 意外と長いので、セッションごとに分割します。 最初のプレゼンは、id:yandodさん 資料は、こちらです しっかし、プレゼンの様子も動画で提供されるし、資料も公開されているから細かいメモはほとんど不要ですね。 でも、昔の癖が抜けないので細かいメモがたくさん。 たまたまこのページにたどり着いてしまった人は他の人のページをみましょう（苦笑）。 はじめに 簡単な紹介はたくさんある 実際の利用例は見ててこない redmineを使うとどうなるのか 世論を形成する気概で redmineの基礎 柔
チケット駆動開発の運用例 - プログラマの思索
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
