部屋とワイシャツとPHPとアジャイル開発と私

部屋とワイシャツとPHPとアジャイル開発と私@remore

自己紹介この勉強会ができたきっかけ「アジャイルプラクティス」を研修に使うべき３つの理由アジャイル開発の事例今日のミニワークショップの進め方今日話すこと

http://rimuru.lunanet.gr.jp/NIJIBOXでエンジニアやってますPHPを使ってアジャイルに開発することを目指してるTDDを設計手法として重宝開発の経験2月まで組み込みの開発やってた10人～20人位のチームで4年くらいウォーターフォール3月に入ってソーシャルアプリの開発始めた1~3人位のチーム非ウォーターフォール@remore

チームの規模が小さく開発期間が短い大体数名＋1~2ヶ月くらい成果を挙げるためにチーム力だけじゃなく高い個人能力がより必要になるそういえば自社開発でした受け入れテストが存在しないとはいえバグが許されるわけでもない（問題が責任問題や賠償問題に発展するかどうかの違いこそあれ、エンジニアとしてクリアすべき課題は同じ）いざお客さんの立場になってみたら、仕様を決めるのって大変何を決めたら仕様が固まったって言いますか？仕様が決まってなくても開発は進む転職してショックを受けたこと

この勉強会が生まれた経緯

ウォーターフォール脳になってる自分に気付いたショックを受けたことに対する答え（の一部）が、アジャイル開発手法を使うと出せる気がした調べてみると、TDDやCIを行う環境としてRubyやJavaの例は数多く紹介されているけど、PHPの情報は少ないようだった。Why not?開発手法を勉強し直そうと思った

Yammerでつぶやいた(3/28)

勉強会が生まれた(4/15～28, 計10回)

1. 成果をあげるのが仕事2. 応急処置は泥沼を招く3. 人ではなくアイデアを批判する4. 機雷がなんだ！全速前進！5. 変化に付いていく6. チームに投資する7. 時が来たら習慣を捨てる8. わかるまで質問する9. リズムに乗る10. 顧客に決断してもらう11. 設計は指針であって、指図ではない12. 技術の採用根拠を明確にする13. いつでもリリースできるようにしておく14. はやめに統合、こまめに統合15. 早いうちにデプロイを自動化する　　「アジャイルプラクティス」とは16. 頻繁なデモでフィードバックを得る17. 短いイテレーションでインクリメンタルにリリースする18. 定額契約は守れない約束19. 天使を味方につける20. 作る前から使う21. 違いがあれば結果も変わる22. 受け入れテストを自動化する23. ありのままの進捗を計測する24. ユーザの声に耳を傾ける25. 意図を明確に表現するコードを書く26. コードで伝える27. トレードオフを積極的に考慮する28. インクリメンタルにコードを書く29. シンプルにすること30. 凝集度の高いコードを書く31. "Tell, Don't Ask" ――― 求めるな、命じよ32. 取り決めを守ってコードを置き換える33. ソリューションログをつける34. 警告をエラーとみなす35. 問題を切り分けて攻める36. あらゆる例外を報告する37. 役に立つエラーメッセージを提供する38. 定常的に顔をあわせる39. アーキテクトもコードを書くべき40. 共同所有を実践する41. メンターになる42. 答えを見つけられるように力を貸す43. コードの共有には段取りがある44. コードをレビューする45. みんなに知らせる

1. 成果をあげるのが仕事2. 応急処置は泥沼を招く3. 人ではなくアイデアを批判する4. 機雷がなんだ！全速前進！5. 変化に付いていく6. チームに投資する7. 時が来たら習慣を捨てる8. わかるまで質問する9. リズムに乗る10. 顧客に決断してもらう11. 設計は指針であって、指図ではない12. 技術の採用根拠を明確にする13. いつでもリリースできるようにしておく14. はやめに統合、こまめに統合15. 早いうちにデプロイを自動化する　　「アジャイルプラクティス」とは16. 頻繁なデモでフィードバックを得る17. 短いイテレーションでインクリメンタルにリリースする18. 定額契約は守れない約束19. 天使を味方につける20. 作る前から使う21. 違いがあれば結果も変わる22. 受け入れテストを自動化する23. ありのままの進捗を計測する24. ユーザの声に耳を傾ける25. 意図を明確に表現するコードを書く26. コードで伝える27. トレードオフを積極的に考慮する28. インクリメンタルにコードを書く29. シンプルにすること30. 凝集度の高いコードを書く31. "Tell, Don't Ask" ――― 求めるな、命じよ32. 取り決めを守ってコードを置き換える33. ソリューションログをつける34. 警告をエラーとみなす35. 問題を切り分けて攻める36. あらゆる例外を報告する37. 役に立つエラーメッセージを提供する38. 定常的に顔をあわせる39. アーキテクトもコードを書くべき40. 共同所有を実践する41. メンターになる42. 答えを見つけられるように力を貸す43. コードの共有には段取りがある44. コードをレビューする45. みんなに知らせる読まなきゃモグリっぽい←

「アジャイルプラクティス」を研修に使うべき３つの理由

プログラミングやエンジニアリングのプラクティスに留まらずに、チームメンバーとしてあるべき態度や心構えなどがバランスよく盛り込まれている先輩メンバーが加わってディスカッションすると、現場に配属される前に情報の交換ができて更に良い理由１：プログラミング演習やチュートリアルでは伝えられない大事なことを伝えることができる

使われている用語の中に、新しく入るメンバーには聞きなれない用語が出てくることがある例：QA, Mock Object, IDE, COMコンポーネント、インクリメンタルな開発とかそんなときの先輩メンバーですよ調べればわかることはググればよいことを教えるチャンス調べるだけだと不十分なところは直接伝えるそうすると新メンバーの顔と名前を覚えられますパーソナリティや大体のスキルも把握できたりしますでもまあ：自分が自信を持って教えられない箇所があるとわかったりして、自分にとって一番勉強になったりします理由２：会話が自然に生まれる

車は急に止まれないし、開発手法も急に変えられない。人がついてこないと何も変わらない研修っていう体でしれっとアジャイル開発の勉強を進めておけば、後々アジャイル開発を導入したいと思ったときに（ドヤ顔で）有利に進められます理由３：アジャイル開発を社内で普及するための布石になる

概要1日30分。ランチの後の眠い時間帯を活用（14時前後）1回5名～10名程度が参加1回3章分進める基本的に本を買うことを薦めるけど、買わない人も参加できるように前日にコピーして配布。勉強会までに読んできてもらう進め方初めに、読んできた部分で分からない点がなかったかを確認して、あれば説明（5分）1グループ4人程度に分かれて、感想をシェア（15分）。読んできた内容で一番印象に残ったことについて経験を交えて話をする各グループの感想を発表（10分）参考：勉強会の進め方

1. 成果をあげるのが仕事2. 応急処置は泥沼を招く3. 人ではなくアイデアを批判する4. 機雷がなんだ！全速前進！5. 変化に付いていく6. チームに投資する7. 時が来たら習慣を捨てる8. わかるまで質問する9. リズムに乗る10. 顧客に決断してもらう11. 設計は指針であって、指図ではない12. 技術の採用根拠を明確にする13. いつでもリリースできるようにしておく14. はやめに統合、こまめに統合15. 早いうちにデプロイを自動化する　　特にウケが良かった内容16. 頻繁なデモでフィードバックを得る17. 短いイテレーションでインクリメンタルにリリースする18. 定額契約は守れない約束19. 天使を味方につける20. 作る前から使う21. 違いがあれば結果も変わる22. 受け入れテストを自動化する23. ありのままの進捗を計測する24. ユーザの声に耳を傾ける25. 意図を明確に表現するコードを書く26. コードで伝える27. トレードオフを積極的に考慮する28. インクリメンタルにコードを書く29. シンプルにすること30. 凝集度の高いコードを書く31. "Tell, Don't Ask" ――― 求めるな、命じよ32. 取り決めを守ってコードを置き換える33. ソリューションログをつける34. 警告をエラーとみなす35. 問題を切り分けて攻める36. あらゆる例外を報告する37. 役に立つエラーメッセージを提供する38. 定常的に顔をあわせる39. アーキテクトもコードを書くべき40. 共同所有を実践する41. メンターになる42. 答えを見つけられるように力を貸す43. コードの共有には段取りがある44. コードをレビューする45. みんなに知らせる

1. 成果をあげるのが仕事2. 応急処置は泥沼を招く3. 人ではなくアイデアを批判する4. 機雷がなんだ！全速前進！5. 変化に付いていく6. チームに投資する7. 時が来たら習慣を捨てる8. わかるまで質問する9. リズムに乗る10. 顧客に決断してもらう11. 設計は指針であって、指図ではない12. 技術の採用根拠を明確にする13. いつでもリリースできるようにしておく14. はやめに統合、こまめに統合15. 早いうちにデプロイを自動化する　　特にウケが良かった内容チームメンバーや、ステークホルダーとのコミュニケーションの重要性が特に響いた様子16. 頻繁なデモでフィードバックを得る17. 短いイテレーションでインクリメンタルにリリースする18. 定額契約は守れない約束19. 天使を味方につける20. 作る前から使う21. 違いがあれば結果も変わる22. 受け入れテストを自動化する23. ありのままの進捗を計測する24. ユーザの声に耳を傾ける25. 意図を明確に表現するコードを書く26. コードで伝える27. トレードオフを積極的に考慮する28. インクリメンタルにコードを書く29. シンプルにすること30. 凝集度の高いコードを書く31. "Tell, Don't Ask" ――― 求めるな、命じよ32. 取り決めを守ってコードを置き換える33. ソリューションログをつける34. 警告をエラーとみなす35. 問題を切り分けて攻める36. あらゆる例外を報告する37. 役に立つエラーメッセージを提供する38. 定常的に顔をあわせる39. アーキテクトもコードを書くべき40. 共同所有を実践する41. メンターになる42. 答えを見つけられるように力を貸す43. コードの共有には段取りがある44. コードをレビューする45. みんなに知らせる

アジャイル開発の事例

PHP, MySQL, OpenSocialJavascript API, FlashOSSベースに自社開発したMVCフレームワークYahoo!モバゲーの週間女性ランキングでけっこう上位に述べ15万人以上のユーザがインストールハンゲーム等他プラットフォームにも展開中開発してるアプリの例

継続的インテグレーション（※道半ば）PHPUnitを使った自動化されたテストJenkins, Phing, Subversionを使用ストーリーポイントによる見積かんばんボードスタンドアップミーティングBacklogを使ったチケット管理プロジェクトで導入しているアジャイルプラクティス

Modelに実装したメソッドに対してテストコードを作成。いま150Assertくらい。300Assertくらいまで増える予定サーバ側の実装がシンプルだとAssertも実はそんなに増えなかったりControllerに対して追加したテストコードはいま数十AssertくらいのみViewについてはテストコード書いてない。実効的な検証はソースコードレビューがメイン最近Viewからmodelのメソッドを呼び出している事例があって不具合になったりして大慌てしたりしたテスト自動化の程度

自動化されたテストたった150Assertでも高い効果が得られているデグレが発生する頻度が低くなったテストコードを追加で導入するために行ったリファクタリングによって、潜在的なバグも潰せた心理的な安心感かんばんボードより多くの人にチームの状況を理解してもらえるようになった。より説明が行き届いている状態（Assertive）になってるスタンドアップミーティング朝会。頭がシャキっとして良いです。タスクの状況やチームの状況の情報が入ってきやすくなったプラクティスの導入効果

CIPEAR依存だけど、機能の充実度で基本はPHPUnitを使うことになるJenkins良いです。サーバでもローカルでもすぐに使えるし使い易いTDDPHPでは型変換を意識することを忘れずにテストコードの書き方自体については一旦ブログにまとめていますhttp://rimuru.lunanet.gr.jp/notes/post/2882/TDDやCIはテクニカルな壁以上に、メンタリティ（思い込み）な部分で壁をつくっちゃってる場合もありそうそのあたり含めてTDDの経験談の細かいところを7/9のTDD Boot Camp in Tokyo でLTさせて頂く予定満席のため会場での参加は難しいかもしれませんが、Ustream配信もありそう（予定）なのでこちらもぜひ！http://atnd.org/events/16311PHPでTDD, CIするときの実際

案ずるより産むが易し

今日のミニワークショップの進め方

Githubに課題をアップロードしましたhttps://github.com/remore/StudyTDD課題１ケントベックが作成した解答と@remoreが作成した解答をテストコードの例として置いてあります。自分で解答を作成した後、解答を比較して楽しんでください。色々な発見があるはず※課題の回答はPHPUnit3で動作確認済み。SimpleTest使う人は、適宜読み替えてください。課題２もお手すきのときにぜひ。時間をとれる方は、手を動かしてみましょう

１グループ4～5名で構成します初めに、自己紹介を各自1分前後で次に、以下を参考に本の紹介とトークをしていきますまず1～2分でその本について説明その後フリートーク。続けて本についてご紹介いただいても良いですし、皆でディスカッションになっても面白いと思っています。フリートークは最大5分。これで1人分が終了です。今日の読書会の進め方

ニジボックスではエンジニア募集中PHP, Java,.NETあたりの経験者でソーシャルアプリ作りたい方スマートフォンアプリの開発も進めてます興味のある方はニジボックスHPへGO!ニジボックスは勉強会の開催を積極的にサポートしていきますおまけ

部屋とワイシャツとPHPとアジャイル開発と私

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to 部屋とワイシャツとPHPとアジャイル開発と私 (20)

Recently uploaded (10)