Content-Length: 261400 | pFad | http://b.hatena.ne.jp/tune/LeSS/
大規模組織でLeSSの再導入をしています - ねこのひたい
スクラムが好きです。ここ数年、スクラムをよく知らないけどスクラムイベントをやっているという現場でスクラムを再導入するということに向き合ってきました（よくよく考えると不思議な縁だなと思ったのですが、よくあることなのでしょうか）。 今まさにそろそろ始めるぞ！というタイミングなので、始めるまでにやったこと、考えたことをまとめていきます。 現在の現場ではスマートフォンゲーム開発をしており、組織規模は大きめです。エンジニアはスクラムチームが複数作れる人数、ディレクターが複数人いて、デザイナーは少なめ、QAチームがたくさんというチーム構成です。PMやEMも複数人います。スクラムを知ってる？と聞くと「なんとなく知ってる」「聞いたことはある」が若干名。 プロローグ 状況把握 弊社のEMは組織課題の解決やアジャイルな開発プロセスの導入が含まれています。 まずは現在どのような状態を把握するためにヒアリングから
スケールする大規模スクラム開発「LeSS」の実践例＠Timers - Tech Blog
はじめに CTOのあまど ( @amado_tech )です。 Timersでは2013年頃から長らくスクラム開発を中心に据えてプロダクトを作ってきました。初期の頃はなんちゃってスクラムだったり、人が増えるにあたって自己組織化するのが難しくなったり、たくさんの課題や問題を乗り越えてきました。 現在16名程度のアプリ開発チームが2つのスクラムチームと1人のプロダクトオーナーの体制で、2週間のスプリントを効果的に回しながら生産性高く＆納得度高くプロダクト改善が出来ており、我々のコアプロダクトである「家族アプリFamm」は順調に改善され事業成長もしています。 そんな開発体制を支えているのが、「LeSS(Large Scale Scrum)」という大規模スクラムのフレームワークです。本記事ではLeSSの紹介と実践する上でのノウハウを共有します。 LeSS(Large Scale Scrum)とは
組織の拡大に伴うアジャイルなプロダクト組織構築 - KAKKA is not 閣下
Drivemodeというスタートアップにジョインしてから4年が経ちました。ジョインした（入社すると決めた）当時はまだシードラウンド以前であり、ファウンダー4人+エンジニア2人という状態でした。ですが今となっては組織も数十人規模まで大きくなってきています。 組織が大きくなるにつれ、様々な組織やマネジメントの問題に遭遇するようになり、今後もこれらと真剣に向き合わないといけません。 本記事では、これまでの経験を踏まえて、組織の成長に伴ってどのようなアプローチで組織や文化を構築すれば良いか、考えをまとめて書きます。 常に管理されたプロダクトバックログの重要性 いきなりですが、まずプロダクトバックログの話をします。 常に管理されているプロダクトバックログというものは非常に大切です。プロダクトバックログとは目的地に向かうための道筋であり、そこが空になっていたり、でたらめな状態だと、車（プロダクト）は暴
Engineering Manager Meetup #4で「1つの大きなプロダクトをみんなで作る」を話してきました #em_meetup - tuneの日記
はじめに 昨年からSlackに参加していたEngineering ManagerコミュニティでMeetupがあるというので参加 & 発表してきました。 開催してくださった ohbaryeさん、素敵な会場を提供いただいたRettyさん、発表にコメントいただいたみなさま、どうもありがとうございました。 engineering-manager-meetup.connpass.com Twitterでいただいたコメント 機能別チーム、技術負債返却チーム 機能でわける。その時縦割りになっていってしまう可能性がありそうって懸念でるよなぁ。 #em_meetup— つよぽそ (@cobasparxxx) February 1, 2019 みる範囲が明確になるのはメリットだけど、コードが別れて独自進化を遂げていくのが問題なんですよね。 技術的負債を返済するチーム、でかいテーマがあったときに一時的にプロジェ
フィーチャーチーム
フィーチャーチームは、“組織の既存の枠やコンポーネント等にとらわれず、多くの顧客 のフィーチャーを1つずつ完成させる長寿命のチーム” です。フィーチャーチームは、大規模開発でアジャイル開発を実践するために必要不可欠です。フィーチャーチームがなければ、（その代わりに、コンポートネットチーム、コード所有権に基づく、もしくは１つの機能に基づくグループ、アナリストグループ、プログラマグループ、テストグループ等に分類）あなたの組織は、結果的に逐次的開発サイクル（ウォーターフォール, ...）となり、非常に多くの無駄を生み出したり、部分最適化を行います。フィーチャーチームは、多く無駄を取り除くと同時に、変化と挑戦を求めます。 フィーチャーチームは大きなプロダクト開発で長期間、活躍します。例えば、テレコムシステム（Ericsson）やコンパイラ開発（Microsoft）等。フィーチャーチームが仕事
認定LeSS実践者研修を受けてきた - Qiita
Help us understand the problem. What is going on with this article? Odd-e社主催の認定LeSS実践者研修を11/29~12/1に受けてきたので、簡単に報告します。以下の内容は研修中にもらった資料、講義中の話をベースにしています。 LeSSとは？(概要) 大規模開発用のアジャイル開発フレームワーク Large-Scale Scrumの略 基本はスクラムで、大規模用に拡張を行っている 適用範囲は2〜数百チーム(3000人規模の開発チームに導入したとか・・・) 2~7チームはLeSS、8チーム~はLeSS Hugeを使う LessとLeSS Hugeの違いは追加の役割とか、プロダクトバックログの作り方ぐらい(後述) 認定LeSS実践者研修とは？ 3日間の研修 講師はOdd-e代表 Bas Vodde氏(同時通訳あり) LeS
LeSS (Large-Scale Scrum) の概要
1. LeSSの概要 (Large-Scale Scrum) 2016/11/25 Ryuzee.com 吉羽龍太郎 (@ryuzee) 2. LeSS概要 ✤ 大規模用のスクラムフレームワーク。まぁまぁ十分という程度を目指している ✤ 8チームまで用とそれ以上のチーム用(LeSS Huge)の2バージョンがある ✤ LeSSはスクラムなので以下はそのまま適用される ✤ 製品は1つでプロダクトバックログも1つ ✤ 完了(完成)の定義も1つ ✤ スプリントの最後には出荷判断可能な製品の増分を作る ✤ 1人のプロダクトオーナー (スクラムマスターは複数でOK) ✤ クロスファンクショナルチーム ✤ スプリント期間は固定期間 (各チーム共通で同じ日に開始・終了) 3. 歴史 ✤ ✤ CraigとBasによって2005年から開発。多くの事例 ✤ 通信機器 - Ericsson & Nokia Ne
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/tune/LeSS/
Alternative Proxies:
On "Product Teams" and "Feature Teams"
Introduction to the Japanese Edition of the LeSS Book
eliminate-dependencies.html