【公開】RedmineのFAQとアンチパターン集 #Rxtstudy

本日、Redmineでのタスク管理を考える勉強会＠大阪第1回が開かれました。
スタッフの皆さん、ありがとうございました。
今日の発表資料をCC Attribution ライセンスで公開します。

RedmineのFAQとアンチパターン集 from akipii Oga

Redmineを初めて導入した時によく聞かれる質問や、よくはまるアンチパターンについて発表しました。
多分、どれか一つぐらいは経験があるだろうと思います。

「放置されたチケット」は原因が根深いアンチパターンです。実際、他のアンチパターンと同様に発生してます。
「空っぽのロードマップ」はバージョンやロードマップの機能が分かっていないチームに多い。
特に、MantisやTracでは、バージョン(マイルストーン)やロードマップをまともに使っていないチームはRedmineよりも多いでしょう。

Twitter / @akipii: まさにその通りですね。redmineを使う以前の問題なのかも。　RT @agilekawabata 空っぽのロードマップパターンは、先にアジャイル開発について研修すべきだと思う #RxTstudy #redmine

また、「工程単位のバージョン」「工程単位のプロジェクト」はWF型開発にとらわれすぎたチームに多いです。

Twitter / @cero_t: アンチパターンとか、質問とか見てると、「Redmine」の使い方を知らないというよりも、「ソフトウェア開発」とか「物事のあり方」を理解してない人が多いっていう感じがしますねぇ。 その使い方はないだろ、という。 #RxTstudy

しかし、会社で既存のツールや開発プロセスが強制されていると、全工程に完全チケット方式を導入するのは難しい時もあります。
そんな時は、補完チケット方式で、一部の工程だけに導入するのもアリだと思います。

Twitter / @akipii: #RxtStudy　Redmineをコードレビューやリリース管理などの特定工程で使っている。ぜんぜんアンチパターンではなく、redmineの特徴を理解してうまく運用されている。

他に、@sakabaさん、@kuranukiさん、@yohhatuさんたちの発表もありました。
@kuranukiさんの発表は衝撃的でしたw

Twitter / @agilekawabata: もうRedmineの話じゃなくて、すごい熱い話になってる #RxTstudy

Twitter / @agilekawabata: @kuranuki #RxTstudy Redmine勉強会で「RedmineからPivotalへ」を熱く語るw

Twitter / @shin1x1: #RxTstudy まさか Redmine 勉強会で、Redmine をやめることを検討するとは。

また、IPAの方が定量的メトリクス収集ツールとRedmineの連携などの話もあり、盛りだくさんでした。
Twitterにも書きましたが、最近のIPAは非常に参考になる資料を公開されてます。

Twitter / @akipii: #RxtStudy　最近のIPAは、RubyやRailsの資料の公開、Agile開発の研究資料の公開など、良い仕事をされている。

IPAが書いたアジャイル開発の研究会報告書: プログラマの思索

IPAが公開したRubyやRails教育プログラム: プログラマの思索

IPAが公開した形式手法の調査報告書: プログラマの思索

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

Railsの性能検証報告書: プログラマの思索

Facebookにもコミュニティページがありますので、今回の感想や次回に期待する内容を書き込んで下さい。

Facebook RxTstudy

【追記】
Togetterに当日のTwitterをまとめておきました。

Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会＠大阪第1回」

@bufferingsさんのTogetterもあります。
Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会＠大阪」

@hiroe316さんがUST・スライドを一つのHPにまとめて下さいました。
RxTstudy vol.1 (2011/07/30) - RxTstudy

IPA大和田さん、@yohhatuさん、@kuranukiさんの発表資料はコチラ。

定量的プロジェクト管理ツール概要 Lt 20110730

View more presentations from hiroetoh

RxTstudy　#1　私のRedmineの使い方@yohhatu

View more presentations from hiroetoh

SonicGarden流タスク管理の紹介

View more presentations from Yoshihito Kuranuki

【追記2】
はてなの感想をメモ。

はてなブックマーク - RedmineのFAQとアンチパターン集

(引用開始)
unarist
自分がなんとなく描いていた理想に近かったので実践したい 2013/12/02

raimon49
チケット棚卸しの話とか多くの人に読ませたい。 2011/08/21

kozy4324
うなずいた、関連スライド後で見よ 2011/08/09
(引用終了)

はてなブックマーク - 【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

(引用開始)
diary193
Redmineに限らずTiDDやタスク管理の「あるある」への対処方法が提示されていて参考になる 2011/08/01
(引用終了)

edubase Streamの講座一覧リンク

@hatsanhatさんのBlogから、コンピュータサイエンスやソフトウェア工学に関する日本の大学講義が無料で提供されている記事を見つけたのでメモ。

【元ネタ】
トップＳＥのための基礎知識｜HATのブログ

edubase Streamの講座一覧 ? 山本隆の開発日誌

僕はまだ見てませんが、「データベース設計論」「エンピリカルソフトウェア工学」「アジャイルソフトウェア工学」「組込みソフトウェア設計論」「並行システムのモデル化と検証」など面白そうなタイトルがずらりと並んでいる。

現代は、ハーバード大など世界一流の大学の授業が動画で無料で見れる時代。
「これからの「正義」の話をしよう――いまを生き延びるための哲学」はまさにその典型例だったのではなかろうか？

インターネットがあるおかげで、地理的に離れていても、世界最先端の知識に触れることができる。
最初は分からなくても、最先端と自分の距離は少なくとも分かる。

夏の夜に見るのもいいかもしれない。

Velocity駆動のイテレーション計画の作り方とは

RedmineやTracから工数集計に関するメトリクスを採取していて、色々気付いたことがあった。
「アジャイルサムライ」「アジャイルな見積りと計画づくり」「アート・オブ・プロジェクトマネジメント」も読んでみて考えたことをメモ。
ラフなメモ書き。

RedmineやTracから工数集計に関するメトリクスから僕が一番抽出したいのは、Velocityだ。
Velocityは開発チームの生産能力を意味する。
Velocityが分かれば、顧客から突然降ってきた要求に対して、開発チームが受け入れる能力があるかどうか、プロジェクトリーダーが判定できるし、顧客へ対応を延期するよう説明することもやりやすくなる。

Agile開発では、複数回のイテレーションを繰り返して最終リリースするから、イテレーション単位の生産能力(Velocity)を計測しやすい。
複数回イテレーションをこなせば、理論的にはVelocityのばらつきもなくなり、安定してくるはず。

「アジャイルな見積りと計画づくり」では、イテレーション計画の作り方として、Velocity駆動とコミットメント駆動をあげていて、コミットメント駆動を推奨している。
「アジャイルサムライ」では、Velocityをチームが分かっているという前提で、Velocity駆動による計画づくりを具体的に説明してくれている。

Velocity駆動でイテレーションを計画すると、バーンダウンチャートで右肩下がりにいつ頃リリース出来るのか、を予測しやすくなる。

「アート・オブ・プロジェクトマネジメント」では、プロジェクト後半の戦略として、残作業の降下速度の調整が重要と書いているが、残作業の降下速度はまさにVelocityを意味していると思う。

XPやScrumが教える所では、Velocityは安定しているものだから、期日までにリリースするには、残作業の量を減らすしか選択肢がない。
つまり、リリース順位の高い作業を優先することで、残作業の量を絞り、残作業の降下速度(Velocity)の先を期日に合わせるように調整するのがAgile開発の本来のマネジメントになる。

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart13 #tidd

「Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ】
2011-07-27 - 「Redmineによるタスクマネジメント実践技法」の輪講を終えて　rasuyuk.log （組み込みから来ました）

(前略)
最後はKPTで問題点の洗い出しと、次回に向けてのフィードバックを得て無事完走したのだった。
終わってみたら、参加者の中から日常業務でも使うようになったり、小さなプロジェクトでも使うようになったりと使い方の勉強もできて、布教活動もできてまさに一石二鳥であった。
(中略)
ということで、実際の運用方法をまとめた書籍はなかなかないので
使い始めたけどどうしていいか分からない方々は読むことをおすすめします。

輪読されたらしいので、フィードバックを聞きたいです(笑)

redmineでナレッジを蓄積していく方法

Redmineでナレッジを蓄積していく方法をメモ。

【1】Redmineにはチケット管理だけでなく、Wikiやフォーラム機能、リポジトリ閲覧機能などがあるので、チケット以外にも情報を蓄積できる仕組みがある。
情報を蓄積していくことができれば、新規メンバーへ説明しやすくなるし、作業の引継ぎも楽になる。
だが、情報を蓄積して保守していくコストをいかに感じさせないようにするか、という仕掛けが大事。

普通はWikiでプロジェクト内部の情報や技術ノウハウを蓄積していくだろうが、Redmineのプラグインで特定目的の情報を蓄積していくこともできる。

下記にあげたようなプラグインがあるようだ。

【用語集】
Redmine 用語集プラグイン: プログラマの思索

Redmine 用語集プラグイン Wiki - SourceForge.JP

(引用開始)
Redmine(プロジェクト管理システム)に用語集の機能を追加するプラグインです。以下のような用途に使えます。
* 業務分析工程での専門用語の管理、社内辞書
* 対訳表
* 用語とデータ型(クラス名)との変換辞書
* コーディング時の略名の付け方の方針管理
(引用終了)

【FAQ】
Redmine - PluginEzfaq - Redmine

Furgas/ezfaq_plugin - GitHub

CentOS 5.xにRedmineをインストールする

「Q&A形式のコンテンツを作成するプラグインです。ただし、質問は題名（1行）だけで詳細を書けず、質問と回答を一緒に記述して登録するので、FAQ作成担当者が各所から集めたQ&Aを整理して登録する使い方が向く機能です。」とのこと。
使い道としては、インシデント管理プロセスで、オペレータが消費者に電話対応の受け答えていくFAQを蓄積した後、HPで公開する方法があるだろう。
「パスワードを忘れてログインできません」という問合せに対しては、HPのFAQを御覧下さい、とかわせばいい。

【蔵書】
Redmine - PluginEzlibrarian - Redmine

zouchaoqun/ezlibrarian - GitHub

CentOS 5.xにRedmineをインストールする

「書籍や物品管理機能を追加します。貸し出し管理、書籍（物品）レビュー記載が行えます。」とのこと。
@mkinside82さんによれば、ネットワーク機器などの資産管理や現物照合に、蔵書プラグインを利用するアイデアもあるようだ。

Twitter / @mkinside82: @akipii 実運用にまではいたっていませんが、デバイスの貸し借りを管理できる事に目を輝かせていました。色々な機器を持っている人なので、誰にいつ貸したのか分からなくなるそうです。全ての機器を登録しておけば、誰にいつ貸したのか管理できるはずです。

Twitter / @akipii: @mkinside82 なるほど。本の管理の場合、ISBN番号という唯一の識別子がありますが、機器の管理の場合、マウスとキーボードとモニタを合わせて一つの識別子にするなどやや複雑になります。資産管理(現物照合)にredmineを使うアイデアは面白いですね。

【ナレッジ】
Redmine - Knowledgebase Plugin - Redmine

alexbevi/redmine_knowledgebase - GitHub

自分の環境に入れてみたものの、使い方がよく分からなかったので、@mkinside82さんに聞いたら、こんな使い方をしている人のこと。
とても参考になる。

Twitter / @mkinside82: @akipii 開発環境/各種の設定方法/運用方法等々を登録しています。他部門の方が同じ事を聞いてきたり、メールで情報共有をしていて、まずはナレッジベース見てみてね、無ければ聞いて下さいねーという運用してます。無い場合に追加しています。検索にもひっかかる？ようです。

Twitter / @mkinside82: @akipii 問題としては、ナレッジ追加が通知されない事でしょうか。 Wikiでもよいのですが、カテゴライズやタグ付、レートが付けられるので良いですね。カテゴリはツリー表示されるので、俯瞰することが可能です。 KPTのKやPへの対処を追加するのも楽しいかと思います。

Redmineのプラグインがこれほど作りやすいのは、Railsアプリであるおかげで、情報を蓄積するテーブル設計さえできれば、マイグレーションで一発でスキーマを生成できて、scaffoldでCRUD画面を一瞬で自動生成できるからだ。
アイデアさえあれば自作してみてもいいかもしれない。

【追記】
知識データベースプラグインが便利！on Redmine.: 100ねんごの未来予想図

Redmine3.2でバージョン管理もできるドキュメント管理プラグイン「DMSF」 | 俺的備忘録 〜なんかいろいろ〜

redmineの作業分類から工数集計～活動基準原価計算

Redmineによる工数集計について考えたことをメモ。

【1】工数集計の問題点

チーム運営する現場リーダーではなく、売上責任を持つマネージャがRedmineに期待する機能は工数集計だろう。
マネージャにとって、プロジェクトの成功とは、品質の良いシステムを確実に納品できるだけでなく、売上がコストよりも高くて利益が出ることだ。

ITプロジェクトは殆どが受託プロジェクトであるから、SEやPGの人月計算、つまり工数集計が重要になる。
特に運用保守のように、一定の金額で契約している場合、当初の予定工数よりも大幅に実績工数がオーバーしたら、ビジネスでない単なるサービスに過ぎない。
だから、予定工数よりも実績工数が上回らないように、もし上回ったとしても、多少の赤字に抑えるようにマネジメントしなくてはならない。

しかし、工数集計の作業は面倒極まりない。
従来のExcelの場合、メンバーに月末に指定のExcelフォーマットで集計報告させて、そこから活動別に集計しなおす必要がある。
何故なら、本来の契約範囲内の作業もあれば、自社の作業で契約外の作業の場合もありうるから、それらを厳密に区別しなくてはならないからだ。

更に、改善要望別に予定・実績工数を集計する必要もある。
何故なら、改善要望ごとにどれだけのコストがかったのかを顧客へフィードバックして、コストに見合った改善が行われたのか、評価するデータを提供しなくてはならないからだ。
しかし、改善要望別に実績工数を把握するには、メンバーにテーマ別に毎日、工数入力を強制しなければならない。
特に、複数のタスクを掛け持ちで作業しているメンバーにとって、毎日の工数入力はかなりの手間がかかるから、とても嫌がる。

また、開発チームとしては、サブシステム単位あるいは機能単位に、問合せ調査や障害対応、改善要望の実績工数を把握しておきたいものだ。
何故なら、どの機能で顧客から問い合わせが多いのか、本番環境で障害が多いのか、どれくらいの対応工数がかかるのか、をまとめて、今後の是正対策や予防対策に役立てたいからだ。

しかし、実際のタスクは複数機能にわたるタスクもあるし、ドキュメント作成のように特に機能に依存しない管理工数の範疇もある。
すると、それらの工数は、各機能へ均等に配分(按分)する必要があり、その計算はとてもややこしい。
その計算はExcelだけでは役不足で、Accessを使って一つのプログラムを作るぐらいの手間がかかってしまう。

【2】活動基準原価計算(ABC：Active Based Costing)とは

工数集計の考え方は最終的には活動基準原価計算、つまり原価計算の考え方に通じる。
渡辺さんの「生産管理・原価管理システムのためのデータモデリング」の最終章に、SEの立場から活動基準原価計算について優れた解説があり、とても分かりやすい。
また、下記のITProの記事も分かりやすい。

ABC（Activity Based Costing：活動基準原価計算）／ABM（Activity Based Management：活動基準原価管理）：ITpro

製造間接費の予定配賦と原価計算表: 簿記２級　工業簿記の考え方

第7章直接原価計算

ABC（活動基準原価計算） - Q-BPM

レポート：＜役に立つ管理会計＞活動基準原価計算（ＡＢＣ）

活動基準原価計算の発端は、多額の間接費をいかに按分するか、本来の原価とは何か、という問題に対して生まれたようだ。
詳しくは、簿記2級の工業簿記、簿記1級の原価計算を勉強すると良い。

活動基準原価計算では、一つのサービス(製品、システム)のコストをどんぶり勘定で原価を収集するのではなく、活動(アクティビティ)単位で細かく原価を集計して、それらを分析することに利点がある。
上記のITProの例では、コールセンターのオペレータの人件費を、サービス単位ではなく、電話対応や資料作成、会議などの活動単位で労働時間を記録し、そこから原価を計算する。

そうすれば、本来の活動でどれだけの価値創出があったのか、を厳密に計算できるようになる。
ITProの例では、電話対応よりも資料作成や会議に多くのコストがかかっているならば、コールセンターの仕事の生産性は実はあまり高くなかったのではないか、という評価を出すこともできる。

【3】Redmineの工数集計機能は使い物になるか？

Redmineの場合、チケットに予定工数と実績工数はデフォルトで付いている。
Redmineの工数集計のViewは、何通りもある。

例えば、バージョン単位で工数集計したいならば、バーンダウンチャートが相当するだろう。
Chartsプラグインや@daipresentsさん作成のバーンダウンチャートプラグインを使えばよいだろう。

redmine_chartsプラグインでバーンダウンチャートは表示可能: プログラマの思索

Redmineに入れたプラグイン一覧part2: プログラマの思索

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

メンバー別に工数集計したいならば、WorkTimeプラグインを使えば良い。
WorkTimeプラグインは、実績工数の入力のUIもとても優れているので、日々の実績工数の確認もしやすい。

RedmineのWorkTimeプラグイン: プログラマの思索

あるいは、テーマ別に工数集計したいならば、チケットの親子関係(Subtasking)を使えばいいだろう。
つまり、親チケットはテーマ(改善要望)ごとの集計用チケットとして、子チケットに各メンバーのタスクを登録しておけば、親チケットへ予定・実績工数や進捗率を自動集計してくれる。

また、プライベートチケットを使って、顧客へ見せる必要がないタスクはプライベートチケットにして、工数集計から外す運用もしてもいい。

但し、Redmineのデフォルトの工数表示機能であるレポート機能は正直UIが弱い。
せめてCSV出力できるようにして欲しい。

【4】RedmineにあってTracにない機能は「作業分類」という項目だ。
「作業分類」は日々の実績工数をラベル付けする属性であり、これがまさに活動基準原価計算の「活動(Activity)」に相当する。
すなわち、Redmineの作業分類をうまく使えば、活動基準原価計算に応用することもできるだろう。

僕は以前、作業分類を「設計」「開発」「テスト」「リリース」などのように工程別に入れていたが、あまり役立たなかった。
活動基準原価計算の考え方に従うと、原価計算の観点から活動単位を作業分類に割り当てるべきだろう。

すると、Redmineの作業分類には、「会議」「レビュー」「本来の開発」「リリース」などのように、1人だけの作業時間と、複数人で行う作業に分けた方が良いと思う。
例えば、「本来の開発」よりも「会議」「レビュー」に時間がかかりすぎている場合、そのタスクはかなりの無駄が含まれている事が分かる。

この考え方を発展させると、Redmineの作業分類は、新規開発プロジェクトよりも運用保守、ITプロジェクトよりも営業チームのタスク管理やインフラチームのタスク管理の方に向いていると思う。
何故なら、営業チームやインフラチームのタスク管理では、ITSとSCMを連携する機能よりも、タスクの工数集計と原価計算を組み合わせる方がはるかに価値があるからだ。
特に、ITILをRedmineで運用した場合、インシデント管理・問題管理・変更管理・リリース管理の各プロセスでどれだけの工数がかかったのか、を集計して分析する方が、その後の改善に役立つ。

【5】Redmineの工数集計は、バージョン別・人別・テーマ別・作業分類(活動)別の観点で、集計して分析することが可能だ。
そこから原価計算という考え方を取り入れることも可能。
色々試してみる。

アジャイルイサムライを読んだ

@sakaba37さんが「アジャイルサムライ－達人開発者への道－」先に購入していて、ちょっと読んだらいい感じだったので、即購入してみた。

【参考】
アジャイルサムライ ――達人開発者への道｜Ohmsha

[Agile][書評]アジャイルサムライー達人開発者への道 #agilesamurai | Ryuzee.com

「アジャイルサムライ－達人開発者への道－」の出版おめでとうございます！ #agilesamurai - かおるんダイアリー

blog.shu-cream.net: なぜ私はこんなにも「アジャイルサムライ－達人開発者への道－」が好きなのか

アジャイルサムライが異常に読みやすい件 | 48JIGEN

【読書会】
アジャイルサムライ in ドワンゴ道場 - GitHub

第1回アジャイルサムライ読書会 渋谷道場 #agilesamurai on Zusaar

「アジャイルサムライ－達人開発者への道－」は既に色んな人達の感想がのっている。

僕の率直な感想は、XPを経験した人がScrumや最近のアジャイル開発のトレンドをうまく取り込んで現場に活かした体験を上手く書いている本と思う。
実際、「用語と言葉づかいについて少し」の段落では、著者がXPが好きだと告白した後で、XPとScrumの用語を整理して、どちらを使っても同じだよ、と書かれている。

Redmine・Trac・Mantisでチケット駆動開発を実践していたから、「アジャイルサムライ－達人開発者への道－」に書かれている内容はまさに体験した通りだ、と思ってしまった。
また、「アジャイルサムライ－達人開発者への道－」に出てくる「期待のマネジメント」「プロジェクト憲章」はPMBOKに由来があるし、「アジャイルな方向付け」「アジャイルな計画づくり」などのタイトルからはRUPのプロセスを想起させる。
そんなことを思い浮かべると、著者は大変な博学で、それらの知識をアジャイル開発にうまく適用しているように思える。

今度アジャイル開発の本を書く時があったら、「アジャイルサムライ－達人開発者への道－」のような本を書いてみたい。

日経Systemsにredmineの記事を書きました

日経Systemsの2011/8月号に「開発支援のマストツール」としてRedmineの記事を@sakaba37さんと書きました。
一部の方は既に読まれているようです。

【元ネタ】
日経BP書店｜雑誌バックナンバー　-　日経ＳＹＳＴＥＭＳ2011年8月号

Twitter / @kaorun55: 今月の日経SYSTEMSにあきぴーさんと、さかばさんのRedmineの記事がのってたー

Twitter / @teyamagu: 第3特集でしたねー QT @kaorun55: 今月の日経SYSTEMSにあきぴーさんと、さかばさんのRedmineの記事がのってたー

Twitter / @kotashan: お、今月号の日経systems届いてる。redmine用に契約したserversmanがほっぽってある(おい)ので、明日はちょこっと再構築してみっかな。やってる業務が90度変わったから、ただの再インストールでよさげ。

Twitter / @cointoss1973: Redmineのメリット (1)進捗や品質をWeb上で一括管理できる (2)メンバーの実績工数入力が容易で工数集計はツールで自動化可能 (3)課題の状況はチケットの履歴として残るので情報共有が楽 (4)細かな作業を漏れ無く管理できアジャイル開発と相性が良い(日経SYSTEMS)

Twitter / @ABORTED: 日経SYSTEMのRedmineの特集読んでます。うちのタスクチームの進捗管理に使えないものか。

Twitter / @mkinside82: 日経システムズのRedmine記事読んだー。社内のみなさんへ回覧しなきゃ！とてもわかりやすい内容です。

Twitter / @kami_teru: マネージャーに「Redmineの記事あるよ」と手渡された日経SYSTEMSの2011.8月号。@akipii さんの記事だった。あきぴーさん、読んどきます!

今回の記事は、マネージャ向けにRedmineでどんな問題を解決できて、どのように運用できるのか、を簡単に説明しています。
今までのTracやRedmineの記事は開発者向けがターゲットでしたが、今回はマネージャのような管理職をターゲットにしているのが最大の特徴になります。

Twitterを日々見る限り、開発者は積極的にRedmineを導入して運用を試している人が多い。
しかし、PMやPLクラスの人達は、そもそもBTSやITSのようなツールを導入しようという意気込みはあまり感じられない。

その理由の一つは、ツールを導入したとしても、どのように運用すれば効果的なのか、というノウハウが足りないからだと思う。
20年以上前からCaseツールや開発プロセスをセットにしてプロジェクトへ導入してきた所はとても多いが、実際の現場では、インストールや設定作業が大変だったり、作業履歴や実績工数の入力負荷が高かったりして、さほどありがたみが感じられなかったのではないだろうか？

RedmineやTracは運用方法をうまく考えれば、過去の有償ツールよりも高機能であり、足りない機能は実際にプラグインで作ればいい。
「No Ticket, No Commit!」「Ticket First」の運用ルールによって作業履歴や実績工数は必ず入力されるし、入力の手間を省いて、ゆるやかにログを収集する仕掛けがRedmineにあるのが最大の利点だろう。
特に、マネージャが一番こだわる顧客向けの進捗報告や課題一覧の元ネタはRedmineのDBに一元化されているので、その情報をワンクリックで出力できるような機能をもっと強化すればいいと思う。

わずか8ページの記事なので、細かく書けてませんが、RedmineでScrumを実践できるBacklogsプラグインについても若干記載しています。
読まれた感想は、#redmineのハッシュタグでツイートしてくれると嬉しいです。

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd

チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。
考えたことをメモ。

【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。
過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。

しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。
ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。
WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。
試行錯誤やリスクをあまりにも恐れている気がする。

Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。
チケット管理は結構泥臭い。

でも僕はそれでいいと思う。
100％計画通りにプロジェクトが進むようなら、それはルーチンワーク。
チケット駆動開発上でAgileに開発していると、アウトプットを少しずつ出しながら、目の前の大きな問題をいきなり解決するのではなく、問題のサイズを少しずつ小さくして、最終的に解決できるようにしていく。

【2】RedmineやTrac、Mantisでチケット駆動開発を運用して上手くいっていないチームを見ると、普通は、バージョンやロードマップの機能を全く使っていない。
だから、いつ何をリリースするのか、という基準がないために、数百枚のチケットを精査するのに難儀している場合がとても多い。
つまり、リリース計画がないので、本番リリースは1回だけと想定しているようだ。

そのアンチパターンの具体例は下記に書いた。

バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠～マイルストーンの役割を誰も理解していない: プログラマの思索

日本のWF型開発は、経産省が出した共通フレームでフレームワーク化されており、そこでは、本番リリースが1回なんて書いてはいない。

「共通フレーム2007 第2版」の発行

でも、開発チームの中にいると、最後の本番リリースだけのために作業して、リリース後の作業はあまり考えていないメンバーがとても多い。
本番リリースさえ終われば全て丸く収まることはありえない。
リリース後にユーザが実際に使って、障害や改善要望が上がって、それらに対処して、少しずつ改善していくサイクルが必要なのに。

多分、受託プロジェクトでは、開発工程とテスト工程に大量の開発者が動員されて、リリース後はプロジェクトから離れる開発者が多いため、本番リリースは1回だけで終わりという雰囲気になってしまうのだろうと推測する。

【3】また、WF型開発の概念にこだわりすぎて、RedmineやTrac、Mantisによるチケット駆動開発がうまくいっていないチームもよく見かける。
悪いWF型開発に囚われたチームは、Redmineバージョンを工程単位に作ったり、Redmineプロジェクトを工程単位に作ったりしている。
そのアンチパターンについては下記に書いた。

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

工程単位にバージョンを作った場合、要件定義バージョン、設計バージョン、開発バージョン、結合テストバージョンのようになる。
すると、レビューや障害修正のたびに過去の工程のバージョンにチケットが追加されて、手戻り作業が発生する度にバージョンがReOpenされてしまうため、いつまで経っても、どのバージョンもCloseされない。
つまり、バージョンがイテレーションに対応していないため、ズルズルと納期が伸びる。
バージョンを工程単位にアサインしたロードマップは、そもそもリリース計画ではないのだ。

又、大規模プロジェクトで工程単位にRedmineやMantisのプロジェクトを作った場合、要件定義プロジェクト、設計プロジェクト、開発プロジェクト、結合テスト障害プロジェクトのようになる。
要件定義や設計プロジェクトでは、チケットのカテゴリを各チームに対応付ければ、課題管理に使えるので、最初は問題ない。

しかし、レビューや障害修正、後になって判明した仕様変更が起きると、手戻り作業が発生するので、どのプロジェクトにチケットを登録したらいいか分からなくなる。
例えば、障害の修正では、当然、設計書も修正するし、修正モジュールも検証するし、障害調査で新たな課題が出てくる時もある。
それらチケットは各工程のプロジェクトへバラバラに登録されてしまうので、タスクも管理しづらくなる。
つまり、各工程のプロジェクトのロードマップは、一つの製品のリリース計画になっていないので、成果物の変更履歴を追跡しづらい。

工程単位にバージョンやプロジェクトを作る場合も同様に、作業やリリースの判定基準、リリース計画があいまいだ。
設計をきちんとやってから開発して、全部ソースを書き終わったらテストを開始するという綺麗なやり方に固執し過ぎている。

【4】悪いWF型開発の最大の特徴は「工程単位に綺麗に開発して本番リリースは最後の1回だけ」という点に尽きると思う。
本番リリースが1回だけなので、頻繁にリリースしながら機能も品質も改善していくという小規模リリースの発想がそもそもない。
だから、イテレーションという概念が発生しない。

イテレーションという概念がない特徴から出てくるアンチパターンは下記に書いた。

TiDD初心者が陥りやすい罠～バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

イテレーションの考え方は締め処理と同じ: プログラマの思索

イテレーションがCloseされるタイミングで、終了チケットの実績工数やシステム規模が確定する。
すると、そこからScrumが発見したVelocityという概念が出てくる。
つまり、イテレーション単位の開発チームの生産能力が確定する。

XPやScrumが教える所では、開発チームの生産能力は安定すべきものであり、増やすべきものではない。
マネージャは、1イテレーションの作業量を2倍くらいに増やしたくなるが、そうするとメンバーを増やす対策をとる時が多く、それはチームに混乱をもたらす。
人月の神話で知られているように、チームの人員が増えるほど、開発チームの生産能力は逆に落ちていく。

WF型開発では、イテレーションという概念がないのでVelocityを収集しにくい。
だから、チームの生産能力が分からないので、普通は作業負荷が大きくなりがちで、メンバーに残業や休日出勤を強いる。

【5】チケット駆動開発はおそらく、どの開発プロセスでも、どの業界でも適用できるだろう。
その場合、チケット駆動開発の運用例から、どのような特徴が見えてくるのかを色々調べてみたい。

Redmineインフォメーションプラグイン

Redmineインフォメーションプラグインをインストールしたのでメモ。

【元ネタ】
Redmine Infomation - Redmine インフォメーション プラグイン - Redmine

ダウンロード - Redmine インフォメーション プラグイン - SourceForge.JP

Graphviz の簡単なサンプル

RedmineのVer1.2.0では、rp-information-0.2.1.zipであれば正常動作した。
Redmineインフォメーションプラグインの古いバージョンでは、Rails情報を表示するときに落ちるので注意。

Redmineインフォメーションプラグインが優れているのは、ワークフロー画面でステータスの状態遷移図をGraphvizで表示してくれること。
ステータス名が日本語でも文字化けしない。

似たようなプラグインとしては、redmine_workflow_vizもある。
このプラグインは以前試した。

Redmineのワークフローを視覚化: プログラマの思索

Redmineに入れたプラグイン一覧part3: プログラマの思索

Redmineインフォメーションプラグインはワークフロー以外にも、権限レポート、Wiki マクロ、Rails 情報をサイドバーへリンク表示してくれるので、ワンクリックで確認できる。
権限レポートは、ロールと権限の画面を一度開いてからリンクしないと表示できないので、ワンクリックで操作できず、ちょっと不便だったから、とても役立つ。

Redmineインフォメーションプラグインの作成者であるyoshidaさんは、r-labs - プラグイン開発ガイド - Redmineを書いて下さったり、とても素晴らしい仕事をされている。
早くTwitterデビューしてくれないだろうか？(笑)

【追記】
さっそくRails情報出力を修正したバージョンが公開された。

Twitter / @yohshiy: Redmine インフォメーション プラグイン プロジェクト日本語トップページ - SourceForge.JP http://t.co/ZwJeIwS via @sourceforgejp Rails 情報の不具合修正しました(0.2.2)。

Rails を知らない人のための Redmine プラグイン開発ガイド: プログラマの思索

【告知】アジャイル同人誌UltimateAgileStoriesが販売されます #uastories

アジャイル同人誌UltimateAgileStoriesが、8/14に開催されるコミックマーケット80@東京ビックサイトで販売されます。
ご興味のある方は是非買って読んでください。
利益は、全額、東日本大震災の被災地支援として寄付されます。

【参考】
UltimateAgileStories About

スクラムを味方につけろ！ - SEA関西プロセス分科会 -: ソフトウェアさかば

【本の名称】
Ultimate Agile Stories Iteration1

【著者(編者)】
Ultimate Agile Stories編集部

【販売価格】
2,000円

【目次】
※正式な目次はコチラ。
UltimateAgileStories目次

UltimateAgileStories刊行にあたって
アジャイル放談／Ultimate Agile Stories編集部
日本のアジャイル１０年、人々とコミュニティの物語／平鍋 健児
ソフトウェア開発の3種の神器～チケット駆動開発を支えるツール群／小川 明彦
学術研究論文に学ぶアジャイル開発の有効性の示し方／森崎 修司
やる夫で学ぶTDD／太田 健一郎
アジャイル開発者への警鐘／新保康夫
アジャイルはどこから来たのか、それは何か、どこへ行くのか？／羽生田 栄一
アジャイル怖い～／徳冨 優一
神様からのプレゼントはアンラッキーのおまけつき ～ あるエンジニアのタイムボックスの使い方 ～ ／前川 直也
エクストリームプログラミング／天野勝
Redmineと私／@yohhatu
アジャイル開発とRuby／川端光義
「とりあえず、生」のあなたへ／永瀬 美穂
アジャイル×テスト開発を考える UltimateAgileStories編／細谷 泰夫
テスト×アジャイルFAQ／agile.swtest
一人称の組織変革をまじめに考える Fearless Change という本を読んでいます。／川口 恭伸
チームビルディングでもにょもにょ／えと～(@hiroe316)
継続的改善フレームワークとしてのScrum／tetsu_m（てつ。）
アジャイル、始めました／山中美智子
仕事としてのアジャイルと労働としてのアジャイル／岡島幸男
アジャイル失敗は蜜の味／牛尾　剛
時をかけるテスト　～CIのテストをどう作るか／井芹 洋輝
EM ZEROの作り方／野口隆史
継続的フィードバックとツール活用／長沢 智治
チケット駆動開発はアジャイル1次ブームの夢を見る／阪井誠
僕がXPを選んだワケ　─ Can't live without XP! ─／西 丈善
手段と目的／山根 英次
コミットメントとは何か？／吉羽 龍太郎(@Ryuzee)
始まらなかったAgileの話をしよう。／市谷 聡啓／papanda
日本におけるアジャイル開発適用の問題点と展望／長瀬嘉秀
自転車にはアジャイルのヒントがある！／土屋ひでみつ
アジャイルからはじめる社会変革／Takeshi Kakeda
おわりに

【入手方法】
コミックマーケット公式サイトへようこそ
2011/8/14（日) コミックマーケット80@東京ビックサイト
東2ホールのP29b　

その後は、アジャイルのイベントなどで販売予定です。

【感想】
XPJUG関西の細谷さんが発起人となって、目次を見ての通り、日本の主なAgile関係者が集まってアジャイルについて書いた同人誌です。
僕も執筆者の一人として書かせて頂きました。

同人誌ゆえに執筆者が自由に書いているので、読んでみると面白いと思います。
僕の一押しは、平鍋さん、西さん、川端さん、牛尾さんの記事です。
皆さんの個人体験が含まれていて、とても熱い！
日本のアジャイルコミュニティで活動している人達が読んだら、じーんと来るものがあると思います。

【追記】
感想や問合せは、ハッシュタグ#uastoriesでTweetしてください、とのことです。

【補足】
ソフトウェア業界の同人誌は他にもあるそうです。

ソフトウェアエンジニアのコミュニティを引っ張る有名人が寄稿する同人誌3冊：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ

アジャイル日本上陸10年。そしてアジャイル同人誌が。：ITとビジネスの可能性：ITmedia オルタナティブ・ブログ

UltimateAgileStories 同人誌が発売！寄稿しました。 #uastories - 長沢智治のライフサイクルブログ - Site Home - MSDN Blogs

DOAとOOAの違い

@hatsanhatさんにDOAの質問をしたら、とても参考になる回答をもらったので、僕の理解の範囲内でまとめてみる。
＃間違いがあったら後で直す。

【参考】
モデラーとは:アーキテクト360

review 生産管理・原価管理システムのためのデータモデリング- Ynishi Bussiness Logs

Domain Logic and SQL - Ynishi Bussiness Logs

(1)リレーションシップはキーという「証拠」があるから引ける

OOAでは、クラス同士の関連は簡単に引ける。
クラス同士の関連はビジネス上の制約から発生するけれども、それを表現するのは多重度ぐらいしかない。
コンポジションと集約の違いはOOAではあいまいに表現されやすい。
実際、クラス図で関連がコンポジションなのか制約なのか、を意図的に明示するモデラーは少ない。
また、関連クラスは分析モデルで表現されるだけであり、実装モデルでは消えてしまう。

連関エンティティと関連クラス: プログラマの思索

しかし、DOAではエンティティ同士の関連はそう簡単に引けない。
リレーションシップを貼るには、親子・参照・派生関係のいずれかが必要であり、それらを真面目に考えると、キー(識別子)の整合性を考慮しないといけない。
キーをエンティティに作ると、キーによってエンティティの性質が固定化されてしまう。

@hatsanhatさんは、DOAは現実の業務（正確には帳簿組織）をどう設計するかを考えるが、ＯＯＡはオブジェクトという抽象的なものを仮定してそれの設計図を書こうとしているだけに過ぎない、と言われているが、なるほどと思う。
OOAは、既に要件が固まって概念モデルが固まった後の設計工程では、開発までスムーズに連携できるが、肝心のシステムの全体像を見出す工程は正直難しい。
アナリシスパターンやドメイン駆動設計は、システム化提案や要件定義などで出てくる概念モデル設計で役立つアイデアだが、DOAのような厳しい制約を課すわけではないので、経験値が高くないとOOAは難しいだろうと思う。

(2)DOAでは、親子・参照・派生関係の3つの制約の違いを理解しておくのが重要

親子関係は、注文ヘッダ・注文明細のように主キーが複合キーになる。
普通は、二つのマスタの値の組み合わせとして、連関エンティティとして生成される時が多い。

参照関係は、注文ヘッダと顧客マスタのように、外部キーという参照制約がある。
普通は、二つのエンティティに業務の制約条件が発生する場合、外部キーというリレーションシップが自然に現れる。

UMLなら、親子関係はコンポジション、参照関係は集約として表現できるだろう。
だが、ER図を書く時に、二つのエンティティの関係を、親子関係と参照関係で使い分けるのは結構難しい。
全てを外部キーとして表現できるし、逆に連関エンティティを作りまくることもできる。

二つのエンティティ(リソース・イベント)のリレーションシップの張り方については、T字形ERが鮮やかに解決している事は下記で書いた。

候補キーと2次識別子に関する概念: プログラマの思索

自分流モデリング探しの旅(2)～T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

もう一つの関係である派生関係は、UMLなら単なる継承に過ぎないが、DOAで派生関係が出てくるモデルを読みとくのはかなり難しい。

DOAの派生関係がOOAの単なる継承と違うのは、排他と共存の2種類があるからだ。
過去の記事でも書いた。

データベース設計で派生関係は難しい: プログラマの思索

派生関係の場合、スーパータイプ(親)とサブタイプ(子)の主キーは必ず一致する。
排他の派生関係は、UMLと同じ普通の「完全」な継承であり、スーパータイプはサブタイプの真部分集合になる。
サブタイプ同士のデータは相容れない。
普通は、スーパータイプに「～区分」「～種別」というフラグでサブタイプの関係を明示する。

共存の派生関係は、NULL値排除のためにサブタイプを作る。
例えば、取引先マスタに得意先や仕入先の情報を区別したい場合は、取引先マスタをスーパータイプ、得意先マスタや仕入先マスタはサブタイプにする。
この場合、得意先でもあり仕入先でもある取引先は、3つのマスタに存在するため、排他ではなく、共存になる。
UMLでは、共存の派生関係は、クラス同士のロールで表現できる。

下記にある「データモデル表記読み替えハンドブック」を参考にするとよい。

データモデル表記読み替えハンドブック: プログラマの思索

@hatsanhatさんから、DOAの派生関係が難しい理由は、OOAでは要素から上に向かってグルーピングするしていくので簡単だが、DOAでは逆に集合から真部分集合を切り出す作業であり、しかも切り出すためのデータ項目(区分値)やキーがないとスーパータイプを作れない、と教わって、ようやく理解できた。

又、@hatsanhatさんから、T字形ERがNULL値排除にこだわる理由は「index-only」という実装方法にある、と教わって、ようやくNULL値排除の本当の理由が分かったような気がした。
NULL値排除のために共存の派生関係を作っているので、全てのカラムにインデックスを貼ることができ、検索を高速化することも可能なのだろう。
共存の派生関係が出てくるとスーパータイプとサブタイプをJOINしなければ、本来のデータを取得できないため、SQLも複雑になってくるからだ。

DOAの派生関係は、特に生産管理システムや在庫管理システムで頻繁に出てくる。
部品(品目)、受払(入出庫)、ロケーション(在庫、倉庫)の派生関係を理解して、それらのサブタイプを区別していくのは、業務知識だけでなくモデリングの技法も分かっていないとそう簡単にモデリングできないだろう。

(3)渡辺幸三さんの本が他のDOA本よりも優れている点は、下記の説明があることだと思う。

(3-1)ボイスコッド正規化は2次識別子の制約を課す
(3-2)継承属性を明示することで暗黙的なリレーションシップを見出す
(3-3)「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」「エリック・エヴァンスのドメイン駆動設計」のように、モデルを色んな観点で分析して揺さぶり、洗練させていく
(平鍋さんは渡辺幸三さんの本を、日本人が書いたアナパタと絶賛していた)

モデリングとプログラミングの観点の違い: プログラマの思索

児玉公信さんの「UMLモデリングの本質」、佐藤正美さんのT字形ER、真野正さんの「実践的データモデリング入門」を読んで、やっとDOAを少しずつ理解できてきたように思う。
個人的には、渡辺幸三さんには、「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」「エリック・エヴァンスのドメイン駆動設計」のように、DOAパターン集のような本を出して欲しいと思う。

チケット駆動開発の面白さ #tidd

@nobiinu_andさん、@two_packさん、@naitohさん、@haru_iidaさんと第0回関東Redmine飲み会を開催しました。
Redmineに関するマニアックなお話ができて楽しかったです。
またこういう機会を作りたいなと思っています。

皆と話していて、Redmineの背後にあるチケット駆動開発の面白さについて考えたことをメモ。

【1】チケット駆動開発は、Tracのチケット管理の経験を元にまちゅさんが提唱された。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

チケット駆動開発(TiDD)が障害管理(BTS)や単なる課題管理(ITS)と異なる点は二つある。

一つは、「No Ticket, No Commit!」と呼ばれる運用ルールでチケットに構成管理情報を付与することで、ITSとSCMを連携する機能に着目したこと。

もう一つは、「Ticket First」「No Ticket, No Work!」と呼ばれる運用ルールでソフトウェア開発のプロジェクト管理をチケット管理に置き換えることで、マネジメントの問題をプログラミングで解ける問題に変換できること。

【2】前者は、OSSのツールを連携することによって、新しい使い方が判明して、その使い方によってソフトウェア開発の生産性が大きく上がる事実を示している。

RedmineはSVNが同一サーバー上だけでなく他サーバーへリモートで接続可能という機能のおかげで、チケットとSVNコミットログを簡単に連携できる。
そして、SCM連携と呼ばれるRedmineの機能によって、要件や仕様からチケットを経由してソースのリビジョン、更にはビルドモジュールまでのトレーサビリティを実現できる。
トレーサビリティによって、過去のパッチの変更理由を追跡できるだけでなく、現在修正中のソースが過去のチケットでどのような変更履歴を持つのかを調べることによって、ソースの意図をより深く理解することも可能になる。
従来のAgile開発、ひいてはソフトウェア開発では実現できなかったトレーサビリティという性質によって、ツール上で厳格な変更管理を運用することも可能。

つまり、トレーサビリティという性質は、ITSとSCMの連携によって生まれたが、同様に他のツールとITSやSCMが連携することによって、新しい使い方を発見できる可能性がある。

@haru_iidaさんは、ITS・SCM・CIの三つのツールを「ソフトウェア開発の3種の神器」と呼んで、ツール同士の連携でソフトウェア開発のインフラを拡張できることを示唆されている。
又、古いツールを使って新しい使い方で利用する現象を、上田さんは「チケット駆動開発はAjaxみたいだね」と話されて、なるほどと思った時がある。
僕は、Redmineの対象バージョンをXPのイテレーションと同一視する運用によって、初めて自然にAgile開発を経験できた。

ITS・SCM・CIだけでなく、テスト管理や品質管理、コードレビューのツールも連携できれば、新しい使い方を見つけることができて、更に開発の生産性を高めることができるだろう。

【3】後者は、ソフトウェア開発のプロジェクト管理を主導する役割がマネージャからプログラマへ移ってきた事を示唆している。
ソフトウェア開発をツールでサポートする発想は従来から試されており、そのようなツールも販売されたり、ツールとセットで開発プロセスが提唱されたりした。
IPA(情報処理推進機構)も昔から、メトリクスを収集するツールはフリーで公開している。

EPMツール：情報処理推進機構：ソフトウェアエンジニアリング

しかし、結局普及しなかったのが現状ではなかろうか？

普及しなかった理由は、ツールそのものが使いづらい点もあるが、「上から目線」の発想にあると思う。
下記のBlogに書かれているように、PMOや品質管理部門が開発チームを教育しようという発想が根底にあり、現場の開発者が顧客(マーケット)であるという発想がそもそもなかったのが最大の原因だったのだろうと思う。

ＰＭＯとプロジェクトマネージャ｜HATのブログ

「プロジェクトが遅れない理由」も数値化できる － ＠IT情報マネジメント

チケット駆動開発はTracのチケット管理から生まれた経緯もあって、現場の試行錯誤の中から生まれた開発プロセス。
だから、開発者が作業しやすいように、作業履歴を残しやすくしたり、タスクとソースのコミット情報を連携したり、進捗が分かるような仕掛けがITSに自然に実装されている。
チケット駆動開発は決して、PMOや品質管理部門、あるいは高尚な理論から生まれたアイデアではない。

チケット駆動開発では、SCMと連携する機能を持つITSをソフトウェア開発のタスク管理へ適用すると、スコープ管理をAgile開発のイテレーション管理へ置き換えたり、タスクの順序入れ替えをチケットの取捨選択に置き換えるなど、まさにXPの計画ゲームっぽいことが簡単に運用できる。

そして、マネージャや開発者から寄せられる苦情や改善要望は、ITSの一機能として実現すればいい。
特に、進捗報告や課題一覧は、マネージャやユーザの観点と開発者の観点で大きく異なるけれど、その問題はチケット集計機能というビューを使い分けることで解決できるはず。

チケットの粒度と進捗ビューの関係: プログラマの思索

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

Redmineが使いづらいと言う質問～開発業務をRedmineへマッピングできていない: プログラマの思索

プログラミングに携わる者としてチケット駆動開発が面白いのは、ITSの機能にベストプラクティスが含まれているため、その機能に慣れると自然に良い習慣が身に付くこと。
逆に言えば、ソフトウェア開発で利用するツールが古いと、最新のベストプラクティスが使えないために、開発の生産性が停滞してしまうこと。
つまり、より拡張された概念であるソフトウェア構成管理のツールがソフトウェア開発の作業手順、プロセス、生産性に制約をかけているのだ。

Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう: プログラマの思索

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

構成管理のアンチパターン～TiDD初心者が陥りやすい罠 #tidd: プログラマの思索

チケットの粒度と進捗ビューの関係

チケットの粒度と進捗ビューの関係について、考えたことをメモ。

【元ネタ】
TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索

【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。
RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。
その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。

前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。
開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。
Agile開発なら、動くシステムが最終ゴールであり、顧客に取って一番価値あるものが動くシステムだからだ。

【2】後者の回答は、ITSに貯められたチケットは、見たいと思う観点のビューでSQLを発行してビューを作ればいいということだ。
そもそもチケットの粒度を揃えたいという要望は、マネージャ層から発生する。
その理由は、ITSから顧客へ提出する進捗報告や課題一覧、工数集計を出力したいのに、チケットがバラバラだと抽出しにくいからだ。

でも、それらの報告書は、チケットの属性を選択してフィルタリングして、抽出すればいいだけのことだ。
顧客向けの進捗報告はストーリーカードだけ抽出すればいいし、課題一覧は課題チケットだけ抽出すればいい。
工数集計はチケットの実績工数を合計して導出すればいいだけのことだ。

そのイメージを描いてみた。

Scrum・pf・wfのビュー from akipii Oga

PF(プロジェクトファシリテーション)では、開発者はかんばん、ユーザはバーンダウンチャートで作業の進捗を計測し合う。
Scrumでは、開発者はタスクボードにタスクカードを貼り付けて進捗管理するし、プロダクトオーナーはバックログに実現したい機能をストーリーカードに書いて優先順位付けする。
ユーザの観点のビューでは他にも、パーキングロットチャートがあげられるだろう。
つまり、Agile開発では、開発者やユーザが見たい観点はそもそも異なることを前提として、それらビューを作っている。

しかし、WF型開発では、開発者はガントチャートで進捗が管理されるが、ユーザの観点の報告書のフォーマットが定型化されてない。
ガントチャートはあまりにも細かすぎるので、顧客向け報告には向かない。
普通は顧客向け報告書をExcelで表形式に作るだろうが、何を書けばいいのか、というフォーマットは特に指定されておらず、各プロジェクトで全然違う。
つまり、各プロジェクトでローカルルールがはびこり、プロセスの標準化がやりにくい弱点がある。

【3】RedmineのようなITSの利点の一つは、チケットというデータベースに作業や課題の情報を蓄積すれば、チケットの属性を上手く使うだけで色んなメトリクスが抽出出来ること。
進捗報告や課題一覧は、プロジェクトの一側面の情報に過ぎない。

Redmineが他のITSよりも優れている理由の一つは、チケットの属性とチケット集計機能の関係がとてもよく考えられている点だと思う。
ガントチャートは、チケットの開始日、終了日、進捗率がセットされていれば自動生成できる。
バーンダウンチャートは、チケットの対象バージョン、予定工数、実績工数、終了ステータスがセットされていれば自動生成できる。
PMBOKのEVMですらも、チケットの予定工数、実績工数、開始日、終了日、進捗率があれば、自動計算できる。

もしRedmineのデフォルトのチケット集計機能が不足しているなら、MySQLに直接SQLを発行すればいいだけのことだ。
RedmineはRailsアプリなので、テーブル設計はとても綺麗だし、JOINしたSQLも書きやすい。

Agile開発であれPMBOKであれ品質管理であれ、メトリクスは所詮、チケットの属性をキーとしたSQLのビューに過ぎない。
だから、チケットの粒度なんか気にせず、むしろチケット集計機能をもっと強化していくことが大事だと思う。

【告知】Redmineでのタスク管理を考える勉強会＠大阪で発表します #RxTstudy

【元ネタ】
RxTstudy : ATND

RxTstudy

【内容】
プロジェクト管理ツール「Redmine」でのタスク管理にフィーチャーした勉強会を開催します。

Redmine を触ったことがない方も、チケット駆動バリバリという方も
プロジェクト、タスク遂行をより良くするための情報共有の場としてふるってご参加ください。

■タイムスケジュール

13:15 開場
13:30 開始
17:45 終了

※詳細は決まり次第追加いたします。

■セッション内容
◆「Redmineによるタスクマネジメント実践技法」著者のお二人による講演

講演1 「チケット駆動開発入門」
株式会社ＳＲＡ 阪井誠氏(@sakaba37)

デベロッパーズサミット2011でベストスピーカー賞第3位の講演(阪井担当分)をします。
チケット駆動開発(TiDD)とはどのようなものであるかを、注目される理由、歴史、そして従来プロセスの課題課題をTiDDがどのように解決するか、などを踏まえて解説します。

講演2 「RedmineのFAQ、アンチパターン集」
あきぴー氏(@akipii)

昨今、Redmineのように高機能化した課題管理システムをソフトウェア開発のプロジェクト管理に適用して、Agileに開発するチケット駆動開発(TiDD)が静かに広まっています。
しかし、Redmineを導入したものの、思ったよりも効果が出ない事例もよく聞きます。
本講演では、Redmine初心者がよく発する質問やRedmineを運用した時のアンチパターンの事例について話します。
Redmineが使いづらいと思う人、Redmineの使い方が分からない人は参考になさって下さい。

◆Redmineの実業務における活用事例紹介
@yohhatu 氏

◆ライトニングトークセッション
発表者

特別ゲスト@kuranuki氏（「Redmine -もっと手軽にプロジェクト管理!」著者）

◆全員参加ディスカッションなど

【感想】
TracはShibuya.tacが随分前から活発に活動しているのに、Redmineのコミュニティは今まで存在してませんでした。
ですが、@pinkmacさんのつぶやきの一言がきっかけで、日本初のRedmineコミュニティが立ち上がることになりました。

Twitter / @pinkmac: 【緩募】関西でRedmineをタスク管理に使いたい勉強会を開催したら参加/発表してみたいという方！

Redmineでタスク管理な勉強会「RxTstudy」7/30大阪で開催！ | PINKMAC

告知してわずか1日で満員御礼になってしまいました。
キャンセル待ちの人も10人以上います(^^;)
Redmineのマーケットが日本で広がっている事実もありますが、TwitterやSNSのエネルギーはすごいなと思います。

Twitter / @pinkmac: Redmineでのタスク管理を考える勉強会「RxTstudy」7/30大阪にて開催です！ http://t.co/lOM30lT #RxTstudy

Twitter / @nobiinu_and: ですね！ USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会＠大阪で議論できると思います。http://t.co/X2o1jPF #RxTstudy

デブサミ2011でもTracやJiraのようなチケット管理システムに注目している人たちが多い事実もありました。
RedmineのようなITSは、気軽に導入できるものの、運用して効果を出すには色々とノウハウはいります。
僕も過去4年Redmineを自分のチームだけでなく、他チームでも運用しているのを見たりアドバイスしているうちに、よく聞かれるFAQやTiDD初心者が陥りやすいアンチパターンがたまってきたので、まとめてみようと思います。

Twitter / @akipii: Redmineを導入して使いづらいと言う人達は、アンチパターンの罠にはまっている時が多い。この辺りの事例をまとめてみたい。チケット駆動開発は最終的にはアジャイル開発をサポートするインフラになると思う。#redmine

今回の勉強会では、日本で出版されたRedmine本の著者4人が全員そろうという意味でも、とても重要なイベントになると思います。
色々企画しているようなので、楽しみにお待ちください。

Rails を知らない人のための Redmine プラグイン開発ガイド

r-labsにRedmineプラグイン開発ガイドが公開されていたのでメモ。
これは素晴らしい。

【元ネタ】
Twitter / @haru_iida: こんな大作ができていた。Yoshidaさん、素晴らしい。 / Rails を知らない人のための Redmine プラグイン開発ガイド

r-labs - プラグイン開発ガイド - Redmine

RedmineはOSSのプロジェクト管理ツールとしてかなり優れていると思うが、PM層からはまだまだたくさんの改善要望をもらう。
PM層はガントチャートのPDFやExcelの課題一覧など、帳票(紙)やビューにすごくこだわっている。
だから、プラグインを作って彼らが欲しいと言うビューを実現できれば、簡単に解決できる問題が多い。

RedmineはRailsなので、Rubyが書ける人なら誰でもカスタマイズできる。
JavaやC#が書ける人なら、Rubyはすぐに慣れるだろう。
口が先に動くマネジメントよりも手を動かしてプログラミングする方が大好きな人なら、Redmineをカスタマイズしたり、プラグインで機能拡張する方が手っ取り早い。

上記のガイドはとても丁寧に書かれていて、サンプルもダウンロードできるから、実際に作ってみた方が簡単だと思う。

PDF出力に関しては、@naitohさんが優れたパッチを作ってRedmine本家に取り込まれているので、今後のバージョンアップが楽しみだ。
ガントチャートだけでなく、チケット一覧、チケット、Wikiなども文字化けせずにPDFで出力できれば、PM層へアピールしやすくなるからだ。

Twitter / @naitoh: PDF wiki形式出力パッチが採用＆コミットされた♪自分の初Featureパッチになります。 #redmine 1.3.0でチケットのWiki形式記法がPDF出力に反映されるようになります♪ http://redmine.org/issues/69

Twitter / @naitoh: お、Redmine 1.2.1 でも自分のパッチが一部採用された♪ http://t.co/FgHIg2p

Twitter / @haru_iida: Great job!! RT @naitoh: 一昨日出した #redmine PDF wiki形式出力パッチ http://t.co/I4kJQy5 に"Great Job!"と言って頂けて採用されそうなのでめっちゃ感激です♪

チケット駆動開発の普及はタンポポでいい

Redmineやチケット駆動開発の普及はどうすればいいか、聞く時がある。
自分の考えをメモ。

Redmineによるチケット駆動開発の普及は、僕はそれほど考えていなかった。
周囲が注目して自然に普及していった感じ。

自分のプロジェクトで、RedmineのVer0.6.3の頃から運用してみて、プロジェクト終了後も成功事例の一つとしてイントラで公開していた。
その理由は、僕自身がその事例を参照したかったのもあるし、他人に説明する時に、実際のRedmineを見てもらった方が理解しやすいからだ。

僕のRedmineでは、ロードマップがリリース履歴になるように、RedmineバージョンがSVNのリリースタグ＋Hudsonのビルド番号としてリネームしている。
そのバージョンに紐づく終了チケットは、リリースに必要なタスク一覧であり、それらチケットには必ずSVNの修正履歴がリンクしていて、どのチケットでどのソースや設計書が修正されたのか、をSVNリビジョンから辿ることができるようにしている。
SVNリビジョンをクリックすれば、ソースのDiffをRedmine上で見れるから、どういう意図でパッチを当てたのか、すぐに分かる。

また、Wikiにプロジェクトで必要な情報の説明やリンク、チケット駆動開発のアイデアを書いて情報共有している。
そして、フォーラムに過去のふりかえりの内容を時系列に並べていて、後から参照できるようにしていた。
だから、開発者は暇な時に、Wikiやフォーラムを結構見ていて、チケット駆動開発の運用ルールをおさらいしたり、過去のふりかえりから自分やチームがどれだけ成長したのか、を確認していたようだ。
特に、過去のふりかえりの履歴は、若手がよく参照していて、モチベーション向上に役立ったみたい。

他チームがRedmineについて質問される時、過去のRedmineのロードマップを見せながら、ロードマップがリリース計画作りであること、リリースするソース修正一覧台帳はExcelではなくRedmine＋SVNで代用できること、実績工数や予定工数の比較はRedmineのWorkTimeプラグインで代用できること、などを話している。

又、Redmineプロジェクトをtrunkやリリースブランチ単位に作っていたので、Redmineプロジェクトをどのように作るべきか、という事例の一つとして紹介していた。

特に、チケットの中身やチケットの粒度は、あれこれ議論するよりも、実際に運用している各チームのRedmineを見て、参考にするなり反面教師にする方が手っ取り早い。

僕は無理にRedmineを他チームに押し付けようとしていない。
むしろ、タンポポのように、やりたい人があちこちに散らばって、実際に実践して広まればいいと思っている。
Redmineでうまくプロジェクト管理できた人もいれば、逆にRedmineが掛け声だけで終わり、使えなかったと言われて終わるかもしれない。

タンポポはその可憐な外見とは裏腹に、例えば砂浜に咲くタンポポは根が5メートル以上まで伸びてしぶとく繁殖すると読んだことがある。
同様に、Redmineが一度プロジェクトに根付けば、今後Redmine無しでプロジェクト管理するのは考えられなくなるはずだ。
一度根を張ったタンポポがしぶとく繁殖するように、Redmineも一度成功すれば、自分たちの運用ルールを作り込みながら、プロセス改善していくチャンスが生まれて、チームが学習して成長する仕掛けが整うはず。

だから、あえてRedmineを普及しようとは思ってないし、タンポポの種のように勝手に飛んで広がっていくだろうと思っている。

Redmineの大規模化の壁

昨日、meeting/17 - Shibuya.trac第12回勉強会～チケット管理システム大決戦　第二弾～Shibuya.trac Wiki - SourceForge.JPが開かれた。
UStreamで観戦して、とても面白かったです。
スタッフの皆さん、お疲れ様でした。

実際の議論を聞いて参考になったとともに、Redmine派の自分としては、@daipresentsさんの話がもっと聞きたかったな、と思っている。
今の僕の興味は、一プロジェクトでITSを使ってプロジェクト管理することよりも、1個の事業部、1つの会社全体へRedmineのようなITSを導入して運用して、ソフトウェア開発の基幹業務システムにしてしまいたいという思いに移っているから。

僕もRedmineを4年間使ってみて、一プロジェクトの事例はたくさん経験したし、ボトムアップで成功例を作ることで他チームへ影響させることができることも知った。
けれど、数十人、数百人のメンバーで数十個以上のプロジェクトが並行して動いている場合、Redmine1個でどこまでプロジェクト管理を代用できるのか、はまだ手探り。
だから、@daipresentsさんが楽天で1000人規模でRedmineを運用してぶつかった壁について、もっと知りたいと思っている。

Redmineを大規模化するために、今考えていることをメモ。

【元ネタ】
meeting/17 - Shibuya.trac第12回勉強会～チケット管理システム大決戦　第二弾～Shibuya.trac Wiki - SourceForge.JP

[資料公開]チケット管理システム大決戦 第二弾 #shibutra | Ryuzee.com

かおるんダイアリー　2011年06月30日

3年使ったRedmineの使い方について共有したい10のこと | 世界 - @daipresents

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - @daipresents

Shibuya.trac第12回勉強会でチケット管理システム大決戦第2弾が開かれるようです #tidd: プログラマの思索

【1】Redmineを一プロジェクトの数人のタスク管理だけでなく、数十人、数百人、数千人の規模まで拡張したい目的は2つある。
1つは、ITSによって事業部や会社全体の開発プロセスを標準化できること。
もう一つは、ITSをプロセス改善の道具に出来ること。

前者は、ITSの機能で開発プロセスを実装することによって、全チームのプロジェクト管理にツールによる制限という規律を自然に導入出来ること。
つまり、ITSをプロセス標準化の道具として使うこと。
プロセスを標準化できれば、新米の現場リーダーも初期設定の標準プロセスをそのまま使ってチーム運営できるし、どのチームのプロジェクト管理も同じならば、要員の流動化も図りやすい。

従来のCMMI、PMBOK、WF型開発のように、開発プロセスを標準化しようとすると、大量のドキュメントと融通のきかない承認フローによって、開発の速度が鈍くなる。
しかも、せっかく標準化したとしても、これだけインターネットで情報がアッという間に普及する時代では、すぐに陳腐化してしまいがち。
プロセスの内容をバージョンアップするだけでかなりの苦労がかかる。

後者は、ITSに蓄積された障害やタスク、リリース作業の履歴から、データマイニングによる傾向分析によって、意味あるメトリクスを抽出して、予防対策や是正対策を取れるような仕掛けをもたらすこと。
つまり、ITSを中核として、チームが自律的に学習する組織へ変えること。
チームが自己組織化することによって、自ら問題を解決していく組織へ変えることができる。

プロセス改善していくには、今どんな問題が目の前にあり、どのように解決するのかという方針を自ら決めて、実際に対策を評価するというPDCAサイクルが必要。
CMMIは今までのソフトウェア開発のベストプラクティスを分類してレベル分けした点が素晴らしいけれど、やることが多すぎてプロセス改善まで手が回らない。
又、普通のプロジェクトでは、障害の履歴を残して、後から分析出来る仕組みがないから、そもそも改善していく仕掛けすら無い。

【2】Redmineを大人数で使う場合、WebサーバーやSCMリポジトリに問題が出てくる。
1個のプロジェクトで5人しかメンバーがいないなら、SVNリポジトリへリモートでアクセスして、Webrickで起動していても問題ない。

しかし、数十個以上のプロジェクトが並列に動いている場合、Webrickではアクセスがもたついて使いづらい。
Unix上にRedmineがあるならば、Passengerが一番安全。
Apacheの負荷分散やスケールアップのノウハウは枯れているので、安心できる。
僕の経験では、Webrick＜Mongrel＜Thin＜Passengerの順で高速で安全なように思える。

できれば、JRuby＋TomcatでRedmineの運用も試してみたい。
@haru_iidaさんがRedmine 1.2.0 をJRuby 1.6.2 + SQLite3で動かす方法を公開されている。

Haru's blog: JRuby で Redmine や ChiliProjectを動かす

JRuby＋TomcatでRedmineの運用を試したい理由は、Tomcatで負荷分散するノウハウは既に枯れているからだ。
RailsよりもJavaのWebアプリケーションサーバーの方が歴史が長く、負荷分散やスケールアップの技術ノウハウは結構あるので、流用できるものは使った方が楽だから。

【3】SVNリポジトリが既に存在していて、巨大な場合、リモートで接続を指定すると、@daipresentsさんの言う通り、Redmineがダウンしてしまう事も経験した。
正直この現象はとても痛い。
構成管理ツールと連携しないITSは、ただのチケット管理システムに過ぎず、No Ticket, No Commitの運用ルールが使えないから、成果物のトレーサビリティを実現できない。
だから、ロードマップがソース修正履歴となり、Excelのリリース管理台帳をRedmineで置き換える手法が使えなくなってしまう。

僕の考えでは、Redmineと同一サーバー上にミラーリポジトリを作って、マスターリポジトリとミラーリポジトリを同期させるのが現実的な解決方法だろうと考えている。
Subversionならsvnsyncで同期させるし、GitやMercurialなら元々分散バージョン管理だから、ブランチを同期させるのはもっと簡単だ。

この辺りは下記のTwitterで色々議論した。
@Kokawa_Takashi さんの指摘にあるように、JenkinsでSCMリポジトリをリアルタイムなバッチ処理のように同期させる手法はとても優れているように思える。

Twitter / @akipii: @kyon_mm @aoi_wakusei 大規模プロジェクトや巨大なSCMリポジトリの場合、同一サーバー上にミラーリポジトリを作らないと実用的でないでしょう。@daipresentsさんの話にもありますが、Redmineがダウンしてしまいます。

Twitter / @akipii: @kyon_mm @Kokawa_Takashi さんの指摘通り、RedmineはリモートSVNでURL指定可能です。小規模プロジェクトならとても便利です。

Twitter / @akipii こちらを参考にしてくださいー。うちではJenkinsで定期的にrubyのタスクを走らせています。 redmine.jp/guide/RedmineR… #shibutra

Twitter / @akipii: @Kokawa_Takashi JenkinsでSCMリポジトリを同期ですか！なるほどね。リアルタイムなバッチ処理みたいな使い方ですね。参考にします。　#shibutra

【4】Redmineを大人数で使う場合、プロジェクト・チケット・バージョンの階層化という特徴はとても相性が良い。

Redmineプロジェクトは、実プロジェクトや組織構造にそのままマッピングしやすい。
事業部や会社の組織は、命令系統が階層構造となっているので、ツリー構造でマッピングできる。
Redmineプロジェクトの階層化は、プロマネには理解しやすいみたいだ。

Redmineプロジェクトを大規模組織に適用する時に難しい点は、どこまでプロセスを標準化できるか、という点だ。
Redmineの管理画面では、カスタムフィールドをトラッカー単位、プロジェクト単位に対応付けることができる。例えば、バグ修正のワークフローではチケットの属性に障害管理報告票の項目を追加すればいいし、課題問合せのワークフローは課題特有の項目をカスタムフィールドに追加してもいい。
それらカスタムフィールドは、選択したプロジェクトのみ反映されるので、チェックボックスでチェックしなければ反映されないから、使わない運用もできる。
また、ステータスは必ずトラッカーに依存する設定のため、課題問合せのワークフローはタスクのワークフローと異なるように管理することもできる。

しかし、各チームの要望を受け入れてカスタムフィールドやステータス、ワークフローを増やしすぎると、組織全体でプロセスを標準化していく方向からずれてしまう。
各チーム独自のローカルルールがはびこると、プロセスの標準化による利点が消えてしまう。
この辺りは、どこまでRedmineでプロセスをカスタマイズしていくか、というさじ加減になる。

【5】チケットの階層化も、MS Projectに慣れたプロマネは理解しやすいみたいだ。
チケットの階層化の利点は、顧客やプロマネが見たいビュー(ストーリーカード)と開発者が管理したいビュー(タスクカード)を分けることにあると思う。

Redmineに対するプロマネの要望の殆どは、ガントチャートや課題一覧などビューの見せ方が多い。
彼らは、顧客視点から眺めた一機能の進捗や課題について管理したいのであり、開発者レベルの細かなタスクの進捗や仕様上の質問は正直興味ない。

一つの解決方法としては、RedmineのBacklogsプラグインのように、親チケットをストーリーカード、子チケットをタスクカードで階層化することで、ビューの見せ方を意図的に変えることができると思う。

あるいは、Redmineの対象バージョンをストーリーカード、対象バージョンに紐づくチケットをタスクカードと見なしてもいい。
つまり、本番リリース日までに実装する機能をリリース予定バージョンと見なすわけだ。
この手法は、@daipresentsさんのパーキングロットチャート・プラグインを使えば、バージョン1個の進捗が顧客にとって価値ある機能の進捗に相当するので、非常に分かりやすい。

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - @daipresents

又、Redmine1.2.0から導入されたプライベートチケットを使って、開発者個人のToDoチケットはプライベートチケットにして、工数集計から外すという運用も可能だ。
つまり、工数集計すべきチケットと工数集計から外すチケットをプライベートチケットによって分別するという新しい手法もある。

Redmineはチケットの属性とチケット集計の機能の関連がとてもうまく作られているので、色々試してみる価値があると思う。

【6】Redmineで大規模Agileを実践する時に重要な手法は、アジャイルリリーストレインの実装だ。
複数チームのリリースを制御したい場合、アジャイルリリーストレインを適用することで、全チームのリリースを同期させるようにする。
Redmineでは、バージョンを継承することが可能で、親プロジェクトのバージョンを子プロジェクトへ強制的に反映させることができるから、アジャイルリリーストレインを実現することができる。

アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る: プログラマの思索

Redmine 0.9 新機能紹介(2): バージョンの継承 | Redmine.JP Blog

アジャイルリリーストレインが重要な理由は、複数チームのリリース計画作りの一手法であるからだ。
複数チームのリリースの同期はアジャイルリリーストレインを使えばいいし、組込み製品の開発のようにハードウェアチームとソフトウェアチームが内部リリースを繰り返しながら最後にリリースを同期させるようなイテレーションの入れ子関係のような手法もある。
大規模組織におけるリリース計画作りは、色んなバリエーションが必要だ。

しかし、Redmineの残念な点は、子プロジェクトへ継承したバージョンは、子プロジェクトのバージョンと見なされないために、子プロジェクトのチケット一覧に表示されず、親プロジェクトのチケット一覧にしか表示されない。
アジャイルリリーストレインを運用したい場合、子プロジェクトへ継承したバージョンは、子プロジェクトのバージョンでもあり、子プロジェクトのチケット一覧やガントチャートでもフィルタリングできるようにしたい。
何故なら、子プロジェクトへ継承したバージョンに紐づくチケットは、子プロジェクトのタスクなので、子プロジェクトで管理したいからだ。
チケット一覧やガントチャートのSQLのうち、バージョンの取得条件をちょっと修正するだけでアジャイルリリーストレインを実現できると思うのだが、誰か直してくれないのかな？

【追記】
RedmineのVer1.1.xでは上記の症状が発生するが、Ver1.2.xではバグが直っているようだ。
実際、親プロジェクトのバージョンを子プロジェクトが継承した場合、子プロジェクトのチケットで継承したバージョンをセットすると、親プロジェクトでも子プロジェクトでも、ガントチャートやチケット一覧に子プロジェクトのチケットが表示される。
つまり、Redmineの最新バージョンでは、アジャイルリリーストレインの実装は可能だ！

【7】Redmineを大規模組織、全チーム、全プロジェクトへ適用することで、色んな利点が出てくるし、運用してみて色んな発見があって面白い。
RedmineのようなITSがあれば、プロジェクト管理の問題をツールの一機能という問題に置き換えて、プログラミングでマネジメントの問題を解決していく方向に変える。

プロジェクト管理の経験が少なくても、Rubyでプログラミングできる技術さえあれば、シミュレーションして自分だけのノウハウを貯めることも可能。
色々試してみたい。