Redmine・Trac・Mantisによるチケット駆動開発を4年間やってきて、いつも新しい観点を発見している。 最初はRedmineプロジェクトへ組織構造をマッピングする件について考えたことをメモ。 全3回の予定。 【0】最初は小規模プロジェクトでRedmineを運用し始めて、じきに保守ブランチが必要になったり、メンバーが増えて複数チームになったり、現行ソースを他の顧客へカスタマイズして販売する派生開発になったりすると、複数プロジェクト機能を使わざるを得なくなる。 あるいは、一つの組織でいきなり全てのプロジェクトへRedmineを導入して運用しようとすると、Redmineプロジェクトの構造をどのように決めるか、考えなくてはならない。 自分が過去に運用したり、周囲を見聞きしてきて、下記の3パターンでまとめられるように思う。 それぞれについて解説してみる。 (1)派生プロジェクト (2)保守

RedmineのTime Trackerプラグインは、実績工数をタイムウォッチのように簡単に計測してくれるので便利。 しかし運用の注意点があるのでメモ。 【元ネタ】 RedmineのTimeTrackerプラグインが使いやすい: プログラマの思索 Twitter / @bageljp: RedmineのチケットにToodledoやHiTaskみたいなタイマー機能ないのかね。実績工数をいちいち手動入力って面倒すぎ。作業の開始と終わりにボタン押して時間計測してくれれば楽なのになー。 Twitter / @akipii: @bageljp Time Trackerプラグインが良いです。 - Plugins - Redmine redmine.org/plugins/redmin… Twitter / @bageljp: @akipii ありがとうございます！！早速入れて使ってみましたが、まさにイ

「git-flow によるブランチ管理」という記事で、分散バージョン管理ツールを使った構成管理手法をとても分かりやすく書かれていた。 以前僕が書いた記事を見直して、理解が足りなかった部分があったと感じたので、もう一度まとめてみた。 【元ネタ】 git-flow によるブランチの管理 - O'Reilly Japan Community Blog A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind 見えないチカラ: A successful Git branching model を翻訳しました A successful Git branching model: プログラマの思索 Mercurialで独立並行リリース管理: プログラマの思索 Mercurialによるチケット駆動開発は強力だ！: プログラマ

バーンダウンチャートを見れば、チームの進捗だけでなく、チームの成熟度やその後の予測もある程度可能だ。 良い記事があったのでメモ。 【元ネタ】 InfoQ: バーンダウンチャートを解読する 理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索 最初に、3パターンが紹介されている。 一つ目は、スプリント終了時に残作業量がゼロにならなかったケース。 例えば、スプリント後半にバグが頻発して、計画通りに作業が進まず、重大なバグを解決できずにリリースできなかった状況があるだろう。 二つ目は、スプリント前半は残作業がかなり残って遅延していたが、スプリント中盤からいきなり急角度で残作業が減っていき、最終的にゼロになったケース。 結果オーライかもしれないが、記事では次のように解説している。 「おそらく彼らは積極的に数字を更新することをしなかったことを示す

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

@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。 【元ネタ】 Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。 Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。 【1】Redmineでチケット駆動開発を運用していると、チケットの粒度

AdobeAirでスマートフォン向けアプリ開発をやっていて、アジャイル開発に向いているなあと思った。 考えたことをメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! 資料公開：「納品のない受託開発」にみるソフトウェア受託開発の未来～IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは - Social Change! Twitter / @akipii: 最近のシステム営業では紙や画面だけでは客の反応がなくスマートフォンのアプリのように動く物でないと客が食い付かないと聞いた。だから苦労してるらしい。SIの外側はアジャイルを受け入れる環境があるのに変化に付いていけてない。 Twitter / @akipii: 製品発表時のインパクトは小さくとも同じプラットフォームをユーザーが長期間使い続けられるようにデザインされた製品が着実にユーザーへの浸透を果

さかばさんの記事を読んで思ったことをメモ。 【元ネタ】 [#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011: ソフトウェアさかば [#TiDD] チケット駆動でAdaptable Waterfall開発！: ソフトウェアさかば いきなりBTS/ITSをベースに全ての作業をチケット化してタスク管理する完全チケット方式が難しい場合、補完チケット方式という手法がある。 補完チケット方式の具体例の一つは、テスト工程の障害管理。 又、チケット駆動開発をWF型開発に適用する場合、一番導入しやすいのはテスト工程の障害管理。 要件定義、設計、開発、単体テストと順調に進んでも、結合テスト以降のテスト工程は予期しないバグ修正や突然の仕様変更が頻発しやすい。 そこで、チケット駆動開発を導入したいなら、チケット管理システムをまさにバグ管理として導入して運用すればいい

IPAの定量的プロジェクト管理ツール概要やさかばさんの記事を読みながら考えたことをメモ。 ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 Jenkinsの特長 - メトリクス収集サーバの視点から -: ソフトウェアさかば InfoQ: 継続的デリバリのパターン マネージャから以前、ベースライン単位にタスクの進捗や課題の状況を履歴表示できないか、という問合せを受けた。 彼の意図としては、ベースライン(プロジェクトのマイルストーン)単位に集計して、予定と実績の差を見たいということだった。 僕は、現状のRedmineでは力不足です、と答えた。 その理由は、Redmineのチケット集計機能はユーザが画面表示した時点のチケットの状態を集計表示する機能だけであり、集計結果を履歴表示する機能はないからだ。 バーンダウンチャート、チケットの登録・完了の累積数、ロードマップスなどのプラグインはあるが

Jenkinsコミッタの川口さんの記事を見かけたのでリンクしておく。 【元ネタ】 InfoQ: 継続的デリバリのパターン InfoQ: Jenkinsによる継続的インテグレーションのススメ(1) InfoQ: Jenkinsによる継続的インテグレーションのススメ(2) ~Jenkinsを使い始める~ InfoQ: Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~ (引用開始) 元々CIはこのようにビルド・テストの実行といった狭い分野にフォーカスしていましたが、最近では、汎用の自動化プラットフォームとして、バックアップ・リリース・デプロイメントなどのスクリプト可能な作業をなんでもやらせる事も広義のCIに含んでよいと思います（Continuous Deploymentなどと呼ばれる事もあります）。今までは、こうした作業は担当者が個人の計算機上でスクリプ

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

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

RxtStudyやshinagawa.redmineで見聞したことを思い出しながらメモ書き。 間違っていたら後で直す。 【1】プライベートチケットの使い方 プライベートチケットはVer1.2から追加された新機能。 プライベートチケットに設定すると、初期設定されたロール以外の人からチケットが見えなくなる。 Redmine 1.2.0 released！: プログラマの思索 Redmineの大規模化の壁: プログラマの思索 プライベートチケットの使い道が最初は分かっていなかったが、@g_maedaさんから、Redmine本体の運用から生まれた機能であると聞いた。 例えば、redmine.orgへRedmine自体のセキュリティに関するバグチケットが登録された場合、そのチケットの情報が公開されることでRedmine本体に悪影響を与える可能性があるため、サイト管理者がプライベートチケットで隠してし

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

Redmineでナレッジを蓄積していく方法をメモ。 【1】Redmineにはチケット管理だけでなく、Wikiやフォーラム機能、リポジトリ閲覧機能などがあるので、チケット以外にも情報を蓄積できる仕組みがある。 情報を蓄積していくことができれば、新規メンバーへ説明しやすくなるし、作業の引継ぎも楽になる。 だが、情報を蓄積して保守していくコストをいかに感じさせないようにするか、という仕掛けが大事。 普通はWikiでプロジェクト内部の情報や技術ノウハウを蓄積していくだろうが、Redmineのプラグインで特定目的の情報を蓄積していくこともできる。 下記にあげたようなプラグインがあるようだ。 【用語集】 Redmine 用語集プラグイン: プログラマの思索 Redmine 用語集プラグイン Wiki - SourceForge.JP (引用開始) Redmine(プロジェクト管理システム)に用語集の機

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

本日、Redmineでのタスク管理を考える勉強会＠大阪第1回が開かれました。 スタッフの皆さん、ありがとうございました。 今日の発表資料をCC Attribution ライセンスで公開します。 Redmineを初めて導入した時によく聞かれる質問や、よくはまるアンチパターンについて発表しました。 多分、どれか一つぐらいは経験があるだろうと思います。 「放置されたチケット」は原因が根深いアンチパターンです。実際、他のアンチパターンと同様に発生してます。 「空っぽのロードマップ」はバージョンやロードマップの機能が分かっていないチームに多い。 特に、MantisやTracでは、バージョン(マイルストーン)やロードマップをまともに使っていないチームはRedmineよりも多いでしょう。 Twitter / @akipii: まさにその通りですね。redmineを使う以前の問題なのかも。　RT @agi

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

細谷さんの下記のつぶやきでいくつか考えたことをメモ。 【元ネタ】 Twitter / @yasuohosotani: @akipiiさんがbit.ly/9LRcnhで触れているようにXDDPとチケット駆動はとても相性がいいです。たぶん、USDM作成時に各階層の粒度がある程度そろった結果、1つの変更設計に対する作業量や深さも揃うからだと思っています。 ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（1） - アークウェブシステム開発SandBox ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（2） - アークウェブシステム開発SandBox ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（3） - アークウェブシステム開発SandBox ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（4） - アークウェブシステム開発SandBox www.sakuttol

チケット駆動開発が従来のどんな問題を解決して、どんな新しい観点をもたらしたのか、考えを整理してみる。 【元ネタ】 Twitter / @akipii: ツールの背後にあるチケット駆動開発の意義を汲み取って欲しい。RT @yusuke_kokubo 自分が管理してメンテナンスするならRedmineだけど自分が使う側だったらTracでもJIRAでもなんでもかまわない。ちゃんと使えれば Twitter / @akipii: #redmine ツールの背後にあるチケット駆動開発が従来のどんな問題を解決して、SW開発にどんな新しい観点を提示したのか？を汲み取って欲しいのです。 【1】SW開発の難しさは、結合テスト以降の障害管理ではっきり現れてくると思う。 WF型開発であれAgile開発であれ、ある程度動くモジュールに対して、機能を追加して品質を向上していくプロセスは、そう簡単なものではない。 そもそ