10周年のSPコンテンツ!
2
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
「1チームスクラムと大規模スクラム(LeSS)ではPO目線で何が変わるのか?」はじまりました。 #postudy #less postudy.doorkeeper.jp/events/87970 pic.twitter.com/iAEKiXExAL
拡大
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSは2チーム以上のスクラムチームに適用される。ただ、本当は1つのチームでやって欲しいし、LeSSを進めているわけではない。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
1チームでスクラムをやっているのと同じ状態を複数チームに適用できるか、が、ポイント。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSでは、チーム間の調整において、チーム間の調整役は不要と考えている。他チームとの調整はチームの責任と考えている。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
プロダクトオーナー視点で言うと、チームの数が増えるとやることが増える。チームが増えると、プロダクトオーナーが全部用意して説明することが難しくなるので、開発チームに委譲していくことになる。全チームにビジョンを示していったり、最終的な意思決定はプロダクトオーナーが行う #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSにおけるレトロスペクティブは、チーム内に閉じない、もっと広い観点のレトロスペクティブが行われる。システムや組織全体の視点で、高い価値を提供する上での課題を探求していく。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
8チーム以上になった場合、LeSS Hugeを適用することになる。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSS Hugeで追加されるのは、エリアプロダクトオーナーと、エリアプロダクトバックログ。エリアxxxは、各チーム単位のプロダクトオーナーとプロダクトバックログを指す。すべてのエリアプロダクトオーナーを束ねるのがプロダクトオーナーになる。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSの導入の際は、組織を変える必要がある。 従来のプロジェクト、プロダクト、役割、チームを変えることになります。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSでは、チームはクロスファンクショナルになる必要があります。 ただコードを書いてテストをするだけではなく、ソフトウェアの設計、アーキテクチャ、顧客の理解はもとより、フィーチャーへの対応もしていくことになります。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSにおけるフィーチャーチームとは、顧客が求めるニーズを満たす方向に作用する役割を果たします。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSに関わるメンバーが他責な態度にならないように、極力シンプルな状態を維持していく、というのが、LeSSの各プラクティスにおける考え方の基本になります。 xxの責任だ、いろんなところに責任を分散させる、ではなく、開発チームにも責任を持たせる、ということ。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSにおいて製品開発に関わる方々は、皆、オーナーシップを持っていただくことになる。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSでは、開発チームだけでは解決できない問題に対しても、解決に向けて取り組んでいくことが必要。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSでやりたいこと: スクラムで出来ていたことを極力維持しつつ、チームの数を、必要なだけ増やして対応していく。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
[Q]LeSS Hugeはなぜ8チーム以上? [A]1チーム4バックログを持っていくぐらいの規模。3スプリント分ぐらい先まで把握していたとして、8チームだと、合計100バックログぐらいになる。そのぐらいの数が、一人のプロダクトオーナーが見れる限界値。なので、LeSS Hugeはその辺りを境界線に #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
[Q]なぜ責任は分散させてはいけないのか [A]責任分散をさせてしまうと、ひとつにならない。部分最適がはじまってしまう。そうすると、助け合いが生まれず、組織をよくしていく方向と真逆のベクトルが働く。 LeSSで重要しているのは顧客。常にひとつに統合されたものがリリースされていく。 #postudy
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSにおけるレビューやバックログリファインメントの場で、マーケットから学びを得た場合は、開発チームにシェアはしていく。その後、どう対応するかは開発チームに対応をしてもらう。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
[Q]すでに作ってしまったロードマップやマイルストーン、バックログに対して、大きな変化を起こす必要が出てきた場合 [A]バックログの見直しや再分解は、開発チームにやってもらう。プロダクトオーナーは、その方向性を明確にしていく役割を担う。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
5チーム42名で2年ぐらい開発している例:42名全員集まって、プロダクトオーナーがどうしたいのか、何を意志決定したのかを共有していくようにしていた。その後、タスクをそれぞれ持ち帰ってもらった。テスト等からのフィードバックは、PO側で整理して、全員に展開していた。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
目安箱を用意しておいて、そこにアイディアを入れてもらった。入れてもらったバックログの元ネタは、プロダクトオーナーが拾う、ということをしていた。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
LeSSにおける共有についてのフィードバック。スプリントレビューは全員でやる。大きな部屋で各チームがブースを持って仕事をしている(=バザールのような状態)。各チームが作った物は簡単に見て回り、フィードバックがその場でできるようにしていた。 #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
[Q] ソースコードはどのタイミングでシェアをしているのか →別のチームが開発したモノを学習する、という場は、意識的にやらないと厳しいのでは? #postudy #less
関 満徳@fullvirtue / PO,PdMコンサル @fullvirtue
[A] LeSSでは、コードはいつでも共有されていて、誰でも変更できる状態を目指すことをオススメしている。 #POStudy #LeSS
残りを読む(31)

コメント

関 満徳@fullvirtue @fullvirtue 2019年3月7日
まとめを更新しました。
ログインして広告を非表示にする
ログインして広告を非表示にする