Regional Scrum Gathering® Tokyo 2019の自分メモ

公式はこちら

2019.scrumgatheringtokyo.org

スライドはこちら

scrummasudar.hatenablog.com
まとめてくださって多謝。

最初にまとめ

RSGTは知識だけじゃなくて、衝動みたいなのも激しく得られる。
そして、それがわりと重要。
本当に必要なのは行動して、知識を経験に転化させること。*1

自分が組織に戻って、展開はすることもするんだけれどそれじゃたりんのだよ、それじゃあ。

f:id:i47_rozray:20190114231009j:plain
f:id:i47_rozray:20190114231018j:plain

今回の自分の気づきキーワード

  • 計測
  • 素早く検証
  • 実験

参加したセッションのテーマが違えど、この辺のキーワードが耳についた。
*2

個人的ふりかえり

2016年から?参加、今年3回目だったかな。
そして、全て良い記憶。
RSGTは、今のフェーズの自分に一番多くの価値がある勉強会だなと。

それから、ネットワーキングというか懇親会というか、例年よりフリーにお話させてもらえた。
Twitterでもお話させてもらったし、ありがたみ高い。

前職の人にもオススメしたら来てくれていたけれど、どうだったんだろ。
感想を聞いてみたい。

グラメモ

  • 青はタイトルとか区切りとか
  • 緑は自分の感想
  • 黒はメモ
  • 赤はまとめとか重点的なとこ

f:id:i47_rozray:20190114231543j:plainf:id:i47_rozray:20190114231547j:plainf:id:i47_rozray:20190114231550j:plainf:id:i47_rozray:20190114233741j:plainf:id:i47_rozray:20190114233958j:plainf:id:i47_rozray:20190114234051j:plainf:id:i47_rozray:20190114234118j:plainf:id:i47_rozray:20190114234129j:plainf:id:i47_rozray:20190114234140j:plainf:id:i47_rozray:20190114234151j:plainf:id:i47_rozray:20190114234201j:plain

コーチクリニック

  • 作業の可視と分担
  • スキルの可視化と成長、教育
  • スプリントにストーリーは入らないことはない、入る。MVPを恐れない。
  • 出来ないかも、でなくてやってみる、話ししてみる、「出来ないかも」なら判断前にシンプルにしてみる。
  • タイムボックスは変えない。

ネットワーキングやセッション外での学び

  • POが動いてくれないと嘆く前に透明化、プロダクトの目的のすり合わせなど。
  • POを混ぜる。のが難しい場合、POの役割も踏まえて契約。
  • ウォーターフォールで厳密に管理。ビジネスにならなくなる。
  • 作業:期間:効果よりも作業:売上:効果で比較、交渉。
  • KPTで出たタスクは一番上に詰む。運用とのコリジョンはPOと合意する。
  • まず最初に、関係性の構築をする。
  • 人、関係、プロセスの順に構築

f:id:i47_rozray:20190114230916j:plain
f:id:i47_rozray:20190114230924j:plain
f:id:i47_rozray:20190114230938j:plain
これは2日目のランチの写真。

OST

見積もり

  • 見積もりを行う場合は、コスパを考える。状況による。
  • 見積もりはコミュニケーションツール、いつも必要というわけではない。
  • 関係性の中で必要なくなっていく場合もあるが、見積もりは無駄という話ではない。
  • 見積もりのメリデメはある。
  • 見積もりは、対外的な要求に応えるところが多いと感じていたが「モチベが上がる」や「仕様の洗い出し、すり合わせ」などの効果もある。
  • ロードマップなども見積もりと言えるがファット。MVPでもない。また、リリース出来ている(という信頼関係)があるから見積もりがなくてもよい。
  • ROI、リファクタの説明として、他の開発のROIが変わる。という説明は腑に落ちる。

f:id:i47_rozray:20190114230950j:plain

ユーザーストーリー

  • 説明書、ユーザーとの対話のツール。というのは印象的だった。
  • 自分の認識としては目次があって必要なものを逆引きできる。ポケットリファレンスとか。ソレ。
  • POにプロダクトを見せて、自然と使えなかったらユーザーストーリー書けてない、伝わっていない。
  • PressReleaseを書く。「マイナーなバグフィックスってなんやねん」
  • 書けていないPOは仕事していないPO。

f:id:i47_rozray:20190114230959j:plain

スクラムの見積もり?

  • ストーリーのS,M,L。
  • Lは複雑なもの。サイズをSへシンプルにしていく。
  • 契約対プロセス、厳密性と柔軟性、契約よりもデリバリ。

モブ基調講演

  • 最高なランチはなんですか?とそれを達成してもらう。

おわりに

次のRSGTやこの辺の役割の未来が気になる。
次なる転換点というか。
ラクティスの整理がデザインパターンで行われたことを知ったわけだけれど、
開発のプロセスの上限ってどこだろ、揺り戻しとかくるんかな。みたいなことを考えたりして。

個人的には、開発プロセスやチームビルドなど、その周辺に求めることって、
「良いチームを作って、良いプロダクトを生み出す」ことだと思っていて、
今、あまり語られないのって、もっと根源的教育の場の話とかなんかなー。*3
それでいうと、今回TAKAKINGさんの新卒研修の話はとても興味深かったわけで、更にelemental?な話にアプローチするのも面白そう。

ひとまず!!明日からまた新たなる実験をはじめよう。

*1:二の足踏んでる人は、騙されたと思って参加した方がいいよ。で、本当に騙されたと感じたら、あたくしに言ってください。

*2:「めぐらぶ」は一旦置いておく。

*3:俺たちをとっとと越えていけ!!的なやつ