大規模アジャイルフレームワークの紹介

みなさんこんにちは。@ryuzeeです。 12月1日に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 スクラムの認定コースでも基礎的なコースでも、よく聞かれるのが大規模の場合の対応についてです。 そこで、今日は大規模の場合の選択肢になりそうな大規模アジャイルフレームワークを紹介します。 紹介しますが、最初に大事なことをお伝えしてから紹介します。 そんなにたくさん作っても使わない2019年にプロダクトマネジメント関連のSaaS企業であるPendoが行った調査によると、ソフトウェアプロダクトにおいて平均的な機能の利用状況は次のようになったそうです。 まったく使わない: 24%ほとんど使わない: 56%よく使う: 8%いつも使う: 12%つまり80%の機能はほとんど、もしくは、まったく使われないということになります。 たくさんの人を集めて、たくさんの機能を作るのは、ムダであ

[morimarii]

「いかに不要なものを作らないようにするか」まじこれです。機能も会議もドキュメントも運用での定期タスクもすべてこれ。まずやってみるのはいいけど止めたり捨てる基準や判定時期を明確にする必要がある

[miholovesq]

SI的なヒエラルキーの大人数プロジェクト構造のまま「大規模でアジャイルやるには？」って聞かれるけど、スモールチームもないのに繰り返し構造やスクラムイベントみたいなプロセスだけインストールしたら地獄や

[inose660]

こんなにあるのか。。。しかし『大規模アジャイル』って、なんつーか『半チャーハン大盛り』的な自己矛盾があるな。小さいことが美点なのに、わざわざ大きくしちゃうの？っていう。

[snare_micchan]

「ほとんど使わない」をムダ扱いするのは開発プロジェクト失敗フラグなんだけどなあ。例えば決算関連の機能は使用頻度は低いが、その機能がないと決算をまとめられず企業として死ぬ

[ryuzee]

大規模まじやりたくないという話を書いた気がする

[medihen]

大規模ウォーターフォールの成功率は3%しかないのか？　引用元の資料には、確かに"The overall results clearly show that waterfall projects do not scale well, while agile projects scale much better. "とあるが...

[rgfx]

「成功したければ、規模を小さくするのが鉄則」はい

[minamishinji]

興味深いけど、最初の分割の問題が肝なのでは。たぶん大規模アジャイルフレームワークは使うことなさそう…

[sawarabi0130]

"いかにプロダクトを分割して、それぞれを独立、疎結合にするか"　つまり大規模でなくする。

[estragon]

“大規模アジャイルの検討をする前に、スコープを減らしたり、ドメインを分割したりして、1チーム（10人以内くらいのサイズ）でやる方法がないのか？を考え抜く必要があります。 規模が大きいというのを変えられない

[s99e209]

“LeSS”

[hi-hats]

Disciplined Agile、知りませんでしたが、まさに大規模って感じでうへーだなあ

[tk_musik]

Q.スケールするにはどうしたらいいですか？A.スケールするな、は有名なやり取り。ただ、なんでそういう要求が出てるの？は考える必要あるよね。切り捨てるだけならそれはサイロ化だし組織を変えるなら理解からだよね

[tpircs]

大規模やりたくないのは伝わるけど、それならもう少しフレームワークそれぞれについて突っ込んだdisが欲しいなぁ。

[turanukimaru]

スコープは減らすんじゃなくて絞り込むものなのに中心の話をせずに闇雲に分割する話ばかりしてるから焦点がぶれて必要か不要か分からない。例えば販売員支援システムのユーザは販売員だけど中心はお店のお客さん。

[spaciba8443]

\

[raimon49]

＞スコープを減らしたり、ドメインを分割したりして、1チーム（10人以内くらいのサイズ）でやる方法がないのか？を考え抜く必要があります。 規模が大きいというのを変えられない制約と見なすべきではありません。

[forcutie]

[ プロダクトマネジメント / プロジェクトマネジメント]

[surume000]

アジャイル開発のプロセスを落とし込むフレームワークがあるんだ

[dmr]

責任