1 of 25

Scrum実践4年。

『今』のスクラムチームの形・やり方

2 of 25

自己紹介

名前：茶屋　彰仁

お仕事：Webアプリケーション開発

趣味：娘とデートすること

　　　スプラトゥーン２

その他：アジャイル(スクラム)、AWS、VR/AR

​

3 of 25

アジャイル

4 of 25

5 of 25

アジャイルが広く知れ渡るきっかけになった

アジャイルソフトウェア開発宣言

​

6 of 25

実際に今やってます

今、Sprint85

7 of 25

8 of 25

開発

PO

9 of 25

色々と課題があり

常に試行錯誤した

10 of 25

朝会がすんごく長い

11 of 25

朝会がすんごく長い

課題をコードレベルで話しだす

誰が何やろうってモヤモヤ

レビューなどの

調整

設計しだしちゃう

12 of 25

朝会がすんごく長い

課題をコードレベルで話しだす

誰が何やろうってモヤモヤ

レビューなどの

調整

設計しだしちゃう

  • 朝会でやることを再度チーム内で共有
    • 昨日やったこと
    • 今日やること
    • 阻害要因
  • 話が長くなるネタは2次会の場を作る

13 of 25

レビューが多い

14 of 25

レビューが多い

  • 対面じゃなく、Gitのプルリク内容をレビューする
    • 誰がレビューするのか曖昧になった
    • レビューする人が実装ノッてるのに中断しないといけなくなった
  • ペアワークすることでレビューを無くした
    • 品質の低下もなかった
    • 開発速度が上がった
    • 知識の共有が即時できるようになった
    • スキル差を手っ取り早く解消
    • 新規参入者が早くチームになじめた
  • チーム内で有識者がいないような新規技術についてはモブワークする
    • つまづきポイントの早期解消
    • 知識の共有が即時できるようになった

レビューのやり方を変えてみた

15 of 25

設計書の作成に

Sprintの半分割かれる

16 of 25

設計書の作成にSprintの半分割かれる

  • Sprint期間を2週間から1か月に伸ばしてみた
  • 画面設計要らない。動いているものが正しいものである。
  • クラス図・シーケンス図も要らない。ソースコードを読みやすくすればいい。
  • テスト仕様書も要らない。箇条書きレベルで確認ポイントがあればいい。
    • ただし、バックログが十分に小さくなっていることが前提
    • テストコードがかけるものはテストコードを書く

​

設計書を捨てた

17 of 25

テスト工数がかさむ

18 of 25

テスト工数がかさむ

  • 基本的にWebAPIなどのテストは自動化
    • Gitのプルリクトリガーで自動的にすべてのテストを実行してくれる
    • 開発時はまずテストコードから書き始める
  • 画面のUIテストもなるべく自動化する
    • SilkTestというツールを使ってみた
      • 多機種・多ブラウザをカバーしている
      • メンテナンス性が悪い
    • 本当に必要最小限の範囲のテストしかしない
    • テスト対象機種・ブラウザを半期ごとに見直してPOと整合を取る

​

やり方・範囲を見直した

19 of 25

Sprint中でやることが変わる

20 of 25

Sprint中でやることが変わる

  • バックログがSprint中に差し込まれるのは認めない
    • ほんの数日前までは重要じゃなかったものなはず、少しくらい待てるはず
  • 次のSprintに回すようにPOと調整する
    • MAXでも2週間後から着手すればいい
  • 理由を聞いてみる
    • ビジネス上、緊急度があるのかもしれない
  • どうしても差し込むときはトレードオフ
    • 差し込むからには、できなくなるものが出る

基本的に認めない

21 of 25

自己組織化って

なかなか難しい

22 of 25

自己組織化ってなかなか難しい

  • 目的解決のための最適な方法/プロセスを選べるように毎日1時間個人で学習できる時間を確保
  • チームとして技術情報を頻繁に共有することを意識づける
  • 改善意識を強く持つようにする
    • 振り返りのProblemとTryが紐づくようにして、すぐにできることはすぐにやる(実施して成功したという体験を何度も経験することが大事)
  • 3年、5年後のビジョンをしっかりと把握する
    • 開発チームからもPOに対して積極的に質問・語りかけをしていく
    • POと開発区の物理的な距離を無くして(出張して)、戦略の集中検討をする
  • 従来のやり方を変えるということを恐れずに「やってみる」
    • 心理的な安全性が高いチーム作りをしておくことも重要

23 of 25

何故か毎Sprint

バーンダウンしない

24 of 25

何故か毎Sprintバーンダウンしない

  • スプリントバックログをとても細かくする
    • バックログの内容が実装の内容レベルまでイメージわくくらい細かくすることで、見積もりの精度を上げる
  • 完了の定義を曖昧にしない
    • 作るものが明確になってないものは着手しない
    • 曖昧なものを明確にするのはおもったよりも時間がかかる
  • バックログの見積もりの指標を一旦リセットする
    • 見積もりの精度を上げるために、あえて今までの指標を捨ててみる
  • スプリントの長さを2週間から1か月にかえてみた
    • リリースまで2週間で終わらないなら期間を変えてみる
  • スクラムの達成度は50%くらいと言われているので、気にしすぎない

ホント、いろいろ試す

25 of 25

スクラムは理解は容易だが、習得は困難だと言われています。

なので、皆さん情報共有(ディスカッション)をたくさんしましょう。