Recommended
More Related Content
Similar to Agile Japan 2014 Okinawa
Similar to Agile Japan 2014 Okinawa (20)
Agile Japan 2014 Okinawa
- 3. チームメンバー 砂川昌平 自律分散システム研究室M2 Twitter: @kanpe777 =>仕事now (2014/06/28現在) 大城佳明 インターネットシステム工学研究室M2 Twitter: @himajin315 =>マレーシアnow (2014/06/28現在)
- 5. enPiT とは (*1) 最先端の情報技術を実践的に活用することができる 人材育成を目指しているプログラム 大学院生向けのプログラムで 2013年度が第1回目 1. Education Network for Practical Information Technologies 分野・地域を越えた実践的情報教育協働ネットワーク
- 6. enPiT とは (*1) 最先端の情報技術を実践的に活用することができる 人材育成を目指しているプログラム 大学院生向けのプログラムで 2013年度が第1回目 1. Education Network for Practical Information Technologies 分野・地域を越えた実践的情報教育協働ネットワーク ちなみに6単位貰えます！！！
- 7. enPiTの分野 • クラウドコンピューティング (Cloud) • ビジネスアプリケーション (BizApp) • セキュリティ (Security) • 組込みシステム (Emb)
- 8. enPiTの分野 • クラウドコンピューティング (Cloud) • ビジネスアプリケーション (BizApp) • セキュリティ (Security) • 組込みシステム (Emb) 私たちはBizApp分野に参加しました
- 9. enPiTのスケジュール 6 8月:講義 Agile開発手法について 9月: 集中合宿 vagrantやgit等のツールについて 講演の聴講 第0スプリント(企画とデプロイ) 10 12月: 開発 Agile開発手法の実践 (10週間) 2月: 発表 BizApp分野の成果発表
- 10. Agileの座学(前期) 講師: 永瀬美穂さん (Twitter: @miholovesq) スクラム部外者 顧客、出資者etc ステークホルダー 方 針 決 定 権 限 優 先 順 位 決 定 権 製 品 に 対 し て の 責 任 プロダクトオーナー 幹 事 的 な 存 在 スクラムマスター 上 手 い 仕 組 み の 責 任 チ ｜ ム を 守 る 開発チーム 作 る 責 任 開発チームへのプレッシャー 守る 注意 ： スクラムチームにマネージャーは存在しない プロダクトバックログ やりたいことのリスト (必ずシーケンシャル) プロダクトオーナのみ 並び替え可能 スクラムチーム サポート、(そもそもスクラムとは...) スクラムを回すetc... スクラムを回す 雇う & 解雇 開発環境の要求etc... ５-９人 スプリント スプリントバックログ スプリントで実施する 開発チームのタスクリスト (タスク1つは時間 で見積もる) スプリト計画ミーティング スプリントの過ごし方を計画 スプリントバックログも決まる インクリメント 出荷可能な 製品の増分 毎日の繰り返し デイリースクラム デイリースクラム デイリースクラム デイリースクラム 毎日チームが以下の 3つの質問に答える ・昨日やったこと ・今日やったこと ・困っていること ∼15分 スプリントレビュー 作ったものを確認し、改善 振り返り スプリントの中での改善事項を 話し合って、次に繋げる Doneの定義 何をもって「完了」とするかを 定義したリスト スプリント スプリントバックログ スプリントで実施する 開発チームのタスクリスト (タスク1つは時間 で見積もる) スプリト計画ミーティング スプリントの過ごし方を計画 スプリントバックログも決まる インクリメント 出荷可能な 製品の増分 毎日の繰り返し デイリースクラム デイリースクラム デイリースクラム デイリースクラム 毎日チームが以下の 3つの質問に答える ・昨日やったこと ・今日やったこと ・困っていること ∼15分 スプリントレビュー 作ったものを確認し、改善 振り返り スプリントの中での改善事項を 話し合って、次に繋げる スプリント スプリントバックログ スプリントで実施する 開発チームのタスクリスト (タスク1つは時間 で見積もる) スプリト計画ミーティング スプリントの過ごし方を計画 スプリントバックログも決まる インクリメント 出荷可能な 製品の増分 毎日の繰り返し デイリースクラム デイリースクラム デイリースクラム デイリースクラム 毎日チームが以下の 3つの質問に答える ・昨日やったこと ・今日やったこと ・困っていること ∼15分 スプリントレビュー 作ったものを確認し、改善 振り返り スプリントの中での改善事項を 話し合って、次に繋げる スプリント スプリト計画ミーティング スプリントの過ごし方を計画 スプリントバックログも決まる インクリメント 出荷可能な 製品の増分 スプリントバックログ スプリントで実施する 開発チームのタスクリスト (タスク1つは時間 で見積もる) 毎日の繰り返し デイリースクラム デイリースクラム デイリースクラム デイリースクラム 毎日チームが以下の 3つの質問に答える ・昨日やったこと ・今日やったこと ・困っていること ∼15分 スプリントレビュー 作ったものを確認し、改善 振り返り スプリントの中での改善事項を 話し合って、次に繋げる 1つのスプリントの期間は大体１−４週間(全てのスプリントの期間の長さは同一) ス プ リ ン ト を 繰 り 返 す 作: kanpe777
- 11. 集中合宿 1 4日目:講演を聴講
- 16. 余談:飛行機対決の結果
- 17. 余談:飛行機対決の結果
- 18. 余談:飛行機対決の結果
- 22. 集中合宿 6日目 楽天APIを使用したWebアプリケーション開発の計画立案 第0スプリント やったこと • 企画 • エレベーターピッチ作成 • 第0スプリント • 環境構築 • herokuへのデプロイ • なんでも良いから1機能作る
- 23. 第0スプリント 企画
- 25. 第0スプリント 作業
- 26. 第0スプリント成果 Developer team User View Deploy Manage Source Code Test GitHub Travis-CI Heroku 環境構築 herokuへのデプロイ
- 27. 第0スプリント成果 Developer team User View Deploy Manage Source Code Test GitHub Travis-CI Heroku 環境構築 herokuへのデプロイ 第0スプリントからTravisを経由して Herokuにデプロイできたチームは 私たちのチームだけでした
- 28. Agile開発を実践 期間 10/12(Sat) 12/14(Sat)の 10週間(10スプリント) 予定 毎週土曜にデモ 作業 毎週2コマ分の時間 (90分*2)
- 29. 私たちのScrum • プロダクトオーナーが居ない • 開発チームが兼業 • スクラムマスターが居ない • デイリースクラムが無い • ウィークリースクラム
- 37. ミーティング • 毎週土曜日のデモ後に実行 • スプリントバックログの作成 • プロダクトバックログアイテムから選択 • 見積もり • 作業者の割り当て • UIなどは実際に書いて みんなに見せる
- 41. デモと振り返り • TV会議を利用して産業技術大に居る 先生や他のチームとデモ • エレベーターピッチ、今週やったこと、 デモ、来週追加する機能 • 先生や他チームからの コメント
- 42. エンドレステン -> スプリント計画ミーティング -> 開発 -> デモ -> 振り返り -> 上に戻る 10週間繰り返すだけの簡単なお仕事 (簡単とは言ってない)
- 44. 第1スプリント • プロダクトバックログができていない • デモ時に見せたものはスプリントバックログ • 永瀬先生、激オコ • 「プロダクトバックログ見せろ」 • やることは細かく分けて、 それぞれgithub issuesを作成 • issuesだらけで見づらい
- 45. 第2スプリント • プロダクトバックログを作成 • github wikiを利用 • 作業時間をトラッキングしていた • 永瀬先生「作業時間のトラッキングはやめよう！」 • issuesを細かく分けない • checkboxの利用
- 46. 第3スプリント • プロダクトバックログ • Google Spread Sheetに移行 • markdownで記述するのが大変だった • 色分けできて、見やすい、説明しやすい、便利！ • プロダクトバックログの書き方 • 「全然なってない」 • 何も知らない人が プロダクトバックログを見たときを考える
- 47. 第4スプリント • プロダクトバックログ • 「どんな恩恵を受けれるか」を記述 • このスプリントでは先生方に突っ込まれなかった！ この辺りからバックログの作成など、 スプリントを回すのがスムーズに！
- 48. 第5スプリント以降 • アジャイル的な観点で突っ込みを貰うことは 目に見えて減った！ • 代わりにプロダクトについてのコメントが増加 • 褒められたり、「こういう機能があるといいかも」
- 52. 注意していた点 • 情報はちゃんと共有する • ミーティングでは歯に衣着せぬ物言いを • 遠慮せずに思ったことはちゃんと言う • 他人が読みやすいコードを書く • 規約の統一や、積極的なリファクタリング • 間違いだと思ったことは直ぐに修正する
- 53. 突っ込まれたこと • デモ時に スプリントバックログ を見せてしまった • 作業時間をトラッキングしていた • プロダクトの目的を書く • プロダクトバックログが分かりにくい • 何も知らない人がバックログを見たときを想定 • そもそも楽天APIを使え • Learn, Build, MeasureのMeasureが弱い • もっと営業しよう • リリース直前に駆け込み作業をしないこと • etc…
- 54. 褒められたこと • プランをグリグリいじれるのが良い！ • 既存サービスとの差別化があっていい！ • 突っ込まれたことをすぐ実装して偉い！(楽天API) • プロダクトバックログの書き方がよくなってきた！ • 面白い！ • UIに大きな変化があってビックリ！ • 一覧できるのがいい！ • 最終発表が楽しみ！ • スモールリリースを繰り返すことで魅力的になった！ • デモの仕方がうまい！ • etc…
- 55. 学んだこと • 情報の共有の大切さ • 開発者の環境を同じにすることの大切さ • 実際にデモができるのはとっても大事 • デモ時にもらったコメントや振り返りから 迅速に方向転換や修正が可能なのが アジャイル開発の良い点
- 56. やってて良かったこと • git管理 • sprint毎の変化が分かりやすい！ • Pull Requestが来た！ • vagrant • 開発環境をそろえるのが簡単！ • Travis連携 • テストが通ったらherokuへ自動デプロイ
- 57. デモ or 質疑応答