DVCSもBTSも知らない人達とScrumをやってみた。

このエントリーはStartup Scrumなブログではありません。Scrumというものに興味をもった当時23歳うさみみ系エンジニアがScrumという言葉を借りて開発してみた。という話です。2011/3から2011/5あたりの話。

2011/3。僕はデスマ４年目を終えて、新しいプロジェクトに移りました。
あるプロジェクトの中の4人チームのうちの1人として。もちろん僕はいちばん下っ端として。
（元請け会社の2人、当時同じ会社だった先輩、僕の4人）
そのプロジェクトはWFだったんですけど、タイムボックスやリスク管理について理解があることは雰囲気で伝わってきました。

僕はその頃勉強し始めていたあらゆることを現場で試してみたいって強く思いました。
僕はMercurial、Jenkins、Groovyを趣味的に使い始めていて(MercurialとJenkinsは2010/10から。Groovyは2011/2から。)、
Redmine+Backlogs(@yusuke_kokuboさんの紹介)の簡潔さに魅力を感じ、
Agileがもつチームの魅力に心惹かれていました。（今もそうだけど。

チームメンバーはDVCSもBTSもUnitTestもAgileも知らない人たちでした。
でも、きっと出来るはずだって思いました。（始まって2週間働いてみた印象ではメンバーはお互いを尊敬していると確認できたから

Scrumという概念の導入

まず2週間ほどで次の資料を読んでおいてもらいました。 "スクラム入門"
2週間後にScrum勉強会をしました。
Agileの基本的な概念、Scrumのザックリとした説明や不明点を吸いだして答えるというのを1時間ほど。実際のツールの使い方を1時間ほど。
この説明のなかで何度も繰り返して伝えたテーマがあります。
「細かいリリースとか書いてあるけど、個人的にはそこはプロジェクトに合わせればいい。」
「僕はAgileなチームを作りたいだけであって、ぶっちゃけると戦術はなんだっていい。僕達が無理なくやれる範囲でスタートしたい。」
この後、2週間程度のSprint、プランニングポーカーなど実際にやったわけですが、それは規模も進捗も自分達が知っている方法の中で一番明確だったからっていう選択です。
ちなみにロールとしては僕がスクラムマスターで、チームのリーダーがプロダクトオーナーになりました。

ツール選定

「チームメンバーはDVCSもBTSもUnitTestもAgileも知らない人たちでした。」というチームに対して僕がアプローチするのは運がよかったかもしれません。
僕自身が「学習コストが低い」「運用コストが低い」が好きで、そういったものは先のような状況で導入が楽だからです。（楽できるほうがいいじゃん。。。みたいな。

開発マシンであるWindowsのみを与えられているときに如何に簡単にスタートを切れるか。
つまり、ここでインストールしたBTSやCIやDVCSのサーバーは全て僕の開発マシンにインストールしました。
これに尽きました。（僕は別にコンサルやマネージャーとして入っているわけでもないですしね。自分たちのリソースでなんとかする。

導入したツールは次の3つです。
・Windows上でのGUIが超絶的に優秀なMercurial
・どんなOSでも簡単に使い始められるJenkins
・入力項目が5項目以下でしかもタスクがわかりやすいRedmine+Backlogs

Rubyを全く知らない僕にRedmine+BacklogsをWindows上で構築することがすごく難しくて悩んでいたら、
@yusuke_kokuboさんがパッケージングしてくれたものをくれました。
（プロジェクトが終わる頃にBitNamiで環境構築できるくらいのスキルはつきました。
Windows上でのRedmine+Backlogsの構築方法はこちら
→「BitNami RedmineとBacklogsをインストールしてみたよ！ - うさぎ組」

Redmine+Backlogsの始め方

Scrumを基本とするのでストーリーでタスクを管理していくことになりますが、プロジェクトのガントチャートはそうなっていません。
ですが、実現したい(アウトプットしたい)ことを明確にしていくことは変わらないはずですし、
とりあえずは「期間に収まって、意志が伝わる内容であればストーリーとしていい」(ガントチャートに書かれているままでもいい)で始めました。

まず最初の1週間はSprintとかを考えずに操作になれてもらうことにしました。ワークフローになれてもらうって感じですね。
POがProduct Backlogにストーリーを追加して、Sprintを作成して、優先順位つけて、Storyを移して、見積もって、自発的にタスクをこなして、デイリースクラムをする。
デイリースクラムは毎朝僕のパソコンの前でBacklogsの画面を見ながら10分以内で終わらせるようにしました。
Backlogsはあくまでトレーサビリティをとるものであって、
毎日お互いの状況を見えるようにしながら報告しあって、問題がありそうならチームで解決を図るっていうのはいいなーって思いました。

翌週からはちゃんとタイムボックスやバーンダウンチャートを意識してSprintを回し始めました。
SP見積もりにプランニングポーカーを用い始めたのは1ヶ月くらいたってからでした。

Mercurialの始め方、CIの始め方

まずは共有ファイルサーバーで使っていたディレクトリをMercurialのリポジトリにして、今まで通りにファイルサーバーのファイルを上書きしてもらっていきます。
でも、更新したらcommitすること。これで簡単に過去にもどれるようになります。

更新したらcommitすることを覚えたらDVCSの真価を発揮させます。ローカルとセントラルでやりとりするようにします。
最初はブランチとか気にせずに。でも、コミットコメントは意味のあるものにするように毎日僕がコミットログを見るようにしていました。
2週間くらいでだいたい出来るようになった気がします。

pull/push/mergeを覚えたら長期的ブランチを導入します。開発用ブランチとリリースブランチ。Sprintが完了するたびにリリースにマージしてタグを打つ。
このプロジェクトではトピックブランチの作成までは導入しませんでした。
と、同時に開発者毎のpush専用リポジトリ、全員共通のpull専用リポジトリを作成します。
開発者毎にpush専用リポジトリを用意し、自動テストを実行してから、pull専用リポジトリに自動的にpushします。

CIが実行されるタイミングはセントラル側のリポジトリがincomingを検知して勝手に実行されるようにしました。incoming = wget http://localhost:8080/jenkinsJob みたいなものをhgrcに書くだけ。
CIの導入に実質的な障壁はありません。(ローカルに影響がない
失敗したらメールを飛ばしたり、Persona Plugin入れてメンバーが好きなアーティストを表示しておいたりもしておきました。

バーンダウンチャートについて

バーンダウンチャートは結構使えました。というのも、終わらなさそうっていうのがすぐにわかるので。
終わらなさそうだったときに、何かを外せないか、何か重複しているものはないかを必死に考えて、案がいくつか出たらメンバーやプロダクトオーナーと話し合って。
いま、思うとこれは「いかにして問題を解くか」ステップの逆パターンかもしれません。

実際の開発について

シェルスクリプトを使ったバッチ処理、小さいJavaライブラリを作りました。

どちらでも設計時に気をつけたのは、誰かが設計案を出すたびに「で、それが正しいことはどうやって確認出来るんでしたっけ？」って答えるようにしていたことです。
テスタビリティ大切ですね。ある振る舞いの再現性を低くしてしまう要因は出来るだけ排除しました。

僕はシェルスクリプト初心者で、Bashってなんですか。。。？だったのですが、自分でテストフレームワークみたいなのをつくっていくうちに覚えていきました。
関数をテストするものだったり、テストスイートつくったり、ログ検査つくったり、テスト結果ログファイル出したり。。。
自分が不慣れな言語であるほど、自動化は大切でした。テストのやり直しやバグ探しがめちゃくちゃ大変です。
HinemosというOSSで定時処理をするアプリだったのですが、GUI以外だと非公式なSOAP APIで動くらしくて、最後に少し自動化できたくらいでした。面倒だったのと、Hinemosのソースコードが結構ひどかったのを覚えています。

Javaはなんとか出来るレベルだったので、積極的に取り組んでみました。テストコードにはGroovy+JUnit4、ビルドにはGradleを使いました。
もちろんペアプロでTDDです。僕以外は自動テストをしたことがない人達でしたけど、ペアプロの楽しさ、TDDのリズムを共有できたと思います。
開発対象がライブラリだったので、クライアントコードを書くチームにはAPIのJavaDocとサンプルコードを渡して合意してからそれらを自動受け入れテストとして初めから組み込みました。
お互いに変更があれば、まずは自動受け入れテストを変更して、試して、お互いに結果を確認するって感じです。
このとき、Key-Valueがネストになっている(ValueにさらにKey-Valueが入る)ような構造をXMLとして吐く必要があって、
Javaで書いたら300行くらいの意味不明なコード(つまり僕のスキルでは汚い設計)になってしまい、Groovyで書けないかと、Twitterで助けを求めたら半日ほどで20行ほどのコードになりました。 Groovyistカッコイイ！
詳しくはこちら→GroovyでKey、ValueをXMLにクールに出力する-keyValueXml.groovy- - Togetterまとめ
interfaceさえ継承すればJavaレベルで型安全な使い方をできるのもGroovyの魅力だなーって思いました。
初めて仕事でGroovyとか使いましたね。

テスト設計について

この頃やっとソフトウェアテストを勉強しはじめたばかりでどうしていいのかわからなかったのですが、
「マインドマップから始めるソフトウェアテスト」を読んでいたこともあって、マインドマップでテスト設計をしてみました。
これがすごくわかりやすくってよかったです。テスト設計レビューのときにもズームイン/ズームアウトしやすかった。
それと同時にこれ以上複雑アプリでは自分の今のスキルではテスト設計のリファクタリング力が足りないなーとも感じました。
ここからNGTにつながっていった気もします。

困ったことについて

Scrumをやっていて困ったことはとくにありませんでした。
みんな毎日楽しいって言ってくれた。
「あぁ、仕事ってこんなに楽しいものなんだな」って初めて思いました。
Agile初心者が真似事をやってうまくいった外的要因がいくつかあると思っていて、大きくは2つ。
1つはプロジェクト全体として無理を言ってこない人たちで構成されていたので、PMが優秀だったのだと思います。
もう1つはアプリケーションがそこまで複雑ではなかったのもよかったんだと思います。調べごとに追われなかったとかも。

これがすごく財産になった

これをキッカケに「うさぎ組-ust-」や JGGUGでの発表が続いて行きます。
そしてSCMBootCampが生まれました。
TDDBootCampにも積極的に参加できました。(毎回Groovyで参加しています！
JaSST Tokaiの実行委員会にも入らさせて頂きました。
当時の自分で出来る全てのことをやったのがあのプロジェクトでした。
たぶん、これがキッカケで「開発環境改善」っていうのに目覚めた気がします。

当時Scrum導入で参考にしたもの

いろんな書籍や情報があるので参考にならないかもしれないけど、当時これを参考にチームと付き合ったっていうものを挙げてみます。

書籍

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

Web
「スクラム入門」
「スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） － Publickey」
「重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） － Publickey」
「10分でスクラム - kawaguti の日記 (id:wayaguchi)」
「「10分でスクラム」、アジャイル開発の「スクラム」に興味がわいた方へ － Publickey」
「アジャイル/スクラムの振り返り - ヒントと秘訣」
「スクラムアジャイルチームに必要なスキル」
「かんばんとスクラム 両者のよさを最大限ひきだす」
「改善、成功と失敗: 中国でのスクラム導入」
「プロダクトオーナーを成功させる」
「プロダクトオーナーにバックログを優先順位付けさせる方法」
「スクラムにユースケースは使えるか？」
「制約は利点の仮の姿だ」
「アジャイルチームへ上手く移行するには」
「リスバーガー - かおるんダイアリー」
「リスバーガー・２ - かおるんダイアリー」
「アジャイル開発の始め方」
「スクラムクラスタの人教えて。 チームに技術的に、こうして欲しいといった要望を伝えたいんだけど、どうしたらいい - Togetterまとめ」
「資料公開 Scrum概論 | Ryuzee.com」
「「アジャイル開発の基本的な流れ」 - ヲトナ.backtrace」
「テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組」

最後に

こんなエントリーを書いてもどうしようもないなって諦めたんですけど、@ryuzeeがリプライくれたり、他にもRTで期待を寄せてくれた方もいました。
ありがとうございました。おかげで少し楽しかった。