AgileJapan2012講演資料「チケット駆動開発の課題と展望」【公開】AgileJapan2012講演資料「チケット駆動開発の課題と展望」 #aj12: プログラマの思索 http://forza.cocolog-nifty.com/blog/2012/03/agilejapan2012-.html Agile Japan 2012 https://www.facebook.com/AgileJapan2012Read less
チケット駆動開発がもたらした新しい観点part3～トラッカーの考え方 - プログラマの思索
Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。 トラッカーについて考えたことをメモ。 ラフなメモ書き。 【1】Redmineのトラッカーはワークフローそのもの。 Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。 デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。 個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。 トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。 ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。 バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。 だから、それら作業はワークフローに複数人の担
チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張 - プログラマの思索
Redmine・Trac・Mantisでチケット駆動開発を実践してみて、技術的に一番面白いのは、ツールの連携によるトレーサビリティの強化であり、その拡張だ。 この考え方は「ソフトウェア構成管理とはそもそも何なのか？」という問題に行き着くと思う。 以下ラフなメモ書き。 【1】チケット駆動開発の基本的な運用ルールは「No Ticket, No Commit!」だ。 実際の運用方法は、SVNやGit、Mercurialのコミットログに「refs #チケットNo」「fixes #チケットNo」を付けてcommitすると、自動的にチケットとリビジョンが相互リンクするやり方。 この運用ルールは、障害管理において、障害報告票に基づいてどのようにソースが修正されたのかをレビューしたり検証したり、リリース後に確認できるようにしたい発想から生まれた。 この単純な運用ルールこそが、従来のAgile開発には無かっ
[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に不満がある人
クローズできないチケット - rabbit2goのブログ
3月末が期限だったtracのマイルストーンをクローズする。「チケットキーパーという存在」として、未解決のチケットについてはマイルストーンの変更（要するに先送りだ）や、担当者にチケット更新の催促を行う。幾つかのチケットはクローズ出来たものの、中にはクローズを認められないものも有る。例えば、こんなチケットだ。 やるやる詐欺型 「次回はレビューを行います」「確実なチェックを実施します」なんて書かれているけれど、今までそんなことが実際に行われて成果を上げているなんて聞いたことがないし、そもそも次回の開発時には、こんな回答すら忘れられていることが多い。だから、作業手順書を改訂する、チェックリストに確認項目を追加する、実際にレビューを行うなど具体的なアクションが完了するまでチケットはクローズ出来ない。 フィードバック欠如型 障害の修正だけで作業が終わってしまい、再発予防策とか未然防止策が実施されていな
Redmineの各機能から眺めたチケット駆動開発の課題 - プログラマの思索
Redmineの各機能から眺めたチケット駆動開発の課題についてメモ。 ラフなメモ書き。 【プロジェクト】 「Redmineのプロジェクトはどんな単位で作るべきか？」という質問は良く出る。 僕がTiDDをアジャイルに運用した経験から言えば、二つある。 一つ目はブランチのライフサイクルに合わせる。 二つ目はITILの運用保守プロセスに合わせる。 前者は、RedmineのプロジェクトがSCMリポジトリと1対1に対応している思想から、自然に扱える。 例えば、本番リリースしたソースは本番ブランチとして作られて、trunkとは別のコードラインで保守される。そして、次のメジャーバージョンが出たら、古い本番ブランチは廃止されて、以後は保守されなくなる。 つまり、プロジェクトとブランチが1対1に対応する状態遷移になる。 プロジェクト：新規作成→使用中→非公開→終了 ブランチ：新規作成→使用中→廃止(以後保守
TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間 - プログラマの思索
TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 ＃下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
チケット駆動開発とアジャイル開発の密接な関連 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20090911/p01/