Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
JavaScript development by
Agile and Scrum
Nov/09/2013
Hisafumi Kikkawa(@shinjukujohnny)
.
Agenda

•
•
•
•
•

About me
Introduction
Summary of our project
Our solutions
Summary

2
About me

吉川 久文(@shinjukujohnny):
Work:
ソフトウェアエンジニア
某社アフィリエイトシステムフロン
トエンド開発チーム 開発リーダー

Study:
産業技術大学院大学
情報アーキテクチャ専攻修士過程1
年...
Introduction

私達のチームはAgile & Scrum でのシステム開発を
2012年頃から本格的に取り入れ、システム開発を
しています。
その中でも今回はAgile & ScrumをJavaScript開発に
適用したプロジェク...
Summary of our project

2013年4月、弊社アフィリエイトサービスフロン
トエンド開発チームは新しい広告配信エンジンの
開発を開始しました。
Requirements
充分なテストを行うこと
納期までにリリースすること(...
Summary of our project

2013年4月、弊社アフィリエイトサービスフロン
トエンド開発チームは新しい広告配信エンジンの
開発を開始しました。
Requirements

仕様は常に変化し得る!
1. 充分なテストを行うこ...
Our solutions

1. Scrumの導入
a. スプリント計画ミーティング
b. デイリースクラム
c. レトロスペクティブ(KPT)

2. 自動化
a.
b.
c.
d.
e.

npmによる開発環境作成自動化
Mochaによる...
Scrumの導入

8
Why Scrum?

複雑で変化の激しい問題に対応するためのフレームワー
クであり、可能な限り価値の高いプロダクトを生産的か
つ創造的に届けるためのものである。 (from The Scrum
Guide)

In case of our t...
Why Scrum?

複雑で変化の激しい問題に対応するためのフレームワー
クであり、可能な限り価値の高いプロダクトを生産的か
つ創造的に届けるためのものである。 (from The Scrum
Guide)

In case of our t...
Sprint 計画 MTG

スプリントの作業は、スプリント計画ミーティングで計
画する。計画はスクラムチームの共同作業である。
• スプリントの成果であるインクリメントに何を入
れるか?
• インクリメントを届けるためにどのように作業を
する...
Sprint 計画 MTG

スプリントの作業は、スプリント計画ミーティングで計
画する。計画はスクラムチームの共同作業である。
• スプリントの成果であるインクリメントに何を入
れるか?
• インクリメントを届けるためにどのように作業を
する...
Daily Scrum

デイリースクラムは、開発チームが活動の状況を確認
し、次の 24 時間の計画を作る 15 分のタイムボックスで
ある。デイリースクラムでは、開発チームメンバが次の
ことを説明する。
• 前回のデイリースクラムから行った...
Daily Scrum

デイリースクラムは、開発チームが活動の状況を確認し、
次の 24 時間の計画を作る 15 分のタイムボックスである。
デイリースクラムでは、開発チームメンバが次のことを
説明する。
• 前回のデイリースクラムから行った...
スプリント レトロスペクティブ

スプリントレトロスペクティブは、スクラムチームの検
査とスプリントの改善計画を作成する機会である。
• 人・関係・プロセス・ツールの観点から今回のスプ
リントを検査する。
• うまくいった項目や今後の改善点を特...
スプリント レトロスペクティブ

スプリントレトロスペクティブは、スクラムチームの検
査とスプリントの改善計画を作成する機会である。
• 人・関係・プロセス・ツールの観点から今回のスプ
リントを検査する。
• うまくいった項目や今後の改善点を特...
What’s changed by Retrospective?
まずは全員で設計だ!
ホワイトボード前集合!

最小モジュールから
TDDで開発回してこーぜ!

今度こそいけるだろ!
あれ?やっぱまだおかしいかも・・・。

あれ?何か設計おか...
What’s changed by Retrospective?
まずは全員で設計だ!
ホワイトボード前集合!
で、結局どんなもの
最小モジュールから
が
TDDで開発回してこーぜ!
できあがるの!?
(By ビジネスサイ
ド)

今度こそいけ...
What’s changed by Retrospective?
• 当初はモジュール単位で設計し、モジュール単位で完
璧に作りこんでいくスタイルだった。

• モジュール単位で完璧に作りこんでいくスタイルだと、
完成品をイメージしにくい上に、...
What’s changed by Retrospective?
まずは全員で設計だ!
ホワイトボード前集合!

とりあえず最低限の機能だけで
動くシステムを作り切る!

もう見れるの?
どれどれ、なるほど。
ここをこう変えられる?

20
What’s changed by Retrospective?
まずは全員で設計だ!
ホワイトボード前集合!

とりあえず最低限の機能だけで
動くシステムを作り切る!

動くものを見せることができれば、
ユーザーからのフィードバックを受けるこ...
自動化

22
npmの導入

• npmで開発環境構築自動化
• git clone → npm install で開発環境が揃う!
• package.jsonに記載されているモジュールが自
動installされる。

どこでも同じ開発環境を簡単に用意可能...
24
UnitTest自動化

•

ローカル環境自動UnitTest実行による効率化
a. Mocha/Chaiによるローカル環境UnitTest実行
b. grunt-contrib-watchによる自動UnitTest

ブラウザを介さないので...
26
ブラウザテスト自動化

•

Browser test
a. ローカルテスト用に作ったMocha/Chaiの
UnitTestをブラウザ用に変換して、クライアン
トサイドで実行。
b. 成果物のJavaScriptコードがブラウザでも正常動
作...
28
Jenkinsによる自動化

•

Jenkins
a.
b.

Git pushをトリガーとして以下の処理を行う。
git clone -> nvm で nodeのバージョン指定
-> npm install -> gruntでbuild実行...
30
複雑化を回避

31
CoffeeScriptでコードをシンプルに

•

CoffeeScript
a. JavaScriptにコンパイルされるObject志向言
語。RubyやPythonのような感覚でJavaScript
を実装できる。

32
JQuery.Defferdで非同期処理をシンプルに

• JQuery.Defferdで非同期処理実装
a. コールバックにより、ネストが多くなりが
ちなJavaScriptの非同期処理をシンプルに書
ける。
説明が難しいので省略orz

3...
やってみてわかったこと

• ハマった点・学んだこと
•
•

•
•

Scrum masterは結構気を使う。人間関係、
プロジェクトの進捗など。
JavaScriptコードを1枚に結合して難読化す
るとUnitTestが通らなくなった。原...
Summary

•
•
•
•
•
•

Agile開発では振り返りでガッツリ改善するの
が大事。毎回何か改善をTRYすべし。
JavaScriptでAgile開発する場合も、UnitTestがか
なり重要。TDDで実装するのが良い。設計、
...
ご清聴ありがとうございました。

36
Upcoming SlideShare
Loading in …5
×

Java script development by agile and scrum 201310

485 views

Published on

2013年10月にDevLove甲子園で発表した際に使用した資料になります。

Published in: Technology
  • Be the first to like this

Java script development by agile and scrum 201310

  1. 1. JavaScript development by Agile and Scrum Nov/09/2013 Hisafumi Kikkawa(@shinjukujohnny) .
  2. 2. Agenda • • • • • About me Introduction Summary of our project Our solutions Summary 2
  3. 3. About me 吉川 久文(@shinjukujohnny): Work: ソフトウェアエンジニア 某社アフィリエイトシステムフロン トエンド開発チーム 開発リーダー Study: 産業技術大学院大学 情報アーキテクチャ専攻修士過程1 年 Expertise: Java, PHP, JavaScript, ActionScript and so on… 3
  4. 4. Introduction 私達のチームはAgile & Scrum でのシステム開発を 2012年頃から本格的に取り入れ、システム開発を しています。 その中でも今回はAgile & ScrumをJavaScript開発に 適用したプロジェクト事例をご紹介します。 4
  5. 5. Summary of our project 2013年4月、弊社アフィリエイトサービスフロン トエンド開発チームは新しい広告配信エンジンの 開発を開始しました。 Requirements 充分なテストを行うこと 納期までにリリースすること(約2ヶ月) 開発メンバーは3人固定 ビジネス側の人間が使える簡易プログラミング言 語(DSL)を開発すること 5. 仕様はビジネス側と話しながら決めること 6. 拡張可能な設計とすること 1. 2. 3. 4. 5
  6. 6. Summary of our project 2013年4月、弊社アフィリエイトサービスフロン トエンド開発チームは新しい広告配信エンジンの 開発を開始しました。 Requirements 仕様は常に変化し得る! 1. 充分なテストを行うこと 時間、品質、お金のスコープは動かせない! 2. 納期までにリリースすること(約2ヶ月) 3. DSL開発ってマジか!ノウハウねーよ! 開発メンバーは3人固定 4. ビジネス側の人間が使える簡易プログラミング言 語(DSL)を開発すること 5. 仕様はビジネス側と話しながら決めること 6. 拡張可能な設計とすること 6
  7. 7. Our solutions 1. Scrumの導入 a. スプリント計画ミーティング b. デイリースクラム c. レトロスペクティブ(KPT) 2. 自動化 a. b. c. d. e. npmによる開発環境作成自動化 MochaによるサーバサイドUnitTest自動化 grunt-contrib-watchによるソース監視&自動テスト MochaによるクライアントサイドUnitTest自動化 CI(Jenkins) + gitによる自動テスト 3. 複雑化を回避 a. 開発言語をCoffeeScriptに b. JQuery.Defferdで非同期処理実装 7
  8. 8. Scrumの導入 8
  9. 9. Why Scrum? 複雑で変化の激しい問題に対応するためのフレームワー クであり、可能な限り価値の高いプロダクトを生産的か つ創造的に届けるためのものである。 (from The Scrum Guide) In case of our team • 我々のプロジェクトは、ビジネス要望によって常に変 化し得るものである。 • 技術検証できていないプロダクトも多数導入を検討。 • メンバーのスキル・ナレッジも充分でなかった。 9
  10. 10. Why Scrum? 複雑で変化の激しい問題に対応するためのフレームワー クであり、可能な限り価値の高いプロダクトを生産的か つ創造的に届けるためのものである。 (from The Scrum Guide) In case of our team • 我々のプロジェクトは、ビジネス要望によって常に変 プロジェクトは複雑で、その状態は日々変化する! 化し得るものである。 • 技術検証できていないプロダクトも多数導入を検討。 だからこそScrum! • メンバーのスキル・ナレッジも充分でなかった。 10
  11. 11. Sprint 計画 MTG スプリントの作業は、スプリント計画ミーティングで計 画する。計画はスクラムチームの共同作業である。 • スプリントの成果であるインクリメントに何を入 れるか? • インクリメントを届けるためにどのように作業を するか? (from The Scrum Guide) In case of our team • • • Planning porkerによる、チームでの見積もり プロダクトバックログからチームのヴェロシティ 分のタスクを取り出し、次のスプリントで消化す るタスクとする マイルストーンに達するには何を守り、何を諦め るかを議論する 11
  12. 12. Sprint 計画 MTG スプリントの作業は、スプリント計画ミーティングで計 画する。計画はスクラムチームの共同作業である。 • スプリントの成果であるインクリメントに何を入 れるか? • インクリメントを届けるためにどのように作業を するか? (from The Scrum Guide) 現実的で、チームの実態を反映したスケジューリング In case of our team • • • Planning porkerによる、チームでの見積もり プロダクトバックログからチームのヴェロシティ 分のタスクを取り出し、次のスプリントで消化す るタスクとする マイルストーンに達するには何を守り、何を諦め るかを議論する 12
  13. 13. Daily Scrum デイリースクラムは、開発チームが活動の状況を確認 し、次の 24 時間の計画を作る 15 分のタイムボックスで ある。デイリースクラムでは、開発チームメンバが次の ことを説明する。 • 前回のデイリースクラムから行ったこと • 次回のデイリースクラムまでに行うこと • 問題点 (from The Scrum Guide) In case of our team • • • • 前回のデイリースクラムから行ったこと 次回のデイリースクラムまでに行うこと 問題点 レトロスペクティブで上がった改善点の確認 13
  14. 14. Daily Scrum デイリースクラムは、開発チームが活動の状況を確認し、 次の 24 時間の計画を作る 15 分のタイムボックスである。 デイリースクラムでは、開発チームメンバが次のことを 説明する。 • 前回のデイリースクラムから行ったこと • 次回のデイリースクラムまでに行うこと 毎朝のMTGは短く • 問題点 (from The Scrum 前スプリントの改善点も毎朝確認 Guide) In case of our team • • • • 前回のデイリースクラムから行ったこと 次回のデイリースクラムまでに行うこと 問題点 レトロスペクティブで上がった改善点の確認 14
  15. 15. スプリント レトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検 査とスプリントの改善計画を作成する機会である。 • 人・関係・プロセス・ツールの観点から今回のスプ リントを検査する。 • うまくいった項目や今後の改善点を特定・整理す る。 • スクラムチームの改善実施計画を作成する。 (from The Scrum Guide) In case of our team • • KPTを使って問題点・改善点を洗い出し、次のスプ リントから改善を実践 一番変えたのはプロジェクトの進め方 15
  16. 16. スプリント レトロスペクティブ スプリントレトロスペクティブは、スクラムチームの検 査とスプリントの改善計画を作成する機会である。 • 人・関係・プロセス・ツールの観点から今回のスプ リントを検査する。 • うまくいった項目や今後の改善点を特定・整理する。 • スクラムチームの改善実施計画を作成する。 振り返りは超重要!The Scrum Guide) (from チームの改善エンジン In case of our team • • KPTを使って問題点・改善点を洗い出し、次のスプ リントから改善を実践 一番変えたのはプロジェクトの進め方 16
  17. 17. What’s changed by Retrospective? まずは全員で設計だ! ホワイトボード前集合! 最小モジュールから TDDで開発回してこーぜ! 今度こそいけるだろ! あれ?やっぱまだおかしいかも・・・。 あれ?何か設計おかしくね? も一回ホワイトボード前集合! 17
  18. 18. What’s changed by Retrospective? まずは全員で設計だ! ホワイトボード前集合! で、結局どんなもの 最小モジュールから が TDDで開発回してこーぜ! できあがるの!? (By ビジネスサイ ド) 今度こそいけるだろ! あれ?やっぱまだおかしいかも・・・。 あれ?何か設計おかしくね? も一回ホワイトボード前集合! 18
  19. 19. What’s changed by Retrospective? • 当初はモジュール単位で設計し、モジュール単位で完 璧に作りこんでいくスタイルだった。 • モジュール単位で完璧に作りこんでいくスタイルだと、 完成品をイメージしにくい上に、結合してみて初めて わかる問題もあることがわかった。 • ソフトウェア工学から、反復的プロセスモデル(プロ トタイプを作ってブラッシュアップするのを繰り返 す)の開発手法を参考に、動くソフトウェアをスプリ ント毎にブラッシュアップしていくやり方へ変更。 19
  20. 20. What’s changed by Retrospective? まずは全員で設計だ! ホワイトボード前集合! とりあえず最低限の機能だけで 動くシステムを作り切る! もう見れるの? どれどれ、なるほど。 ここをこう変えられる? 20
  21. 21. What’s changed by Retrospective? まずは全員で設計だ! ホワイトボード前集合! とりあえず最低限の機能だけで 動くシステムを作り切る! 動くものを見せることができれば、 ユーザーからのフィードバックを受けることができ、 もう見れるの? どれどれ、なるほど。 早急に認識のズレを埋めることができる。 ここをこう変えられる? 21
  22. 22. 自動化 22
  23. 23. npmの導入 • npmで開発環境構築自動化 • git clone → npm install で開発環境が揃う! • package.jsonに記載されているモジュールが自 動installされる。 どこでも同じ開発環境を簡単に用意可能! 23
  24. 24. 24
  25. 25. UnitTest自動化 • ローカル環境自動UnitTest実行による効率化 a. Mocha/Chaiによるローカル環境UnitTest実行 b. grunt-contrib-watchによる自動UnitTest ブラウザを介さないので 効率的に開発・テストができる! 25
  26. 26. 26
  27. 27. ブラウザテスト自動化 • Browser test a. ローカルテスト用に作ったMocha/Chaiの UnitTestをブラウザ用に変換して、クライアン トサイドで実行。 b. 成果物のJavaScriptコードがブラウザでも正常動 作することを、UnitTestを流すことで確認。 UnitTestをブラウザで流すだけで動作することを 証明できるので、テストが簡単! 27
  28. 28. 28
  29. 29. Jenkinsによる自動化 • Jenkins a. b. Git pushをトリガーとして以下の処理を行う。 git clone -> nvm で nodeのバージョン指定 -> npm install -> gruntでbuild実行&テスト -> coverage測定 29
  30. 30. 30
  31. 31. 複雑化を回避 31
  32. 32. CoffeeScriptでコードをシンプルに • CoffeeScript a. JavaScriptにコンパイルされるObject志向言 語。RubyやPythonのような感覚でJavaScript を実装できる。 32
  33. 33. JQuery.Defferdで非同期処理をシンプルに • JQuery.Defferdで非同期処理実装 a. コールバックにより、ネストが多くなりが ちなJavaScriptの非同期処理をシンプルに書 ける。 説明が難しいので省略orz 33
  34. 34. やってみてわかったこと • ハマった点・学んだこと • • • • Scrum masterは結構気を使う。人間関係、 プロジェクトの進捗など。 JavaScriptコードを1枚に結合して難読化す るとUnitTestが通らなくなった。原因不明 > 難読化は諦めた。 IEに対応していないモジュールがあって、 パッチをあてて対応。 ローカル実装でUT/実装だけに集中してい ると、結合段階で、ブラウザの仕様で不可 解な動きをするケースがある。 34
  35. 35. Summary • • • • • • Agile開発では振り返りでガッツリ改善するの が大事。毎回何か改善をTRYすべし。 JavaScriptでAgile開発する場合も、UnitTestがか なり重要。TDDで実装するのが良い。設計、 仕様の変更に対応しやすくなる。 ローカルでUnitTest回せると格段に効率が上が る。 最終的には各種ブラウザでの結合テストが必 要 スプリントの終わりには常に動くソフトウェ アを届けるべし。 時間が許すなら、コードの品質を上げられる ライブラリは積極導入すべき 35
  36. 36. ご清聴ありがとうございました。 36

×