agile japan 2014 okinawa

10スプリントでwebアプリ開発

~学生によるAgile開発~ Yosuke OTA Yu SUGIMOTO

太田陽祐インターネットシステム工学研究室M2 Twitter: @y0t4

杉本優並列信頼研究室M2 Twitter: @salvare234

自己紹介

チームメンバー砂川昌平自律分散システム研究室M2 Twitter: @kanpe777 =>仕事now (2014/06/28現在)

大城佳明インターネットシステム工学研究室M2 Twitter: @himajin315 =>マレーシアnow (2014/06/28現在)

きっかけ後期に授業を取りたくない学生たちは enPiTというプログラムに参加し、単位を得ようと考えていました。

学生4人のagile開発はここから始まりました

そのプログラムのテーマが「ScrumによるWebアプリケーション開発」

enPiT とは(*1)

最先端の情報技術を実践的に活用することができる人材育成を目指しているプログラム

大学院生向けのプログラムで 2013年度が第1回目

1. Education Network for Practical Information Technologies 分野・地域を越えた実践的情報教育協働ネットワーク

enPiT とは(*1)

最先端の情報技術を実践的に活用することができる人材育成を目指しているプログラム

大学院生向けのプログラムで 2013年度が第1回目

1. Education Network for Practical Information Technologies 分野・地域を越えた実践的情報教育協働ネットワーク

ちなみに6単位貰えます！！！

enPiTの分野• クラウドコンピューティング (Cloud) • ビジネスアプリケーション (BizApp) • セキュリティ (Security) • 組込みシステム (Emb)

enPiTの分野• クラウドコンピューティング (Cloud) • ビジネスアプリケーション (BizApp) • セキュリティ (Security) • 組込みシステム (Emb)

私たちはBizApp分野に参加しました

enPiTのスケジュール6~8月:講義 Agile開発手法について 9月: 集中合宿 vagrantやgit等のツールについて講演の聴講第0スプリント(企画とデプロイ) 10~12月: 開発 Agile開発手法の実践 (10週間) 2月: 発表 BizApp分野の成果発表

Agileの座学(前期)講師: 永瀬美穂さん

(Twitter: @miholovesq)

スクラム部外者顧客、出資者etc

ステークホルダー

方針決定権限

優先順位決定権

製品に対しての責任

プロダクトオーナー

幹事的な存在

スクラムマスター上手い仕組みの責任

チ｜ムを守る

開発チーム

作る責任

開発チームへのプレッシャー

守る

注意　：　スクラムチームにマネージャーは存在しない

プロダクトバックログ

やりたいことのリスト(必ずシーケンシャル)プロダクトオーナのみ並び替え可能

スクラムチーム

サポート、(そもそもスクラムとは...)スクラムを回すetc...

スクラムを回す

雇う & 解雇開発環境の要求etc...

５-９人

スプリント

スプリントバックログ

スプリントで実施する開発チームのタスクリスト(タスク1つは時間　で見積もる)

スプリト計画ミーティング

スプリントの過ごし方を計画スプリントバックログも決まるインクリメント

出荷可能な製品の増分

毎日の繰り返し

デイリースクラムデイリースクラムデイリースクラムデイリースクラム毎日チームが以下の　　　3つの質問に答える・昨日やったこと・今日やったこと・困っていること

～15分

スプリントレビュー

作ったものを確認し、改善

振り返り

スプリントの中での改善事項を話し合って、次に繋げる

Doneの定義何をもって「完了」とするかを定義したリスト

スプリント








～15分



振り返り


スプリント








～15分



振り返り


スプリント



出荷可能な製品の増分スプリントバックログ




～15分



振り返り


1つのスプリントの期間は大体１－４週間(全てのスプリントの期間の長さは同一)

スプリントを繰り返す

作: kanpe777

集中合宿1~4日目:講演を聴講

集中合宿5日目楽天APIの解説 !

集中合宿5日目楽天APIの解説チームビルディング紙ヒコーキを飛ばす(ワークショップ)

集中合宿5日目楽天APIの解説チームビルディング紙ヒコーキを飛ばす吉岡さん

名嘉村先生

余談:飛行機対決の結果


私たちのチーム


私たちのチーム先生たちのチーム


私たちのチーム先生たちのチーム

大勝利！！！

集中合宿6日目楽天APIを使用したWebアプリケーション開発の計画立案第0スプリント

やったこと • 企画 • エレベーターピッチ作成 • 第0スプリント • 環境構築 • herokuへのデプロイ • なんでも良いから1機能作る

第0スプリント

企画

第0スプリント

エレベーターピッチ

第0スプリント

作業

第0スプリント成果

Developer team

User

View

Deploy

Manage Source Code

Test

GitHub Travis-CI

Heroku

環境構築

herokuへのデプロイ

第0スプリント成果

Developer team

User

View

Deploy

Manage Source Code

Test

GitHub Travis-CI

Heroku

環境構築

herokuへのデプロイ

第0スプリントからTravisを経由して Herokuにデプロイできたチームは私たちのチームだけでした

Agile開発を実践

期間 10/12(Sat)~12/14(Sat)の 10週間(10スプリント) 予定毎週土曜にデモ作業毎週2コマ分の時間 (90分*2)

私たちのScrum• プロダクトオーナーが居ない • 開発チームが兼業

• スクラムマスターが居ない • デイリースクラムが無い • ウィークリースクラム



方針決定権限




幹事的な存在


チ｜ムを守る

開発チーム

作る責任


守る








５-９人

スプリント








～15分



振り返り



スプリント








～15分



振り返り


スプリント








～15分



振り返り


スプリント







～15分



振り返り






方針決定権限




幹事的な存在


チ｜ムを守る

開発チーム

作る責任


守る








５-９人

スプリント








～15分



振り返り



スプリント








～15分



振り返り


スプリント








～15分



振り返り


スプリント







～15分



振り返り




全て土曜日に実行



方針決定権限




幹事的な存在


チ｜ムを守る

開発チーム

作る責任


守る








５-９人

スプリント








～15分



振り返り



スプリント








～15分



振り返り


スプリント








～15分



振り返り


スプリント







～15分



振り返り




全て土曜日に実行

不在

プロダクトバックログGoogle Spread Sheetを利用


絶対に必要な機能は優先順位を高く


ユーザ目線な説明

絶対に必要な機能は優先順位を高く

ミーティング• 毎週土曜日のデモ後に実行 • スプリントバックログの作成 • プロダクトバックログアイテムから選択

• 見積もり • 作業者の割り当て • UIなどは実際に書いてみんなに見せる

スプリントバックログGithub Issuesを利用

スプリントバックログGithub Issuesを利用

スプリントバックログはなるべく細かく記述する

作業形態• 2人1組での作業 • 得た知識はgithubのwikiやissuesで共有

デモと振り返り• TV会議を利用して産業技術大に居る　先生や他のチームとデモ • エレベーターピッチ、今週やったこと、　デモ、来週追加する機能 • 先生や他チームからの　コメント

エンドレステン -> スプリント計画ミーティング -> 開発 -> デモ -> 振り返り -> 上に戻る

10週間繰り返すだけの簡単なお仕事 (簡単とは言ってない)

スプリント淡々と説明してきたけれど…

!

!

当然、最初からうまくできた訳ではないスプリントを振り返ってみる

第1スプリント• プロダクトバックログができていない • デモ時に見せたものはスプリントバックログ • 永瀬先生、激オコ • 「プロダクトバックログ見せろ」

• やることは細かく分けて、　それぞれgithub issuesを作成 • issuesだらけで見づらい

第2スプリント• プロダクトバックログを作成 • github wikiを利用 • 作業時間をトラッキングしていた • 永瀬先生「作業時間のトラッキングはやめよう！」

• issuesを細かく分けない • checkboxの利用

第3スプリント• プロダクトバックログ • Google Spread Sheetに移行 • markdownで記述するのが大変だった • 色分けできて、見やすい、説明しやすい、便利！

• プロダクトバックログの書き方 • 「全然なってない」 • 何も知らない人がプロダクトバックログを見たときを考える

第4スプリント• プロダクトバックログ • 「どんな恩恵を受けれるか」を記述 • このスプリントでは先生方に突っ込まれなかった！

この辺りからバックログの作成など、スプリントを回すのがスムーズに！

第5スプリント以降• アジャイル的な観点で突っ込みを貰うことは　目に見えて減った！ • 代わりにプロダクトについてのコメントが増加 • 褒められたり、「こういう機能があるといいかも」

Agileの良さデモ時にコメントをもらって、やり方を改善する !

Agile == 機敏な !

失敗しても機敏に対応していこう！ !

Agileの良さデモ時にコメントをもらって、やり方を改善する !

Agile == 機敏な !

失敗しても機敏に対応していこう！ !

その結果が

成果物http://sharepla.herokuapp.com

http://sharepla.herokuapp.com

注意していた点

• 情報はちゃんと共有する • ミーティングでは歯に衣着せぬ物言いを • 遠慮せずに思ったことはちゃんと言う

• 他人が読みやすいコードを書く • 規約の統一や、積極的なリファクタリング

• 間違いだと思ったことは直ぐに修正する

突っ込まれたこと• デモ時に”スプリントバックログ”を見せてしまった • 作業時間をトラッキングしていた • プロダクトの目的を書く • プロダクトバックログが分かりにくい • 何も知らない人がバックログを見たときを想定

• そもそも楽天APIを使え • Learn, Build, MeasureのMeasureが弱い • もっと営業しよう

• リリース直前に駆け込み作業をしないこと • etc…

褒められたこと• プランをグリグリいじれるのが良い！ • 既存サービスとの差別化があっていい！ • 突っ込まれたことをすぐ実装して偉い！(楽天API) • プロダクトバックログの書き方がよくなってきた！ • 面白い！ • UIに大きな変化があってビックリ！ • 一覧できるのがいい！ • 最終発表が楽しみ！ • スモールリリースを繰り返すことで魅力的になった！ • デモの仕方がうまい！ • etc…

学んだこと

• 情報の共有の大切さ • 開発者の環境を同じにすることの大切さ • 実際にデモができるのはとっても大事 • デモ時にもらったコメントや振り返りから　迅速に方向転換や修正が可能なのが　アジャイル開発の良い点

やってて良かったこと• git管理 • sprint毎の変化が分かりやすい！ • Pull Requestが来た！

• vagrant • 開発環境をそろえるのが簡単！

• Travis連携 • テストが通ったらherokuへ自動デプロイ

デモ or 質疑応答

発表しなかった技術的な部分や各スプリントのより細かい内容、感想、プロダクトの出来映えを

記述した資料があります。興味のある方は、是非見に来て下さい

agile japan 2014 okinawa

Engineering