『スクラムチームの開発者ってどんな仕事？』〜 スクラム Bar #4 に参加しました。
開発者の視点でスクラムについて語られた会でした。気になったこと、心に残ったことをまとめます。
やり方(How)は開発者に任せよう
Why(なぜ作るのか)、What(何を作るのか)、How(どうやって作るのか)についてのお話で以下のようなトピックがありました。
- 信頼関係がないとHowについて意見したり、議論することが多い
- 担当者が決まった後のやり方は任せると摩擦が減る
- DACIを導入する
- POはサイズ感を考えるためにHowも考えるけど、最終的なHowは開発チームに決めてほしい
- POはHowについては文句は言わない
- 立場によって、WhatのつもりがHowに受け取られることもあるので、スプリントを通して塩梅を見つけていく
DACIフレームワークは初めて知りましたが、良さそうだと思いました。DACIは推進者、承認者、貢献者、報告先を明確にするフレームワークてす。承認者が決まっていると意思決定も早いですね。また、自律的なチームを促すことにも一役買いそうです。「決める人はあなた」が決まっていると意識が変わるんです。やっぱり。
blogs.informatica.com
エンジニアにスクラム知識は必要か？
- スクラムマスターがフォローできるので、必須ではない
- プランニングについては知った方が良い
エンジニアにスクラムの知識は必要かどうかという話題で、スクラムイベントのプランニングは知っておいたほうが良いですねという話でした。
プランニングはPOと開発者が対等に話せたほうが良いですし、プランニングの二部は開発者が主体になるので知っておいたほうが良いですね。
個人的にはアジャイルの考え方も知っておいたほうがスプリント中のイベントで活発に話せたり、改善が進むと思いました。
とはいえ、このあたりはスクラムマスターが頑張るところだと思います。
チケットを積極的に取らない人への対応は？
- ペアで考えさせながら教えて成功体験を築く
- 託児所パターン：ベロシティを下げないように生産性に影響しにくいタスクを持ってもらう
託児所パターンは組織パターンという書籍に書かれているようです。ペアやモブで開発するとき初心者に合わせると進捗が出ない、有識者に合わせると初心者がついていけないため、「進捗より教育に重きを置くチーム」と「進捗に重きを置くチーム」に分けるみたいです。新しいことを知れました。両方のメリットを得るのが難しい場合は分ければ良いんですね。
ふりかえりで工夫していること
- 包みかかさず話す
- 個人的な意見ではなく、チームの声だと思って聞く
ふりかえりの意見はその人がシステムに言わされていると考えて、その理由を探るのが大事という話は、新しい感覚を掴めた感じがします。システムで捉えるとこの感覚なんですね。
まとめ
DACIフレームワークと託児所パターンは使える場面がありそうです。「システムに言わされる」という感覚は開発をシステムで捉える重要な感覚になりそうです。
今回も参加してよかった！運営の皆さん、参加者の皆さん、ありがとうございました！
