Dev love kansai
•
5 recomendaciones•3,447 vistas
進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) http://devlove-kansai.doorkeeper.jp/events/13377 で発表した資料です。
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Dev love kansai
Similar a Dev love kansai (20)
Dev love kansai
- 2. 自己紹介
- 3. • 池田尚史（いけだたかふみ） • 株式会社ディー・エヌ・エー所属 • 『チーム開発実践入門』を執筆しました • オライリー『Jenkins』にも付録を書きました • Playframework1のコミッター（幽霊部員） @ikeike443
- 5. 大体こんなこと話します • 書籍の紹介 • チーム開発の課題って • プロジェクトの課題って • チーム開発をどう改善してき たか • まとめ的な
- 7. 第一章 チーム開発とは
- 10. 第二章 チーム開発で起きる問題
- 11. チーム開発で起きる問題 • チーム開発の現場で実際に起きがちな問題をケーススタディとして 見せている章です。 • 実際にわたしが体験したいくつかの現場での事例を組み合わせて います • 課題管理ができない • デグレが頻発 • 環境ごとに動きが違う • etc etc
- 12. 第三章 バージョン管理
- 13. バージョン管理 • チーム開発をスムーズにするための基礎の基礎 • さすがに使ってない現場はないとは思うが • データベーススキーマのバージョン管理（データベー スマイグレーションですね）についても触れていま す
- 14. 第四章 チケット管理
- 15. チケット管理 • チケット管理に向くフェーズ、向かないフェーズも あります • チケット管理システムは定型的な課題管理に向く • 流動的な課題の管理には非定型ドキュメントを使 うべき • 課題の粒度と使うべきツールについても示唆してい ます
- 17. CI（継続的インテグレーション） • 継続的改善に必要不可欠なのがCIです • なぜ不可欠なのか、以下の2点で説明しています • 市場の変化のスピード • コストメリット
- 18. • ビルドが壊れた時のゲームについてなど、CIの運用 についても触れています。 • CI自体は目新しいものではなく、大昔から実践され てきたプラクティスであることにも触れました。 • ここまでがチーム開発の基礎となる部分です。 CI（継続的インテグレーション）
- 20. • デプロイの自動化について、必要性と方法を解説 • Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説 • Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツールについて デプロイの自動化
- 21. 第七章 リグレッションテスト
- 22. • 受入テストとそのリグレッションの自動化 • 意外と具体的な情報がないのがこの分野 • デグレを絶対に起こさず機能追加していくには必須 • 特にB2B向けのサービスでは重要 リグレッションテスト
- 25. 以上、本の紹介でした
- 26. 大体こんなこと話します • 書籍の紹介 • チーム開発の課題って • プロジェクトの課題って • チーム開発をどう改善してき たか • まとめ的な
- 27. チーム開発における課題
- 28. の話の前に
- 31. • 要件が定かでない • 誰が要件を決めるのか不明 • おもてたんとちゃう
- 32. • 価値を提供できているのか不明 • やる意義はあるんだっけ？ • 利益は出るのか？
- 34. • チームがパフォーマンスを出していない • チームビルディングができていない • 開発効率が悪い
- 35. 再掲
- 36. • プロジェクトの目標が定まっていない • 誰が要件を決めるのか分からない • 価値を提供できているのか分からない • リスク管理ができていない • チームがパフォーマンスを出していない
- 37. 言い換えると
- 38. • ゴールはどこ？ • 決めるのは誰？ • 利益は出るの？ • リスクは見えてるの？ • チーム開発はうまくいってるの？
- 39. チーム開発は問題の一部
- 40. • ゴールはどこ？ • 決めるのは誰？ • 利益は出るの？ • リスクは見えてるの？ • チーム開発はうまくいってるの？
- 42. • 方法論はどんなものを使うの？ • コミュニケーションプランはどうする？ • 成果はどう測る？ • チームビルディングはどうする？ • 開発ツールはどう使う？
- 44. • 方法論はどんなものを使うの？ • コミュニケーションプランはどうする？ • 成果はどう測る？ • チームビルディングはどうする？ • 開発ツールはどう使う？
- 45. だが、基礎である
- 47. • 市場の変化は早い • 計画は容易に変わり得る • 臨機応変に変化に対応しなければ なぜなら
- 48. • 遅すぎる開発サイクルはNG • 複数人が素早く並行して開発できないと • でもデグレードは起こしてはいけない ゆえに
- 49. では
- 50. ツールが解決する問題って？
- 51. • 重要メールが多すぎて優先順位が決められない • テスト環境で動かしてみるまで、アプリが壊れているこ とに気づかない • 自信を持ってリファクタリングできない • バグの発生時期、修正時期がわからない、追跡できない • 開発環境で動くものが本番環境では動かない • リリースが複雑で属人的、時間がかかる、よく失敗する
- 56. 例えばググってみると
- 57. Gitチケット管理Chefバージョ 動化JUnitSeleniumテストフ apsitrano Github Puppetテ abricデプロイInfrastructure erspec リグレッションテスト frastructure Vagrant VCS アジャイル開発Gitチケット管理C ン管理ビルド自動化JUnitSeleni レームワークCapsitrano Githu スト駆動開発FabricデプロイInfr as code Serverspec リグレッ 理Chefバージョ eniumテストフ hub Puppetテ nfrastructure レッションテスト アジャイル開発Git ン管理ビルド自動化 レームワークCaps スト駆動開発Fabr as code Servers Immutable Infra utable Infrastructure Vagrant VCS Immuta
- 58. • 情報が多い。。。 • 整理されてない。。。 • 何から手をつければ。。。
- 59. そこで『チーム開 (ry
- 62. • 予算管理の話 • 工数管理、見積もりの話 • チームのモチベートの話 • 採用の話 • 上記はもちろん大事なんだけど、「作らない人」の 話ばかり
- 63. 世にある開発ツール本
- 64. • ツールの紹介 • インストール方法、コマンド解説 • 事例紹介 • チケット管理、バージョン管理、CI、CD等々バラ バラに解説 • 一つ一つの担当者には大変有益だが、全体を俯瞰で きない
- 65. 断絶
- 66. そこで『チーム開 (ry
- 69. 開発現場の地図になれば
- 71. 大体こんなこと話します • 書籍の紹介 • チーム開発の課題って • プロジェクトの課題って • チーム開発をどう改善してき たか • まとめ的な
- 72. チーム開発をどう改善 してきたか
- 74. • 2005年∼2009年ごろ • 200名規模、20チーム以上で開発し、5年以上販売、 運用している製品 • 池田はプロジェクト開始直後からジョイン • メンバーは問題解決の意識は高いがエンジニアとし てのスキルにはばらつきがある 某プロジェクト1
- 75. • 課題管理がされておらず、何が起きているかが担当者以外には わからなかった • バージョン管理がきちんとされておらず、上書きによる変更の 消失などが頻繁に起こる • 単体テストは書かれておらず、そもそもリポジトリの最新コー ドはコンパイルできるかどうかも保証されていない • 2週間の結合テスト期間に入っても最初の1週間はビルドにかかっ ていたため、品質も上がらなかった 課題
- 76. • 課題管理は独自システムがあったが機能しておらず、各チーム が独自にExcelなどを駆使して管理しており、担当者に聞かな いと状況がわからなかった • PVCSというロックベースのVCSを使っており、マージができ ず並行開発が困難だった • テストを書くという文化、発想がそもそもなかった なぜこうなったか
- 77. • PVCSではどうにもならず、Subversionへの入れ替えを • 課題管理にTracを導入 • TracとSubversionを連携することで変更の管理と追跡を行え るように どう解決を試みたか
- 78. ところが、、、
- 79. 壁が！
- 80. • TracやSubversionの導入、検証を行うためのリソースがない • 人のリソース • サーバリソース 改善の壁
- 81. • 稟議を通すのは困難 • 導入してみないと効果がわからないのでコストをかける妥当 性を説明できない • 今までのやり方で回ってるのになぜ？ に答えられない 改善の壁
- 83. • サーバリソース • 総務と仲良くなり、余剰PCが出た瞬間に知らせてもらった • 上司の協力も得て0円稟議を書き、PCをゲット • 人のリソース • 検証のための時間は取れないので自分と自分のチームの業務時 間をそのまま当てる • 要するに自分のチームを実験台に 壁を超えるために
- 84. • 自分のチームだけ違うVCSを使い、違う課題管理システムを使 います、では全体の業務フローがおかしくなる • 既存の業務フローと統合させてスムーズに回してみせることが 重要 • 既存の課題管理システムとTracの同期スクリプトを書いた • 既存のPVCSリポジトリとSVNを定期的に同期するスクリプ トも書いた 既存の業務フローとの統合
- 85. 可視化による自分事化 • 課題管理をし、バージョン管理をすることで問題が 可視化 • 可視化されると、各メンバーが自分事として改善を 考えるようになる • そうするとさらに改善は進むと考えた
- 86. • チーム間の課題を共有できるようになり無駄が減る • 誰が何をしているか、課題がどうなっているかわかるように • テストは相変わらずなかったが、代わりにコードのDiffを手軽に見れるよ うになったので（事後ではあるが）コードレビューできるようになった • マージが簡単になり、並行開発ができるようになった • CIまでは行かなかったが、VCSを変えて課題管理をしただけでも、結合 に係る時間は短縮できた • 結果、目に見えて品質も開発スピードも上がった 結果を出し既成事実を
- 87. 結果が出たッッッ！
- 88. • 結果が出たのを見て他のチームから問い合わせが来るように • 全社的にプロセス改善を行っている部署から声がかかり、一緒 に全社展開のプロジェクトにとりかかることになった • 各チームの見通しが良くなり、各所で改善活動がされるように なった 結果が出ると話が早い
- 89. 仲間が増え、広がっていった
- 90. • 「許可を求めるより謝罪」まずはやる • 壁にへこたれない、言い訳をしない • 既存の業務フローとの統合までやり切らないと説得力はない • 結果を出して仲間を増やす まとめると
- 91. • ある新サービスの開発プロジェクト • 開発開始後2ヶ月が経過 • スクラムを採用 • 池田は途中からジョイン • メンバーひとりひとりはスキルが高く大変優秀 某プロジェクト2
- 92. • タスク管理があいまい • 業務過多で連日徹夜 • 終わらない、見通せない、リリースが危ぶまれる • 企画サイドとエンジニアサイドの相互不信感MAX • CIがなくよく壊れる • 開発環境を整える工数はない ジョイン当時
- 93. タスク管理があいまい • バックログの管理はされていたが、 • 何が終わり、何が終わっていないのか、誰がボー ルを持っているか、があいまい • スプレッドシートで管理されており、よく壊れる
- 94. タスク管理があいまい • まずチケット管理システムに移行し、システムとし ての信頼度を高めた • タスクの完了定義をしっかりと行い、状況を確認し きちんと更新することで、内容的な信頼度を高めた
- 96. 課題 • 見積りが不正確で、毎スプリント計画通り終わらない • エンジニアが計画とは関係ないことをやっている • 企画「エンジニアは全然作業を完遂できない」 • エンジニア「企画は重要な作業が分かってない」 • スプレッドシートはよく壊れ、信頼出来ない状態に
- 97. なぜこうなったのか • スプリントの見積り、計画にエンジニアが入っていないため、 • 見積りの根拠があいまい • システム的に重要なタスクが抜ける • 複数人が思い思いにスプレッドシートをいじるため、 • 頻繁に壊れる • 誰がどこをどう変更したかわからず、信頼出来ない状態に
- 98. • 全てをJIRAに一本化 • JIRAのGreenHopperプラグインを導入 • スプリント計画にエンジニアを入れるように • 計画値と実績値を記録し、定期的に全体共有するように どうしたか
- 100. どうなったか • エンジニアが見積りに入ることで • 見積もりがある程度正確に近くなった • ツールを整備したことで、 • スプリント毎の計画値と実績値が可視化できるようになった • 可視化できたことで、 • 各自が見積りと計画を自分事と捉え、改善策を考えるように
- 101. 可視化による自分事化 • 企画とエンジニアとの間で情報共有を容易にした • 可視化することによって、ここでも自分事化が起き る • 見えてくるとみんなどうやって改善できるだろうか と考え始め、好循環が生まれる
- 103. 起きていたこと • 毎週金曜の朝にスプリントレビューがある • 直前になって開発環境にすべての変更を統合 • きちんと動作せず、レビューに間に合わせるために徹夜
- 104. なぜこうなったのか • 機能要件を実装するのに忙しく、CI, CDなど実施するための余 裕がない • 開発生産性を高めるための作業が洗い出されておらず、計画も されていない • エンジニアが見積り、計画をしていないことも大きい
- 106. どうなったか • レビュー前日の徹夜がなくなった • いつでも動く成果物が存在する状態になり、企画と エンジニア間のコミュニケーション頻度が上がり活 性化 • 品質管理部門もテストをしやすくなった • 開発スピードが上がり、目に見えてチームの状況は 良くなった
- 107. • 課題を一箇所にまとめ可視化 • 課題管理システムを信頼できる状態にし、情報共有を容易に • エンジニアが見積もり、計画をするようにし、タスクの抜け漏 れをなくした • 生産性を担保するための必要なインフラ構築の工数を確保する ようにした • CIを実施し品質を担保、レビューをスムーズに まとめると
- 109. 大体こんなこと話します • 書籍の紹介 • チーム開発の課題って • プロジェクトの課題って • チーム開発をどう改善してき たか • まとめ的な
- 110. チーム開発を改善するには
- 111. • まず可視化 • 現実を直視できる環境を作れば、おのずと改善サイクルは 回り出す • そのための必要なことはどんなことでもするのがスクラム マスター（またはプロジェクトマネージャー）の仕事 チーム開発を改善するには
- 112. 小さなことからコツコツと • いきなり「継続的デリバリー！」とか言わない • いきなり「Githubのように一日千回リリース！」 とか無理無理 • やれるところから、インパクトの大きいところから はじめるようにしています
- 113. 一人ではできない • 当たり前ですが一人ではできません • チーム開発です • 開発もチームでやるなら、開発フローの改善もチームで やりましょう • 「あいつらわかってない」とか「環境が整ってない」と か言わない • 仲間を見つけよう
- 114. 管理しない • チーム開発を「管理する」発想だと管理者のレベル を超えたものは生まれない • シナジーを重視する • シナジーを生むためにはメンバー全員が自律的に考 えて動く必要がある
- 120. • 僕はよくあります
- 121. チーム開発あるある • チケット管理を始めたはいいけど誰も書かなくなる • 始めのうちは単体テストを書いていたけど、仕様変 更が重なるうちにメンテしなくなる • CIを始めたはいいけどテストがよくこけるので誰も テスト結果を気にしなくなる
- 122. よくある回答
- 124. これって何かに似てませんか
- 126. ダイエット
- 128. • ググった先でいいことが書いてありました • ダイエットが続かない理由はダイエットを始めるから！ • 太っていない人は「ダイエットし続けている」わけでは なく「太りにくい生活習慣をおくっている」
- 130. まとめると • 自ら率先してやってみせることが重要 • みんなが続けやすい環境づくりに労力を割くことも とても重要 • いきなり気張ってやり過ぎず、習慣付けを意識する • できることをできる範囲でコツコツとやる • 無理しない
- 131. 以上、
- 133. ご清聴ありがとうございました