No Ticket, No Commitの効果について考えたことをメモ。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 明日からできる！バージョン管理システムへのコミット粒度を最適化するトレーニング方法 - 刺身☆ブーメランのはてなダイアリー Twitter / @yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ) Twitter / @yusuke_kokubo: @akipii コミットの粒度とコミットメッセージあたりですね。 まちゅさんのスライドにもあるように、チケット駆動開発の最も基本的な運用ルールは「

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な

Shibuya.trac第12回勉強会 ～チケット管理システム大決戦　第二弾～ でパネリストを初めて経験しました。Shibuya.tracや参加者の皆様。貴重な場を提供していただきありがとうございました。とても楽しかったです。 大決戦なので、はじめは「怖いなー」というイメージでしたけど、他のツールの利用者の声を聞くことができて、本当に勉強になりました。資料は100ページを超えるものですが、開発現場でプロセス改善されている方の魂がこもっているので、興味のある方はぜひ一読ください。 パネルディスカッションだったため、話せる時間が限られていたのですが、そのあたりは別途ブログで公開しようと思います。勉強会には間に合わなかったのですが、世界のスクラムマスターの使うツールを調べたりしたので、それもまた。 以下、資料や発表を聞いていて思ったことなどをば。 僕は、オープンソースアプリケーションは、無料で使

Redmineを初めて使う管理者が陥りやすいアンチパターンを見つけたのでメモ。 【元ネタ】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索 Twitter / @cointoss: アジャイルの導入に二の足を踏む現場において、チケット駆動開発(=TiDD)であれば受け入れやすい理由は、プラクティスが少なく実践的なものに絞っているからだろう。リリース予定をバージョンとすることでイテレーションやスプリントが定義できるため、そこだけはアジャイルっぽくはなる。 【1】僕がRedmineを設定する場合、あらかじめヒヤリングした後にプロジェクト設定画面でカテゴリ・バージョンは登録している。 全てのチームがアジャイル開発に慣れているわけではないので、あらかじめ対象バー

工事進行基準 工事進行基準というのは、最終納品時に売り上げを計上するのではなく、開発の進捗に合わせて売り上げを計上できる会計の方法です。毎月売り上げが上がるので、納品が1日遅れるだけで売り上げが次の期なるということがありません。 工事進行基準を採用するには、一定の規模以上で、きちんと計画が立てられていて(ある程度詳細なWBSがあり)、その実施が可能と考えられる場合です(売り上げを単純に期間で立てられる会社もあるようですので、もう少しゆるい場合もあるかもしれません。 私の勤める会社の場合、顧客と合意した工数でWBSを作成し、そのWBS上の (完了工数/総工数)×受注金額 で売り上げを決めます(完了工数にもステータスで進捗率を決めるなどのルールがありますがここでは省略します)。チケット駆動開発のプロジェクトではWBS 相当の情報をチケットにしますので、当然のようにチケットの内容をTSVで出力し

Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は

チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。 最初の質問について、自分なりに考えたことをメモ。 【元ネタ】 チケット駆動開発を導入しても変わらないこと - Basic まずは箇条書きより始めよ - Basic デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002 【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。 チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。 チケットが放置されがちな状況

【元ネタ】 創発　未来につながるために　世界に帆を立てるために　Developers Summit 2011 セッション内容～創発　未来につながるために　世界に帆を立てるために　Developers Summit 2011 【17-B-3】チケット駆動開発～タスクマネジメントからAgile開発へ～ 最近、RedmineやTracのような高機能なBTS(バグ管理システム)をソフトウェア開発のタスク管理に適用して、アジャイルに開発する「チケット駆動開発(TiDD：Ticket Driven Development)」が静かに広まっています。 チケット駆動開発は細かな作業をチケットで管理することから生まれましたが、アジャイル開発と関連する点が多いことから、アジャイル開発をブラッシュアップする技術としても、利用されるようになりました。 本講演では、ソフトウェア開発の歴史におけるチケット駆動開発の意

開発チームとしてやるべき事は、大きなものから小さなものまで全てTracのチケットに放り込んで作業を進めている。目的は下記の通り。 作業量の顕在化 チケットの更新状況を見れば、チームとしてどんな作業を進めており、どのくらいの分量が残っているのか一目瞭然だ。 作業遅延の顕在化 各チケットには期日があるし、タイムラインにはチケットの更新状況が出てくるので、作業が予定通りに進んでいるのか、遅れているのか直ぐに分かる。 作業漏れの顕在化 やるべき事は全てチケットに入っているはずだが、ふとした会話の中で、これ以外に問題が見つかることが珍しくない。このような誰にも気付かれずに存在していた問題こそが対処を要するものだ。 チケットに記載するということは「やるべき事を明確に定義する」という事に他ならない。「仕事をする」ということは実際のところ曖昧模糊としていて「やるべき事を忘れていた」とか「誰かの作業がいつの

自分が今いるチームは、3か月半ぐらい前にTracを導入して、チケット駆動開発に移行しました。 今では、チケットを中心に作業を進め、進捗の報告もチケット上で行っています。 そんなチケットですが、より作業がスムーズに進むよう3タイプの人を意識して書くように工夫しています。 同僚、先輩 → 詳細に書く 同僚や先輩に向けてチケットを書くときには、できるだけ詳細に書くように注意しています*1。 バグ報告のチケットなら、 発生手順（どういう前提条件で、どう操作をすれば発生するのか） 根本原因（ただの単純ミスなのか、設計上の問題なのか） 修正方法（どのクラスを直すか、水平展開のポイントはどこか） といった点を詳細に書いています。 Trac導入前だと、これらを口頭で説明したり、手書きのメモで箇条書きにして渡したりしていました。 でも、これだと相手に意志がうまく伝わらず、直したと言われてもチェックしたら直っ

ウォーターフォール(WF)とアジャイルの議論はいつもかみ合いません。それは、モデルで考えるなら、1回だけか複数回かで複数回の方が変化に強いに決まっているものの、WFは決められた仕様どおりのものを作ることが目的で、アジャイルは変化に対応しながら顧客の要求に合ったものを作ることが目的だからです。目指すものが違うので、それを比較しても、どちらが良いということはありません(もちろん、あるプロジェクトにとって、どちらが向いているかはあります)。 ここでは、WFではなく「従来法」と呼ぶプロセスを考えてみます。具体的には、開発標準として、上流から下流までの段階的な工程に分かれ、各工程での作業、成果物、品質向上策のほか、メトリクスの基準が決められている。初めての技術に関しては、プロトタイピングが実施されて技術的な検証がされる。また、上流では少人数で、下流工程では増員されるようなプロセスを考えます。 このよ

工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。 ラフなメモ書き。 【元ネタ】 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 頻繁なVerUpがソフトウェア開発の本質: プログラマの思索 【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。 自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。 例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。 機能Aの設計バージョン、機能Aの開発

TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。 【参考】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。 それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。 例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。 大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位

続きです。ようやく最終回(のつもり)です。 １．事件は現場で起きている！ チケット駆動開発は現場から生まれました。 細かな作業を管理する ソースコードの履歴を管理する ツールで自動化する これらは、現場がいかに楽をするか、肉体労働でなく知的生産をするか、という観点です。もちろん、プロジェクトマネージメントやプロセス改善で意識するQCDの向上、つまり品質向上、コストダウン、納期とも間接的には関係しますが、それが目的ではなかったのです。 ２．既存技術の現場との乖離 ソフトウェア工学の歴史を振り返ると、その始まりころは構造化プログラミングによって、現場のスパゲッティプログラム問題を解決してくれましたが、定量的、統計的、汎用的、なものを目指すあまりに現場に対して即効性が低くなったように思います。 研究の価値を考えるならば、定量的であることで客観的になり、統計的であることでその有効性が明らかになり、

これまで、チケット駆動開発のポイント、チケット駆動開発によるプロセスの変化、チケット管理、形式化と説明してきました。このような変化から生まれるのは、開発の「リズム」です。 リズムは、明確になったプロセスが繰り返されることにより生まれます。ここまで説明した2階層のプロセスには、以下のリズムがあります。 個人では、チケット一覧をチェックして、1日の作業範囲を決めて作業し、その日の終わりには進捗を登録するという日々のリズムがあります。 プロジェクトでは、朝会に始まる日々のリズムのほか、棚卸しのリズム、マイルストーンあるいはイテレーションというリズムがあります。 パターン化された繰り返しの中で、リズムが生まれます。同じことを繰り返す中で習熟し、見積もりが正確になります。また、チケットに関する運用ルールが守られる様になります。 このリズムの生まれ方、スピード、対象、はチケット駆動開発の大きな特徴です

続きです。 では、チケット駆動開発でどのようにプロセスが変わるかというと チケットへの依存から、チケット中心の開発 2階層プロセスが明確になる リアルタイムに見える化される スコープの変更(計画ゲーム)が実施される 改善が始まる リリース回数が増える という点です。 チケットへの依存から、チケット中心の管理へ 手作業による管理が難しい状況では、チケットによる管理は効果的です。チケットを使うことで、細かな作業、仕様変更、不具合が容易に管理できます。チケットを使い出すと、チケット以外のメディアとの2重管理は無駄です。すぐにチケットを中心とした開発に移行していきます。 チケットが中心になると、常にチケットを見ながら次の作業を考えるようになります。そして、1日の作業が、チケットの確認から始まり、目標設定、作業、進捗の登録といったリズムを持つようになります。 2階層プロセスが明確になる チケットを中