アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～第2回 RxTstudyの講演資料 チケット駆動開発はアジャイル開発と親和性が高い一方で、従来法の開発中に生じる想定外の問題を管理・解決する際にも有効です。チケット駆動開発を導入することでプロジェクトの危機的な状況から抜け出して、メンバーが積極的に、プロジェクトが元気になり、プロジェクトを成功に導いた事例をご紹介します。
[TiDD] 速報！史上初の「チケット駆動開発」の本が出版に - ソフトウェアさかば
来月、いよいよチケット駆動開発の本が出版されます。そのタイトルは 「Redmineによるタスクマネジメント実践技法」 です。大人の事情でタイトルにこそ入っていませんが、表紙にはしっかりと「チケット駆動開発」の文字が入る予定です。まだ1ヶ月ほど先になりますが、すでにAmazonでは予約受付されています。 この本は、チケット駆動開発に関して精力的に活動されているあきぴーさんの多くの実践ノウハウを中心に、私(さかば)と共著で書きました。もちろん良書の条件を満たすべく、チケット駆動開発の歴史や背景も書いています。もちろん、Redmineのノウハウも詰まっていますし、TestLinkも説明しています。 中堅の技術者をイメージして書いていますので、近頃にない内容の濃い本になっています。目次は以下のようになっています。ご期待ください。 第1部 チケット駆動開発技法 ─BTSによる作業管理─ 第1章 障害
![[TiDD] 速報！史上初の「チケット駆動開発」の本が出版に - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
【告知】「Redmineによるタスクマネジメント実践技法」を出版します #TiDD - プログラマの思索
さかばさんと共著で「Redmineによるタスクマネジメント実践技法」を2010/10/13に出版します。 世界初のチケット駆動開発の本になります。 【元ネタ】 [TiDD] 速報！史上初の「チケット駆動開発」の本が出版に: ソフトウェアさかば 過去３年間、RedmineやTestLinkなど各種ツールを駆使して、チケット駆動開発という開発プロセスの上でAgile開発をいかに運用するか、をテーマにして、試行錯誤した経験と今まで思索してきた内容を全て書きました。 そのため、350ページ近くまで膨れ上がりました(笑) 最初に断っておきますが、RedmineやTestLinkのインストール方法には特に触れていません。 XPなどのAgile開発の文脈の上で、チケット駆動開発という開発プロセスを世界で初めて定義して、その応用分野や今後の課題についてひたすら書いています。 読者層は、BTSに不満がある人
アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する - プログラマの思索
「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。 ラフなメモ書き。 【元ネタ】 「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮) 「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮) 【12章 リーダーシップが信頼に基づく理由】 「表明」とはコミットメント、約束を意味する。 メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。 チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。 プロジェクトで発生する全ての作業は、チケットに起票してから開始する。 WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。 そのチケットには、開始日と終了日、
Subversion, Git, Redmine, Hudson - 現状の連携 � tune web
会社の仕事を「Gitを中心に据えた開発ワークフロー」に変えたいなとこの週末ぼんやりと考えていたんですが、現状を整理して残しておくのも、あとで振り返った時も参考になるかもしれないと思って残しておきます。 開発しているものは画像処理ライブラリで、言語はC言語。プラットフォームはWindowsとLinux両方に対応していて、32bitと64bitどちらでも動くようにしたいのが前提。ほとんどのソースは共用出来るようにしています。開発者はWindowsを使ってVisualStudioで開発し、自動テストやリリース時はLinuxでMakefileを使ってビルドします。 バージョン管理は課で管理しているSubversionを使い、他のプロジェクトともリポジトリを共用しています。他に使っているツールはテスト自動化にHudsonとタスク管理と障害管理でRedmineがあります。Hudsonは2種類のテストを
[TiDD] ひとりチケット駆動開発はメールを使え！ - ソフトウェアさかば
XP祭り関西2010で、「ひとりチケット駆動開発は楽しくなかった」と述べましたが、訂正します。 「ひとりチケット駆動開発にBTSは向かない。メールを使うべきだ」 発表の後で、色々な人に「昔からやっているんですけど、忘れないように自分にメールする方が便利なんですよね」と言っていました。でも、倉貫さんがスプレッドシートでチケット駆動開発(TiDD)と言われていたことを思い出して、メールによるものもTiDDであると考えます。 すると私は、ひとりTiDD歴がかれこれ4半世紀になります(チョット自慢<-おじさんなだけですorz)。 まじめな話、メールはひとりTiDDに最適です。こんな感じです。 1) 忘れてはいけない作業が発生したときに、自分にメールします。 2) 必要なら、専用のフォルダを作成してメールを振り分けます。 3) 優先順位の高い作業にはタグなど目印をつけます。 4) 完了していない作業
[TiDD] BTSがチケット駆動開発に向いている理由 - ソフトウェアさかば
XP祭り2010のチケット駆動開発(TiDD)パネルで、倉貫さんがgoogleスプレッドシートでTiDDをされていたことに、あきぴーさんはあきぴーさんは納得されていない様子です。 個人的には作業を見える化してコミュニケーションを図るという意味で、「あり」だと思いますが、あきぴーさんのこだわりの中ににTiDDを整理するヒントがありそうなので、BTSだとなぜ良いかを考えてみました。 1) 個人のビュー＝ひとりスクラム TiDDでは毎朝、あるいは作業が終わったときなどに、担当している作業の一覧を確認し、今後の進め方を計画します。作業開始後はその作業に集中して実施します。この一連の流れは、スクラムと非常に似ています。 スクラムでは、チームが要求されている作業の一覧があり、プロダクトオーナによってその優先順位がみめられます。次にスプリントの作業を決めるために、スプリントミーティングによって対象のプロ
【公開】XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」 - プログラマの思索
昨日、ＸＰ祭り関西２０１０が無事に終了した。 多分150人近い参加者だったと思うので、大成功だった。 東京から長瀬さん、AgileJapanのebackyさんやミルズさん、日経BPの井上さん、XPJUGの倉貫さん、岡山からてつさん、福井から岡島さん。 東京や名古屋など遠方から結構な数の人が来てくれた。 関西はアジャイル開発のマーケットが十分にある手応えを感じた。 チケット駆動開発セッションも、懇親会で感想を聞くと評判が良かったみたい。 TiDDの事例や試行錯誤を聞けて興味深かったらしい。 実際にBTSを使っている人もいれば、今から試そうとしている人もいて、色んな観点で聞いていたようだ。 僕はWeb系開発でRedmine、さかばさんはパッケージ製品開発でTrac、小枝さんは組込製品開発でManitsを使って、TiDDを実践した事例を三者三様で話した。 僕も、二人の話は既に聞いていたけど、改め
Re:mercurialでチケット駆動開発 - monjudoh’s diary
元記事 mercurialでチケット駆動開発 - logiqboard default・confirm・topic*いっぱいというbranchの使い方の懸念点 リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえるということで気になったのは、あるtopic branchでの変更について、 confirm branchにmergeして動作を確認しても、 そのtopic branchをdefault branchにmergeして正しく動作する事を保証しない、 ということ。 例えば開発完了したtopic branchがb1〜b5の5個あったとして、 b2,b4のみリリース予定は他より後になっているとする。 この時、confirm branchにb1,b2…という順番でmergeされているとして、 b5の正常動作がb2や
Mercurialによるチケット駆動開発は強力だ！ - プログラマの思索
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t
mercurialでチケット駆動開発 - logiqboard
本格的にmercurialを使い始めて数ヶ月、色々ノウハウがたまったのでまとめてみる。 想定する状況 VCSはmercurial一本で運用 IssueがなにかしらのBTSで管理されており、チケット単位でかつ並列に開発を進めたい リリース順≠開発完了順（チケットAは開発完了しているが優先してチケットBだけを今すぐリリースしなければいけない という状況がありえる リポジトリ配置 中央(central) どこかの共有サーバー上にあり、全ての開発成果が集まる場所。 中央@個人用(default) ↑と同じ場所にある個人の開発用の中央リポジトリ。個人ローカルと完全に同期する。 確認環境(test) 中央からclone, pullされる。リリースチェック、各チケットの動作確認を行う。 個人ローカル 個人の開発環境上に置かれるリポジトリ。やりたい放題する。 ブランチ運用 default リリースブランチ
[tech]チケット駆動開発 - Kazumi007の日記
id:kunitさんの[Git] gitだからこそできるチケット駆動開発のやり方を読んでたら、自分たちもチケット駆動開発的なものをやっていることに気がつきました。せっかくなので、ちょっと紹介します。 構成管理はCVS、BTSはJIRAを使っています。チケット駆動ということを意識してはいませんが、ルールとして「構成管理にコミットするときには、コミットログにチケットIDと変更概要を記述する」ということを守っています。 日々の開発 日々の開発では、まず機能(ユースケース)ごとにチケットを起票します。このチケットは、管理タスクとして使用します。JIRAでは１レベルのサブタスクを定義する事ができます。この機能を利用して数日で達成できる単位（どちらかというと、CVSのコミットに都合の良い単位や開発者にアサインしやすい単位）で、サブタスクにチケットを分割していきます。サブタスクは、タスクが発生したり、お
![[tech]チケット駆動開発 - Kazumi007の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ad87cf023f904c227b84afa86aa1c22555351d1/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127136432888%2F17680117127136434846%2F1558043426)
チケット単位に並行開発する事例 - プログラマの思索
分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。 【事例1】 gitだからこそできるチケット駆動開発のやり方 - kunitの日記 今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 1. 会員管理を拡張したいなぁ 2. じゃRedmineでチケットを切るぞ 3. チケット番号が振られた(たとえば #567 だとする) 4. さぁ、ブランチ切るか(members_567) 5. そのブランチで作業開始！ 濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。 【事例2】 Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂 t
gitだからこそできるチケット駆動開発のやり方 - kunitの日記
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/k_aruga/20091014
[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する- - ソフトウェアさかば
[TiDD] チケット駆動開発の最初の一歩 - ソフトウェアさかば
[TiDD] チケット駆動開発はじめました - ソフトウェアさかば
[TiDD] BTSによるコミュニケーションの効率化 - ソフトウェアさかば