【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine - プログラマの思索
【公開】第4回品川Redmine勉強会資料「チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ(ベータ版)」 #47redmine 本日行われた第4回品川Redmine勉強会の発表資料をCCアトリビューションライセンスで公開します。 スタッフの皆さん、参加者の皆さん、お疲れ様でした。 第4回shinagawa.redmine勉強会 : ATND 今僕が考えている「チケット駆動開発をパターン言語で表現できるか」という問題に対して、勉強会のお題「チケットの粒度」「チケットの完了条件」について当てはめると、どれだけ本質に迫れるか、考えた結果を話しました。 内容は完成版でないし、解法は一つではないです。 オープンディスカッションの前座として、どれだけ皆の議論を引き出せるか、という観点で話しました。 オープンディスカッションでは7チームで議論してもらった結果、白熱したチームもあれば、違
Redmineでチケット駆動開発をAgileに運用するための4つの方法 - プログラマの思索
Redmineでチケット駆動開発をAgileに運用するための方法をもう一度まとめておく。 あくまでも僕の一意見なので参考までに。 【参考】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【Redmineでチケット駆動開発をAgileに運用するための4つの方法】 (1)RedmineチケットをXPのタスクカードのように扱う (Ticket
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？ - プログラマの思索
チケット駆動開発を運用していると話すと、必ず「チケットの粒度はどれくらいが妥当ですか？」という質問が来る。 僕はまだその質問に完全な回答は持っていない。 その質問について考えていることをメモ。 【1】RedmineやTracで、全てのタスクからQAまでチケットを起票してから作業を始めるようにすると、チケットの粒度がかなり細かくなってしまう。 粒度が小さいと作業しやすいが、チケットの完了速度よりもチケットの登録速度が上回ってしまう時が多いため、どんどんタスクが増えていってしまうような感覚に陥ってしまう。 かと言って、チケットの工数が5人日以上になってしまうと、進捗がはかどっているのかどうかも分からない。 チケットの粒度が問題になる状況は、顧客へ進捗報告を出したい時だ。 RedmineやTracによるチケット管理はあくまでも開発者のためのタスク管理が目的だから、粒度が細かすぎて、顧客から見れば
【公開】デブサミ2011講演資料「チケット駆動開発～タスクマネジメントからAgile開発へ」 #devsumi #tidd - プログラマの思索
【公開】デブサミ2011講演資料「チケット駆動開発～タスクマネジメントからAgile開発へ」 #devsumi #tidd デブサミ2011で講演してきました。 聞きに来てくれた方にはありがとうございました。 発表資料「チケット駆動開発～タスクマネジメントからAgile開発へ」をCC Attribution ライセンスで公開します。 【参考】 創発 未来につながるために 世界に帆を立てるために Developers Summit 2011 デブサミ2011【17-B-3】チケット駆動開発～タスクマネジメントからAgile開発へ～ 小川明彦 氏 / 阪井誠 氏 - Togetterまとめ デブサミ2011【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac ?ユーザーが語る、なぜ私はこのツールを使うのか 鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏
TracやMantisによるチケット駆動開発の運用方法 - プログラマの思索
最近、RedmineではなくてTracやMantisを使う機会が多い。 チケット駆動開発をTracやMantisで運用する方法について考えたことをメモ。 【チケット駆動開発を運用する時の注意点】 Redmineでなくても、TracやMantisでもチケットをXPのタスクカードのように扱うことはできる。 BTSのチケット管理をプロジェクト管理に置き換える発想は、Redmineの場合と変わらない。 しかし、Redmineに比べると、TracやMantisによるチケット駆動開発とAgile開発を組み合わせて運用するためには、いくつかのノウハウが必要だ。 僕の経験では、Redmineに比べるとTracやMantisは、イテレーション管理とSCM連携がやりにくい。 【1】Agile開発の基本である小規模リリースを実現するには、イテレーションをBTSに実装しなければならない。 Redmineなら、バー
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
チケット駆動開発のアンチパターンpart2 - プログラマの思索
チケット駆動開発のアンチパターンで気付いたものを更に追記しておく。 【元ネタ】 チケット駆動開発のアンチパターン: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】メトリクスの罠 RedmineやTracでは、いくらでもチケット集計結果からメトリクスを得られる。 管理者はついつい、そのメトリクスで実績評価して、メンバーのモチベーションを下げてしまいがち。 メトリクスは万能ではない。 メトリクスだけではプロジェクトの現状を把握できないのが現実だ。 メンバーの表情、各種の成果物、など色んな観点から、プロジェクトの現状が定まっている。 いくらメトリクスが悪くても今改善途中かもしれないし、メトリクスが良くても実はメトリクスを改ざんしているのかもしれない。 メトリクスはバッドノウハウの塊。過信しない方がいい。 【2】問合せは
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
チケット駆動開発はツールによる改善か、プロセスによる改善なのか - プログラマの思索
チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？ それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の
チケット駆動開発の運用例 - プログラマの思索
チケット駆動開発の記事があったのでメモ。 【元ネタ1】 チケットで工数管理(Shibuya.trac 2009新年会 発表資料) - almost nearly dead kanu_orzさんによるTracのチケット管理の運用例。 インシデント管理や問題管理にTracを下記で運用していると思われる。 ・チケットをExcelで一括インポート ・Tracで工数を入力、集計 ・チケット集計結果をExcelで出力 特徴としては、Trac上で日々の作業の実績管理は行うが、作業の元ネタである大量のチケットはプラグインで一括インポートしたり、月次報告用の工数集計などの結果をExcelで出力している。 これは、いわゆるエンドユーザコンピューティングかもしれない。 つまり、Trac上に日々の作業と言うトランザクションを溜めていくが、マスタ(ここではチケット)の作りこみや、溜まったトランザクションから定期的に
チケット駆動開発はプロセス改善を含む - プログラマの思索
チケット駆動開発を運用してみて、チケット駆動開発と朝会・ふりかえりは相性がよいことに気付いた。 以下メモ書き。 【元ネタ】 朝会について - sakuramateo. 朝会のパターン：立ってるだけじゃないよ プロジェクトファシリテーション実践編：朝会ガイド 初めてのプロジェクトリーダー（6） 「ふりかえり」でプロジェクトを改善する オブジェクト倶楽部の「プロジェクトファシリテーション 実践編 ふりかえりガイド」 【1】駄目な開発チームは、コミュニケーションが無い。 例えば、開発者はPCに座ったまま、一言も喋らずに黙々と作業するだけ。 設計から開発と単体テストまで順調であっても、結合テストで必ず火を噴く。 その時に、お互いのプログラムのインターフェイスが合っていないことが判明して、たくさんのバグが出て、そして収拾がつかなくなる。 責任のなすりあいに陥ったりする。 そういうチームは、フィードバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
