tuneの日記

アジャイル開発、組織変革、ファシリテーションについて学んだことの記録

Engineering Manager Meetup #4で「1つの大きなプロダクトをみんなで作る」を話してきました #em_meetup

はじめに

昨年からSlackに参加していたEngineering ManagerコミュニティでMeetupがあるというので参加 & 発表してきました。 開催してくださった ohbaryeさん、素敵な会場を提供いただいたRettyさん、発表にコメントいただいたみなさま、どうもありがとうございました。

engineering-manager-meetup.connpass.com

Twitterでいただいたコメント

機能別チーム、技術負債返却チーム

みる範囲が明確になるのはメリットだけど、コードが別れて独自進化を遂げていくのが問題なんですよね。

みんなで立ち止まって一斉に負債返却するとまだいいんですけどね。短期で終えないと難しいと思っています。

あるあるなんですね!

コンポーネントチームの問題点

あるあるです、でもコンポーネントチームやめられないプロジェクトが多いなーと感じています。

フィーチャーチームについて

勉強会で紹介したサイトは下記です。「Googleで"フィーチャーチーム"と検索し、1番目に出てくるサイトに全て書いてあります。」

featureteamprimer.org

そうなんです!私も研修受けた後に知ってびっくりしました。

チーム名の決め方

ぜひ試してみてください!

テーマを持たせて決めるのも面白いですね!

自分たちで決めると愛着湧くみたいですよ。

コンポーネントに監督者を置く

監督者を置いて、監督者を中心にチームを作っちゃうからコンポーネントチームができるのかなと思っています。

技術を見れる人がたくさんいるならコミュニティー感を出すために「メンター」がいいと思います。 「コードオーナー」は意味があまりブレないので、コンポーネントみれる人が少ない時はおすすめです。

LeSS/LeSS本について

ググりにくい単語です。"less agile"とか"less scrum"とするといい感じです。

売れてる気がする!

その他

学びは多かったです。ただ実は「組織変更」はしていません。組織は既存のまま、プロジェクト体制だけLeSSでいろいろいじってます。組織を作ってプロジェクト体制を整える会社が多いですが、うまくいくプロジェクト体制を作ってから組織を後から直す方が楽じゃないかと思っています。

実は私も行ったことがありません。本が出て読書会がリブートするという話もあるので期待しています。

SAFeもアジャイル開発をスケーリングさせる手法ですがアプローチが異なります。LeSSは調整役をできる限り置かないアプローチですが、SAFeは調整役を積極的に置く仕組みです。

バックログアイテムに重い責任を伴うものが紛れていると、ババを引いたチームが出てきてしまうことはありえますね。 いいお題として対策を考えてみることにします。

こちらこそありがとうございました!