チーム開発をスムーズにするために何ができるか
Upcoming SlideShare
Loading in...5
×
 

チーム開発をスムーズにするために何ができるか

on

  • 4,880 views

DevLOVEさんの「進め、現場のチーム開発 〜チーム開発実践入門〜」で講演した時の資料

DevLOVEさんの「進め、現場のチーム開発 〜チーム開発実践入門〜」で講演した時の資料
http://devlove.doorkeeper.jp/events/12229

Statistics

Views

Total Views
4,880
Views on SlideShare
4,057
Embed Views
823

Actions

Likes
18
Downloads
35
Comments
0

8 Embeds 823

http://gihyo.jp 350
http://ikeike443.hatenablog.com 346
https://twitter.com 86
http://s.deeeki.com 21
http://feedly.com 15
http://49.212.34.189 3
http://tweetedtimes.com 1
http://www.google.co.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

チーム開発をスムーズにするために何ができるか チーム開発をスムーズにするために何ができるか Presentation Transcript

  • チーム開発をスムーズに するために何ができるか 『チーム開発実践入門』紹介
  • 自己紹介
  • • 池田尚史(いけだたかふみ) • 株式会社ディー・エヌ・エー所属 • 『チーム開発実践入門』を執筆しました • オライリー『Jenkins』にも付録を書きました • Playframework1のコミッター(幽霊部員) @ikeike443
  • • コンサルティングファームで数年間に渡り超大規模プロジェクト に復数参画 • 技術力が明暗を分けると痛感しプログラマーに転身 ! • VCS: 無いこと多い • ITS: Excel • CI: なにそれ? 2001 2004
  • • 国産ERPパッケージベンダーで製品企画と開発マネージャー、プログラ マーを経験 • この時期瞬間最大で同一製品の6バージョンのメンテナンスを行ってい た。。 • SVN+Tracの導入推進をした • VCS: PVCS, 後にSVN • ITS: 独自システム, 後にTrac • CI: なし, 後にHudson 2005 2010
  • • B2B向けWebサービス(SaaS)ベンダーでプロダクトマネー ジャー兼プログラマー • この時期にPlayframeworkのコミッターになるなどした ! • VCS: Git • ITS: Backlog, PivotalTracker • CI: Jenkins 2010 2013
  • 大体こんなこと話します • チーム開発の課題って • プロジェクトの課題って • ツールの情報は散逸してる • 執筆にあたって気にしたとこ ろ • 各章紹介
  • チーム開発における課題
  • の話の前に
  • ソフトウェア開発 プロジェクトによくある課題
  • • プロジェクトの目標が定まっていない • 何を達成すれば成功なんだっけ?
  • • 要件が定かでない • 誰が要件を決めるのか不明 • おもてたんとちゃう
  • • 価値を提供できているのか不明 • やる意義はあるんだっけ? • 利益は出るのか?
  • • リスク管理ができてない • プランBがない
  • • チームがパフォーマンスを出していない • チームビルディングができていない • 開発効率が悪い
  • 再掲
  • • プロジェクトの目標が定まっていない • 誰が要件を決めるのか分からない • 価値を提供できているのか分からない • リスク管理ができていない • チームがパフォーマンスを出していない
  • 言い換えると
  • • ゴールはどこ? • 決めるのは誰? • 利益は出るの? • リスクは見えてるの? • チーム開発はうまくいってるの?
  • チーム開発は問題の一部
  • • ゴールはどこ? • 決めるのは誰? • 利益は出るの? • リスクは見えてるの? • チーム開発はうまくいってるの?
  • チーム開発をはじめるに あたって考えるべきこと
  • • 方法論はどんなものを使うの? • コミュニケーションプランはどうする? • 成果はどう測る? • チームビルディングはどうする? • 開発ツールはどう使う?
  • ツールの使いこなしは さらにその一部
  • • 方法論はどんなものを使うの? • コミュニケーションプランはどうする? • 成果はどう測る? • チームビルディングはどうする? • 開発ツールはどう使う?
  • だが、基礎である
  • プロジェクトを成功に導くための大事な基礎
  • • 市場の変化は早い • 計画は容易に変わり得る • 臨機応変に変化に対応しなければ なぜなら
  • • 遅すぎる開発サイクルはNG • 複数人が素早く並行して開発できないと • でもデグレードは起こしてはいけない ゆえに
  • では
  • ツールが解決する問題って?
  • • 重要メールが多すぎて優先順位が決められない • テスト環境で動かしてみるまで、アプリが壊れているこ とに気づかない • 自信を持ってリファクタリングできない • バグの発生時期、修正時期がわからない、追跡できない • 開発環境で動くものが本番環境では動かない • リリースが複雑で属人的、時間がかかる、よく失敗する
  • • こういった問題はツールをうまく使うことで解決で きる • Webの記事なんかを見てると、色々ツールがある ことがわかる
  • • 組み合わせれば解決しそうだね!
  • ここ3∼5年Webを見て 実践し続けていればね
  • 新人さんだったり、 訳あってキャッチアップ してこれなかった人は どうなるんだろう?
  • 例えばググってみると
  • 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
  • • 情報が多い。。。 • 整理されてない。。。 • 何から手をつければ。。。
  • そこで『チーム開 (ry
  • 世にあるプロジェクト マネジメント本
  • • 予算管理の話 • 工数管理、見積もりの話 • チームのモチベートの話 • 採用の話 • 上記はもちろん大事なんだけど、「作らない人」の 話ばかり
  • 世にある開発ツール本
  • • ツールの紹介 • インストール方法、コマンド解説 • 事例紹介 • チケット管理、バージョン管理、CI、CD等々バラ バラに解説 • 一つ一つの担当者には大変有益だが、全体を俯瞰で きない
  • 断絶
  • そこで『チーム開 (ry
  • 話を受けた当初 • 2012年 • 当時自分の開発環境は • SVN • Backlog, Bugzilla • ReviewBoard • Jenkins • Git, Githubはまだ試している段階(OSSでGithubは使ってた) • ChefやVagrantなんかもまだまだ本格的に触っていなかった
  • ぼんやりしてたら 一年経過
  • 2013年
  • CIは当たり前に なってきた
  • GitHubを使う 会社も増えた
  • ツールもそろってきて 継続的デリバリも かたちが見えてきた
  • 執筆開始
  • • 私自身のトラウマを克服したい • 困っている現場を少しでも無くしたい
  • 開発現場の地図になれば
  • 各章紹介
  • 第一章 チーム開発とは
  • チーム開発とは 最適なプラクティスはケースバイケース チーム開発の世界では、どこにでも通用する万能のベストプラ クティスがあるというより、状況に応じたベターなパターンの 組み合わせが何通りもある、という考え方が正解に近いでしょ う。実際自分が関わるプロジェクトに応じた最適解を見いだせ るかどうかが、プロジェクトを成功に導く といえるでしょう。
  • チーム開発とは 自分が関わるプロジェクトに応じた 最適解を見いだせるかが
  • 第二章 チーム開発で起きる問題
  • チーム開発で起きる問題 • チーム開発の現場で実際に起きがちな問題をケーススタディとして 見せている章です。 • 実際にわたしが体験したいくつかの現場での事例を組み合わせて います • 課題管理ができない • デグレが頻発 • 環境ごとに動きが違う • etc etc
  • チーム開発で起きる問題 • 重要メールが多すぎて優先順位が決められない • テスト環境で動かしてみるまで、アプリが壊れていることに 気づかない • 自信を持ってリファクタリングできない • バグの発生時期、修正時期がわからない、追跡できない • 開発環境で動くものが本番環境では動かない • リリースが複雑で属人的、時間がかかる、よく失敗する
  • チーム開発で起きる問題 • 本文ではこの他にも色々、ありがちな問題をあげ、 起きていることの解説をしています。そしてこれら 問題の解決策となるのが次に続く3章から始まる各 章、というかたちです。 • ちなみに3章以降は、チーム開発改善の際に手をつ けるべき順番に並んでいます。
  • 第三章 バージョン管理
  • バージョン管理 • チーム開発をスムーズにするための基礎の基礎 • さすがに使ってない現場はないとは思うが • データベーススキーマのバージョン管理(データベー スマイグレーションですね)についても触れていま す
  • バージョン管理 • バージョン管理システムの歴史についても触れてい ます • ほんの20年ほどで劇的に変わっているのがバージョ ン管理です。いかに変化の激しい分野なのかを知る と色々はかどります
  • バージョン管理 • 20年前新人だった人がまだ40代 • 決裁権を持っている彼らの技術センスも重要なポイ ント
  • バージョン管理 • ちなみに • バージョン管理の歴史図 • git-flowの図 • 両方とも作者に許可をとって翻訳しました • 献本もしたよ!
  • 第四章 チケット管理
  • チケット管理 • チケット管理システムはOSSのものも商用のもの もたくさんあります • 色々紹介しています。
  • チケット管理 • バージョン管理システムとの連携方法も説明してい ます。 • チケット駆動開発についても簡単に解説しています。
  • チケット管理 • チケット管理に向くフェーズ、向かないフェーズも あります • チケット管理システムは定型的な課題管理に向く • 流動的な課題の管理には非定型ドキュメントを使 うべき • 課題の粒度と使うべきツールについても示唆してい ます
  • 第五章 CI(継続的インテグレーション)
  • CI(継続的インテグレーション) • 継続的改善に必要不可欠なのがCIです • なぜ不可欠なのか、以下の2点で説明しています • 市場の変化のスピード • コストメリット
  • CI(継続的インテグレーション) • CIについて、主にJenkinsをベースに解説していま す。 • ビルド、テストの自動化の方法、Jenkinsの使い方 について解説しています。
  • • Pull RequestをCIする方法(GitHub Pull Request Builder Plugin)も解説しています。 • もちろんTravisCIにも触れています。 CI(継続的インテグレーション)
  • • ビルドが壊れた時のゲームについてなど、CIの運用 についても触れています。 • CI自体は目新しいものではなく、大昔から実践され てきたプラクティスであることにも触れました。 • ここまでがチーム開発の基礎となる部分です。 CI(継続的インテグレーション)
  • 第六章 デプロイの自動化 (継続的デリバリー)
  • • デプロイの自動化について、必要性と方法を解説 • Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説 • Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツールについて デプロイの自動化
  • • クラウド時代のブルーグリーンデプロイメントにつ いても解説 • また、PaaSを使ったデプロイについても デプロイの自動化
  • • 執筆していた2013年という年はこの分野に劇的な進歩が 見られた年 • どんどん変わっていく技術を追いかけながら実践して書籍 に落としこんでいくのはかなりの苦労 • 残念ながら時期が上手く合わず、Dockerを始めとする Immutable Infrastructureについては、ほんの少し言 及するにとどまりまった • 総じてエキサイティングな章になっているはず デプロイの自動化
  • 第七章 リグレッションテスト
  • • 受入テストとそのリグレッションの自動化 • 意外と具体的な情報がないのがこの分野 • デグレを絶対に起こさず機能追加していくには必須 • 特にB2B向けのサービスでは重要 リグレッションテスト
  • • Selenium1をつかったリグレッションテストの自 動化について主に書かれている • 時間のかかるSeleniumテストをいかに高速化すれ ばいいのかについてJenkinsの分散ビルドをどう 使っていけばいいか解説 リグレッションテスト
  • • (一般的に言って)プログラミングが不得意な人の 多いQA担当者とともにいかに効率的に受入テスト 自動化に取り組むかについても示唆 • 内容としては2年ほど前にJenkinsユーザーカンファ レンスにて発表した内容がベース リグレッションテスト
  • ぜひ読んでみてください! 職場の同僚にもすすめてね!
  • 以上、本の紹介でした
  • おまけ
  • • プロジェクトの見積もり、計画 • 運用における振り返りと改善企画 • サービス企画、製品企画と開発を両立するには • コードレビューのやり方、ツール • コーディング規約等々 • エディタの使い方、フォーマットのそろえ方など • 開発環境を良くするための予算のたて方稟議の通し方 • スモールスタートのやり方 • etc, etc, etc.. 漏れたもの
  • 以上、
  • 開発現場の改善に 取り組む皆様の よき地図となれば 幸いです
  • ご清聴ありがとうございました