はてなブックマーク

Scrum Inc. 認定資格スクラムマスター研修をお届けしている中で、受講者の方から「スクラムの各役割を兼任してよいでしょうか？」という質問を多くいただきます。 今回は、スクラムの役割の兼任について書いてみたいと思います。 スクラムを実践する上では、スクラムガイドを元に自分自身で考えていく必要がありますが、その中でも「これでいいのだろうか、合っているのだろうか？」と悩みながら実践している人がほとんどかと思います。このブログが、少しでも読まれた方の道標になり自信を持って実践ができるような助けになれたら嬉しいです。 スクラムの役割について 本題に入る前に、まずはスクラムの役割についておさらいしてみましょう。 スクラムにはプロダクトオーナー、スクラムマスター、開発者の3つの役割があります。 この3つの役割はそれぞれ以下のような責任を持っています。 プロダクトオーナー 顧客に届けるプロダクトの価

2024.07.08 by Jeff Sutherland, Scrum Inc. Team | January 22, 2020 | Blog（翻訳：荒本 実） スウォーミングはシンプルだが見落とされがちな、スクラムチームのベロシティを一気に高める方法である。 これは、業界に関わらず生産性の高いチームで一貫して使われているパターンである。 実際、スウォーミングはとても簡単に実践できるので、アジャイルに慣れていないチームでもすぐに使い始めることができる。 この投稿では、スウォーミングがどのように、そしてなぜ機能するのかを探り、すぐに劇的な結果をもたらした医療現場での実際の適用例を紹介する。 スクラムにおけるスウォーミングの定義とは何か？ スウォーミングは、できるだけ多くのチームメンバーが同じ優先度のアイテムに同時に取り組むときに発生する。 そして、そのアイテムが完了するまで、そのアイテムだ

2024.07.01 この記事は、2001年、ユタ州スノーバードで17人の志を同じくする業界リーダーたちが集い、情熱と対話からアジャイル マニフェストが生まれた瞬間の物語を紹介しています。ここで産まれたアジャイル マニフェストは、個人と対話を尊び、動くソフトウェアに価値を見出し、顧客との協調を重視する4つの価値観によって、ソフトウェア開発に新たな未来を切り拓きました。 by Jeff Sutherland | February 11, 2021 | Blog（翻訳：荒本 実） 原文：How The Agile Manifesto Came To Be With Dr. Jeff Sutherland 20年前、私はユタ州スノーバードに行き、同じ目標を持つ16人の仲間と合流しました。 それは、私たちの業界、つまりソフトウェア開発のやり方をより良い方向に変えることでした。顧客を第一に考え、より

Scrum@Scaleガイドの序文 スクラムは、もともとスクラムガイドで説明されているように、単一のスクラムチームが、持続可能なペースを維持しつつ、最適な価値を提供できるようにすることを重視している。スクラムガイドの発行以降、スクラムの利用はプロダクト、プロセス、サービスなどの開発といった複数チームの協力が求められる領域まで広がりを見せている。 現場では、組織内のスクラムチーム数の増加に伴い、2つの重要な問題の発生が繰り返し見られた。 複数のチームの間での依存関係や作業の重複、コミュニケーションのオーバーヘッドなどの問題により、チームごとのアウトプット（動作するプロダクト）の量、スピード、品質が低下し始めた。 従来の組織構造はビジネスアジリティの実現に十分な効果を上げられなかった。優先順位の競合や、市場の変化に対応するようチームを素早く転換させることができないなどの問題が発生した。 こうし

2020.11.19 スクラムは、アジャイルな働き方の実践手法として、世界中で広まった一方、スクラムの実践が目的化し、成果をあげることにフォーカスできていないチームが世界中で見受けられました。また、ハードウェア開発、マーケティング、セールス、人事など、新たにスクラムの実践を開始したソフトウェア開発以外のドメインの人々にとって、現状のスクラムガイドは、一部、理解しづらい表現や用語がありました。 今回のスクラムガイド2020では、こうした状況を踏まえ、以下を目的に大幅なアップデートが行われました。 主なアップデート内容は以下のとおりです。 作成物に含める確約（コミットメント）対象を明確化 スクラムマスターがチームの確約（コミットメント）の達成に責任を持っていることを強調 チームはより一丸となり、コミットメントの達成に向けてWhy/What/Howを自己管理 スプリントプランニングのトピックの追

2018.05.15 Dr. Jeff Sutherland （翻訳：和田 圭介、梅澤 友紀） ユーザーストーリーの見積りにフィボナッチ数列を使うことについては、頻繁な議論があります。見積りは、完璧なツールではありませんが、計画作業に欠かすことは出来ません。 ユーザーストーリーの見積りは、デルファイ法を開発した1948年のアメリカ国防総省による調査に基づきます。デルファイ法は1960年代までに公式化され、ランド社（アメリカの軍事関連のシンクタンク）のホームページに多くの論文が掲載されています。まず第一に、ランド社の研究者は、不正確な見積りの典型的な原因である、他の人に意見を合わせなければいけないというプレッシャーを避けるため、各自が他の人の影響を受けずに見積りを実施することに決めました。課題に対し、皆、異なる見解を持っているので、まず初めに、見積りは別々に行います。個別の見積りの後、見積り