• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile japan2010 rakuten様プレゼン資料
 

Agile japan2010 rakuten様プレゼン資料

on

  • 3,738 views

 

Statistics

Views

Total Views
3,738
Views on SlideShare
3,677
Embed Views
61

Actions

Likes
3
Downloads
79
Comments
0

2 Embeds 61

http://www.slideshare.net 51
http://paper.li 10

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

    Agile japan2010 rakuten様プレゼン資料 Agile japan2010 rakuten様プレゼン資料 Presentation Transcript

    • Rakuten Development Department 楽天株式会社 開発生産性強化グループ 田澤久 2010年4月吉日 -1-
    • 自己紹介: 田澤 久(たざわ ひさし) 楽天入社: 2007年09月 (業界歴:18年目) 楽天株式会社>開発部>開発環境整備課> 開発生産性強化グループ 開発環境プロデュースグループ IPA: ITアーキテクト委員会 非ウォーターフォール型開発研究会 twitter: (へさし) -2-
    • はじめに・・・ 現在の、楽天株式会社:開発部の実態、課題、想い、 将来に向けて始めた取り組みの紹介などを、本日 のトークにぶつけてみたいと思っています。 ゆえに、皆さんにとって有益な情報になるのか・・・ 分かりませんが、ご了承ください。 -3-
    • Introduction -4-
    • 楽天のご紹介 -5-
    • 開発部の規模感 約30事業のサービス開発・運用 内製による開発・運用 社員数:約900名 派遣数:約500名 約200の開発プロジェクトが同時進行中 -6-
    • 毎日がお祭り騒ぎ (^_^; -7-
    • ビジネス要求 設計・開発 調整 プロジェクト化 プロデューサ SYS-ENG 事業部・営業・企画 デザイナー APP-ENG やり残し リリース 軽微バグの改修 リファクトリング 改善など 活動のメインは こっち 機能改善、増強要請、提案など プロデューサ APP-ENG SYS-ENG システム要求 24時間365日運用 -8-
    • ※マインドに関わる大事な補注 出来上がったサービス(システム)は、誰のもの? 【通常(?)】 発注した(費用を出した)事業側・お客様のもの。 【当社の場合】 開発した開発部のものでもある。 イメージとしては半々。(特に決まりは無い) -9-
    • Issues - 10 -
    • 工数・期間 分布 7 6 期 5 間 期間=√(工数) 期間(月) 4 ( 月 3 の標準線 ) 2 1 0 0 5 10 15 20 25 30 35 40 45 50 工数(人月) 工数(人月) - 11 -
    • 工数・期間 分布 7 6 期 5 間 期間(月) 4 ( 月 3 ) 2 1 規模の割にリリースが 0 0 5 10 15 遅いものが、約半数 20 25 30 35 40 45 50 工数(人月) - 12 -
    • What happened ? スピード開発を重視してきたつもり だったのに、そう言えない現状に なってきている。 - 13 -
    • 組織も多くなり、手続きが増えてきている 仕様を考えるのは、開発主導なのに 途中で生まれたアイデアが反映出来ない - 14 -
    • ~現場の意見~ ●仕様がPRJ初期に決まれば世話ない ●一気に設計、一気にテスト・・・どわ~っ とやるから、管理が面倒くさい ●テストが後なので、デグレが心配 ●スケジュールが間に合わなくて、機能が おちる。あとは運用でカバー - 15 -
    • 要するに・・・ そんな開発 がしたい!! Step by step で開発が出来て 開発リズムが安定していて いつでもテストが出来て 小さな追加開発が速やかに出来て 運用の実態が、すぐに反映出来る - 16 -
    • 苦しんでいる時に重なるもので・・・ 社長がつぶやく・・・ - 17 -
    • Challenges Speed!! Speed!! Speed!! - 18 -
    • アジャイル開発 やってみようか !? - 19 -
    • アジャイル開発といっても、やり方は色々。 以下をやってみよう、という事で進める。 安心・安全な開発 = テスト駆動開発+CI ※TDD 効率的な開発 = CI 目で見る管理 = Redmine テスト に注目する開発方法を指向する。 - 20 -
    • その前に・・ まずは「テスト」をちょっと整理 - 21 -
    • できれば自動化 ビジネス面 手動 結合テスト ユーザビリティテスト プ 開 ABテスト ロ 発 ストーリーテスト ダ 支 ク ここに注目 ト 援 ユニットテスト QAテスト 評 価 自動化 ツール テクノロジー面 * 実践アジャイルテストより - 22 -
    • テストをプログラム化したい なぜ、テストに注目するのか。 なぜ、テストをプログラム化したいのか。 理由 = 私たちは作ってお終いでは無い 運用は、ほぼ永遠に続く 毎回テストで苦労するのは嫌 - 23 -
    • ユニットテストの仕組み = SVN + Hudson レポートも自動で 作成される CIサーバ ログ出力 自 問題発生 動 問題なし 問題なし ゾ ー 自動テストOK 自動テストOK 自動テストNG 機能 機能 ン 追加 修正 間違った 修正 アラートメール送信 手動 コミット !問題検知! 自動 ソースコード管理サーバ - 24 -
    •  テストコードにより  常に動作するアプリケーションが保 障される  CIサーバにより  機械的に繰り返し品質確認できる  ソース管理システムにより  これらがバージョニングされる - 25 -
    • 実際にやってみると・・・ 開発コスト TDD後の運用を見てみると・・・ 開発コスト 半年の開発で 開発6:テスト4 40% の割合になった 毎回の再テスト コストが削減で きる 60% ■・・・開発コスト ■・・・テストコスト 開発 リリース / 運用 時間 動作確認レベルの 単体テストの作成と テスト実施 実施 ■・・・開発コスト ■・・・テストコスト - 26 -
    • 結果 = Feeling good !! 品質面 コスト リスク面 ケース アプリの 運用後の 引継ぎのし デグレード バグによるト 事業へのリ 初期開発時 易さ(人の入 防止 ラブル防止 スク防止 品質 のコスト 開発コスト れ換え) 従来型開 発 × even high ×××× テスト駆 動型開発 ○ even low ○○○○ - 27 -
    • 結合テストの仕組み= VirtualBox + Selenium 詳細は、時間の都合で割愛。。。 なぜに、VirtualBox? システム日付、DBデータの操作性 なぜに、Selenium FireFoxのプラグインで画面操作を 記録すると自働で再現してくれる 繰り返し作業を自働実行するため!! - 28 -
    • 開発メンバーの実感 大変だった。でも、やって良かった。 いつでも全ての動作確認が出来るの は安心、しかも数分で。 良いものを、良い方法で作っている実 感がある。 初期工数を多く使ったので、繰り返し 使って借金を返すぞ! - 29 -
    • なぜ早く取り組まなかったのか・・・ やり方を替える事への不安。 最初に仕様をきっちり決めれば、良い 開発が出来ると思っていた。 何よりサービスリリースを優先して来た。 色々理由はあるけど、これから変わっていき ます。安心して楽しく開発したい! - 30 -
    • まだ始めたばかり。 大きな課題がある。どう立ち向かうか? 巨大な楽天市場 1,000人を超える開発人員 加速する国際化 - 31 -
    • to be continued.. - 32 -