スクラムの開発チームを10人以上で回すツラミ｜Nichi
スクラムガイドでも以下のように書かれているように、スクラムチームにおける開発チームの規模は、3~9人が良いらしいです。 開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。(中略)メンバーが 9 人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。 スクラムガイド P6特に人数が多い場合、有益的ではなくなると書いてありますね。 実は僕が所属しているチームは現状10人以上で構成されており、この辛みに直面しています。 そこで、開発メンバーが多いチームでのスクラムが具体的にどう辛いのかをシェアしようと思います。 なお僕が所属しているスクラムチームの開発メ
スクラムをざっくり説明するときのスライド - Qiita
このドキュメントは 「スクラムを始めるぞ！」というチームに対し スクラムとは 何のためで どんな役割があり 何をやるのか をスクラムマスターがざっくり説明するための資料 参考にすべき書籍 スクラムガイド(2016年版) たった17ページ。無料。 スクラムの大元 エッセンシャルスクラム 過去のスクラムの経験や例を元に、実践的なプラクティスの紹介 スクラムは何のためのものか 向いている対象 物事を予期できない ユーザーに出してみるまで何がウケるか分からない、等 検証が可能 数値を計測する等の方法によりそれが良かったのか悪かったのか検証可能 思想 設計段階から全てを見通すのは無理 少しずつ作って、検証と適応を繰り返す スクラムの核心 透明性 今何が起きているかチームの皆が知れる 検査 作ったもの・作り方を評価する 適応 検査に従ってより良いやり方を探索する スクラムの3つの役割 プロダクトオーナ
プロダクトバックログリファインメント
PBIを確認し、今後のスプリントで着手可能にするためには、スプリントごとにプロダクトバックログリファインメントを行う必要があります。 プロダクトバックログリファインメントで行う主な作業は (1) 大きなPBIの分割 (2) 各PBIを着手可能にする (3) 見積もる 経験的プロセス管理の観点から、Scrumでは、プロダクトバックログリファインメントの細かい how（どう行うか）を規定しません。ただし、Sprintの全体時間のうち 10%を超えないようにすることを推奨しています。プロダクトバックログリファインメントは大抵、Sprintの最中に実施されます。 リファインメントは プロダクトオーナーや、ビジネス分析グループなしには完了できません。彼ら抜きで完了させてしまうことは、情報の分散や伝達ロスによる リーン的ムダ を増大させます。 また、スクラムはチームを方式検討/テストなど役割で分担する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムガイド - Scrum Guide 2020 年 11 月
