僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる

Rxtstudyで@kuranukiさんが「RedmineからPivotal Trackerへ乗り換えた」話をしてくれた。 考えたことをラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 Pivotal Tracker - Simple, Effective Agile Project Management & Team Collaboration, from Pivotal Labs Pivotal Tracker: はじめかた Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile Twitter / @minitau: ICEBOX -> BACKLOGに移動して、BACKLOGでステータスをいじる #RxTstudy Twitter / @sousoumt: @@kuranuki さんに補足：Pivotal Tracker

スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がとても良かったのでリンクしておく。 【元ネタ】 スクエア・エニックスのCTOが書いたプロジェクトマネージメントの資料がスゴイ！ at ミネルヴァの梟は黄昏とともに飛び始める 【1】ゲーム業界のソフトウェア開発案件を元にしているが、仕様・納期・人員・品質などの要素が当初見積りよりもわずかに増えるだけで、実績工数が10倍以上に膨れ上がることを簡単な例で説明している。 更に、10倍に膨れ上がった工数は、仕様を減らし、納期を延ばし、人員を大量投入し、品質を落とし、更に開発者の労働時間を80％増やせば帳尻が合うという話から、簡単にデスマーチに陥ると説明しているのが分かりやすい。 実際は簡単なモデルでは説明できないだろうが、感覚的にはフィットする。 プロジェクトがデスマーチに陥るきっかけは、各要素の些細なギャップから生まれる。 それ

下記プラグインをインストールしてみたら、バーンダウンチャートの表示が可能だけでなく、機能が豊富でとても素晴らしかった。 以下メモ書き。 【redmine_charts】 Redmine - PluginCharts - Redmine mszczytowski's redmine_charts at master - GitHub pullmonkey's open_flash_chart at master - GitHub ruby on railsでグラフを作成する。Open Flash Chart編←【2009/11/18 追記】 【インストール方法】 $redmine/vendor/plugins へredmine_charts、open_flash_chartのフォルダを解凍して配置する ※open_flash_chartフォルダがないと、redmine_chartsが動作しな

Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる

「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には、変更履歴と言うリリース履歴の機能がある。 この機能がいかに重要か、ラフなメモ書き。 【1】チケット駆動開発では、バージョンをリリースしたら、自然にリリース履歴が残る。 SVNコミットに必ずチケットをリンクさせれば、終了チケットがリリース履歴になる。 リリース履歴は何故重要か？ いつ何をリリースしたのか、という記録だから。 手作業でリリース履歴を作ろうとすると作業漏れがおきやすい。 RedmineのようなBTS、Hudsonのようなビルドツールを使っていないチームでは、リリース履歴を自動作成することができないので、リリース履歴をExcelのリリース台帳で管理しているだろう。 例えば、開発者が修正したソースにタグを付けてリリース台帳に記載して、ライブラリアンはリリース台帳を見てビルド＆デプロイを実施するワークフローにしているだろう。 このワークフローはExcelのリリース台

大前研一が、英語・IT・財務がサラリーマンの三種の神器と言っている。 特に財務について、考えたことをラフなメモ書き。 ＃初歩的な内容なので注意。 【元ネタ】 はじめての財務管理 決算診断情報：決算診断「第１４回　損益計算書のカンタンな見方(3)」 決算診断情報：決算診断「第３３回　経営分析解説―生産性（１）」 付加価値 付加価値のつかみ方（分析ポイント講座⑦）: salon tamaken N's spirit　損益分岐点とは　損益分岐点分析とは　CVP分析とは IT技術者ならば、英語とITは日頃からたぶん慣れている。 でも、財務だけは取っつきにくい。 財務とは業務知識の元ネタであり、簿記を知らなければ理解できないだろう。 普通は、簿記3級程度の知識は必須であり、簿記2級の商業簿記まで理解しなければ、実際の株式会社の業務フローは、最終的にモデリングできないだろうと思う。 簿記を習得した後、

Redmineによるチケット駆動開発を通じて、Agile開発の利点や特徴、その弱点も少しずつ理解できてきた。 今後の進化の方向も含めて考えてみた。 以下はあくまでもラフなメモ書き。 【1】現代のSW開発マネジメントは、従来の品質・コスト・納期の三角形から、スコープ・コスト・納期の三角形に変わっている。 この事実は、現代では納期(Deliveriy)の重要性がすごく高まっていることを示唆している。 実際、3ヶ月後の景気すら分からない状況で、数年越しのプロジェクトを実施するビジネスは非常にリスキーになっているからだ。 Agile開発は、WF型開発よりも納期重視の開発スタイルと言える。 Agile開発の開発スタイルは、XPのイテレーション又はScrumのスプリントというタイムボックス単位で順次リリースしていく戦略をとる。これは、納期が2～4週間後に定期的に決まっていて、チームメンバーは数人で固定

ジョエルテストで有名なJoel Spolsky が書いたMercurial チュートリアル hginit.com を和訳していたサイトがあったのでリンクしておく。 MercurialがSubversionとどのように違うのか、そして、どのように使えば効果的なのか、説明がとても分かりやすい。 【元ネタ】 Mercurial チュートリアル hginit.com の和訳 (Contents) - mmitouの日記 Subversion Re-education (Subversion 再教育) Ground up Mercurial (Mercurial の基礎) Setting up for a Team (チームのために設定する) Fixing Goofs (失態に備える) Merging (マージする) Repository Architecture (リポジトリ構成) 構成管理ツール

まちゅさんの記事を読んで思ったことをメモ。 【元ネタ】 「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06) 今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました - SiroKuro Page 「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06)のような状況は、僕も経験した時がある。 本番ソースはRational Clearcaseで厳格に管理されているため、開発チーム内部ではSubversionでソース管理していた。 そして、全て出来上がったら申請書を出して、承認してもらった後、全員で手分けしてClearcaseへ一括コミットする。 やりにくくて仕方ない

「バージョン管理ツールを使うとやる気が出る」という文章に激しく同感。 【元ネタ】 論文を書くときにTeXを使う個人的な理由 - より良い環境を求めて (前略) それからバージョン管理ツールを使うとやる気が出る。 これはgitwebを使い出した効果で、履歴一覧で前回の変更からの経過時間が「1 hours」とか出る。 これが「5 hours」とかになってくるとやばいという気になってきて、とりあえず何でもいいからコミットする。そうすると、やる気はやり始めてから出るの法則で少しずつ進む。 「3 days ago」とかになってきたらもう「。」を「．」に変えるだけとか「である．」を消すとかそういう些細なことでも何かコミットしなきゃという気になってきて、そこから書き始めることができる。 (後略) ソースだけでなくExcelやWordに書いた設計書もバージョン管理すべき。 更新履歴を見るだけで、更新しなき

Redmineの各機能から眺めたチケット駆動開発の課題についてメモ。 ラフなメモ書き。 【プロジェクト】 「Redmineのプロジェクトはどんな単位で作るべきか？」という質問は良く出る。 僕がTiDDをアジャイルに運用した経験から言えば、二つある。 一つ目はブランチのライフサイクルに合わせる。 二つ目はITILの運用保守プロセスに合わせる。 前者は、RedmineのプロジェクトがSCMリポジトリと1対1に対応している思想から、自然に扱える。 例えば、本番リリースしたソースは本番ブランチとして作られて、trunkとは別のコードラインで保守される。そして、次のメジャーバージョンが出たら、古い本番ブランチは廃止されて、以後は保守されなくなる。 つまり、プロジェクトとブランチが1対1に対応する状態遷移になる。 プロジェクト：新規作成→使用中→非公開→終了 ブランチ：新規作成→使用中→廃止(以後保守

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

Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t

久しぶりにRedmineを使い始めた。 やっぱりTracよりもRedmineの方が楽しい。 バージョンにチケットをアサインして、チケットの取捨選択を考えたり、ソースコミット時にチケットNoを書いてリンクさせたり、チケットを消し込んでバージョンをリリースへ持っていくのが楽しい。 Redmineの方がチケット駆動というよりもバージョン駆動なので、その感覚がアジャイル開発とフィットしていてすごく好き。 TestLinkも最新バージョンを実験的に使い始めた。 テストケースやテスト結果にテスト予定日・実績工数・予定工数を入れると、TestLink上で集計する機能があるようだ。 まだまだ使い勝手は悪いけれど、TestLinkにテストの進捗管理機能ができてガントチャートを表示できるようになれれば、強力になるだろう。 MTGというPairwise法でテストケースを自動生成するExcelマクロを試している。

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

Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。 【元ネタ】 Mercurial の利用 特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) ダウンロード - TortoiseHg - SourceForge.JP 「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。 平易に書かれていてとても読みやすい。 また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。 エピローグに「あ！構成管理って楽しいんだ？！」という節がある。 Mer

RedmineとMercurialの連携の設定をメモ。 【元ネタ】 RedmineでMercurialを使う方法 - 床のトルストイ、ゲイとするとのこと TortoiseHgでExcelの差分を見る方法: プログラマの思索 All In One Redmineを見つけた: プログラマの思索 Windows＋Redmine0.8.4＋ToroiseHg0.8.1では2箇所でエラーが発生する。 修正方法は下記の通り。 【修正対象】 lib/redmine/scm/adapters/mercurial_adapter.rb 【修正箇所】 L27 HG_BIN = "C:/Program Files/TortoiseHg/hg.exe" L40 theversion = "1.3.1" L27では、元来Unix上のHgのパスをTortoiseHgのパスへ変更する。 L40では、Mercuiralの