Your SlideShare is downloading. ×
日暮里アジャイル
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

日暮里アジャイル

374
views

Published on

社内勉強会で行ったスクラム勉強会の資料です。 …

社内勉強会で行ったスクラム勉強会の資料です。
スクラム開発の流れや今までの事例を元にまとめています。

Published in: Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
374
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. teens事業部 Candyグループ 佐藤 慎悟 Nippori Agile sprint 0
  • 2. WARNING 夜な夜な日暮里で遊び回っているという 事業部に広がる 私、個人に対するデマへの皮肉を込めて この名前にしただけであって 日暮里とアジャイルは一切関係ありません。 NO日暮里!
  • 3. Me!
  • 4. Nippori Agile sprint 0 本日のメニュー ・アジャイルって何だろう ・スクラムについて ・Candy PC開発でやったこと ・インセプションデッキ
  • 5. アジャイルって何だろう?
  • 6. ・・・その前に
  • 7. サービスを作る上で 本当に大事な事って なんだろう
  • 8. ・何のために作っているの? ・ユーザーにメリットはあるの? ・それが、ちゃんとユーザーに届 けられているかをこまめに確認!
  • 9. 当初よりも良いアイデアが 出てくれば、それを受け入れて 作る物を変えていく
  • 10. 柔軟な対応が必要 当初よりも良いアイデアが 出てくれば、それを受け入れて 作る物を変えていく
  • 11. ・関係者は目的達成のためにお互いに協 力しながら進める ・利用者の反応や関係者からのフィード バックを継続的に得ながら、計画を調整 ・一度にまとめてではなく少しづつ作る ・出来上がった物が求めている物とあっ ているかを頻繁に確認する
  • 12. アジャイルって何だろう?
  • 13. アジャイルは 目的を達成するため の習慣
  • 14. アジャイルをやろう Doing Agile
  • 15. アジャイルをやろう Doing Agile
  • 16. アジャイルをやろう Doing Agile アジャイルにやろう Being Agile
  • 17. スクラムについて
  • 18. スクラム Scrum ・アジャイル開発の手法の一つ ・全員が一枚岩となって行う、作業、会 議、成果物を定めたもの
  • 19. スクラム Scrum ・要求を常に順番に並び替えて、その順番にプロダク トを作る事で成果物を最大化する ・固定の短い期間に区切って作業を進める ・現在の状況や問題点を常に明らかにする(透明性) ・定期的に進捗状況や作っているプロダクトが正しい のか、仕事の進め方に問題がないかどうかを確認 ・やり方に問題があったり、もっとうまく出来る方法 があったりすれば、やり方そのものを変える。
  • 20. 実際の流れはどんな感じ?
  • 21. http://www.scrumprimer.org/
  • 22. スクラムには ロール(役割)があるよ
  • 23. プロダクトオーナー ・プロダクトの結果責任を取る ・プロダクトバックログの管理者で優先順位の最終決定権を持つ ・プロジェクトに必ず一人必要 ・開発チームを活用してプロダクトの価値を最大化する ・開発チームに相談出来るが、干渉は出来ない
  • 24. 開発チーム ・リリース判断可能なプロダクトを作る ・全員揃えばプロダクトを作れる ・上下関係はない ・開発チーム全員で作業を進める自己組織化されたチーム
  • 25. スクラムマスター ・スクラムのプロセスがうまくまわるようにする ・妨害を排除する ・支援と奉仕をする ・教育、ファシリテート、コーチ、推進役
  • 26. http://www.scrumprimer.org/
  • 27. http://www.scrumprimer.org/
  • 28. http://www.scrumprimer.org/ プロダクトバックログ ・実現したい要求をリストにして優先順位で並び変える ・一度作って完了ではなく、絶えず修正されるものなので、 常にメンテナンスして最新に保つ ・プロダクトバックログには作業量を表した値を使う
  • 29. 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい
  • 30. http://www.scrumprimer.org/
  • 31. http://www.scrumprimer.org/
  • 32. http://www.scrumprimer.org/ スプリント計画ミーティング ・スプリントで開発をするには計画が必要 ・ミーティングは二部制 ・プロダクトオーナーは何を欲しいのか(第一部) ・開発チームはどれくらいできそうか(第一部) ➡ストーリーポイントをつけていく ・開発チームはどうやってそれを実現するか(第二部)
  • 33. 1番目に欲しい 2番目に欲しい 3番目に欲しい 4番目に欲しい 5番目に欲しい 6番目に欲しい タスク タスク タスク タスク タスク タスク タスク タスク スプリント
  • 34. http://www.scrumprimer.org/
  • 35. http://www.scrumprimer.org/
  • 36. http://www.scrumprimer.org/ デイリースクラム ・時間は15分以内 ・昨日やった事、今日やる事、問題点を共有 ・別途で話が必要な物は後で時間をとってやる ・全員が進捗や問題になっている事を把握できる ・デイリースクラムは開発チームのためのもの ➡特定の誰かへの報告会ではない
  • 37. 時間は大切
  • 38. http://www.scrumprimer.org/
  • 39. http://www.scrumprimer.org/
  • 40. http://www.scrumprimer.org/ スプリントレビュー ・開発チームの成果物をプロダクトオーナーが確認する ・確認するのは動作するプロダクト ・完了しなかった物はプロダクトバックログに戻される ・プロダクトバックログに追加する項目の有無について議論 ・現在の進捗を踏まえて、リリース日や完了日を予測する
  • 41. http://www.scrumprimer.org/
  • 42. http://www.scrumprimer.org/
  • 43. http://www.scrumprimer.org/ スプリントレトロスペクティブ ・うまくいった事、今後改善すべき点を整理する ・振り返り(KPT法なんかが分かりやすい) ・次回スプリント以降のアクションプランを決める
  • 44. 定期的な振り返りを
  • 45. http://www.scrumprimer.org/
  • 46. よくある質問
  • 47. Q.スプリントの期間って別にバラバラで もよくないですか?
  • 48. Q.スプリントの期間って別にバラバラで もよくないですか? A.スプリントの期間を固定する事でチー ムのベロシティを計れるようになって進 捗を把握しやすくなったり、見積もりの 誤差が少なくなるよ。
  • 49. Q.ストーリーポイントって時間とかで予 測したらダメなわけ?
  • 50. Q.ストーリーポイントって時間とかで予 測したらダメなわけ? A.時間で見積もると人によって見積もり が違う事がある。あと、チームの成長を 考慮していないのでチームが成長して いった時に見積もりをやり直さないとい けなくなるよ。
  • 51. Q.リリース判断可能なポイントってどう いうこと?
  • 52. Q.リリース判断可能なポイントってどう いうこと? A.各ストーリーにおけるゴールを明確に しよう。何をもってリリースが可能かを 決めないといつまで起っても終わりませ ん。また、リリース判断ポイントの定義 は品質基準とも言えます。
  • 53. PC版開発時のおもひで
  • 54. いまいちな事もありました
  • 55. PC開発でいまいちだった点① 何?このストーリー… とても、大きいです…
  • 56. PC開発でいまいちだった点① タスクは細分化しよう。 冷静な判断も下しやすい。 何?このストーリー… とても、大きいです…
  • 57. PC開発でいまいちだった点② ゴールどこ? どこまで走ればいいの?
  • 58. PC開発でいまいちだった点② ゴールどこ? どこまで走ればいいの? ゴールはちゃんと決めましょう。 スプリントって言ってんのにフルマラソン。
  • 59. PC開発でいまいちだった点③ だからこれは デザインなのよ!
  • 60. PC開発でいまいちだった点③ だからこれは デザインなのよ! デザインはデザイン。 仕様等は別のドキュメントで。
  • 61. だけどいい事もあったんだ
  • 62. PC開発でよかった点① 健やかなる時も 病める時も進捗を把握
  • 63. PC開発でよかった点① 健やかなる時も 病める時も進捗を把握 なんだかんだで 状況を全員が把握出来てた
  • 64. PC開発でよかった点② あれちょうだい! はい、これもちょうだい!
  • 65. PC開発でよかった点② あれちょうだい! はい、これもちょうだい! 随時テスト出来る状態にして とにかくテストテスト!
  • 66. PC開発でよかった点③ せっかくなんで ご一緒しませんか?
  • 67. PC開発でよかった点③ せっかくなんで ご一緒しませんか? スプリントレビューに SEO関連部署の方もご招待
  • 68. PC開発でよかった点④ 予定していたよりも 早く完了できましたが何か?
  • 69. PC開発でよかった点④ 予定していたよりも 早く完了できましたが何か? 差し込み対応とかもあったけど チーム力の向上もあって前倒し
  • 70. PC開発でよかった点⑤ 振り返ると楽しかった あの日々
  • 71. PC開発でよかった点⑤ 振り返ると楽しかった あの日々 なんかうるさいとかとも言われたけど 楽しく実りのある開発だった
  • 72. インセプションデッキ
  • 73. プロジェクトの全体像を 端的に伝えるための ドキュメント ※アジャイルサムライを読んでみてください
  • 74. 1.我々は何故ここにいるのか 2.エレベーターピッチを作る 3.パッケージデザインを作る 4.やらないことリストを作る 5.ご近所さんを探せ 6.解決案を描く 7.夜も眠れなくなる問題はなんだろう 8.期間を見極める 9.何を諦めるかをはっきりさせる 10.何がどれだけ必要なのか 10個の手強い質問
  • 75. エレベーターピッチテンプレート • [潜在的なニーズを満たしたり、抱えている課題 を解決したり]をしたい • [対象顧客]向けの • [プロダクト名]というプロダクトは • [プロダクトのカテゴリー]である。 • これは[重要な利点、購入への説得力ある理由] があり、 • [競合サービス名]と違って • 我々のプロジェクトは[差別化の決定的な特徴] が備わっている。
  • 76. エレベーターピッチ例:Gunosyの場合 • [自分の知りたい情報を定期的に収集]したい • [ビジネスパーソン]向けの • [Gunosy]というプロダクトは • [キュレーションサービス]である。 • これは[簡単な設定での使用や、アプリで手軽に アクセス]することができ、 • [Yahooニュース]と違って • 我々のプロジェクトは[常に自分の興味のある分 野の情報を受動的に手に入れられる気軽さ]が備 わっている。
  • 77. 参考書籍
  • 78. Nippori Agile sprint 0 参考書籍 アジャイルサムライ http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06856-0 SCRUM BOOT CAMP THE BOOK http://www.seshop.com/product/detail/15395/ リーン開発の現場 http://lean-trenches.com/
  • 79. 最後に
  • 80. アジャイルにやろう Being Agile
  • 81. ご清聴ありがとうございました
  • 82. 質問タイム
  • 83. Nippori Agile sprint0 ~fin~