概要

2019年4月13日、14日(9:00〜18:00)
講師:Jim Wangさん、原田騎郎さん

学んだことを箇条書きに。

スクラムはフレームワークであり方法論ではない

  • スクラムには3つの柱があり、
  • スクラムは3つの役割、3つの作成物、5つのイベント、5つの価値基準で語ることができる。(詳細はスクラムガイドを読むこと)

  • スクラムはBest of practiceではない。前よりはマシにはなるかもしれないが。

  • 継続的な改善により、スクラムチームは成長する。
  • そしてスクラムがうまく行き始めると、チームはやり方を壊し始めるだろう。
  • だけど、まず「守」ってスクラムの価値と原則を噛み砕く必要がある。ジャズピアノで基本を弾けないのにアドリブなんてできないのと似ているかも。

スクラムマスターは言いにくいことも言わなければならない

  • 引っ込み思案だったり遠慮していたら、あまり...スクラムマスターに向いていない??

スクラムマスターは開発チームの味方

  • 障害を取り除き、鼓舞し、励まし、元気づけ、生活の質さえ上げれるように気を配る

スクラムは厳しい

  • うまくいく方法を教えてはくれない。ただうまくいっていないという現実を直視させられるだけ

気に入った言葉

  • empilical(経験的プロセス)
  • iterative(漸進的)
  • 価値駆動

確約(commitment)

  • チームはスプリント内に行う作業について合意しており必ずできると思っている。
  • POはスプリント内に価値あるものを完成させるために、別のものを入れない、すぐに質問に答える準備ができている。

勇気(courage)

  • 時にはこわいことも言わなければならないかもしれない。

集中(focus)

  • スプリント中はスプリントバックログの作業だけに集中する。

公開(openness)

  • 課題や問題があれば、即座にオープンにする。

尊敬(respect)

  • 役割に縛られない、特定の人が責任を持つわけではない。
  • お互いに尊敬しながら働く。

開発現場の現実は...

  • ユーザーは自分の作りたいものをイメージできていない
  • 開発者はなんでもできる訳ではない
  • 変更は生じる

Timeboxに対する意識改革

ここは難しさを痛感させられた部分。どう改善していくかこれからの一番の課題かもしれない。

なぜ機能横断的なのか

作業スピードという意味でのパフォーマンスは落ちる可能性の方が大きい。
でも、チームは変化に対応しなければならないので、属人的であると価値あるものを作ることに障害となる。
その障害を除くという意味では、パフォーマンスは上がると言えるかもしれない。

実際の現場で働いていて、ここは難しいなーと思った部分

Timebox。どうしても完成させようとしてしまう。「時間までに言われたことすべてを完成させること」を目標にしてしまいがち。
でもコミットすべきなのは、価値のある製品なので、「時間までに言われたことすべてを完成させた」けどステークホルダーに見せれるものになっていなければ失敗である。時間までに完成できないと分かった時点で、ではどうすれば価値のあるものをスプリントの最後にステークホルダーに見せれるのかを交渉する必要がある。