チケット駆動開発の感想のリンク
Redmineでチケット駆動開発を実践した人の感想の記事をリンクしておく。
以下メモ書き。メッセージは特に無し。
【元ネタ】
技術見聞録 - Redmineについて思うところ
kakakikikekeのブログ: チケット駆動開発について今更考えてみた
前者の記事では、
「親チケットは要求定義を除き、機能で分かれているべきである」
「進捗率を見る場所は「ロードマップ」!(ガントチャートじゃない)」
「本来「バージョン」は工程を書くだけの場所ではない」
という指摘は同感。
後者の記事では、「メリットとかイケてるところ」として、こんな感想が書かれていて同感。
(引用開始)
・マネージメントが簡単
日本の会社のようにヒエラルキー型の会社にはがっつりハマると思います
上の人がチケット切って「はい、これやって、これやって」とホイホイ下の人に割り当てればいいだけなのでマネージメントはめちゃくちゃ簡単
アサインしている人ごとにチケットも見れるのでリソースの空き状況もすぐに把握できる
チケットさえちゃんと作成できていればという点はあるが
・ルールが勝手に出来上がる(出来上がった)
これはいい事象かなと思ってます
例えば、文書管理のフォルダ名とかwikiのタイトルとかは全くルールがない状態で初めたんですが、初めに誰かが作成した命名規則的なものを次の人がそれに沿って「いい感じ」に作ってくれるようになりました
例えば、wikiページは必ずYYYYMMDD_で始まるように記載していたら、他の人もそれに合わせて書いてくれるようになったりとか、文書管理のフォルダ名もはじめに00_hogehogeとか数字をつけるようにしていたら次のフォルダ名が01_barbarとかになって自然にルールができていたのはいいなと感じました
(引用終了)
「デメリットとイケてないところ」として、
・クローズされない亡霊のようなゾンビチケットができあがってしまう
・チケットの粒度
・検索機能が弱い
があげられている。
| 固定リンク
「Redmine」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- RedmineをPJ管理ツールと呼ぶのは嫌いだ、Redmineはチケット管理ツールと呼ぶべきだ(2021.01.02)
- PMO観点でRedmineの使い方とは何か(2020.12.20)
- 若手プロジェクトリーダー向けのRedmine教育資料の構想(2020.12.24)
「チケット駆動開発」カテゴリの記事
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
- チケット管理ツールの用途が変わってきている(2020.10.28)
コメント