アジャイル開発とTDDを半年間実践してみた顛末と、これから

株式会社NIJIBOX@remore

PHP Conference Japan 20112011/9/10 Sat

立ち位置

このセッションが参考になるかもしれない人

• アジャイルにあまり詳しくない人• 身近に「テストコードを書く」とか、「イテレーションで開発しよう」とか言ってる人がいない人

• テストが好きな人• テストコードを書いたりTDDやCIを始めたいので、背中を押してほしい人

• PHPを使った開発現場でアジャイルがどう理解されて採用されているか、事例を知りたい人

このセッションがあまり参考にならないかもしれないので心配な人

• 既にアジャイルな開発をされている方、経験豊富な方

• テストコードとか余裕で書いてる人。autotest使わないと生きていけない人などを含む。

• その他、ギークな方々。例えば、”ギーク”トラックにアジャイル開発のセッションがあっていいの、PHPerしっかり、って思っちゃう鋭い人を含む。

①＠remoreとPHP

@remore

2001.4 2011.3

10年間、小さなSIerで受託開発。エンジニアとプロジェクトリーダ。がっつりウォーターフォール

に転職

2011.9

半年前、

• 1982’s、札幌生まれ札幌育ち• 両手両足で収まらない人数で、納品まで１年以上かかる開発をマネジメントしてたことがある程度にはウォーターフォーラー（でした）

http://en.wikipedia.org/wiki/Php

細く長くPHPを愛用

My First Books

①

②

現場のスペック• ソーシャルアプリの自社開発がメイン• 開発期間が短い（0.5ヶ月～3ヶ月）• チームメンバーは流動的。プランナ1～2人にエンジニア1～2人が基本体制で、案件によって協力会社さんと共同作業が発生

• 開発中からリリース直前まで仕様変更が発生し、リリース後も仕様変更がある＝常に仕様が変わる

• エンドユーザからのフィードバックが早く、その分バグ修正や機能修正にも速いスピードが求められる

考えたこと• この現場でウォーターフォールで開発しても成果が上がらなさそう

• アジャイルやってみるか• 試しに社内勉強会でアジャイルプラクティス読んでみよう

• あわよくばTDDで品質を担保できたりしないの

TDDのコード例

Kent Beck wrote:

TDDは分析技法および設計技法であり、実際には開発のすべてのアクティビティを構造化するための技法である。

テスト駆動開発入門p199

TDDは分析技法および設計技法

①

②③

実践したこと（の一部）

2011.3 9月

アジャイルプラクティス社内読書会 全10回 完了

いまここ

5月 7月

アジャイルサムライ邦訳レビュー参加

・テストコードを使って既存アプリの改善開発

「PHPを使ったアジャイル開発のLT、読書会とミニワークショップ」開催

・相対見積りで作業計画を作成・テストファーストで新規開発

アジャイルサムライ渋谷道場全６回会場提供、参加

TDDBC1.5参加

実践ビフォーアフター TDD編

• テストコードを書くエンジニアの数：0人⇒5人• 部署のエンジニア30人。全体の17%がテストコードを書くようになった

• TDDを導入している案件数：0⇒3案件• 平均テスト数（assertion数）はわずか300/アプリ• テスト対象のコードは多くないが、それを差し引いてもテストのカバレッジは高くない。今後の課題。

実践ビフォーアフター TDD編

• 運用中のアプリのデグレの報告件数が目に見えて減少• 前よりもよく眠れるようになった（当社比）• 空いたパワーを他の事に使えるようになった• 潜在バグを修正できたりした

実践ビフォーアフター アジャイル編

• 実践前に比べて、仕様変更が容易に• 相対的な見積り（ストーリーポイント）と機能単位での開発（エンドツーエンド）を行うことで、これまでよりも高い精度で仕様変更の影響を見積もれるようになった

• チーム外へ文化の伝播が始まった• ホワイトボードに作業項目を張り出していたら、自然と他のチームでも張り出す文化が始まっていったりした

• その他に、プランニングポーカーやデイリースタンドアップ、インセプションデッキ等も実験的に行って効果を見極めているところ

かかったコスト（TDDについて）• テストコードを書くエンジニア全員（業務時間内）• テストコードを書く時間• 開発環境（PHPUnit）のインストール等準備時間含む• 社内勉強会に参加してもらう時間• @remore（業務時間内＋時間外）• 勉強会を開催したり参加したりする• 率先して本を読む

これからの課題（TDDについて）

• TDDが自然に伝播していって、我流すぎるやり方が出てきている

• 社内でTDD講習会を開く• CIが継続できていない• Jenkinsのインストールまでは終わってるけど、ビルドしてテストするプロセスを毎日の業務フローに組み込めていない

• 壊れやすいテストコードを書かないように講習会で指導を進める

①

②

④独断と偏見ベースで

③

Rising The Barアジャイルを学んでいくと、

• より価値のあるソフトウェア作りを求める不断の意思が伝わる

• プラクティスを通じて、色々なことに気付かされる• 例えば僕の場合だと、顧客の考える価値は常に変わる＝仕様も常に変わる、という当たり前の事に気付かされた

• それは、ウォーターフォールの世界では”仕様のFIX”という言葉に守られて、顧客に提供することが難しい価値

http://www.flickr.com/photos/scottishathletics/3254776255/

組織的な成功を目指す一助に

• アジャイルなプラクティスたちは、自分から動ける人、肩書きを気にしない人、当事者意識を持って動ける人になるように促してくれる

• 全員で考えるチームを目指せる• コミュニケーションの重要性を絶えず意識できる• 臭いものにフタをするようなマネジメントではなく、顧客を含めたチーム内全員でまずい部分を認識して開発を進める文化が生まれる

いまTDDを学ぶべき理由

• TDDを実践する文化は急にスケールしない• 他の言語と比べるとPHPerにはTDDを使いこなしてる人が多くないみたいでなんとなく悔しい（←

• PHPの中の人は前からテストコード書いてる• テスティングフレームワークやテストコードの書き方の記事も、環境も情報も十分に揃っている。TDD is waiting for you!

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

TIOBE Programming Community Index for August 2011

TDDBCでの使用言語数の比較言語 使用された回数Java 12Ruby 9C# 5

Python 4PHP 4Scala 2

※@remore調べ、2011年８月までの公式情報と参加者のブログを確認して測定※TDDBC/TDDPC佐賀については使用した言語情報が確認できなかったため測定から除外

多分こうなってる（日本だと）

PHPのユーザ総数

TDDやCIの実践者数

ある他の言語

絶対数が多い 絶対数が少ない

実践者数が少ない理由の予想

• 水は低きに流れる？• テストを書きたい人は、テスト書く人が沢山居て、情報がより集約されてるRubyやJavaに流れていってる説

• 必要性を感じている人が少ない？• 利用者がテストを自動化する必要性を感じてないから実践していない説

⇒その恩恵にあずかったことがないのかも。業務で利用する場合は特にその恩恵は大きいはずなんだけど…

Kent Beck wrote:

保守的な登山家は4本の手足のうち、必ず3本は地面につけるという習慣を持っている。１度2本を動かすというダイナミックな動きは、遥かに危険である。

テスト駆動開発入門p124

①

②

⑤

③

④

オススメの導入方法＝価値の説明方法

• まず、押し付けない• 言葉でも用語でもなく、手法の中身と価値を説明する

• 横文字を使わない• 無意識にアジャイルに開発できてる人やチームにああだこうだ余計な事を言わない

• 使えそうなプラクティスから使う• 学習コストを常に意識する

ウォーターフォールの現場でもアジャイル開発を学ぶ意義は大きい

アジャイル ウォーターフォールデイリースタンドアップ 朝会レトロスペクティブ プロジェクト完了報告、総括

見積りは不確かであることを前提とする

スケジュールに必ずバッファを読む

イテレーション、インクリメント長期に渡るスケジュールでは、マイルストーンを小刻みに設定する

時間、予算、品質を固定してスコープを可変にする

提案時に、時間・予算・品質を詳細に定義して前提条件として盛り

込む

ウォーターフォールの開発現場のプラクティスは、アジャイルで深く研究されている

TDDことはじめ＜テスティングフレームワーク選び＞

• PHPUnit：大本命。テストコードの規模が大きくなるならこの一択。なんだかんだ見やすいテストコードが書けるし、情報も豊富。

• limeやSimpleTest：PEAR非依存なのでインストール不要＝わずかだけど初期導入コストが低いといえば低い。中小規模の開発やテスト文化の定着のためであれば利用は大アリ

• その他のテスティングフレームワーク：もやし日記さんのまとめが分かりやすいです

• http://d.hatena.ne.jp/p4life/20080314

TDDことはじめ＜教材選びと勉強会＞

• とりあえずKent Beckのテスト駆動開発入門を読む

• 余力があれば次にgoos本を（Growing Object-Oriented Software, Guided By Tests）

• 社内でテストコードを書いてみる会を開催してみたり、TDDBCが開催されていたら参加してみる

• この後の@yamashiroのセッションもお聞き逃しなく！

TDDの導入は挫折の連続

• TDDつまづくあるある• 実際のソースコードがテストコードが無い状態（レガシーコード）の場合にどこからテストを始めればよいかわからない問題

• テストコードを書く時間分生産性が低下する問題など• 自分なりの乗り越え方のまとめ• http://www.slideshare.net/keiswd/tddtdd

最後に大切なこと

価値のあるソフトウェアを早く継続的に

顧客に提供するということ

大切な事に気付かせてくれる２冊

SpecialThanksTo

@kakutani @t_wada

渋谷の先輩方と仲間

＠bokusamahttp://farm3.static.flickr.com/2485/4101436288_3eb6f90ed8_b.jpg

おまけ

付ろく。参考文献• 三周遅れのXP• http://www.slideshare.net/yoshiori/xp-3242327• 読んでおくべきテスト関係のTL• http://togetter.com/li/5878• http://togetter.com/li/6759• http://togetter.com/li/6923• 本を読むならアジャイルプラクティスとアジャイルサムライが断然オススメ

もっとアジャイルサムライ

• アジャイルサムライのwikiを参照• 全国各地で読書会（道場）が開催されてる• アジャイルサムライのwikiもごひいきに• https://github.com/agile-samurai-ja/support/wiki/AgilesamuraiDojo

• アジャイルサムライを読んだあなたも、これから読んでみようと思ってるあなたも、9/18(日)のアジャイルサムライ他流試合もお見逃しなく

• http://atnd.org/events/19733

人材募集（おやくそく）

• NIJIBOXでは、Unityやりたい人を募集してます←• PHP使える人ももちろん歓迎なんですが、今回はJavascript使いの募集

• ※9/10時点の情報です• 興味のある方は下記URLでチェックしてみて下さい• http://nijibox.jp/unity/

おしまい