部屋とワイシャツと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, Flash OSSベースに自社開発したMVCフレームワーク Yahoo!モバゲーの週間女性ランキングでけっこう上位に述べ15万人以上のユーザがインストールハンゲーム等他プラットフォームにも展開中開発してるアプリの例

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

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

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

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

案ずるより産むが易し

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

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

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

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

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

En vedette

En vedette (20)

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

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

Dernier

Dernier (9)