Bizreachの事例
- 坂本龍太さん
- Bizreach
所属するスクラムチーム
- POはチーム外
- スクラムマスター兼チームリーダー兼エンジニア
- 全チームの大きなPB
- 各チームのPB
スクラムやってみて
- 見積もり
- FW知識不足
- 社内関係者調整
- POやステークホールダーと建設的な議論ができない
- 仕様が大きく変わる
- 実装中に判断することが多い
- 中長期的な方針が見えない
- 2習慣先のタスクが見えない
- 作業の属人化
- タスクがINVEST出なかった
- 会議体だ整理されていない
- 進捗どうですか?をやりたくない
課題の解決
- PR通るまでの時間で見積もる
- 仕様がFIXしておらずチケットの範囲が決まらない
- 早く帰れるロジックを作る
- 5h分のタスクを終わらせたら帰れる
- 妨害作業
- よくある作業を洗い出す
- 新FW学習コスト
- 疑問点を地道に集めて皆で解決
- TRYが実行されない
- チケットの物理と論理
- 物理を廃止
最近の話
- 自チームのしごとをする時間がない
- 今日誰が何をやるのかフォーカス
- 今日分だけのかんばん
- とにかくテストが辛い
- 急成長中で自動化難しい
- 人力楽しくないバグ発見できない
- モブテスティング
- バグの発見率向上
- 割れ窓理論
- 細かいバグとかのこと
- 積もってくると手をつけられない
- 一気にまとめて対処
自己組織的なチーム
- 最善策を自分たちで選択できるチーム
- アプリケーション定義ステートメント
Timersの事例
- 椎名アマドさん(Timers)
Timers
- モバイルアプリ
- Pairy
- Famm
- 古き良きを新しく
- 全部スクラム
- 1-2週のスプリント
1年目
- ただひたすら作る
2年目
- 開発プロセスを入れる
- 途中の成果物が見えない
- 仕様が変わる
- ゴールが見えない
転換期
スクラム導入
- 本で勉強
- 他のチームにやりたいと思わせる
今
- 1-2週のスプリント
- 短いほどいい
- INVEST
- 受け入れ条件は明確に
- プランニングポーカー
- SCRUN TIMEアプリ
- デイリースクラム
- 昨日やったこと
- 今日やること
- 詰まってること
- だけが理想だけど議論が始まってしまう
- burn "up" chart
- sprint review
- チーム外の人も混ぜて
- feedbackを色んな人にもらう
未来(解決したい課題)
- doneの定義が甘い
- 手戻りへの抵抗
- 今後作り直すかもと思うと作れない
- 先なんて見えない
- チームでなくプロジェクト単位でスクラムを考えている
- チームとしてのノウハウが蓄積されない
- チームを固定化
- 専任のSMを置けない
- モバイルアプリ
- shipの単位が大きくなる
- 巨大なPR
- サーバとネイティブの連携
スクラム根付かせるには
- まずはお作法を守って
- スクラムの意識は薄れている
- 社内にSM、啓蒙者を増やす