じ～んわりスクラムプラクティス導入

（仮）発表資料

Transcript

1. じ～んわり スクラム プラクティス 導入
2. 自己紹介 藤田 佳樹 FUJITA Yoshiki 社会人3年目 認定スクラムマスター 趣味：バイク(予定), VTuber, ボードゲーム Twitter @yfujita0929
3. 触ってきた技術 フロントエンド： JavaScript, Node.js,React Redux, React Native バックエンド： SpringBoot, GoLang 興味のあること： GCP, Kubernetes, Cloud Native, BlockChain
4. 最近やっていたこと • Bitcoin関連のアプリケーション開発 • React Redux, GoLang • Bitcoinを利用するライブラリ開発 • C++ • 将来的にはOSSでの公開を目指している
5. 最近やっていたこと • Bitcoin関連のアプリケーション開発 • React Redux, GoLang • Bitcoinを利用するライブラリ開発 • C++ • 将来的にはOSSでの公開を目指している
6. アジェンダ 1. スクラムとは 2. 取り入れたスクラムプロセス 3. まとめ
7. 大前提
8. 本Talkでは、 正しい“スクラム” の導入方法 を伝えるわけではない
9. “スクラム” を導入しようと こんな プラクティス をやっているよ(があるよ) を伝える
10. 正しい “スクラム” が知りたければ
11. 正しい “スクラム” が知りたければ
12. スクラムガイド スクラム開発者である Ken Schwaber と Jeff Sutherland によって記載された スクラムプロセスを定義したガイド スクラムの価値基準やロール、それぞれのイ ベントといった定義が記述されている スクラムを始める際にはぜひ読むべきガイド
13. スクラム概論 - fintan • スクラムの概念や考え方をわかりやすくまとめてある資料 • スクラムを始める際の導入段階で、この資料を利用することで共通概念のもと スクラムを開始することを目指します
14. アジェンダ 1. スクラムとは 2. 取り入れたスクラムプロセス 3. まとめ
15. スクラムとは
16. 複雑で変化の激しい問題に 対応するための フレームワークであり、 可能な限り価値の高いプロダクトを 生産的かつ創造的に 届けるためのものである。[1] [1] Ken Schwaber and Jeff Sutherland, The Scrum Guide Japanese Version https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf より引用
17. 複雑に劇的に変化する ビジネス要件に 素早く対応することで 顧客に価値を届け続ける
18. さあ スクラムを始めよう！
19. そんなに簡単ではない
20. いろんな壁がある ヒューマンスキル 組織的問題 ビジネス難易度
21. １つづつ超えていく
22. アジェンダ 1. スクラムとは 2. 取り入れたスクラムプロセス 3. まとめ
23. ヒューマンスキル
24. ヒューマンスキルの問題 • スクラムへの不慣れ • 不可発なコミュニケーション • メンバー間能力差
25. プラクティス • 開発チームによる”スプリント計画” • Whatを明確化 • なぜ優先度が高いのかをチームで検討 • タスク遂行の問題点はPOへ共有 → タスクやストーリーをチームのモノに オーナーシップの醸成
26. プラクティス • プランニングポーカー • Howを共有 • ストーリーの実現方法をメンバーで共有 • 知識の分散 → 負債化を防ぎつつ、タスク遂行の 悩みを共有
27. プラクティス • レトロスペクティブの実施 • Problemを共有 • ひとりの問題をチームの問題に → 困った時には誰かが助けてくれる 安心感 チーム内の信頼関係の構築
28. プラクティス • 分報チャンネル • 文面コミュニケーションの活発化 • 簡素（曖昧）な設計図の作成 • どう作るかを考えて、コミュニケーション機会を 増加 • タスクローテーション • 属人化の排除の第一歩
29. ビジネス難易度
30. ビジネス難易度の問題 • 実現方法がわからない • どこまで実施するかが不明確
31. プラクティス • スパイク・ストーリーを作成 • 実現方法の調査をストーリーとして管理 • 事前調査として、何をするかを明確化 → 業務ドメイン等を発見 開発チーム内の業務知識の獲得 業務知識の共有
32. プラクティス • 確認観点をテストとして作成 • TDDライクな開発を実施 • 作成する機能をチーム内でも明確化 • POともスプリント内の作成物を共有 → スプリントのゴールが明確になる POと成果物イメージを共有
33. 組織的問題
34. 組織的問題
35. 組織的問題 非常に解決が 難しい問題
36. 考えられるプラクティス • 全体レトロスペクティブ • 価値を届けるための課題点を洗い出す → 組織としての問題を明確化 得られる価値と失う価値を評価
37. アジェンダ 1. スクラムとは 2. 取り入れたスクラムプロセス 3. まとめ
38. 色々と プラクティスを 紹介しましたが
39. 全ての問題は解決しない
40. チーム毎に課題は変わる
41. チームの問題を把握
42. “じ～んわり”解決し続ける
43. 大切なことは
44. 改善し続ける意識
45. レスポンシビリティ
46. より良い開発ライフを！