チケット駆動開発は計画の変更を恐れない #tidd - プログラマの思索
チケット駆動開発でのリスケについての質問を見つけたのでメモ。 下記はあくまでも僕の一意見。 ラフなメモ書き。 【元ネタ】 チケット駆動開発でのリスケジュール方針について | OKWave 【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。 すなわち「バージョンをCloseする＝リリースした」「バージョンをCloseできない＝リリースしていない」になる。 もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。 つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。 チケット駆動開発において、リスケのタイミングといつだろうか？ Agileに開発しているなら、朝会だ。 Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。 PLは課題解決マシーン。実作業はメンバーにお任せ。 課題
複数のRuby環境構築はrvmかpik - プログラマの思索
Ruby1.8.6と並列に、Ruby1.9やJRubyを使いたいと思う時がある。 複数のRuby環境構築の方法が分かったのでメモ。 【元ネタ】 pikで簡単、複数のRuby環境構築！ ? 梨木を読む Ruby/Windows7で1.8と1.9環境を同居させる - 俺の基地 RVMで複数のRubyを使いこなす - Capsule RVMで複数のRubyを管理 Rubyの複数バージョンを共存させるgem。rvmとpikについて - holyppの日記 事の発端は、RedmineのXLS export pluginを入れたら、意味不明なエラーが出たこと。 gem install spreadsheet も設定したのに何故だろうと思ったら、Ruby1.8.6からv1.8.7へアップグレードすると解決した。 Redmine - XLS export plugin - Redmine とはいえ、Rub
pre-commit-hookとpost-commit-hook #tidd - プログラマの思索
Subversionには、pre-commitとpost-commitの機能が元々付いている。 復習のためにメモ。 【元ネタ】 TortoiseSVN の設定 バグ追跡システム / 課題追跡システムとの統合 [Think IT] 第4回：チケットとソースコードを連携せよ！ (1/3) ソフト/Bug Tracking/trac/TortoiseSVNやSubclipseとチケットを連動 - discypus TortoiseSVNとITS・BTSの連携 S.S.S. blog/ウェブリブログ redMine で trac の trac-post-commit-hook のような事をやる バージョン管理システムとの連携 | Redmine.JP TortoiseSVNのようなSVNクライアントには、pre-commitとpost-commitの機能が元々付いている。 pre-commitは、
TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない - プログラマの思索
ITS(Issue Tracking System：課題管理システム)の導入がうまくいっていない状況があったという記事があったのでメモ。 とても参考になります。 【元ネタ】 なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド Agile開発の肝はイテレーションにあり: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 (前略) 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんてITS使ってる人には常識
r-rabsのRedmine Hudson Pluginがすばらしい件 - プログラマの思索
r-rabsのRedmine Hudson Pluginを運用してみて、とてもすばらしいと思ったので、良かった点を書いておく。 【元ネタ】 Redmine - Hudson Plugin 0.1.0 - Redmine RedmineとHudsonを連携させる方法 - Faster Than Light 【1】ジョブの一覧からビルド履歴を簡単に見れる点がよい。 下記を見れば一目瞭然。 r-labs - Redmine 大規模プロジェクトになるほど、開発チーム単位でビルドモジュールを開発するため、複数のジョブが作られる。 Redmineでタスク管理しているのだから、Redmine上でHudsonを見れるのはすごく便利。 【2】チケットにあるSVNリビジョンの履歴に、どこまでビルドしたのか(SUCCESS)、が表示される 下記を見ると、SVNリビジョンにコミットログだけでなく、どのビルド番号に
【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。 ラフなメモ書き。 【元ネタ】 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 頻繁なVerUpがソフトウェア開発の本質: プログラマの思索 【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。 自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。 例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。 機能Aの設計バージョン、機能Aの開発
Redmineのロードマップにある進捗率の意味 - プログラマの思索
Redmineのロードマップの進捗率について良い説明があったのでメモ。 【元ネタ】 ロードマップ画面に表示される進捗率の算出方法 | Redmine.JP Blog Redmineのロードマップでは、進捗率が2種類表示される。 一つは終了チケットの進捗率で濃い緑色で表示される。 もう一つは仕掛り中も含めたチケットの進捗率で薄い緑色で表示される。 上記の機能が意味するのは、濃い緑色の進捗率こそが実質の進捗率であること。 顧客が使える機能は、実装する機能のチケットのステータスが終了でなければ、実装できたとしてもテストも終わっていないのだから、リリースできる品質が確保されていない。 Agile開発では、Done(終了)でない作業は全て未完了と見なすけれど、その意味は、顧客に取って価値あるソフトウェアはまさに動くソフトウェアであるからだ。 まともに動かないソフトウェアは価値あるソフトウェアとは言え
Redmineに複数SCMリポジトリ表示が必要な理由 - プログラマの思索
Redmineに複数SCMリポジトリを表示するパッチについてメモ。 【元ネタ】 Twitter / yusuke-kokubo: #redmine #redmine Multiple SCM per Projectの本体側へのマージに動き出した感じがする。JPLもrake testを追加してる。 Twitter / yusuke-kokubo: 社内Redmineをアップデートする過程でMultiple SCM per Projectも直さないといけなくなったので半泣きになりながらも頑張ってアップデートした。 Redmine - Feature #779: Multiple SCM per project - Redmine Redmineは元々、1プロジェクト1リポジトリの発想。 つまり、Redmineプロジェクトには、一つのSCMリポジトリからビルドされるリリースモジュールと1対1に対
Agile開発の肝はイテレーションにあり - プログラマの思索
Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。 XPを実践したいと思っていても、本当のAgile開発は何か違うのでは？と思っていた。 何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか？ RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。 Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100％になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。 つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。 小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。 Ag
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
チケットがプロジェクトを駆動する #tidd - プログラマの思索
さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。 以下メモ書き。 【元ネタ】 [#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば [#TiDD] チケット駆動開発がもたらすプロセス その２: ソフトウェアさかば 僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。 つまり、イテレーションありきでプロジェクトが開始すると思っていた。 その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。 さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。 多分、
アジャイル開発を前提とした受託開発 - プログラマの思索
永和システムマネジメントさんがアジャイル開発を前提とした新しい契約形態での受託開発サービスを発表していた記事があったのでメモ。 【元ネタ】 新しい契約形態での受託開発サービス ｜ 永和システムマネジメント プライベートセミナー『アジャイルに適したまったく新しい契約形態での受託開発サービス トライアルのご紹介』(2010/11/24) ? 株式会社永和システムマネジメント コンサルティングセンター 永和システムマネジメントの新しい受託契約がすごく面白い - ただのにっき(2010-11-11) WEB技術者の事業貢献度をもっと高めたい - GoTheDistance 受託開発の契約をアジャイル開発を前提とした形態にしてSIビジネスする発想はとても興味深い。 責任者は木下史彦さんと公開されていて、XP祭り関西などで何度もお話を聞いていたから、なるほどと思った。 SW開発が製造業と異なる収益構造
Redmineのロードマップ画面に表示される進捗率と原価計算の関係 - プログラマの思索
Redmineのロードマップに表示される進捗率の計算方法と原価計算の関係について、考えたことをメモ。 ラフなメモ書き。 【元ネタ】 ロードマップ画面に表示される進捗率の算出方法 | Redmine.JP Blog 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 見かけ上の進捗: プログラマの思索 チケット駆動開発にEVMの概念を導入してみる: プログラマの思索 RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索 Redmineのロードマップには2種類の進捗率が表示される。 薄い緑色は、チケットの進捗率から得られた見かけ上の進捗。 濃い緑色は、終了チケットから得られた実質の進捗。 Redmineが他のBTSよりも優れている点の一つは、ロードマップを見れば、実質の進捗と見かけ上の進捗の2つの進捗が見れること。 見かけ上の進捗:
HudsonのSubversion Tagging Plugin - プログラマの思索
ビルド管理ツールHudsonのSubversion Tagging Pluginがとても使いやすいのでメモ。 CVSにも同様のプラグインがある。 【元ネタ】 Subversion Tagging Plugin - hudson - Hudson Wiki CVS Tagging Plugin - hudson - Hudson Wiki HudsonのSubversion Tagging Pluginの使い方は下記を想定している。 SVNでタグ付け 例：yyyyMMdd＋連番3桁 ↓ Hudsonで、指定したSVNタグをチェックアウトして、ビルドモジュールを作成 ↓ リリース後、RedmineのバージョンをSVNタグでリネームする。 又は、TracのマイルストーンをSVNタグでリネームして、完了ステータスへ更新する。 又は、Mantisの修正予定・修正済みバージョンをSVNタグでリネームし
頻繁なVerUpがソフトウェア開発の本質 - プログラマの思索
WF型開発とAgile開発の本質的な違いはどこにあるのか？ プロセスや技術の観点から見れば、WF型開発は本番リリースが1回しかないのに対し、Agile開発は定期的なリリースを基本とする特徴がある。 その観点をもう少し深めて考えてみた。 ラフなメモ書き。 【1】WF型開発は、シーケンシャルに工程単位に開発を行い、フィードバックプロセスをできるだけ排除するプロセス。 半年～1年に1回だけ本番リリースするのが普通だろう。 特に日本のSIは製造業から派生した会社が多いから、ソフトウェア工場の発想に影響を受けている。 つまり、前工程の品質をできるだけ確保するために、レビューやテストを事前にしっかり行い、仕様漏れや検証漏れを前工程で十分に行って、後工程のフィードバックや突然割り込んだ変更要求をできるだけ排除するやり方。 たいていは、スコープは長期間固定化するのが普通で、最後の1回の本番リリースを成功さ
TortoiseHg＋hgsubversionの導入方法 - プログラマの思索
TortoiseHg＋hgsubversionの導入方法の記事があったのでメモ。 【元ネタ】 hgsubversionの導入 - 文殊堂 Gitはgit-svnという優れたツールがあるが、Mercurialはhgsubversionを使うといい。 但し、結構はまる。 上記の方法を試すと良いと思う。 git-svnやhgsubversionの利点は、中央集権SCMであるSVNをあたかも分散バージョン管理のリポジトリかのように扱えること。 マスターリポジトリはSVN、開発者のプライベートブランチはGitやMercurialと使い分けて、trunkから派生させて機能追加して実験したり、トピックブランチ上でパッチを作ったり、色々試せる。 特に、修正の順序とリリースの順序が異なる障害修正のパッチを従来よりも楽にコントロールできるのはよい。 Mercurial以前と以後のチケット駆動開発: プログラマ
Mantisのチケット集計機能にある最大放置日数と平均完了日数 - プログラマの思索
Mantisには要約(summary_page.php)というWebページがチケット集計機能に相当する。 そこに表示されている「最大放置日数」「平均完了日数」についてメモ。 【元ネタ】 MantisBT Git - mantisbt.git/blob - lang/strings_japanese.txt Mantisの日本語化の文言 脱サラ大学生のプログラム日記～Mantisカテゴリ アジャイル開発と品質管理の関係: プログラマの思索 Mantisの要約ページは、Redmineのサマリ画面のように、優先度・開発者・起票者などの観点でチケット数を集計表示してくれる。 その中で興味を引いたメトリクスは、「最大放置日数」「平均完了日数」。 【1】最大放置日数は、チケットが起票されてから未完了のまま放置されている期間を表示している。 RedmineやTracでチケット駆動開発を実践してみると、チ
Mercurialで独立並行リリース管理 - プログラマの思索
「Mercurialで独立並行リリース管理」という良い記事があったのでメモ。 【元ネタ】 Computing Memo of 2008/02/26 パッチを作った場合、そのパッチを取り込む方法はCVS・SVN・Mercurialで違いがある。 例えば、コードラインAのリビジョン修正2にコードライン3のリビジョン修正3を取り込む場合、下記のようになる。 cvs up -j 修正2 -j 修正3 svn merge -r r修正2:r修正3 (A側) hg transplant -s (A')修正3 (前略) むっちゃ簡単! 「どのパッチを取り込む」かを指定するので指定には 「修正3」 とか一個だけでなく何個でも書け，「修正x:修正y」のようにコロンで区切って範囲指定もできる。 そして，既に適用したパッチかどうかはチェンジセットIDで確実に判別してくれるから，リバースパッチなんていうアホな自体
チケット駆動開発の概念は海外に存在するのか？ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CMMIはアジャイル化できるのか？ - プログラマの思索