チケット駆動開発の適用範囲 - プログラマの思索
日本のSI企業がチケット駆動開発について記事を書かれていたのでメモ。 以下ラフなメモ書き。 【元ネタ】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL 補完チケット方式はチケット駆動開発の先祖返り: プログラマの思索 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば ユーザの力を利用するアジャイル開発: プログラマの思索 チケット駆動開発の戦略: プログラマの思索 僕はチケット駆動開発がどこまで知名度が上がっているのか、正直知らない。 でも、チケット駆動開発のアイデアをアジャイル開発だけでなく、従来のWF型開発にも適用すればその恩恵が受けられるのではないか、という意見は、既に@sakaba37さんたちが色々試されている。 チケット駆動開発をWF型開発に適用する場合、「チケット
チケットの粒度と進捗ビューの関係 - プログラマの思索
チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
