TiDD：チケット駆動によるアジャイル開発法
3月6-7日にあるソフトウェア信頼性研究会の第5回ワークショップ(申込み締め切りが２月２０日まで延びました)に参加します。良い機会なので、チケット駆動開発(TiDD)についてまとめてみました。
「TiDD：チケット駆動によるアジャイル開発法」(PDF)
文字ばかりのポジションペーパーですが、コメントがいただけるとうれしいです。
« 必然から生まれたチケット駆動開発 - XP祭り関西2009 その３- | トップページ | 確定申告でふらふら »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会（導入編）- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会（導入編）- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
コメント
トラックバック
この記事へのトラックバック一覧です： TiDD：チケット駆動によるアジャイル開発法:
» チケット駆動開発の論文 [プログラマの思索]
さかばさんがチケット駆動開発の論文を書かれたのでリンクしておく。 【元ネタ】 ソフトウェアさかば: TiDD：チケット駆動によるアジャイル開発法 さかばさんの論文の主張を抽出すると [続きを読む]
ポジションペーパ読みました。信頼性研究会に参加できれば良いのですが、参加できる自信がないので、ちょっとだけコメントを書きます。
PPの中で、「従来，障害管理ツールを利用する際に，要望も障害も同様に扱うというIssue trackingが行われていた．」と書かれていますが、本当でしょうか？障害管理と課題管理（要望）は、まったく別に管理していたんじゃないでしょうか？同じToolを使えない事はありませんが、管理項目も別であり、もし同じ扱いをしていたなら、それは怠慢ではないでしょうか。
投稿: SRX-6 | 2009年2月17日 (火) 14時56分
療養中にコメント頂きありがとうございます。
三島で聞きましたが、お体を大切にしてくださいね。
たしかに従来のソフトウェア開発では、集計上は分けて管理されるべきものだと思います。
しかし、障害管理ツールのGNATSの項目にはfeature requestsという属性値が標準であります。これは、ユーザからの問い合わせをすべて登録して、あとから障害と要望を切り分けるという使い方をすると思います。以下の記事ように「要望」ではなく「問題」とした方が良いかもしれませんね。
http://journal.mycom.co.jp/special/2006/trac/index.html
投稿: さかば(管理人) | 2009年2月17日 (火) 21時51分