@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を@sakaba37さんと読みながら、自分が理解してなかった点がたくさんあることが分かった。
気付いたことをメモ書き。
間違っていたら後で直す。

【shinagawa.redmineの講演資料】

数千人が利用する楽天Redmineの過去と未来 - The past and future of Rakuten Redmine that is the backbone of 1000+ engineers

View more presentations from Dai Fujihara

【RxtStudyの講演資料】

チームにRedmineを適用せよ！ #RxTstudy

View more presentations from Dai Fujihara

【1】SVNリポジトリのスケールアップ

チケット駆動開発の特徴は、ITSにSCM連携の機能があることで、トレーサビリティやソース変更履歴を即座に確認できる利点がある。
しかし、5人ぐらいの小規模開発チームから数百人以上の大規模な組織で運用する場合、SVNリポジトリがダウンしてしまうケースが出てくる。
そもそもRedmineのようなOSSのITSでは、大規模な運用における可用性や信頼性に関してはまだまだ弱点がある。
それについては下記で書いた。

Redmineの大規模化の壁: プログラマの思索

@daipresentsさんの現場ではユーザ4000人がRedmineを使っていると言う。
多分、日本でも最大規模の運用事例だろう。
上記の講演資料では、SVNの構成方法について、マスタ・スレーブ方式で解決する方法が示されている。

この仕組みは、ReadOnlyの参照用SVNリポジトリとReadWriteの更新用SVNリポジトリをsvnsyncでリアルタイムに同期させることで実現している。
すなわち、ITSからリポジトリブラウザの閲覧は参照用SVNリポジトリ、コミットログにチケットNoを書いてSVNコミットする場合は更新用SVNリポジトリで使い分ける手法だろうと思う。

この手法の利点は、大量ユーザがアクセスする参照用SVNリポジトリと更新頻度が少ない更新用SVNリポジトリを別に配置することによって、負荷分散する点にある。

@daipresentsさんは過去の記事で、SVNの構成方法についてたくさん考察されており、実際にたくさん試されている。

Subversionのシステム構成を考えてみた | 世界

svnsyncを使ってリポジトリレプリケーション | 世界

更に、SVNのWebDAV transparent write-through proxyを使えば、複数の更新用SVNリポジトリを同期させることができるので、よりスケールアップしやすくなる。
Apacheサーバーのスケールアップは既に色んなノウハウがあるが、SVNリポジトリでも同様にスケールアップは可能。

Subversion1.5のWebDAV transparent write-through proxy | 世界

Subversion 1.5.0 での新機能 (WebDAV Write Through Proxy)

エンタープライズ環境におけるSubversionの複製アーキテクチャ - インターネットコム

Subversionを見直せ: プログラマの思索

SVNリポジトリのスケールアップが必要な理由は、RedmineチケットとSVNリビジョンを紐づける仕組みでも使いたいからだ。
普通はコミット後、RedmineのSVNリポジトリ画面をリフレッシュしないと紐付けが実施されない。
だから、Webサービス機能を使って、リアルタイムに同期させる手法が普通だろう。

「リポジトリ」を開くまでSubversion等のリポジトリへのコミットが「活動」に表示されません | Redmine.JP

小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog

しかし、この機能は大量ユーザのコミットや大量データのコミットに向かない。
スケールアップするには、JenkinsでSCM連携をポーリング化する手法があるだろうと思う。
そのアイデアは下記に書いた。

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索

Redmineの運用が大規模化するにつれて、RedmineそのものがIT企業の基幹システムになり、可用性や信頼性がよりシビアになってくる。
@daipresentsさんの講演資料にはたくさんのアイデアが含まれていると思う。

【2】Parkinglot Chart Pluginの利点、そしてITSの概念とプロセスのマッピング

@daipresentsさんは以前から、Redmineプラグインの中でパーキングロットチャートプラグインを絶賛されていた。

Redmineプラグイン開発 -- パーキングロットチャートプラグインリリース | 世界

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

パーキングロットチャートはフィーチャ(ユーザ機能)の進捗を示すための図だ。

ユーザ機能駆動開発FDDを再考: プログラマの思索

パーキングロットチャートが何故そんなに重要であり、開発者だけでなくマネージャや経営層にも使われるようになったのか？
Redmineのパーキングロットチャートプラグインは、Redmineのバージョンをフィーチャ(ユーザ機能)に対応付けて運用する。
Redmineのバージョンはリリース予定(済)バージョンだから、実際にリリースされるシステムのバージョンに相当する。
そもそもリリースするバージョンには、顧客の要望にあるビジネス要求を実現するための機能が含まれていて、その機能がリリースされることで顧客価値が実現される。
だからこそ、Redmineバージョンは単なるリリース予定バージョンだけでなく、顧客のビジネス要求を実現する日を示しているのだ。

従って、顧客のビジネス要求の単位でフィーチャを作り、フィーチャをRedmineバージョンに対応付ければ、フィーチャが今どんな進捗状況であり、いつリリースされてそのフィーチャが使えるようになるのか、を示すことができる。
システムのバージョンは単なるSCMタグやITSバージョン、Agile開発のイテレーションに対応するだけでなく、ビジネス要求のフィーチャにも対応付けている点がとても重要だ。

@daipresentsさんの講演資料では、パーキングロットチャートが100個以上並んでいる絵が貼られており、Redmineがビジネス要求の実現のために運用されていることがとてもよく分かる。

この発想を更に突き進めると、Redmineのプロジェクト・バージョン・チケットの概念はプロセスのどれにマッピングできるか、という問題にぶち当たる。
その問題については下記で考えてみた。

ITSと開発プロセスのマッピング: プログラマの思索

@daipresentsさんの講演資料では、タスクをFeature・Release・Iteration・Taskの4つの概念に分けて、Scrumのようなアイデアでタスク管理を回そうとされている。
僕の理解では下記のようになる。

(2-1)Feature：顧客の本来の要望。PivotalTrackerのIceBoxと同様。つまり「～の機能が欲しいなあ」というレベルの要望であり、実現可能性(フィージビリティスタディ）は考えられていない。

(2-2)Release：リリース計画に入れられたFeature。PivotalTrackerのBacklog、Scrumのバックログと同様。Featureの実現可能性(フィージビリティスタディ）を考慮して、実現可能なサイズのストーリーへ更に分割する。
Featureに優先順位がつけられて、優先度の高いFeatureから順に開発対象となりリリースされていく。

(2-3)Iteration：XPのイテレーションやScrumのスプリントと同じ。PivotalTrackerのTaskBoardと同じ。2～4週間のサイクルでFeatureを開発してリリースしていく。

(2-4)Task：実際の作業。タスクカード。3～4人日というサイズから推測すると、ストーリーカードに近い。

@daipresentsさんの講演資料では、Feature・Release・Iteration・Taskを下記のようにRedmineの機能へマッピングしようとしている。

Feature　→Redmineのプロジェクト？
Release　→Redmineのプロジェクト？
Iteration　→Redmineバージョン
Task　→Redmineチケット

僕の考えでは、FeatureやReleaseはRedmineのプロジェクトではなく、Redmineバージョンに対応付けるべきだと思う。
理由は、Redmineプロジェクトは製品に対応付けられる概念であり、FeatureやReleaseは顧客に届ける製品の一機能に過ぎないからだ。
むしろ、FeatureやReleaseはリリース日が無期限のRedmineバージョンに対応付けるべきだと思うからだ。

つまり、FeatureやReleaseにあるTask（チケット）は、優先度が決められてリリース予定日が確定すれば、該当するRedmineバージョン（イテレーション）に移動されて、開発の対象（リリース対象）になる運用になる。
僕も、「内部課題」「仕様変更の要望」といったリリース予定日を100年後に設定した特別なバージョンを用意しておき、似たような運用はしている。

なお、PivotalTrackerやそのクローンであるFulcrumは下記で書いた。
よりアジャイルに開発したい人はそれらのツールを使ってもいいかもしれない。

Pivotal Trackerとredmineの違い: プログラマの思索

Pivotal TrackerクローンのFulcrum をインストールしてみた: プログラマの思索

上記の概念を実運用されている@daipresentsさんの講演資料はとても参考になる。

【3】リスク主導のタスク管理とタスク主導のタスク管理の違い

@sakaba37さんと話しながら思ったことは、僕や@sakaba37さんのチケット駆動開発と@daipresentsさんのチケット駆動開発は違っていること。
@daipresentsさんのチケット駆動開発は、本来のAgile開発に近いと思う。

@daipresentsさんの講演資料では、ユーザストーリーマッピングの写真が出てきて、FeatureやReleaseに出てくるTask(実際はおそらくストーリーカード)を並べる作業が出てくる。
ユーザーストーリーは、昨年のAgileJapanで懸田さんが講演された時に説明を受けたが、それは、縦軸を優先度、横軸をリリース日としてユーザストーリーを並べて、ユーザストーリーの依存関係や本来あるべきビジネス要求の開発順序を考えるために使われていると聞いた。

ユーザストーリーマッピングが最強という@daipresentsさんの資料があるけれど、その意味は、ユーザストーリーマッピングを使って、顧客のビジネス要求を優先度(実際はビジネスの重要度)やリリース日の観点で分類して、タスク管理をやりやすくすることに使っているのだろうと思う。
つまり、FeatureやReleaseレベルのストーリーは、ユーザストーリーマッピングで複数人のSEが自由に議論しながら、ビジネスの重要度やリリース日の観点で精査した後、直近の優先度の高いストーリーから順に開発対象に回して、アジャイルに開発していく運用フローなのだろうと推測する。

その運用フローは、まさにアジャイル開発のタスク管理そのものであり、Redmineをわざわざ使うこともない。
TracでもJiraでもいいし、アナログのPostItでやってもいい。
RedmineチケットはFeatureから「あらかじめ」洗い出されたタスクカード(ストーリーカード)であり、予期しないタスクではない。

逆に、僕や@sakaba37さんのチケット駆動開発は、障害管理の発想を受け継いだ開発スタイルなので、もちろん当初予定されていたタスクはRedmineチケットにあるが、開発中に発生した予期しないタスクもRedmineチケットへ随時発行して管理していく。
だからこそ、リリース日には、当初見込んだタスクよりも2倍近いチケットが実際はこなされている時が多い。
つまり、タスク管理だけでなく、リスク管理や課題管理としてRedmineを運用している。
そして、Redmineをソフトウェア工学の観点で、メトリクス収集のツールとしても重要視している。

本来のAgile開発のタスク管理では、イテレーション中にストーリーカードやタスクカードが増えることはない。
イテレーション実施中の2～4週間はスコープは固定されているのが前提。
でも、僕が実運用していた時、緊急の障害修正や突然の仕様変更に対応する場合は結構あったから、イテレーション中にスコープ変更はやっていた。
だから、本来のAgile開発とは言えない部分がある。

どちらの手法が正しいといわけではないけれども、本来のAgile開発のタスク管理は@daipresentsさんの講演資料の方が近いだろうと思う。
色々考えてみる。