📖

学び始めてから一年でのスクラムを諸々振り返りたい

2023/12/12に公開

概要

スクラムを学び始めてから一年ほど経ったので、スクラムを一度見直す。

経緯

開発体制とかにもともと興味があったのと、縁あってスクラム研修を受けて認定スクラムマスタの資格を取ってから一年間経ったので振り返りたい。

https://zenn.dev/activecore/articles/d4873672015f23

スクラムの定義

自分の記事を振り返ってみると肝心のスクラムの定義等が記載されていなかったのでまずは定義から。
スクラム
複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級開発フレームワーク。

10人以下のチーム体制で動く成果物を出し続けて、改善を高速に回していくための体制。

チーム内にて複数の役割を分けて、特定のイベントを繰り返していく。

  • 開発者
    • 利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
  • プロダクトオーナー
    • スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。
  • スクラムマスター
    • スクラムガイドで定義されたスクラムを確立させることの結果に責任を持つ。

スクラムイベントとしては以下が定義されている。

  • スプリント
    • 一貫性を保つための、一か月以内の決まった長さの期間。プロダクトゴールを達成するためのすべての必要な作業はスプリント内で行われる。
  • スプリントプランニング
    • スプリントの始まりで行われるスプリント単位で実行する作業の計画。計画はスクラムチーム全体の共同作業によって作成される。
  • デイリースクラム
    • 計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させるための日次MTG
  • スプリントレビュー
    • スプリントの成果を検査し、今後の適応を決定するためのMTG。スクラムチームとステークホルダー全体に対して、スプリントで何が達成され、自分たちの環境で何が変化したかについてレビューする機会。
  • スプリントレトロスペクティブ
    • 品質と効果を高める方法を計画するために、チーム内で、個人、相互作用、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する機会。

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

スクラム行ったもろもろとか

csチームにスクラムを導入する

自分がスクラム研修を受けた際などはスクラムが社内で広まっているというわけではなく、
スクラムをサポートチームに取り入れてみようという試みから始まりました。
新卒一年目サポート未経験からスクラム導入は諸々ありましたが良い経験になりました。

詳細はこちらまで
https://zenn.dev/activecore/articles/c70b2277cfa4e9

https://zenn.dev/johndoe/articles/05193162767716

https://zenn.dev/johndoe/articles/d1e6f564cb2ef8

開発チームのスクラムマスター(12,3人)

サポートチームでのスクラムマスタ―の後に、他の経験をしてその後に開発チームのスクラムマスタ―を一時期行っていました。

ただ完全にど壺にはまっている時期のスクラム体制に入ったのもあり、開発チームでスクラムを行えるとなったらなったで問題が生じました。

https://zenn.dev/johndoe/articles/56c6cc05edad54

ミニマムな開発チームの管理(3, 4人)

現在は開発チーム全体を小分けにしたミニマムな開発チームおいて、明確な定義はしていないが、管理などを行っている。
明確なスクラム体制としては運用していないが、プランニングやレトロチックなMTG, デイリースクラムなどは都度行っている。

学んだもろもろとか

大人数でのスクラムは機能しない

スクラムガイドにも書いてあるし、そうっちゃそうなんですが、その時の流れや体制から往々にして常識ではない状態が続いてしまったりします。

スクラムを大人数でしてしまうと

  • デイリーがただの進捗共有会になってしまう
  • レトロスペクティブが特定の人しか能動的に議論しなくなる
  • プランニングの精度が下がる
  • シンプルに会議の時間が長くなるので不満を持つメンバーが必ず出る
  • スプリントレビューを特定の分野しかわからないので受け身になる

こんな感じでした
https://zenn.dev/johndoe/articles/56c6cc05edad54

振り返り及びプランニングの際には数値から振り返れるようにする

スクラムでなんかよくなった~を防ぐために数値が残るような仕組みにした方が円滑になると学びました。
それは会議の時間でもいいし、達成したタスクの数でも良いので数値で出るようにしてその数値を目標からどれだけ差があるのか、安定しているのかを数値結果を可視化している状態で話合うことを行わないと継続的なスクラム運用を行うための障害になるのかなと思っております。

詳細はこちらで
https://zenn.dev/johndoe/articles/5fee9a531478a6

イベントは基本全員参加、参加しなかったりしたりのイベントはなくなるから

基本的に時期とか関係なく、スクラム体制を行うならば原則全員参加orそのイベントはしないの2択なのかなと思っています。
スクラムガイド二もある通り、まずはそのままやった方がよい。少しうまくいっていないからといって自己流にするくらいならスクラムではなくてよいと思っています。
一部の開発者だけレトロ参加、他は不参加、スクラム的にはXX分くらいとらないといけないがプランニングを手短に行うなどする必要があるならば、スクラム体制としては一旦お休みして今あるべき体制を話し合って行う方が良いと学びました。

備考

言っときながら振り返り的なので主観になった。
今年はこういった管理とかスクラム系の記事も数値とかを明確に示しながら書きたい。

参考文献

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

Discussion