Download to read offline
Uploaded byOtsuka Reina
PPTX, PDF1,306 views
はじめてのアジャイルのその後 ーシン・サービス立ち上げ、スクラムぽくなってきたー
2017/04/13 Agile Japan 2017 講演資料
Recommended
はじめてのアジャイルのその後 ーシン・サービス立ち上げ、スクラムぽくなってきたー
- 1.はじめてのアジャイルのその後ーシン・サービス立ち上げ、スクラムぽくなってきたーApr/13/2017 at AgileJapan 2017Reina OtsukaNew Service Development Supervisory Department,Rakuten, Inc.https://agriculture.rakuten.co.jp/
- 2.
- 3.3大塚 怜奈Otsuka Reina楽天株式会社 2010年に新卒で入社 Webアプリケーションエンジニア チームコンダクター プロダクトオーナーはじめました
- 4.Background2010. Arp.2016. May.Rakuten入社-0からのソフトウェア開発2013. Mar. キレイドナビリリース- はじめての0から立ち上げ2015. May. エンジニアリーダー- 9人チームのリーダーに2016. Apr. RaCareリリース-リーダーとして立ち上げ新サービスカンパニーに異動-新たなチーム構築2017. Mar. Ragri リリース-新たなチームでサービスの立ち上げ
- 5.Background2010. Arp.2016. May.Rakuten入社-0からのソフトウェア開発2013. Mar. キレイドナビリリース- はじめての0から立ち上げ2015. May. エンジニアリーダー- 9人チームのリーダーに2016. Apr. RaCareリリース-リーダーとして立ち上げ新サービスカンパニーに異動-新たなチーム構築2017. Mar. Ragri リリース-新たなチームでサービスの立ち上げWellness And HealthcareTeamRagri Team
- 6.Background2010. Arp.2016. May.Rakuten入社-0からのソフトウェア開発2013. Mar. キレイドナビリリース- はじめての0から立ち上げ2015. May. エンジニアリーダー- 9人チームのリーダーに2016. Apr. RaCareリリース-リーダーとして立ち上げ新サービスカンパニーに異動-新たなチーム構築2017. Mar. Ragri リリース-新たなチームでサービスの立ち上げWellness And HealthcareTeam
- 7.Wellness And HealthcareTeam7男性女性20代30代40代新卒中途未婚既婚PartnerProper前衛的 保守的EngineerProduct OwnerProject Leader卒業新加入
- 8.8Wellness And HealthcareTeam• アジャイルの手法を使って、ちょっとだけチームが改善された強いチームをつくる
- 9.Story of WellnessAnd Healthcare Team9https://www.slideshare.net/leinaotsuka/agile-in-2016• アジャイル何それ？のチーム• 改善• Morning Stand Up MTG• Kanban• KPT• Scrumへの挑戦• 改善を楽しめるチームへ
- 10.Today’s story2010. Arp.2016.May.Rakuten入社- 0からのソフトウェア開発2013. Mar. キレイドナビリリース- はじめての0から立ち上げ2015. May. エンジニアリーダー- 9人チームのリーダーに2016. Apr. RaCareリリース-リーダーとして立ち上げ新サービスカンパニーに異動-新たなチーム構築2017. Mar. Ragri リリース-新たなチームでサービスの立ち上げRagri Team
- 11.
- 12.Today’s Story12迫る現実手探りベンダー開発新しいチーム新しいビジネス0からの立ち上げリモートでのコミュニケーションリリース直前のどんでん返しFace toface の大切さ開発プロセス大改造ベンダーとsprintをまわしていく
- 13.
- 14.
- 15.Attention15• アジャイル, アジャイルな話ではありません•特効薬の話ではありません• アジャイルの手法を使って、改善された一例です
- 16.Team16Business OwnerFarmersBusiness UnitDevelopmentUnitUX & Design UnitME
- 17.Ragri Story172016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始QA & Security Audit
- 18.Ragri Story182016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始QA & Security Auditリーンに開発したいな！
- 19.Ragri Story192016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始QA & Security Audit要件定義
- 20.Ragri Story202016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始QA & Security Auditえ、機能が盛り盛り
- 21.Ragri Story212016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始QA & Security Audit開発対象機能一覧の合意
- 22.Ragri Story222016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始人がいない！ベンダー策定QA & Security Audit
- 23.Ragri Story232016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始仕様書/WF/デザインのレビューQA & Security Audit
- 24.Ragri Story242016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始 開発スタートQA & Security Audit
- 25.Ragri Story252016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep. 開発メンバーどんどん増える2016. Oct.Ragri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始あれ、ウォーターフォールっぽいQA & Security Audit
- 26.Ragri Story262016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep.2016. Oct.QA & Security AuditRagri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始メンバーどんどん増える開発メンバーどんどん増える
- 27.Team27Business OwnerFarmersBusiness UnitDevelopmentUnitUX & Design UnitME
- 28.Ragri Story282016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep.2016. Oct.QA & Security AuditRagri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始内部テスト開始開発メンバーどんどん増える
- 29.Ragri Story292016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep.2016. Oct.QA & Security AuditRagri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始リリースまでもう少し！開発メンバーどんどん増える
- 30.Ragri Story302016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep.2016. Oct.QA & Security AuditRagri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始やっとこ社内リリース開発メンバーどんどん増える
- 31.Ragri Story312016. May.2016.Nov.Project Start2016. July. 仕様策定&設計開始2016. Sep.2016. Oct.QA & Security AuditRagri 社内リリース2016. Dec. Ragri 社外リリース延期！2017. Jan. Ragri 社内フルリリース2016. Aug. 開発開始延期！！！開発メンバーどんどん増える
- 32.
- 33.Retrospective33• 参加者• BusinessOwner• Business Unit• UX & Design Unit• Development Unit• 目的• Project Startからいままでの振り返り• 今後のプロセス改善を検討
- 34.Retrospective34• Business Owner/Business Unit / UX &Design Unit /Development Unit それぞれの視点で振り返り
- 35.Business Owner’s wants35•ほしかった機能がない• 実物を触ってみないとわからない• もっと開発スピードをあげたい
- 36.
- 37.
- 38.
- 39.Business Owner’s wants39•ほしかった機能がない• 実物を触ってみないとわからない• もっと開発スピードをあげたい• 次月に開発するものの優先度を一緒に決める• Demo日を決めて、一緒に確認する• 2週間のSprintで進めて、リリースできるものからリリースする
- 40.Team40Business OwnerFarmersBusiness UnitDevelopmentUnitUX & Design UnitME
- 41.
- 42.3 Steps forchanging421. Business Unit / UX & Design Unit /Development Unit でアジャイル講習2. 開発チームみんなでスクラムワークショップ3. プロセス大改造プラン
- 43.3 Steps forchanging431. Business Unit / UX & Design Unit /Development Unit でアジャイル講習2. 開発チームみんなでスクラムワークショップ3. プロセス大改造プラン
- 44.Step 1 :Small Lecture of Agile44https://www.slideshare.net/kawaguti/jikkan-kudo• 参加者• Business Owner• Business Unit• UX & Design Unit• Development Unit• 目的• アジャイルとは何かの共通認識をもつ• 今後のプロセス改善を導入する
- 45.Step 1 :Small Lecture of Agile45https://www.slideshare.net/kawaguti/jikkan-kudo
- 46.Step 1 :Small Lecture of Agile46https://www.slideshare.net/kawaguti/jikkan-kudohttps://speakerdeck.com/kawaguti/jikkan-kudo要件は小さく砕く分類する優先度決める
- 47.47Business OwnerBusiness UnitDevelopmentUnitUX & Design UnitME開発の進め方が、実感をもって理解できた！この進め方を試したい！開発について、ちょっと理解できたアジャイルについて、イメージができた！Step 1 : Small Lecture of Agile
- 48.3 Steps forchanging481. Business Unit / UX & Design Unit /Development Unit でアジャイル講習2. 開発チームみんなでスクラムワークショップ3. プロセス大改造プラン
- 49.49Development UnitMEStep 2: Scrum workshop with members• 参加者• Project Leader• Product Owner• Developer• Tester• 目的• スクラムプロセスを実感してもらう• 実施内容• レゴを使ったスクラムシュミレーションワークショップ
- 50.Step 2 :Scrum workshop with members50PlanningSprintRetrospectiveのスクラムを実感• ストーリーポイントでの見積もり• ROIに基づいた優先順位決め• DONEの定義
- 51.51Step 2 :Scrum workshop with members• チームで進めることを実感できた• 実績に基づいての見積もり方法がわかった• 優先順位の高いものからタスクを行っていくことの重要性を理解できた• Retrospectiveを行うことで改善されることを体験できた
- 52.3 Steps forchanging521. Business Unit / UX & Design Unit /Development Unit でアジャイル講習2. 開発チームみんなでスクラムワークショップ3. プロセス大改造プラン
- 53.Step 3 :Changing planning way53• プロダクトバックログとして、要件をカードに書く• カードに書ける大きさの要件に砕く• 定常作業もカードに書き出すチケット番号チケット内容
- 54.54Step 3 :Changing planning way• リアルを使って、要件をビジネスオーナーと合意する
- 55.Step 3 :Changing planning way55• ストーリーポイントで見積もる
- 56.Step 3 :Changing planning way56• 1ヶ月に開発チームが消化できそうなストーリーポイントを決める• ビジネスオーナーと一緒に、優先順位を決める• 2ヶ月分のタスクの優先順位を決めておく• リリース作業等の定常作業分も見積もる
- 57.Step 3 :Changing planning way57• ボードに並べて、Sprintの準備OK
- 58.
- 59.2017 FebruaryMon TueWed Thu Fri Sat Sun1 2 3 4 56 7 8 9 10 11 1213 14 15 16 17 18 1920 21 22 23 24 25 2627 28 1 259ReleaseReleaseDEMOKPT
- 60.Sprint way601. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 61.Sprint way611. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 62.Morning Stand UpMTG62それぞれの• 昨日やったこと• 今日やること• 困っていること
- 63.Morning Stand UpMTG63それぞれの• 昨日やったこと• 今日やること• 困っていること毎日進捗確認ゴールの設定リスクの共有
- 64.Morning Stand UpMTG64• タスクを共有することでチーム全体の進捗をメンバーが意識するようになった• リスクのキャッチアップがはやくなった
- 65.Sprint way651. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.Sprint way731. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 74.DEMO74• 画面遷移を見える化• Wireframeを実機で確認•実際に動きを見ながら確認
- 75.DEMO75• 仕様に関する認識違いが減った• 仕様の合意を取りやすくなった•プロダクトの全体や遷移を把握しやすくなった
- 76.Sprint way761. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 77.
- 78.
- 79.KPT79February MarchTotal1st 2nd1st 2ndKeep - 23 23Problem - 34 34Try - 4 4
- 80.Look back February80•開発チームの進捗が見える化された• チーム全体で進めている感がでてきた• 柔軟にタスクの入れ替えができるようになった• 認識違いが減った
- 81.
- 82.2017 MarchMon TueWed Thu Fri Sat Sun1 2 3 4 56 7 8 9 10 11 1213 14 15 16 17 18 1920 21 22 23 24 25 2627 28 29 28 30 3182ReleaseRelease DEMOKPTKPT
- 83.Sprint way831. MorningStand Up MTG2. Kanban3. DEMO4. KPT
- 84.Morning Stand UpMTG84それぞれの• 昨日やったこと• 今日やること• 困っていること毎日進捗確認ゴールの設定リスクの共有
- 85.
- 86.
- 87.KPT87February MarchTotal1st 2nd1st 2ndKeep - 23 25 24 72Problem - 34 24 27 85Try - 4 4 3 1111歩前進できた！
- 88.Look back March88•チーム全体で進めている感がでてきた• 認識違いが減った• 柔軟にタスクの入れ替えができるようになった• 突発に対応できるようになった• システム改善の時間が確保できるようになった
- 89.
- 90.Look back90 Ragriチームの一体感がでてきた認識のずれが減ってきた 柔軟にタスクの対応ができるようになった 対応できるストーリーポイントが増えた 月2回の計画リリースができた
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 97.
Editor's Notes
- #2 15 sec / slideはじめてのアジャイルのその後新サービス立ち上げ、スクラムぽくなってきたというタイトルで、楽天株式会社、新サービスカンパニーの大塚 が発表させていただきます。
- #3 まずは、自己紹介です
- #4 大塚怜奈と申します。楽天株式会社に2010年に新卒で入社しました。WEBアプリケーションエンジニアとして従事してまして。最近は、チームコンダクターとプロダクトオーナーの役割をやっております。
- #5 経歴を紹介させていただくと、楽天において、いくつかの新サービスの立ち上げに携わってきたした。2013年にキレイドナビというサービスの立ち上げに、いちWEBアプリケーションエンジニアとして携わりました。その後、そのチームのエンジニアリーダーをやらせていただき、そのチームで、新たなサービス、RaCareの立ち上げを行いました。そして、去年、新サービスカンパニーにひとり移動し、0からのチーム構築を行いながら、Ragriのサービス立ち上げを行いました。
- #6 経歴を大きく分けると、2つに分けられまして、キレイドナビとRaCareのリリースは、wellness and healthcare teamとして、Ragriの立ち上げは、新しいRagriチームで行いました。
- #7 Wellness and healthcare teamでは、
- #8 20代、30代、40代、パートナー、プロパーと様々なバックグラウンドと持って、それぞれの仕事に対する姿勢も違うチームにおいて、
- #9 強いチーム作るべく、アジャイルの手法を使って改善を行いました
- #10 改善の過程は、はじめてのまいあじゃいるというスライドで公開しているので、ご興味ある方は、こちらを見ていただけると幸いです。
- #11 本日の話は、その後の、新しい部署に移動し、0から構築したラグリチームでのお話になります。
- #12 ここで、ラグリとはなんぞやという話なのですが、つい先日の4月5日にラグリをオープンさせていただきました。みなさん、ぜひ、検索してみてください。
- #13 ラグリという新しいサービスをたちあげるにあたって、0からチームを構築し、ベンダーさんと開発を行いました。大きな特徴としては、ビジネスオアーナーは、社外にいることと、現在は、ベンダーさんと一緒にsprintまわすようになっております。
- #14 3min13:0315 sec /slideということで、きょうの話は、
- #15 ラグリを立ち上げるなかで、ウォーターフォール型からスクラムへ変革へしなやかなチームをつくるプロセスについてお話させていただきます
- #16 注意としては、アジャイルアジャヤいるな話ではありません特効薬の話ではありませんアジャイルの手法と使って、チームが改善された一例です
- #17 ラグリチーム、プロジェクトが始まったときにどんなチームかというと、ビジネスオーナーがいて、ビジネスサイドのメンバーがいて、UX デザインのメンバーがいて、開発のメンバーがいました。開発メンバーのうちの一人がわたしになります。人数もスライドのような人数でした。また、ラグリは、農家とユーザーをつなぐプラットフォームになります。そのため、利用者としての農家さんがいます。
- #18 ラグリがリリースされるまでにどういった流れかというと去年の5月にプロジェクトがはじまりました
- #19 立ち上げ当初は人数も数なく、ぜひ、リーンな開発にしたいなという意気込みを一人もっていました
- #20 要件定義のフェーズの段階になって、ビジネスオーナーやビジネスサイトのメンバーを話を詰めていくと
- #21 あれ、機能がモリモリ。
- #22 どの機能も必要とのこと。せめて、優先順位とリリースに必要なものは決めましょうと一覧を作って、合意をとりました。
- #23 よし！機能一覧の合意をとったらと思ったら、作り人がいない！ということで、ベンダー策定して、ベンダー開発なプロジェクトとなりました。
- #24 ベンダーが無事にきまって、仕様書/Wireframe/デザインを決め、ビジネスオーナーのレビューをもらって、
- #25 8月ころに開発スタート！
- #26 ふと、気づいたときには、リリースターゲットとリリース日がなぜか決まっていて、フローがウォーターフォールっぽい感じになっていると気づきました
- #27 開発が遅延するので、メンバーどんどん増え、
- #28 9月には、このような状況で、開発メンバーが最大30人超えるようになりました
- #29 紆余曲折しながらも、内部テストにこぎつけ
- #30 QAとセキュリティ監査を行い
- #31 一部機能を社内リリースすることができました
- #32 そして、12月に社外リリースを行う予定だったのですが、ここで大どんでん返し、上層部の判断で社外リリースが延期になりました
- #33 もう、こんな感じですよね。社外リリースに向けて必死に進めていたのに延期なんて。延期の理由としては、社外にいるビジネスオーナーが社外リリースに対して難色しめしたためでした。なんで、その判断になったのを確かめるために行ったのが、
- #34 このときこのプロジェクトとしてはじめて、ビジネスオーナーとビジネスメンバー、UXデザインメンバー開発メンバーでプロジェクト開始からそのときまでの振り返りを行いました
- #35 付箋でそれぞれのチーム視点での振り返りを共有し、
- #36 ビジネスオーナーとしての思いとして、わかったことが、まずは、ほしかった機能がなかった。プロジェクト始まりのときに、機能一覧と優先順位を決めて合意をとったつもりでいたのですが、本当につもりだっただけで、全く納得していなかったことがこのときにわかりました。みなさんにもありませんかね？こんな経験。そして、fireframe等で画面イメージは共有して合意をとったはずなのですが、いや、触ってみたら思っていたのと違った。また、社内リリースまで見れる機能が何もないって、なんでそんなにかかるんだ！ということでした
- #37 ビジネスオアーナーの合意がないとリリースはできない、はて、どうしよ。。。
- #38 そのとき、社内のアジャイルコーチにアドバイスをもとめました。
- #39 賢者曰く、スクラムを導入してみては？
- #40 ということで、ビジネスオーナー欲しかった機能がないということには、次月に開発するものの優先度を紙を使いながら一緒に決めることにしました。実物を触ってみないとわからないという要望に関しては、月に1回から2回のDemo日を決めて、ビジネスオーナーと一緒に確認しました。もと開発スピードあげたいということには、2週間のSprintで進めて、リリースレディなものからリリースすることとアドバイスをいただきました、なんかよさげな気がする！ということで、
- #41 ウォーターフォールになれたこのチームで
- #42 10min13:1015 sec / slideどうやって実現しようか
- #43 ということで、プロセス変更に向けて、3つのステップを踏みました。それぞれのステップで具体的に何をやったかをお話させていただきます
- #44 まず、開発チーム以外のチームメンバーにもアジャイル講習をうけてもらいました
- #45 チーム全体に、社内アジャイルコーチの川口さんにアジャイルとは何かの講義をしていただきました。アジャイルを導入するには、ビジネスオーナー、ビジネスメンバーの理解が必要だと考えたためです。これによって、アジャイルとは何かの共通認識をチームでもち、今後のプロセス改善の導入しやすい環境にしました。
- #46 話していただいた内容は、機能は大きく作らず、小さく作って、常に改善リリースすることのメリットについて。
- #47 そして、要件を小さくして、優先度をきめ、ビジネス的に価値のあることから作りましょうというアジャイルのシンプルで重要な話をしていただきました。
- #48 この講義によって、開発についてあまり知らないビジネスオーナーにも、開発フローについて理解していただき、ビジネスサイドにもこの進め方を試したいといった同意を得ることができました。
- #49 次に開発チームでのスクラムワークショップについてです。
- #50 ベンダーさんもふくむ開発チームみんなでスクラムのワークショップを実施しました目的としては、ウォーターフォール型になれたメンバーに、スラクムのプロセスを肌で実感してもらうことです。
- #51 ワークショップのなかで、プランニング/スプリント/振り返りのプロセスを実感していただき、ストーリーポイントでの見積もり、ROIに基づいた優先順位決め、DONEの定義をデベロッパー、テスターの方全員に体験していただきました。
- #52 これにより、リーダーの指示のもと個々人で進めていた雰囲気の開発チームが、チームで進めることを時間していただきましたまた、スプリントを行って、その実績に基づいた見積もり方法を理解していただきました優先順位の高い物からタスクを行っていくことの重要性を理解することができましたレトロスペクティブをおkなうことで改善されることを体験することができました
- #53 メンバーの準備とともに、プロセス大改造プランを行いました
- #54 エクセル等で管理していたタスクを1要件を1カードに書いて、見えることとリアルに話し合いのなかでも優先度を入れ替えることができるようにしました
- #55 また、画面に映し出したwireframeでは認識を合わせづらかった仕様については、画面を紙に印刷して遷移や仕様を同じ空間で書き込むことで合意を取りやすい環境にしました
- #56 その仕様に基づき、ストーリーポイントで規模を見積もり
- #57 1ヶ月間で消化できるストーリーポイントをもとに開発チームのタスクの優先順位をビジネスオーナーときめました。これによって、ほしかった機能がないといったことの認識の差を軽減させるようにしました。
- #58 タスクをボードにならべて、スプリントの準備OK
- #59 15 min13:15れっつ、スタートスプリントをいうことで、ここまでの準備を行い、初のスプリントをスタートさせました
- #60 2月のスケジュールはこのような形で。タスクは月単位で計画しつつ、リリースは月に2回に設置。ビジネスオーナーに実際に見せるDEMO日を設けて、KPTによる振り返りの時間をおきました
- #61 スプリント中に実際に行ったことは、この4つになります
- #62 まずは、Morning Stand Up MTGをはじめました
- #63 開発チームのメンバーがそれぞの昨日やったこと、きょうやること、こまっていることを共有することにより
- #64 メンバーの進捗を全体で把握し、その日のゴールを宣言して、何か困ってたら、すぐにキャッチアップできるようにしました
- #65 これによって、チーム全体の進捗をメンバーが意識して終わらせるという雰囲気になりました。また、リスクを共有する時間をつくることで、いままで最後に湧き出てきたリスクに対するキャッチアップがはやくなりました
- #66 次にKanbanです
- #67 このような看板を作成しました
- #68 1スプリント分のプロダクトバックログを配置して
- #69 10営業日分の日付を書き、タスクを実施する計画日にタスクを配置するようにしました。これで、スプリントちゅのプランニングがみえるようになります。
- #70 左には、各メンバーがおこなっている付箋を置き、だれが何に着手しているかを見える化
- #71 テストまで完了したらDONEにもって完了を確認
- #72 こによって、その日にタスクカードの付箋が残っていたら、プランニングから遅延していることがパッと見でわかるようになりました
- #73 Kanbanによって、チーム全員でタスクの消化に取り組む雰囲気ができたチーム外メンバーにも実施内容が見えるようになったタスクの入れ替えに対しての柔軟性がましました
- #74 次にDEMOについてです
- #75 さきほどのお話させていただいたのですが、画面を紙に印刷することによって、全体を把握しやくし、Prottといったプロトタイピングツールもテスト環境を駆使して、画面だけでなく、リアルの動きを見ながらビジネスオーナーを確認できるようにしました
- #76 DEMOによって、仕様に関する認識違いが減った仕様の合意を取りやすくなった全体や遷移を把握しやくなりました
- #77 次にKPTです
- #78 KPTは振り仮のためのフレームワークです。実施したことがあるかたはいらっしゃいますかね。よいこと、改善点をだして、チームで改善できるようになりますこれを実施するようになりました
- #79 初回のKPTの風景はこのようになりました。KPTを行うのが初めてのメンバーが多かったのですが、
- #80 23個のキープ、34のプロブレム、そこから4つのトライを作成しました
- #81 2月を振り返りと1ヶ月、スプリントを回すことによって、開発チームの進捗が見えるかされ、個々人ではなくチーム全体で進めている感がでてきましたまた、見えるかによって柔軟にタスクの入れ替えができるようになりましたそして、ビジネスオーナーや他チームメンバーとの認識違いが減りました
- #82 ストーリーポイントとしては、このような結果です。40のプランニングに他指定、62ポイントのストーリーポイントを消化できました
- #83 13:2020 sec / slideこの調子で、3月です。2月とどうように月単位でタスクをきめ、リリースは月２回実施しました。リリース後にはKPTを行い、月半ばにはビジネスオーナーとのフェイスツーフェイスのDEMO日をおきました。
- #84 やったことは2月と同様です。
- #85 Morning Stand Up MTGで進捗とリスクを確認。
- #86 ボードもKPTの結果、次のスプリント内容の見えるように改善。
- #87 画面遷移をリアルに見えるかして、実際に動かしてDEMOをおこないました。
- #88 KPTも、このようになり、2月、3月で、Keepは、72個。プロブレムは、85個。トライは11個作成され、チームとして11歩前進することができました。
- #89 3月を振り返るとよりチーム全体で進めている感がでてきて、認識違いもへりました。柔軟いタスクの入れ替えができるようになり、突発の対応もできるようになりました。それもやりつつもシステム改善の時間を確保できるようになりました。
- #90 3月の結果として、2月の実績のもとに60で計画していたのですが、82のストーリーポイント消化できるようになりました
- #91 2月、3月をまとめますとラグリチームでの一体がでてきました認識のずれも減ったきたように感じます柔軟にタスクの対応ができるようになりつつも結果として、対応できるストーリーポイントを増やすことができましたそして、月2回の計画リリースをいまも達成しています
- #92 2ヶ月間のスプリントで改善することできました
- #93 ウォーターフォール型からスクラムへしなやかなチームに近づくことができました
- #94 これから、
- #95 よりよりサービスを作るためにさらなる改善を進めていきます
- #96 最後にお知らせです
- #97 ラグリでは、一緒にラグリを作っていってくれる方を募集しております。ご興味あるかたはご連絡ください。
- #98 ご清聴、ありがとうございました！