TiDD初心者から必ず聞かれる質問～「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine - プログラマの思索
「チケットの粒度」と「チケットの完了条件」は、TiDD初心者から必ず聞かれる質問だ。 チケット駆動開発を実践している人なら、周囲からいつもこの質問に対して受け答えしていないだろうか？ 【参考】 第4回勉強会 - shinagawa.redmine 第4回shinagawa.redmine勉強会 : ATND チケット駆動開発のアンチパターンの事例: プログラマの思索 チケット駆動開発を上手に運用するためのポイント: プログラマの思索 プロジェクトマネージャが抱えるプロジェクト管理の問題: プログラマの思索 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索 【1】「チケットの粒度」は、チケットの作り方に悩んでいる人に多い。 チケットが大きすぎると、進捗状況を把握しにくいし開発のリズムも出ない。 現場リーダーがWBSからチケットへ作業を登録する時、1～2
Redmine運用メモ
[ Redmine index ] Redmine運用メモ Redmineを、単なるバグ管理システムとしてではなく、開発作業（いわゆるチケット駆動開発）に使った経験から思うところをメモに残すページ。 前提 プロジェクト全体ではなく、システムの一部機能を開発する10人弱のチームでRedmineを使用 プロジェクトの開発工程はウォーターフォールを使用 プロジェクト管理は、Microsoft ProjectをツールとしWBSおよびガントチャートで実施 各チームは定期的にWBSおよびガントチャートで進捗報告 チケット管理に関する運用 チーム管理者（作業場所には常駐してない）がチーム各員から進捗状況を逐一ヒアリングすることなく、作業状況をRedmineを見れば調べられる仕組みを作りたい 背景 プロジェクト全体で管理するWBS／ガントチャートは、基本設計、詳細設計、という工程毎に機能が列挙される観点の
RedmineをBPMツールとして使うアイデア - プログラマの思索
Redmineを事務処理の申請承認ワークフローシステムとして使うとか、帳票ワークフローシステムとして使うアイデアを考えているうちに、RedmineをBPMツールとして使うアイデアについて考えてみた。 以下、ラフなメモ書き。 【元ネタ】 Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索 Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索 Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索 akipiiさんはTwitterを使っています: "それだ！ @u6k_yu1: チケット管理システム全般に言えることだとは思うけど、中でもRedmineは、ワークフロー制御と項目カスタマイズ性によって完成度が高いと言える/Redmineは帳票ワークフローシステムであるというアイデア
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点 - プログラマの思索
GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点について指摘していた記事があったのでメモ。 【参考】 GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録 GitHub の Issue をあとから Pull Request にする (あとからコードを添付する) - Qiita [キータ] Fujimura ? GitHubで既存のissueに対してpull requestする hub コマンドで github から fork して pull request をさくっと - #生存戦略 、それは - subtech Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記 bleis-tift/Git-Hooks かんばん！～もし女子高生がRedmineでスクラム開発をしたら（6）：Redmine×Gitのハー
チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
