【告知】第2回shinagawa.redmine勉強会と第3回RxTstudyがもうすぐ開催 #RxTstudy #47redmine

Redmineコミュニティが最近活発に活動しているようです。
今週末は東京で第2回shinagawa.redmine勉強会、2月初めに関西で第3回RxTstudyが開催されます。

【元ネタ】
第2回shinagawa.redmine勉強会 : ATND

RxTstudyホーム

ロードマップ - shinagawa.redmine - Redmine

第3回RxTstudy : ATND

【1】関西・関東のいずれの勉強会でも、僕が一番聞きたいのは@daipresentsさんの発表かな。
Redmineの大規模運用事例、アジャイル開発への適用方法、そしてチケット駆動開発の可能性と課題など、色々話されるだろうと期待しています。

Redmineコミュニティで面白い点は、プラグインやインストールツール、パッチの開発で数多くの日本人開発者が関わっているのがよく分かること。
@yohshiyさんはREST APIやプラグイン開発の説明Wikiを公開してくれているし、@mikoto20000さんはUnix上でRedmineを簡単にインストールするツールを公開されている。
@naitohさんはPDF出力のパッチを次々にRedmine本家に送付して、Redmine自体の機能改善に大きく貢献されている。
@me_umachaさんが作られたGraph Activitiesプラグインは、プロジェクトの見える化を強力に推進してくれるツールだと思う。

Twitter / @me_umacha: Redmine Graph Activitiesプラグインで自分たちのチームの活動状況を可視化してあれこれ考えてみる。12月は残業禁止令が出たので前月と比較して18時以降の活動が減った。そして8時台の活動が増えてる。即ち朝ちょっと早く来て仕事する人が増えたということ。

@yandoさんはRedmineのPHPクローンcandycaneを開発されており、本家のRedmineよりもどれくらい簡単になっているのか興味がある。

【2】個人的には、何故Redmineが日本で最近注目されているのか、理由が知りたい。
最初は@g_maedaさんのRedmine日本語情報サイト「Redmine.JP」サイトぐらいしか情報がなく、細々と試行錯誤していたに過ぎないように思う。

おそらく今でも、RedmineよりもTracを使っている現場は多いと個人的に思う。
でも、数多くの有志がRedmineの情報を次々に公開されて、皆で色々試すことが簡単になってきた状況がある。

【3】チケット駆動開発というアイデアは、その言葉や概念を知らなくても似たようなことは従来から既に知られていた。
それについては下記にまとめた。

本来のチケット駆動開発(TiDD)とは何なのか？ - Togetter

Redmine以前に、BugzillaやMantisのようなBTSは既に運用されていたし、障害管理を課題管理へ拡張する方法は既に実践されていた。

Twitter / @quicy: 自分がBugzillaでチケット駆動開発と呼ばれる以前のものをやっていた時には、チーム外からは「ツール使ってるのね」という認識だけで、そこにある軽量さと規律の両立の妙を、なかなか理解してもらうことができなかった。名前と体系化は重要ですね。

もし僕の本「Redmineによるタスクマネジメント実践技法」で他にはない特徴があるとすれば、Redmineによるチケット駆動開発をアジャイル開発へ適用できることについて解説したことにあると思っている。

Twitter / @quicy: チケット駆動開発は、ミニマムなライトウェイト手法に一通りの体系化とカッコいい名前を与えてくれたことが、ものすごく大きな功績だと思います。

Twitter / @quicy: あえて残念な言い方をすれば、チケット駆動開発は、XP/Scrumを実践できない現場、それでも規律的なライトウェイト開発をやりたい、という現場開発者のための、救済なんちゃってアジャイル手法だと思う。

そして、チケット駆動開発が従来知られていた課題管理とは決定的に違う点は、チケットに構成管理情報を付与する機能があることだと思う。
GTDやかんばんのようなタスク管理の手法は確かに優れているけれども、構成管理情報を必ず付与するという特徴はチケット駆動開発特有の考え方だ。
ソフトウェア開発で一番重要なインフラがバージョン管理であり、バージョン管理の配下にある成果物とチケットが連携することによって、多くの特徴が出てくる。

この運用が「No Ticket, No Commit」であり、トレーサビリティを実現し、変更管理を強化するし、各種ツールの連携が可能になってソフトウェア開発の3種の神器という概念まで発展していく。

【4】Redmineコミュニティで今後期待する点は、ツールの運用方法(現場へのテーラリング)とツールの実装方法(機能改善)をセットで議論して欲しいと思うこと。

ツールとプラクティスが密接に関係していることから、アジャイル開発やIT業界以外の課題管理へ適用する手法も色々提唱されている。

RedmineはOSSなので、足りない機能は自分たちでどんどん実装して、その場で試してみたらいい。
足りない機能があるという事実は、ツールの機能が現場の運用にフィットしない点があることを示唆していて、それがどんな場面で出てくるのか、という点に一番の興味がある。

コミュニティと言う場を通じて、コミッタやプラグイン開発者、実運用している現場リーダーや開発者が互いに議論することによって、Redmineを使いやすくするだけでなく、Redmineというツールを通じて今までにない新しいソフトウェア開発のベストプラクティスが生み出されるといいなと思います。

Redmine Site Feedback Pluginの感想

@akiko_pusuさんがRedmine Site Feedback Pluginを公開されていたのでメモ。

【元ネタ】
Redmine Site Feedback Pluginについて - GitHub

Redmineプラグインあれこれメモ: プログラマの思索

Issue from message plugin - Redmine

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

Redmineサイトの運用管理者の立場では、Redmine運用そのものの質問やインシデントを受け付ける時が多い。
その時に、それら質問を入力してもらうように誘導するリンクを付ける機能がRedmine Site Feedback Pluginらしい。

この種の手法は特にWebシステムのユーザインターフェイス改善や画面遷移の改善で特に多い。
B2Cの場合、購入ユーザが説明文を読まなくても直感的にリンクを押せば自然に誘導されるように画面遷移やリンク、画面のデザインを考えておく必要がある。

また、ITILなどの運用保守の観点では、ユーザが見つけた使い勝手の報告や障害報告はできるだけ一つの場所に集めて分析するようにしたい。
ユーザが気軽に入力できるフォーム、ユーザへ即座に回答して連絡する仕組みがあれば、熱心なユーザをテスト担当者の役割に当てはめて、問題発見や問題修復に役立ててもらうことができる。

Redmineをユーザとサイト運用者が有意義な議論を行える場にするには、いくつかの機能改善が必要だと思う。
一つは、上記のように、ユーザが気軽に登録できるような仕組みを整えること。
Hinemosなどのサーバー監視ツールから障害報告メールでチケットを自動登録する機能は以前からあった。
Redmine Site Feedback Pluginのようにフィードバックの誘導リンクもそうだし、Redmineフォーラムで議論しているメッセージからチケット登録するIssue from message pluginも、チケット登録の機能を強化してくれる。

もう一つは、サイト運用者からユーザにフィードバックする仕組みも整えること。
Redmineからユーザへ自動通知する機能として、チケット更新のたびにメールを送ったり、RSSで変更箇所を通知したり、Twitterで連携するなどの機能も考えられる。
もっと色んなアイデアがあるはず。

アジャイル開発の利点の一つは、ユーザと開発者の距離が短いので、問題発見や問題修復の作業にユーザの力を利用することがやりやすいことがあげられる。
その仕組みをRedmineがもっと提供することはできないか？
そうすれば、Redmineを単なるソフトウェア開発のタスク管理だけでなく、製品のサポートデスクや会社の各部門の課題管理へ適用すれば、プログラマ以外の人達もアジャイルの概念に自然に慣れてくれるはずだ。

色々考えてみたい。

チケット駆動開発がもたらした新しい観点part3～トラッカーの考え方

Redmineを運用してみると、トラッカーの概念が分からないという声をよく聞く。
トラッカーについて考えたことをメモ。
ラフなメモ書き。

【1】Redmineのトラッカーはワークフローそのもの。
Redmineのトラッカー管理画面で、ロール単位にステータスのデシジョンマトリクスで自由に設定できる。
デフォルトのトラッカーは「機能」「バグ」「サポート」の3つだが、実際の運用では使いづらい場面があるので、各現場で独特のトラッカーがあるだろうと思う。
個人的には、一人一人の運用ユーザに一番聞いてみたい内容だ。

トラッカーが難しいのは、ワークフローを意識していないからだろうと思う。
ソフトウェア開発の作業は、チケットを一人で担当して終わらせるだけではない。
バグ修正やリリース作業では、必ず複数人のチェックを入れなければ、作業ミスが重大な過失につながる。
だから、それら作業はワークフローに複数人の担当者がやり取りするためのステータスが必要になり、その分複雑になる。

だが、トラッカーが難しいのはそれだけではないと考えている。
どれだけトラッカーを作ればいいのか、悩むからだ。
トラッカーの数を増やしすぎると、直感的に分からなくなるので、新人や途中参加の開発者に逐一説明しないといけなくなる。
レビューやリーダーの承認のようなステータスを全てのトラッカーに入れると、ワークフローが複雑になるため、逆に開発速度が落ちてしまう場合もあるだろう。

【2】トラッカーの基本的な作り方は二つあると思う。
一つは、同じワークフローは一つのトラッカーに揃えること。
もう一つは、プロジェクトで必要な帳票のレイアウトに合わせること。

前者については僕も失敗した経験がある。
Redmineを初めて運用した時、「新規開発」「仕様変更」「リファクタリング」「バグ」「管理」などのトラッカーに細分化していた。
作業の種類ごとにワークフローを作った方がやりやすいのではないか、と思ったからだ。
でも、バグなどの一部のトラッカーを除いて、殆どが同じワークフローになっていた。
実際は、「新規開発」を新規に発生した作業の意味で使っていたから、それ以外のトラッカーはあまり使われなくなった。
だからその後は、「タスク」というトラッカーで一つにまとめて運用するようにした。

この経験を通じて、ワークフローにもファウラーの言う「知識・操作パターン」が当てはまるのだと気付いた。
つまり、「タスク」のインスタンスには「新規開発」「仕様変更」「リファクタリング」「管理」などの作業があり、それらインスタンスを抽象化した型が「タスク」になるのだ、と。

「知識・操作パターン」は抽象的で分かりにくいOOAのパターンの一つだが、クラスとインスタンスの関係と考えれば、インスタンスがいくらあっても、その本質はクラスにあると思えばいい。
同じワークフローのトラッカーがたくさんできてしまった時は、操作レベルではなく一つ上の抽象化レイヤーである知識レベルでは何に当たるのか、を考えるとよいと思う。

【3】後者は、「課題」と「QA」の違いだ。
僕がいたチームではチケット起票に慣れているメンバーが多かったので、顧客確認が必要な質問は「課題」、設計者に確認が必要な質問は「QA」で分けていた。
「課題」も「QA」もワークフローは同じだが、「課題」にはExcelの課題一覧から抽出した属性をカスタムフィールドとして追加していたから、「QA」とはチケットの形式が異なっていた。
Redmineでは、プロジェクト単位でトラッカーをアサインできたり、プロジェクト単位でトラッカーのカスタムフィールドを追加したりOFFにすることができる。
だから、課題一覧のフォーマットから「課題」トラッカーをあらかじめ用意しておくが、各プロジェクトで必要なカスタムフィールドをチェックして、自分たちの課題一覧を作れるように運用した。

マネージャや顧客は課題一覧、障害一覧、作業一覧のような帳票のレイアウトにとてもこだわる。
彼らの要望をそのまま引き受けると、チケットのカスタムフィールドがかなり増えてしまい、逆にチケットの入力が億劫になってしまうこともある。
だから、必要最低限の属性をチケットのカスタムフィールドとして付与するように調整した方がいいだろう。

この経験を通じて、同じワークフローでも帳票(課題一覧、障害一覧など)に応じて、トラッカーを切り替えた方が運用しやすいと考えるようになった。
この考え方は、DOAにおける画面や帳票から項目を抽出してテーブルを正規化していく考え方に似ている。
課題一覧は「課題」トラッカー、障害一覧は「バグ(障害)」トラッカーのように、帳票単位にトラッカーを作った方がいいと思う。
帳票の導出項目は、基本属性から計算できるようにRedmineのプラグインやExcelマクロを上手く使って、チケットの属性から省くようにした方がいいと思う。

すると、実際のプロジェクトではどれだけの帳票が存在していて、どのように使われているのか、を分析する必要があるだろう。
その分析作業そのものが、ERP導入時の画面や帳票の精査であり、Fit Gap分析にもつながる。
ソフトウェア開発の分析作業そのものも、我々が受託開発しているWebシステムの要件定義に似ているのだ。

トラッカーについては研究の余地がまだまだたくさん残っているように思っている。

チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張

Redmine・Trac・Mantisでチケット駆動開発を実践してみて、技術的に一番面白いのは、ツールの連携によるトレーサビリティの強化であり、その拡張だ。
この考え方は「ソフトウェア構成管理とはそもそも何なのか？」という問題に行き着くと思う。
以下ラフなメモ書き。

【1】チケット駆動開発の基本的な運用ルールは「No Ticket, No Commit!」だ。
実際の運用方法は、SVNやGit、Mercurialのコミットログに「refs #チケットNo」「fixes #チケットNo」を付けてcommitすると、自動的にチケットとリビジョンが相互リンクするやり方。

この運用ルールは、障害管理において、障害報告票に基づいてどのようにソースが修正されたのかをレビューしたり検証したり、リリース後に確認できるようにしたい発想から生まれた。
この単純な運用ルールこそが、従来のAgile開発には無かった強力なトレーサビリティによる変更管理を実現してくれる。
つまり、ソフトウェア開発全般の作業において、ソースだけでなく、バージョン管理のリポジトリにある全ての成果物の変更履歴がチケットに記録されることによって、何故こんな汚いパッチが過去に実施されたのか、何故こんな複雑な仕様に行き着いたのか、などの理由を追跡できるようになる。

【2】チケット駆動開発の本来のトレーサビリティは、バージョン管理のリビジョン単位のソースや設計書の変更管理だ。
チケット駆動開発を実践してみて、このトレーサビリティを拡張した考え方は二つある。
一つは、ITSチケットだけでなくITSのプロジェクト、バージョンにもバージョン管理の概念を対応付けること。
もう一つは、CIツールの機能にトレーサビリティの概念を対応付けること。

前者は、下記のWikiに書いた。
RedmineとSCMの機能の関連表～BTSとSW構成管理の密接な関係 #itsjp #tidd: プログラマの思索

つまり、ITSチケットとSCMリビジョン、ITSバージョン(マイルストーン)とSCMのタグ(リリースバージョン)、ITSプロジェクトとビルドモジュール(製品)の3種類に対応付けることができる。
ITSのバージョン(マイルストーン)とSCMのタグ(リリースバージョン)を対応付けるだけでなく、アジャイル開発のイテレーション(スプリント)に対応付ければ、自然に小規模リリースを実現できる。

ITSプロジェクトとビルドモジュールを対応付けることは、例えばRedmineの設計思想において、1プロジェクト＝1リポジトリであることから必然だ。
この対応関係によって、バージョン管理のリポジトリにある成果物の全ての変更作業は、対応するITSプロジェクトのいずれかのチケットに必ず起票され、記録される。
すなわち、バージョン管理のリポジトリからビルドされてリリースされるモジュール(製品)に関する作業履歴は、対応するITSプロジェクトのいずれかのチケットに必ず記録されている。
だから、製品のリリース履歴がITSのロードマップに自然に対応付けられ、そのロードマップこそが製品の今後の開発の方向性をユーザに提示するものになる。

後者は下記のWikiに書いた。
Redmine・HudsonとSCMの機能の関連表 #itsjp #tidd: プログラマの思索

HudsonやJenkinsには、Redmine・Trac・MantisなどのBTS/ITSと連携するプラグインが提供されているので、それらITSに紐づくバージョン管理のコミットログをCIツールのビルドログと関係付けることができる。
この性質によって、どのビルドモジュールにどんなソースの修正が入っているのか、を確認出来る仕組みができあがる。
つまり、ビルドモジュールのビルドNoからSCMリビジョン、ITSチケットを経由することで本来の要件や仕様まで辿ることができる。

また、HudsonやJenkinsにはSubversion(CVS) Tagging pluginがあり、これを使うと、指定したTagをチェックアウトしてビルドする作業が簡単になる。
すなわち、SCMタグをビルドモジュールのリリースバージョンに厳格に対応付けることが可能なことを意味する。
更に、ビルドモジュールのリリース予定バージョンは、ITSのロードマップに書かれたバージョン(マイルストーン)に一致するように運用すれば、バージョン単位の変更履歴を追跡することが楽になる。
どのバージョンが品質が安定しているのか、どのバージョンで仕様変更されたのか、を追跡するときに役立つだろう。

そして、CIツールのジョブをSCMリポジトリに対応付けるのは当たり前の作業。
これらの対応関係によって、CIツール・SCM・ITSが密接に連携できるようになり、ソフトウェア開発の3種の神器の概念を更に強化してくれる。

【3】トレーサビリティの概念が重要な理由は、変更管理や構成管理を実際に運用する時に使うからだ。
仕様を変更する時にきちんと手続きを経て決めたのか、修正履歴は必ず残されているか、をサポートするためにトレーサビリティが必要。

実際の修正履歴は、ITSチケットとSCMリビジョンの連携によって記録される。
だが変更管理で重要な概念はベースラインだ。
つまり、顧客や会社の上司など全てのステークホルダーが承認した時点の成果物のスナップショットがベースラインとして順次記録されていく。
このベースラインという概念は、Agile開発のイテレーション、システムのリリース済バージョン、SCMタグと同一視できるのがポイントだ。
そのアイデアについては以前書いた。

イテレーションはSW開発で何故重要なのか？: プログラマの思索

チケット駆動開発の本質はバージョン・ファースト: プログラマの思索

悪いウォーターフォル型開発では、工程がベースラインになっているため、手戻り作業が発生するともう一度過去の工程の作業にさかのぼらなくてはならない。
その時、ITSバージョンを工程単位(例：設計・開発・テストなど)に作っていると、過去にリリース済みのバージョンをReOpenして修正する羽目になってしまう。
だから、手戻り作業が発生する度にバージョンをReOpenしてしまい、いつまで経ってもどのバージョンもリリースできなくなる。
そもそもITSバージョンがベースラインと同一視されるならば、過去のベースラインを改ざんすることはシステム監査上ありえないはずだ。

逆にアジャイル開発では、イテレーションが終了したら、リリースしたモジュールの過去の履歴は触らず、次のイテレーションに向けて要件や作業を決めていく。
アジャイル開発ではイテレーションがベースラインに自然に同一視されるから、未来のベースラインに向けて機能改善を積み重ねていく。
これが本来のソフトウェア開発のあり方だと思う。

すると、ソフトウェア構成管理とは一体何なのか？という話になる。
ソフトウェア構成管理は単なるバージョン管理だけでなく、ソースや設計書の修正だけでなく要件や仕様の変更をコントロールする仕組みを提供するものであるはずだ。
そのアイデアについては下記に書いた。

構成管理、変更管理、プロジェクト管理の密接な関係: プログラマの思索

PerforceによるSW構成管理: プログラマの思索

ソフトウェア構成管理の定義はIEEEやCMMIに書かれているけれども、僕には何となくピンとこなかった。
その理由は、変更管理の実装方法がきちんと書かれていないために変更管理をイメージできていなかったからだと思う。
だからこそ、チケット駆動開発で構成管理や変更管理について色々試してみて、ようやく腑に落ちるものがあった。

但し、上記はあくまでも僕が経験した内容に過ぎず、もっと深い意味が隠れているのかもしれない。
色々考えてみたい。