distributed-agile-team.connpass.com
こちらのイベントに参加してきたので、会で印象的だったことと感想を書いていきます。
会の概要
こちらのプロポーザルを聴いてみた後、OSTをしていこうという会です。
会で印象的だったこと
「スクラムの向き不向きとは結局？？導入チームで検証した話」の講演
スクラムの向き不向きに寄与しそうな特性を見てみる
役割の専任・チームの人数・人の固定期間・学びの機会・導入の目的・ステークホルダーとの関係性・採用技術・開発要件・完成の定義の8項目*1を見てみて、スクラムに向いている・スクラムに向いていない・(スクラムで上手くいっていないように思えるが)スクラムに向いていないわけではない、の3パターンに分けてみたということです。
スクラムに向いているチームの特徴、向いていないチームの特徴
上記の特性をチームごとに測って、スクラムに向いているチームはどのような特徴を持っているか、あるいは持っていないかを考えてみた結果を紹介してくれました。
向いていないチームの特徴としては、要件が明確化されていて使う技術要素も決まっていることや、要件も分からず使う技術も定まっていないなどといった特徴があったということです。
向いているチームの特徴としては、チームがPO/SM/Devが専任で活動していることや、チームの人数が3-9名で収まっているなどといった特徴があったようです。
チームの支援
特性をチームごとに測って、特性が満たせていないと判断されたチームに対して、具体的にどのように支援を行ったのかお話してくれました。
具体的に満たせていない特性が分かったことで、完成の定義/ロードマップ作成の支援/チームビルディング...満たせていない特性に合わせた支援をすることができたため、感覚と経験で「スクラムやるならこういうことを気を付ける」「こういう時はこうする」位でしか回答できていなかった状態が解消されたというお話がありました。
特にマネジメント層は、「スクラムで成果を出してよ」という状態から、「こういう特性ができていないからスクラムをやるならチームの土壌をこういう風に整える」という状態への遷移が説明しやすくなったという効果があったようです。
OST～スクラムの中で検証/テストとの付き合い方がいまいちわからないので、相談したいです！～
ゲーム会社でスクラムをしていて、シフトレフトに着手し出しているけどスプリントレビューをはじめとした開発後半で指摘が増えてきたりするのに困っているというテーマでスタートしていきました。
最初の方は、なるべく早くフィードバックをもらう(指摘をシフトレフトする)ためのTipsとして、
- プロダクトバックログ作成から入ってみる
- 自動テストを充実させる
- テストを如何に減らせるか？ということを考えてみる
といった話をしていたのですが、後半からはQAのテストスキルに対して着目して話が展開されていきました。
QAをしていくにあたって、ドメイン知識はもちろんですがその他にもテストスキルを学ぶ必要があるよね、という話がブロッコリーさんから出てきて話が盛り上がっていき、非常に楽しかったです。
全体を通した感想
前半の講演でも後半のOSTでも実際の職場の話を聴くことができて、学びが多い回でした。
前半の会でも後半の会でも、エネルギーが溢れている方々の話を聴くことができて、学びだけではなく元気ももらえるような会でした。
*1:プレゼンではこの8項目が紹介されていましたが、実際はもっと項目が細分化されているということ
