Download as PDF, PPTX
Uploaded byTakafumi Ikeda
PDF, PPTX3,453 views
Dev love kansai
進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver)http://devlove-kansai.doorkeeper.jp/events/13377で発表した資料です。
Related topics:
Recommended
More Related Content
What's hot
Viewers also liked
![Making systemic change[1]](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fmakingsystemicchange1-101203115806-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[plan politika] Indonesian Youth and Politics : Serial Slide Bakal Calon Gube...](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fmengenalahokdaridekat-2-111027205203-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
Similar to Dev love kansai
More from Takafumi Ikeda
Dev love kansai
- 1.
- 2.
- 3.• 池田尚史（いけだたかふみ）• 株式会社ディー・エヌ・エー所属•『チーム開発実践入門』を執筆しました• オライリー『Jenkins』にも付録を書きました• Playframework1のコミッター（幽霊部員）@ikeike443
- 5.大体こんなこと話します• 書籍の紹介• チーム開発の課題って•プロジェクトの課題って• チーム開発をどう改善してきたか• まとめ的な
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.チーム開発で起きる問題• チーム開発の現場で実際に起きがちな問題をケーススタディとして見せている章です。• 実際にわたしが体験したいくつかの現場での事例を組み合わせています•課題管理ができない• デグレが頻発• 環境ごとに動きが違う• etc etc
- 12.
- 13.バージョン管理• チーム開発をスムーズにするための基礎の基礎• さすがに使ってない現場はないとは思うが•データベーススキーマのバージョン管理（データベースマイグレーションですね）についても触れています
- 14.
- 15.チケット管理• チケット管理に向くフェーズ、向かないフェーズもあります• チケット管理システムは定型的な課題管理に向く•流動的な課題の管理には非定型ドキュメントを使うべき• 課題の粒度と使うべきツールについても示唆しています
- 16.
- 17.CI（継続的インテグレーション）• 継続的改善に必要不可欠なのがCIです• なぜ不可欠なのか、以下の2点で説明しています•市場の変化のスピード• コストメリット
- 18.• ビルドが壊れた時のゲームについてなど、CIの運用についても触れています。• CI自体は目新しいものではなく、大昔から実践されてきたプラクティスであることにも触れました。•ここまでがチーム開発の基礎となる部分です。CI（継続的インテグレーション）
- 19.
- 20.• デプロイの自動化について、必要性と方法を解説• Bootstrapping,Configuration,Orchestrationの3フェーズに分けて解説• Kickstart, Vagrant, Chef, Capistrano,Fabric, Serverspecといったツールについてデプロイの自動化
- 21.
- 22.• 受入テストとそのリグレッションの自動化• 意外と具体的な情報がないのがこの分野•デグレを絶対に起こさず機能追加していくには必須• 特にB2B向けのサービスでは重要リグレッションテスト
- 23.
- 24.
- 25.
- 26.大体こんなこと話します• 書籍の紹介• チーム開発の課題って•プロジェクトの課題って• チーム開発をどう改善してきたか• まとめ的な
- 27.
- 28.
- 29.
- 30.
- 31.• 要件が定かでない• 誰が要件を決めるのか不明•おもてたんとちゃう
- 32.• 価値を提供できているのか不明• やる意義はあるんだっけ？•利益は出るのか？
- 33.
- 34.
- 35.
- 36.• プロジェクトの目標が定まっていない• 誰が要件を決めるのか分からない•価値を提供できているのか分からない• リスク管理ができていない• チームがパフォーマンスを出していない
- 37.
- 38.• ゴールはどこ？• 決めるのは誰？•利益は出るの？• リスクは見えてるの？• チーム開発はうまくいってるの？
- 39.
- 40.• ゴールはどこ？• 決めるのは誰？•利益は出るの？• リスクは見えてるの？• チーム開発はうまくいってるの？
- 41.
- 42.• 方法論はどんなものを使うの？• コミュニケーションプランはどうする？•成果はどう測る？• チームビルディングはどうする？• 開発ツールはどう使う？
- 43.
- 44.• 方法論はどんなものを使うの？• コミュニケーションプランはどうする？•成果はどう測る？• チームビルディングはどうする？• 開発ツールはどう使う？
- 45.
- 46.
- 47.• 市場の変化は早い• 計画は容易に変わり得る•臨機応変に変化に対応しなければなぜなら
- 48.• 遅すぎる開発サイクルはNG• 複数人が素早く並行して開発できないと•でもデグレードは起こしてはいけないゆえに
- 49.
- 50.
- 51.• 重要メールが多すぎて優先順位が決められない• テスト環境で動かしてみるまで、アプリが壊れていることに気づかない•自信を持ってリファクタリングできない• バグの発生時期、修正時期がわからない、追跡できない• 開発環境で動くものが本番環境では動かない• リリースが複雑で属人的、時間がかかる、よく失敗する
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.Gitチケット管理Chefバージョ動化JUnitSeleniumテストフapsitrano Github PuppetテabricデプロイInfrastructureerspecリグレッションテストfrastructure Vagrant VCSアジャイル開発Gitチケット管理Cン管理ビルド自動化JUnitSeleniレームワークCapsitrano Githuスト駆動開発FabricデプロイInfras code Serverspec リグレッ理Chefバージョeniumテストフhub Puppetテnfrastructureレッションテストアジャイル開発Gitン管理ビルド自動化レームワークCapsスト駆動開発Fabras code ServersImmutable Infrautable Infrastructure Vagrant VCS Immuta
- 58.• 情報が多い。。。• 整理されてない。。。•何から手をつければ。。。
- 59.
- 61.
- 62.• 予算管理の話• 工数管理、見積もりの話•チームのモチベートの話• 採用の話• 上記はもちろん大事なんだけど、「作らない人」の話ばかり
- 63.
- 64.• ツールの紹介• インストール方法、コマンド解説•事例紹介• チケット管理、バージョン管理、CI、CD等々バラバラに解説• 一つ一つの担当者には大変有益だが、全体を俯瞰できない
- 65.
- 66.
- 67.
- 68.
- 69.
- 71.大体こんなこと話します• 書籍の紹介• チーム開発の課題って•プロジェクトの課題って• チーム開発をどう改善してきたか• まとめ的な
- 72.
- 73.
- 74.• 2005年∼2009年ごろ• 200名規模、20チーム以上で開発し、5年以上販売、運用している製品•池田はプロジェクト開始直後からジョイン• メンバーは問題解決の意識は高いがエンジニアとしてのスキルにはばらつきがある某プロジェクト1
- 75.• 課題管理がされておらず、何が起きているかが担当者以外にはわからなかった• バージョン管理がきちんとされておらず、上書きによる変更の消失などが頻繁に起こる•単体テストは書かれておらず、そもそもリポジトリの最新コードはコンパイルできるかどうかも保証されていない• 2週間の結合テスト期間に入っても最初の1週間はビルドにかかっていたため、品質も上がらなかった課題
- 76.• 課題管理は独自システムがあったが機能しておらず、各チームが独自にExcelなどを駆使して管理しており、担当者に聞かないと状況がわからなかった• PVCSというロックベースのVCSを使っており、マージができず並行開発が困難だった•テストを書くという文化、発想がそもそもなかったなぜこうなったか
- 77.• PVCSではどうにもならず、Subversionへの入れ替えを• 課題管理にTracを導入•TracとSubversionを連携することで変更の管理と追跡を行えるようにどう解決を試みたか
- 78.
- 79.
- 80.
- 81.• 稟議を通すのは困難• 導入してみないと効果がわからないのでコストをかける妥当性を説明できない•今までのやり方で回ってるのになぜ？ に答えられない改善の壁
- 82.
- 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.
- 95.
- 96.課題• 見積りが不正確で、毎スプリント計画通り終わらない• エンジニアが計画とは関係ないことをやっている•企画「エンジニアは全然作業を完遂できない」• エンジニア「企画は重要な作業が分かってない」• スプレッドシートはよく壊れ、信頼出来ない状態に
- 97.なぜこうなったのか• スプリントの見積り、計画にエンジニアが入っていないため、• 見積りの根拠があいまい•システム的に重要なタスクが抜ける• 複数人が思い思いにスプレッドシートをいじるため、• 頻繁に壊れる• 誰がどこをどう変更したかわからず、信頼出来ない状態に
- 98.• 全てをJIRAに一本化• JIRAのGreenHopperプラグインを導入•スプリント計画にエンジニアを入れるように• 計画値と実績値を記録し、定期的に全体共有するようにどうしたか
- 99.
- 100.どうなったか• エンジニアが見積りに入ることで• 見積もりがある程度正確に近くなった•ツールを整備したことで、• スプリント毎の計画値と実績値が可視化できるようになった• 可視化できたことで、• 各自が見積りと計画を自分事と捉え、改善策を考えるように
- 101.可視化による自分事化• 企画とエンジニアとの間で情報共有を容易にした• 可視化することによって、ここでも自分事化が起きる•見えてくるとみんなどうやって改善できるだろうかと考え始め、好循環が生まれる
- 102.
- 103.起きていたこと• 毎週金曜の朝にスプリントレビューがある• 直前になって開発環境にすべての変更を統合•きちんと動作せず、レビューに間に合わせるために徹夜
- 104.なぜこうなったのか• 機能要件を実装するのに忙しく、CI, CDなど実施するための余裕がない•開発生産性を高めるための作業が洗い出されておらず、計画もされていない• エンジニアが見積り、計画をしていないことも大きい
- 105.
- 106.どうなったか• レビュー前日の徹夜がなくなった• いつでも動く成果物が存在する状態になり、企画とエンジニア間のコミュニケーション頻度が上がり活性化•品質管理部門もテストをしやすくなった• 開発スピードが上がり、目に見えてチームの状況は良くなった
- 107.• 課題を一箇所にまとめ可視化• 課題管理システムを信頼できる状態にし、情報共有を容易に•エンジニアが見積もり、計画をするようにし、タスクの抜け漏れをなくした• 生産性を担保するための必要なインフラ構築の工数を確保するようにした• CIを実施し品質を担保、レビューをスムーズにまとめると
- 109.大体こんなこと話します• 書籍の紹介• チーム開発の課題って•プロジェクトの課題って• チーム開発をどう改善してきたか• まとめ的な
- 110.
- 111.• まず可視化• 現実を直視できる環境を作れば、おのずと改善サイクルは回り出す•そのための必要なことはどんなことでもするのがスクラムマスター（またはプロジェクトマネージャー）の仕事チーム開発を改善するには
- 112.小さなことからコツコツと• いきなり「継続的デリバリー！」とか言わない• いきなり「Githubのように一日千回リリース！」とか無理無理•やれるところから、インパクトの大きいところからはじめるようにしています
- 113.一人ではできない• 当たり前ですが一人ではできません• チーム開発です•開発もチームでやるなら、開発フローの改善もチームでやりましょう• 「あいつらわかってない」とか「環境が整ってない」とか言わない• 仲間を見つけよう
- 114.管理しない• チーム開発を「管理する」発想だと管理者のレベルを超えたものは生まれない• シナジーを重視する•シナジーを生むためにはメンバー全員が自律的に考えて動く必要がある
- 115.
- 116.
- 117.
- 118.
- 119.
- 120.
- 121.チーム開発あるある• チケット管理を始めたはいいけど誰も書かなくなる• 始めのうちは単体テストを書いていたけど、仕様変更が重なるうちにメンテしなくなる•CIを始めたはいいけどテストがよくこけるので誰もテスト結果を気にしなくなる
- 122.
- 123.
- 124.
- 126.
- 128.• ググった先でいいことが書いてありました• ダイエットが続かない理由はダイエットを始めるから！•太っていない人は「ダイエットし続けている」わけではなく「太りにくい生活習慣をおくっている」
- 129.
- 130.まとめると• 自ら率先してやってみせることが重要• みんなが続けやすい環境づくりに労力を割くこともとても重要•いきなり気張ってやり過ぎず、習慣付けを意識する• できることをできる範囲でコツコツとやる• 無理しない
- 131.
- 132.
- 133.