スクラムエッセンス導入3ヶ月のチームに起きた変化
by
hacomono Inc.
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Last Update 2022.03.16 スクラムエッセンス導入3ヶ月のチームに起きた変化
Slide 2
Slide 2 text
簡単に自己紹介
Slide 3
Slide 3 text
◾ 所属 株式会社hacomono UX部 エンジニア ◾ すみか 大阪府 ◾ すき do / 進藤 渉
Slide 4
Slide 4 text
hacomono UXチームの事例を通じて、 スクラムエッセンスの導入とチームに 起きた変化を紹介します
Slide 5
Slide 5 text
スクラムエッセンス 導入前のお話
Slide 6
Slide 6 text
hacomono UXチーム ユーザの顕在・潜在ニーズを探求し続け、期待を超え るユーザ体験(価値)を生み出し、より早くユーザに 届けられるチーム 目指すチーム像
Slide 7
Slide 7 text
hacomono UXチーム PdM デザイナー 開発エンジニア QAエンジニア
Slide 8
Slide 8 text
課題感 これまでは職能ごとに開発をバトンタッチしていた (いわゆるウォーターフォールに近い形) PRD (プロダクト要求仕様書) デザイン プログラム テスト
Slide 9
Slide 9 text
課題感 プログラミング中に仕様やデザインが実現できないと発覚 デザイン プログラム テスト 手戻り! PRD (プロダクト要求仕様書)
Slide 10
Slide 10 text
課題感 テスト中にクリティカルな問題を発見 PRD (プロダクト要求仕様書) デザイン プログラム テスト 手戻り!
Slide 11
Slide 11 text
課題感 前工程の遅延がテストフェーズへの負債になりがち PRD (プロダクト要求仕様書) デザイン プログラム テスト PRD (プロダクト要求仕様書) デザイン プログラム テ ス ト 理想 現実
Slide 12
Slide 12 text
課題感 チーム全体の 機能理解が浅い? コミュニケーション が不足している? 後ろの工程になるほど リスクが大きいな・・ 全般的にシフトレフト できないかな? (特にテスト)
Slide 13
Slide 13 text
・・・と、前置きはここまで。 このような課題感を踏まえて、hacomono UXチームが 取り組んだことを紹介していきます!
Slide 14
Slide 14 text
取り組んだこと / チームに起きた変化
Slide 15
Slide 15 text
小さく作って、小さくテスト その1
Slide 16
Slide 16 text
これまで デザイン全部オワタ 実装ヨロシク! 実装全部オワタ テストヨロシク!
Slide 17
Slide 17 text
こうした デザイン一部オワタ 次の機能に取り掛かるね! 実装オワタ テストヨロシク!
Slide 18
Slide 18 text
● 開発全体の見通しが良くなった (透明性が上がった) ● 開発の進捗が追いやすくなり、デザイン修正の タイミングを測りやすくなった
Slide 19
Slide 19 text
● 実装で考えることがシンプルになった ● レビューもやりやすい ● テストがシンプルになった ● テストのシフトレフトを実現したことで、 無理のない稼働で安定した品質を確保できた
Slide 20
Slide 20 text
PRDとデザインを全員でレビューし 受け入れ条件を全員で考える その2
Slide 21
Slide 21 text
ホバーした時の 挙動どうなる? パフォーマンス みた方が良さそ う リストの並び順 は? スマフォでの 見え方は? ここで解決した いユーザーの課 題は? こういう見せ方 にすると分かり やすいかも この条件はどう なってる? 本当にファース トリリースで対 応すべき? etc...
Slide 22
Slide 22 text
● 未検討や未伝達の仕様を洗い出せた ● 意見交換が活発になり、どんな発言でも受け入れられる 土台ができた ● 細かいデザインや挙動を全員で議論したことによって、 より洗練された
Slide 23
Slide 23 text
● やるべきことが明確になり、実装中に仕様を聞き回るこ とが減った(集中できた) ● 不具合が減った ● QAエンジニアだけでは気づき辛いようなテスト観点も 洗い出された ● 役割を越えてQAエンジニア以外もテストに関心を持つ ようになり、チーム全体の品質意識が向上した
Slide 24
Slide 24 text
プレQA その3
Slide 25
Slide 25 text
● チーム全体で実動作や仕様について共通認識を作れた ● 動くものをベースに議論することで、解像度高く フィードバックサイクルを回せた
Slide 26
Slide 26 text
今のやり方を疑い、柔軟に変更する その4
Slide 27
Slide 27 text
全体進捗が見え 辛くなってきた からタスク管理 手法変えない? 会議体見直し て、作業時間増 やしたい 最初の方の実装 はペアプロしな い? デイリーの「昨 日やったこと」 本当に必要? デザインプロセ ス見直したい QAでモブテスト やらない? Working Agreement 作らない? タスクは1日で終 わる粒度で細分 化しては? etc...
Slide 28
Slide 28 text
● スクラムエッセンスを取り入れた当初と比べて、 格段に開発チームとして成長した ○ コミュニケーションの質の向上 ○ 開発プロセスの最適化 ○ フロー効率の向上 ● 変更したらそれで終わりではなく、 定期的に見直して更なる改善サイクルを回せている
Slide 29
Slide 29 text
まとめ
Slide 30
Slide 30 text
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
Slide 31
Slide 31 text
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
Slide 32
Slide 32 text
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
Slide 33
Slide 33 text
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
Slide 34
Slide 34 text
小さく作って、小さくテスト PRDとデザインを全員でレビューし、 受け入れ条件を全員で考える プレQA 今のやり方を疑い、柔軟に変更する 手戻りリスクの低減 品質向上 開発プロセス 開発体験の向上 共通認識の醸成
Slide 35
Slide 35 text
ユーザの顕在・潜在ニーズを探求し続け、期待を超え るユーザ体験(価値)を生み出し、より早くユーザに 届けられるチーム UXチームの 目指すチーム像 これまでの取り組みで、ある程度の余白が生まれた 今後はこの余白で価値に向き合い、それをより早くリ リースすることに取り組んでいきたい