#agilesamurai dojo gathering 2012@オラクル青山センターに行ってきました

Agile Samurai Dojo Gathering

サムライ戦記実践編で登壇しました

サムライ戦記実践編で「内製基幹システムのOne-Iteration」というタイトルで登壇。

その時のTweetのトゥギャりは以下のリンク。
http://togetter.com/li/277905

資料について補足すること

資料はあまり細かく書いていないので補足します。
現在の基幹システムプロジェクトを1年と3ヶ月ほど進行しています。


プロジェクト初期
プロジェクト開始当時2週間(月曜始まり、金曜終わり)を1Iterationとして成果を
お届けしていたのですがスコープ定義とFeed backを行った結果のブレが大きかった
ことや開発人員が途中で1名増えるなどの要因があり1Iterationを1週間(水曜始まり、
火曜終わり)に変更しました。プロジェクト運営をして11ヶ月目のことでした。
当初「2週間でいいんじゃない?」という意見が開発メンバーから出ましたが
「2週間だと必ずしも当初要求通りに成果を届けられていないような気がしている。
1週間1Iterationを実験的にやってみないか?」と改めて開発メンバーに提案して
切り替えました。
金曜終わりから火曜終わりにしたのは、金曜をイテレーションの終わりにしていると
リリースのタイミングを合わせづらいのとイテレーションのクロージング、
イテレーションの開始準備の負荷が高いので火曜終わりにしました。


同じくプロジェクト開始当時、HudsonのようなCIを導入したいと思ったのですが
社内の関連部署にお断りされたのとそこまで緊急でもないので共用の開発機に
DailyBuild.shなるものを作ってcron登録を行いテストの自動実行環境を構築しました。
ついでにgrepでインデントや改行コードだけ簡易チェックを実施。
(静的コード解析を入れるのが面倒だった)。
改行コードをDOSで保存されてしまうと非常に稀ですがプログラムが正常に動作しなく
なったりバージョン管理の差分チェックで引っかかるなど手間が増えるので常にチェック
しておいたほうが良いです。DailyBuild.shは約1年以上、毎日稼動しています。
今は約1,200個のテストが稼動しています。他のプロジェクトのエンジニア(@katzchang)
からは「1年プロジェクト運営してその数は少ないよ」と指摘を受けていますが。


プロジェクトを1年運営してみて
1年以上開発を続けているけれども開発速度は落ちていません。というより、初期よりも速いです。
プロジェクト開始当時は要件が不確実なので思考錯誤と認識の相違で悩む時間や
手戻りが多くて開発速度がとても遅かったです。おそらく現在の半分程度の速度
だったんじゃないかなと思っています。


Day 1〜Day 4の開発プラクティス補足
TDDとテストの自動化を実施していないとリファクタリングはかなり困難であろう
という話もしました。テストが自動実行されていないと、テスト自体の品質が確認されていない
という事態になり、テストコードを信頼できなくなります。そこで前述のbash + cronが効いてきます。


Day 5の補足
Feed back MTGの難しいところは「顧客の時間を確保できないこと」です。
基本的に顧客は既存の業務で忙しいです。忙しいなか出ていただいても
ちゃんと動く画面を軽く実演したりするとOKとおっしゃってくれます。
リリースしたあとに本当は全然OKじゃないということに気づくこともありました。
こういうとき、顧客が忙しいということを認識しているにもかかわらずFeed back MTGの
進行や成果物自体を洗練させられていないことの問題はこちらにあります。
アジャイル関連の本にはよく、
「毎週Feed back MTGを開催して価値ある成果を顧客に届けよう!」
なんてことがサラっと書かれているのですが司会進行の能力や成果物の見せ方や勘所の
説明などは短いMTGの中で行う必要があるのでかなり難しくスキルを要求されます。

質問への回答

当日講演が終わってからの質問とTweet上での質問があったのでこちらに回答、記載します。


Q:リファクタリングをスコープに含めることは非常に難しいと思っている。どのように実施しているか?
これは我々のプロジェクトでもとてつもなく難しい。「リファクタリングを実施する」
といってもその成果を示すというのは至難です。この質問をされた時に改めて
振り返ってみました。我々のプロジェクトでは、「KPTのTryでリファクタリング
対象として認められた範囲かつ次のイテレーションに関係している場合は
リファクタリングを実施する」と、タイミングを見計らって押し込んでいました。


Q:今の環境で新しい言語、フレームワーク、開発方法の学習コストが高い、あなたのプロジェクトではそれをどのように支払っているか?
これは経験を話しただけで解決策を提示できていないのですが、ペアプログラミング
コードレビューを行いながらそれ相応の時間を払っていくしかないんじゃないかと
答えました。プロジェクトごとに言語もフレームワークも開発方法も異なることは
仕方がないので都度学習するという方法しかないんじゃないかなーと。
我々のプロジェクトでも新しく人が入ったらそのあたりの習得には3ヶ月ほど
かかっていました。



上に記載しておきました。



2週間を1Iterationにしている時よりもMTGの時間は少し増えるので作業時間は減ります。
その代わり手戻りにかける時間は減ったと思います。



TDDでFunctional testは書いていないです。Functional testを書くときは
大体以下の流れで構築しています。

  1. UT作成
  2. 開発
  3. リリース
  4. 運用
  5. Controllerのテストがあったほうがもうちょっと楽だよね
  6. Functional test作成


さらに質問があればこのエントリーにコメントに書いて頂ければと思います。

感想

基調講演からビアバッシュまでどれも面白かったけれど、個人的にはワールドカフェが
断トツに面白かったです。自分の経験とまだ経験していないことに対する疑問。
同じテーブルにいる方たちの経験とまだ経験していないことに対する疑問。
それをぶつけ合うのはとてつもなく面白い。

ワールドカフェでは、

  1. アジャイルでコレはやってよかった!
  2. なぜアジャイルでやりたいのか?
  3. 明日からやること

の3つに参加しました。

  • そもそもアジャイルとは何か?
  • 人やエンジニアはどのような特性を持って業務を執行しているのか?
  • 朝会っていいよね!
  • 振り返りっていいよね!

そんな話をして盛り上がりました。こういう話は楽しい。来週から何をやろうか。
普段何を心がけようか、それらを考えさせられる良い機会でした。ワールドカフェ最高!


最後になりますがagile samurai dojo gatheringを主催してくれたスタッフ各位、
アジャイルサムライを書き上げた執筆者各位、この会に参加してくれて一緒に
議論してくれた参加者の皆さんに感謝いたします。