JavaScript development by Agile and Scrum

Nov/09/2013Hisafumi Kikkawa(@shinjukujohnny)

.

2

Agenda

• About me• Introduction• Summary of our project• Our solutions• Summary

3

About me

吉川 久文（ @shinjukujohnny ） :

Work:ソフトウェアエンジニア某社アフィリエイトシステムフロントエンド開発チーム 開発リーダー

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

Expertise ：Java, PHP, JavaScript,ActionScript and so on…

4

Introduction

私達のチームは Agile & Scrum でのシステム開発を 2012 年頃から本格的に取り入れ、システム開発をしています。

その中でも今回は Agile & Scrum を JavaScript 開発に適用したプロジェクト事例をご紹介します。

5

Summary of our project

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

Requirements1. 充分なテストを行うこと2. 納期までにリリースすること（約 2 ヶ月）3. 開発メンバーは 3 人固定4. ビジネス側の人間が使える簡易プログラミング言

語（ DSL ）を開発すること5. 仕様はビジネス側と話しながら決めること6. 拡張可能な設計とすること

6

Summary of our project

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

Requirements1. 充分なテストを行うこと2. 納期までにリリースすること（約 2 ヶ月）3. 開発メンバーは 3 人固定4. ビジネス側の人間が使える簡易プログラミング言

語（ DSL ）を開発すること5. 仕様はビジネス側と話しながら決めること6. 拡張可能な設計とすること

仕様は常に変化し得る！時間、品質、お金のスコープは動かせない！

DSL 開発ってマジか！ノウハウねーよ！

7

Our solutions

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

2. 自動化a. npm による開発環境作成自動化b. Mocha によるサーバサイド UnitTest 自動化c. grunt-contrib-watch によるソース監視＆自動テストd. Mocha によるクライアントサイド UnitTest 自動化e. CI （ Jenkins ） + git による自動テスト

3. 複雑化を回避a. 開発言語を CoffeeScript にb. JQuery.Defferd で非同期処理実装

8

Scrum の導入

9

Why Scrum?

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 (from The Scrum Guide)In case of our team• 我々のプロジェクトは、ビジネス要望によって常に変

化し得るものである。• 技術検証できていないプロダクトも多数導入を検討。• メンバーのスキル・ナレッジも充分でなかった。

10

Why Scrum?

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。 (from The Scrum Guide)In case of our team• 我々のプロジェクトは、ビジネス要望によって常に変

化し得るものである。• 技術検証できていないプロダクトも多数導入を検討。• メンバーのスキル・ナレッジも充分でなかった。

プロジェクトは複雑で、その状態は日々変化する！だからこそ Scrum ！

11

Sprint 計画 MTG

スプリントの作業は、スプリント計画ミーティングで計画する。計画はスクラムチームの共同作業である。• スプリントの成果であるインクリメントに何を入

れるか？• インクリメントを届けるためにどのように作業を

するか？(from The Scrum Guide)

In case of our team• Planning porker による、チームでの見積もり• プロダクトバックログからチームのヴェロシティ

分のタスクを取り出し、次のスプリントで消化するタスクとする

• マイルストーンに達するには何を守り、何を諦めるかを議論する

12

Sprint 計画 MTG

スプリントの作業は、スプリント計画ミーティングで計画する。計画はスクラムチームの共同作業である。• スプリントの成果であるインクリメントに何を入

れるか？• インクリメントを届けるためにどのように作業を

するか？(from The Scrum Guide)

In case of our team• Planning porker による、チームでの見積もり• プロダクトバックログからチームのヴェロシティ

分のタスクを取り出し、次のスプリントで消化するタスクとする

• マイルストーンに達するには何を守り、何を諦めるかを議論する

現実的で、チームの実態を反映したスケジューリング

13

Daily Scrum

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

（ from The Scrum Guide ）In case of our team• 前回のデイリースクラムから行ったこと• 次回のデイリースクラムまでに行うこと• 問題点• レトロスペクティブで上がった改善点の確認

14

Daily Scrum

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

（ from The Scrum Guide ）In case of our team• 前回のデイリースクラムから行ったこと• 次回のデイリースクラムまでに行うこと• 問題点• レトロスペクティブで上がった改善点の確認

毎朝の MTG は短く前スプリントの改善点も毎朝確認

15

スプリント レトロスペクティブ

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

トを検査する。• うまくいった項目や今後の改善点を特定・整理する。• スクラムチームの改善実施計画を作成する。

（ from The Scrum Guide ）

In case of our team• KPT を使って問題点・改善点を洗い出し、次のスプ

リントから改善を実践• 一番変えたのはプロジェクトの進め方

16

スプリント レトロスペクティブ

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

トを検査する。• うまくいった項目や今後の改善点を特定・整理する。• スクラムチームの改善実施計画を作成する。

（ from The Scrum Guide ）

In case of our team• KPT を使って問題点・改善点を洗い出し、次のスプ

リントから改善を実践• 一番変えたのはプロジェクトの進め方

振り返りは超重要！チームの改善エンジン

17

What’s changed by Retrospective?

まずは全員で設計だ！ホワイトボード前集合！

あれ？何か設計おかしくね？も一回ホワイトボード前集合！

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

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

18

What’s changed by Retrospective?

まずは全員で設計だ！ホワイトボード前集合！

あれ？何か設計おかしくね？も一回ホワイトボード前集合！

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

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

で、結局どんなものが

できあがるの！？（ By ビジネスサイ

ド）

19

What’s changed by Retrospective?

• 当初はモジュール単位で設計し、モジュール単位で完璧に作りこんでいくスタイルだった。

• モジュール単位で完璧に作りこんでいくスタイルだと、完成品をイメージしにくい上に、結合してみて初めてわかる問題もあることがわかった。

• ソフトウェア工学から、反復的プロセスモデル（プロトタイプを作ってブラッシュアップするのを繰り返す）の開発手法を参考に、動くソフトウェアをスプリント毎にブラッシュアップしていくやり方へ変更。

20

What’s changed by Retrospective?

まずは全員で設計だ！ホワイトボード前集合！

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

もう見れるの？どれどれ、なるほど。

ここをこう変えられる？

21

What’s changed by Retrospective?

まずは全員で設計だ！ホワイトボード前集合！

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

もう見れるの？どれどれ、なるほど。

ここをこう変えられる？

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

早急に認識のズレを埋めることができる。

22

自動化

23

npm の導入

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

動 installされる。

どこでも同じ開発環境を簡単に用意可能！

24

25

UnitTest 自動化

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

ブラウザを介さないので効率的に開発・テストができる！

26

27

ブラウザテスト自動化

• Browser testa. ローカルテスト用に作った Mocha/Chai の

UnitTest をブラウザ用に変換して、クライアントサイドで実行。

b. 成果物の JavaScript コードがブラウザでも正常動作することを、 UnitTest を流すことで確認。

UnitTest をブラウザで流すだけで動作することを証明できるので、テストが簡単！

28

29

Jenkins による自動化

• Jenkinsa. Git push をトリガーとして以下の処理を行う。b. git clone -> nvm で node のバージョン指定

-> npm install -> grunt で build 実行 & テスト -> coverage測定

30

31

複雑化を回避

32

CoffeeScript でコードをシンプルに

• CoffeeScripta. JavaScript にコンパイルされる Object志向言

語。 Rubyや Python のような感覚でJavaScript を実装できる。

33

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

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

説明が難しいので省略 orz

34

やってみてわかったこと

• ハマった点・学んだこと• Scrum master は結構気を使う。人間関係、

プロジェクトの進捗など。• JavaScript コードを１枚に結合して難読化す

ると UnitTest が通らなくなった。原因不明 -> 難読化は諦めた。

• IE に対応していないモジュールがあって、パッチをあてて対応。

• ローカル実装で UT/ 実装だけに集中していると、結合段階で、ブラウザの仕様で不可解な動きをするケースがある。

35

Summary

• Agile 開発では振り返りでガッツリ改善するのが大事。毎回何か改善を TRY すべし。

• JavaScript で Agile 開発する場合も、 UnitTest がかなり重要。 TDD で実装するのが良い。設計、仕様の変更に対応しやすくなる。

• ローカルで UnitTest 回せると格段に効率が上がる。

• 最終的には各種ブラウザでの結合テストが必要

• スプリントの終わりには常に動くソフトウェアを届けるべし。

• 時間が許すなら、コードの品質を上げられるライブラリは積極導入すべき

36

ご清聴ありがとうございました。