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

4,138 views

Published on

「PHPを使ったアジャイル開発のLT、読書会とミニワークショップ」 http://atnd.org/events/16018 での発表資料

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,138
On SlideShare
0
From Embeds
0
Number of Embeds
1,417
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

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

  1. 1. 部屋とワイシャツとPHPとアジャイル開発と私<br />@remore<br />
  2. 2. 自己紹介<br />この勉強会ができたきっかけ<br />「アジャイルプラクティス」を研修に使うべき3つの理由<br />アジャイル開発の事例<br />今日のミニワークショップの進め方<br />今日話すこと<br />
  3. 3. 自己紹介<br />
  4. 4. http://rimuru.lunanet.gr.jp/<br />NIJIBOXでエンジニアやってます<br />PHPを使ってアジャイルに開発することを目指してる<br />TDDを設計手法として重宝<br />開発の経験<br />2月まで組み込みの開発やってた<br />10人~20人位のチームで4年くらい<br />ウォーターフォール<br />3月に入ってソーシャルアプリの開発始めた<br />1~3人位のチーム<br />非ウォーターフォール<br />@remore<br />
  5. 5. チームの規模が小さく開発期間が短い<br />大体数名+1~2ヶ月くらい<br />成果を挙げるためにチーム力だけじゃなく高い個人能力がより必要になる<br />そういえば自社開発でした<br />受け入れテストが存在しない<br />とはいえバグが許されるわけでもない(問題が責任問題や賠償問題に発展するかどうかの違いこそあれ、エンジニアとしてクリアすべき課題は同じ)<br />いざお客さんの立場になってみたら、仕様を決めるのって大変<br />何を決めたら仕様が固まったって言いますか?<br />仕様が決まってなくても開発は進む<br />転職してショックを受けたこと<br />
  6. 6. この勉強会が生まれた経緯<br />
  7. 7. ウォーターフォール脳になってる自分に気付いた<br />ショックを受けたことに対する答え(の一部)が、アジャイル開発手法を使うと出せる気がした<br />調べてみると、TDDやCIを行う環境としてRubyやJavaの例は数多く紹介されているけど、PHPの情報は少ないようだった。Why not?<br />開発手法を勉強し直そうと思った<br />
  8. 8. Yammerでつぶやいた(3/28)<br />
  9. 9. 勉強会が生まれた(4/15~28, 計10回)<br />
  10. 10. 1. 成果をあげるのが仕事<br />2. 応急処置は泥沼を招く<br />3. 人ではなくアイデアを批判する<br />4. 機雷がなんだ! 全速前進!<br />5. 変化に付いていく<br />6. チームに投資する<br />7. 時が来たら習慣を捨てる<br />8. わかるまで質問する<br />9. リズムに乗る<br />10. 顧客に決断してもらう<br />11. 設計は指針であって、指図ではない<br />12. 技術の採用根拠を明確にする<br />13. いつでもリリースできるようにしておく<br />14. はやめに統合、こまめに統合<br />15. 早いうちにデプロイを自動化する<br />   「アジャイルプラクティス」とは<br />16. 頻繁なデモでフィードバックを得る<br />17. 短いイテレーションでインクリメンタルにリリースする<br />18. 定額契約は守れない約束<br />19. 天使を味方につける<br />20. 作る前から使う<br />21. 違いがあれば結果も変わる<br />22. 受け入れテストを自動化する<br />23. ありのままの進捗を計測する<br />24. ユーザの声に耳を傾ける<br />25. 意図を明確に表現するコードを書く<br />26. コードで伝える<br />27. トレードオフを積極的に考慮する<br />28. インクリメンタルにコードを書く<br />29. シンプルにすること<br />30. 凝集度の高いコードを書く<br />31. "Tell, Don't Ask" ――― 求めるな、命じよ<br />32. 取り決めを守ってコードを置き換える<br />33. ソリューションログをつける<br />34. 警告をエラーとみなす<br />35. 問題を切り分けて攻める<br />36. あらゆる例外を報告する<br />37. 役に立つエラーメッセージを提供する<br />38. 定常的に顔をあわせる<br />39. アーキテクトもコードを書くべき<br />40. 共同所有を実践する<br />41. メンターになる<br />42. 答えを見つけられるように力を貸す<br />43. コードの共有には段取りがある<br />44. コードをレビューする<br />45. みんなに知らせる<br />
  11. 11. 1. 成果をあげるのが仕事<br />2. 応急処置は泥沼を招く<br />3. 人ではなくアイデアを批判する<br />4. 機雷がなんだ! 全速前進!<br />5. 変化に付いていく<br />6. チームに投資する<br />7. 時が来たら習慣を捨てる<br />8. わかるまで質問する<br />9. リズムに乗る<br />10. 顧客に決断してもらう<br />11. 設計は指針であって、指図ではない<br />12. 技術の採用根拠を明確にする<br />13. いつでもリリースできるようにしておく<br />14. はやめに統合、こまめに統合<br />15. 早いうちにデプロイを自動化する<br />   「アジャイルプラクティス」とは<br />16. 頻繁なデモでフィードバックを得る<br />17. 短いイテレーションでインクリメンタルにリリースする<br />18. 定額契約は守れない約束<br />19. 天使を味方につける<br />20. 作る前から使う<br />21. 違いがあれば結果も変わる<br />22. 受け入れテストを自動化する<br />23. ありのままの進捗を計測する<br />24. ユーザの声に耳を傾ける<br />25. 意図を明確に表現するコードを書く<br />26. コードで伝える<br />27. トレードオフを積極的に考慮する<br />28. インクリメンタルにコードを書く<br />29. シンプルにすること<br />30. 凝集度の高いコードを書く<br />31. "Tell, Don't Ask" ――― 求めるな、命じよ<br />32. 取り決めを守ってコードを置き換える<br />33. ソリューションログをつける<br />34. 警告をエラーとみなす<br />35. 問題を切り分けて攻める<br />36. あらゆる例外を報告する<br />37. 役に立つエラーメッセージを提供する<br />38. 定常的に顔をあわせる<br />39. アーキテクトもコードを書くべき<br />40. 共同所有を実践する<br />41. メンターになる<br />42. 答えを見つけられるように力を貸す<br />43. コードの共有には段取りがある<br />44. コードをレビューする<br />45. みんなに知らせる<br />読まなきゃモグリっぽい←<br />
  12. 12. 「アジャイルプラクティス」を研修に使うべき3つの理由<br />
  13. 13. プログラミングやエンジニアリングのプラクティスに留まらずに、チームメンバーとしてあるべき態度や心構えなどがバランスよく盛り込まれている<br />先輩メンバーが加わってディスカッションすると、現場に配属される前に情報の交換ができて更に良い<br />理由1:プログラミング演習やチュートリアルでは伝えられない大事なことを伝えることができる<br />
  14. 14. 使われている用語の中に、新しく入るメンバーには聞きなれない用語が出てくることがある<br />例:QA, Mock Object, IDE, COMコンポーネント、インクリメンタルな開発 とか<br />そんなときの先輩メンバーですよ<br />調べればわかることはググればよいことを教えるチャンス<br />調べるだけだと不十分なところは直接伝える<br />そうすると<br />新メンバーの顔と名前を覚えられます<br />パーソナリティや大体のスキルも把握できたりします<br />でもまあ:自分が自信を持って教えられない箇所があるとわかったりして、自分にとって一番勉強になったりします<br />理由2:会話が自然に生まれる<br />
  15. 15. 車は急に止まれないし、開発手法も急に変えられない。<br />人がついてこないと何も変わらない<br />研修っていう体でしれっとアジャイル開発の勉強を進めておけば、後々アジャイル開発を導入したいと思ったときに(ドヤ顔で)有利に進められます<br />理由3:アジャイル開発を社内で普及するための布石になる<br />
  16. 16. 概要<br />1日30分。ランチの後の眠い時間帯を活用(14時前後)<br />1回5名~10名程度が参加<br />1回3章分進める<br />基本的に本を買うことを薦めるけど、買わない人も参加できるように前日にコピーして配布。勉強会までに読んできてもらう<br />進め方<br />初めに、読んできた部分で分からない点がなかったかを確認して、あれば説明(5分)<br />1グループ4人程度に分かれて、感想をシェア(15分)。読んできた内容で一番印象に残ったことについて経験を交えて話をする<br />各グループの感想を発表(10分)<br />参考:勉強会の進め方<br />
  17. 17. 1. 成果をあげるのが仕事<br />2. 応急処置は泥沼を招く<br />3. 人ではなくアイデアを批判する<br />4. 機雷がなんだ! 全速前進!<br />5. 変化に付いていく<br />6. チームに投資する<br />7. 時が来たら習慣を捨てる<br />8. わかるまで質問する<br />9. リズムに乗る<br />10. 顧客に決断してもらう<br />11. 設計は指針であって、指図ではない<br />12. 技術の採用根拠を明確にする<br />13. いつでもリリースできるようにしておく<br />14. はやめに統合、こまめに統合<br />15. 早いうちにデプロイを自動化する<br />  特にウケが良かった内容<br />16. 頻繁なデモでフィードバックを得る<br />17. 短いイテレーションでインクリメンタルにリリースする<br />18. 定額契約は守れない約束<br />19. 天使を味方につける<br />20. 作る前から使う<br />21. 違いがあれば結果も変わる<br />22. 受け入れテストを自動化する<br />23. ありのままの進捗を計測する<br />24. ユーザの声に耳を傾ける<br />25. 意図を明確に表現するコードを書く<br />26. コードで伝える<br />27. トレードオフを積極的に考慮する<br />28. インクリメンタルにコードを書く<br />29. シンプルにすること<br />30. 凝集度の高いコードを書く<br />31. "Tell, Don't Ask" ――― 求めるな、命じよ<br />32. 取り決めを守ってコードを置き換える<br />33. ソリューションログをつける<br />34. 警告をエラーとみなす<br />35. 問題を切り分けて攻める<br />36. あらゆる例外を報告する<br />37. 役に立つエラーメッセージを提供する<br />38. 定常的に顔をあわせる<br />39. アーキテクトもコードを書くべき<br />40. 共同所有を実践する<br />41. メンターになる<br />42. 答えを見つけられるように力を貸す<br />43. コードの共有には段取りがある<br />44. コードをレビューする<br />45. みんなに知らせる<br />
  18. 18. 1. 成果をあげるのが仕事<br />2. 応急処置は泥沼を招く<br />3. 人ではなくアイデアを批判する<br />4. 機雷がなんだ! 全速前進!<br />5. 変化に付いていく<br />6. チームに投資する<br />7. 時が来たら習慣を捨てる<br />8. わかるまで質問する<br />9. リズムに乗る<br />10. 顧客に決断してもらう<br />11. 設計は指針であって、指図ではない<br />12. 技術の採用根拠を明確にする<br />13. いつでもリリースできるようにしておく<br />14. はやめに統合、こまめに統合<br />15. 早いうちにデプロイを自動化する<br />  特にウケが良かった内容<br />チームメンバーや、<br />ステークホルダーとの<br />コミュニケーションの<br />重要性が特に響いた様子<br />16. 頻繁なデモでフィードバックを得る<br />17. 短いイテレーションでインクリメンタルにリリースする<br />18. 定額契約は守れない約束<br />19. 天使を味方につける<br />20. 作る前から使う<br />21. 違いがあれば結果も変わる<br />22. 受け入れテストを自動化する<br />23. ありのままの進捗を計測する<br />24. ユーザの声に耳を傾ける<br />25. 意図を明確に表現するコードを書く<br />26. コードで伝える<br />27. トレードオフを積極的に考慮する<br />28. インクリメンタルにコードを書く<br />29. シンプルにすること<br />30. 凝集度の高いコードを書く<br />31. "Tell, Don't Ask" ――― 求めるな、命じよ<br />32. 取り決めを守ってコードを置き換える<br />33. ソリューションログをつける<br />34. 警告をエラーとみなす<br />35. 問題を切り分けて攻める<br />36. あらゆる例外を報告する<br />37. 役に立つエラーメッセージを提供する<br />38. 定常的に顔をあわせる<br />39. アーキテクトもコードを書くべき<br />40. 共同所有を実践する<br />41. メンターになる<br />42. 答えを見つけられるように力を貸す<br />43. コードの共有には段取りがある<br />44. コードをレビューする<br />45. みんなに知らせる<br />
  19. 19. アジャイル開発の事例<br />
  20. 20. PHP, MySQL, OpenSocialJavascript API, Flash<br />OSSベースに自社開発したMVCフレームワーク<br />Yahoo!モバゲーの週間女性ランキングでけっこう上位に<br />述べ15万人以上のユーザがインストール<br />ハンゲーム等他プラットフォームにも展開中<br />開発してるアプリの例<br />
  21. 21. 継続的インテグレーション(※道半ば)<br />PHPUnitを使った自動化されたテスト<br />Jenkins, Phing, Subversionを使用<br />ストーリーポイントによる見積<br />かんばんボード<br />スタンドアップミーティング<br />Backlogを使ったチケット管理<br />プロジェクトで導入しているアジャイルプラクティス<br />
  22. 22. Modelに実装したメソッドに対してテストコードを作成。<br />いま150Assertくらい。300Assertくらいまで増える予定<br />サーバ側の実装がシンプルだとAssertも実はそんなに増えなかったり<br />Controllerに対して追加したテストコードはいま数十Assertくらいのみ<br />Viewについてはテストコード書いてない。実効的な検証はソースコードレビューがメイン<br />最近Viewからmodelのメソッドを呼び出している事例があって不具合になったりして大慌てしたりした<br />テスト自動化の程度<br />
  23. 23. 自動化されたテスト<br />たった150Assertでも高い効果が得られている<br />デグレが発生する頻度が低くなった<br />テストコードを追加で導入するために行ったリファクタリングによって、潜在的なバグも潰せた<br />心理的な安心感<br />かんばんボード<br />より多くの人にチームの状況を理解してもらえるようになった。より説明が行き届いている状態(Assertive)になってる<br />スタンドアップミーティング<br />朝会。頭がシャキっとして良いです。<br />タスクの状況やチームの状況の情報が入ってきやすくなった<br />プラクティスの導入効果<br />
  24. 24. CI<br />PEAR依存だけど、機能の充実度で基本はPHPUnitを使うことになる<br />Jenkins良いです。サーバでもローカルでもすぐに使えるし使い易い<br />TDD<br />PHPでは型変換を意識することを忘れずに<br />テストコードの書き方自体については一旦ブログにまとめています<br />http://rimuru.lunanet.gr.jp/notes/post/2882/<br />TDDやCIはテクニカルな壁以上に、メンタリティ(思い込み)な部分で壁をつくっちゃってる場合もありそう<br />そのあたり含めてTDDの経験談の細かいところを7/9のTDD Boot Camp in Tokyo でLTさせて頂く予定<br />満席のため会場での参加は難しいかもしれませんが、Ustream配信もありそう(予定)なのでこちらもぜひ!<br />http://atnd.org/events/16311<br />PHPでTDD, CIするときの実際<br />
  25. 25. 案ずるより産むが易し<br />
  26. 26. ということで、<br />
  27. 27. 今日のミニワークショップの進め方<br />
  28. 28. Githubに課題をアップロードしました<br />https://github.com/remore/StudyTDD<br />課題1<br />ケントベックが作成した解答と@remoreが作成した解答をテストコードの例として置いてあります。<br />自分で解答を作成した後、解答を比較して楽しんでください。色々な発見があるはず<br />※課題の回答はPHPUnit3で動作確認済み。SimpleTest使う人は、適宜読み替えてください。<br />課題2もお手すきのときにぜひ。<br />時間をとれる方は、手を動かしてみましょう<br />
  29. 29. 1グループ4~5名で構成します<br />初めに、自己紹介を各自1分前後で<br />次に、以下を参考に本の紹介とトークをしていきます<br />まず1~2分でその本について説明<br />その後フリートーク。<br />続けて本についてご紹介いただいても良いですし、皆でディスカッションになっても面白いと思っています。<br />フリートークは最大5分。 これで1人分が終了です。<br />今日の読書会の進め方<br />
  30. 30. ニジボックスではエンジニア募集中<br />PHP, Java,.NETあたりの経験者でソーシャルアプリ作りたい方<br />スマートフォンアプリの開発も進めてます<br />興味のある方はニジボックスHPへGO!<br />ニジボックスは勉強会の開催を積極的にサポートしていきます<br />おまけ<br />

×