台風が接近しているということでキャンセルも結構ありましたが、MT東京の Scrum の勉強会に参加してきました。

【MT東京-49】Extra Edition 02 scrum勉強会「スクラムで前進しよう!」
https://mt-tokyo.doorkeeper.jp/events/76939


Scrum については本とかで読んだことあって、なんとなくならわかるけど、、、普段の業務にどう取り込むのかがいまいちイメージがわかない感じな状態でした。
プログラマが複数名のチームとかだとなんとなくイメージは湧くんですけどね。。

  • Scrum は現状を把握するためのフレームワーク
  • 単純だったり、難易度が低いものはwaterfallのほうが向いてる
  • プロダクトバックログからタスクを決めるのは開発メンバーで、開発メンバーが自分でやることを決めていく
  • スクラムマスターはすべての役割の人が円滑に進められるように障害を取り除く
  • スプリントプランニングの時点では設計(どう実装するか)が完了している。1スプリントのうちスプリントプランニングをする日があったりする。
  • スプリントレトロスペクティブ(=振り返り)では改善案を出しましょう、というルールを設定することでアジャイルな状態になりやすい。振り返り大事。
  • プロダクトバックログ(=機能)には誰でも追加できるようにして、プロダクトオーナーが優先順位をつける
  • スプリントを回すことでチームのベロシティ(=1スプリントでこなせるボリューム)が見えてくる

不明確なものを少しずつ着実に明確にして進めていくという感じの印象。
Web制作みたいに1つのチームにデザイナ、フロントエンド、プログラマ、みたいな人がいる場合、スプリント内に終わらなそう、みたいな話を懇親会のときにきいたら、デザインは別チームでわけるってのもありかも、みたいなことは教えてもらった。

Webサイト構築がメインではない人の話も聞けて参考になった。自社の開発にはマッチしそうなイメージ。
とはいえお問い合わせ対応とかそういう割り込みがあるのでその辺どうするのがいいのか?といったかんじで。
お問い合わせ自体が別チームみたいな感じが近いのかなー。

要件定義の段階でCMSのプロトタイプ作って〜、とやる流れなんかは xxx の機能を作る、という感じですすんでいくので近いところがあるのかなー、という気がしつつ。

開発手法に限らず振り返りをやる習慣をつけたほうがいいんだろうなー、という気はした。
bit part も言問も複数案件がずっと動いてて、各自が掛け持ちだったりするし、案件単位で入る人や固定的に入る人、社員の人といったかんじで時間とかがバラバラなところもあるので、そのあたりはどう採用するのか?という自社の問題な気がする。

定例会議的なものが似たようなところもあるのかも、という気がしつつ。。。
この辺は一緒にやってるメンバーにも聞いてみつつ模索していきたい気がするな。