Agile and Iterative Development: Lessons from 20 Years of Ninja-style Testing
![Agile and DevOps の歴史をチェリーピック](https://cdn-ak-scissors.b.st-hatena.com/image/square/3a53cfeb5d93ee5f95ebb8629112e82048560d77/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F15da046fe1b148b0b4004ea8219d522b%2Fslide_0.jpg%3F22640184)
最近はよくスクラムについてのレクチャーを実施させて頂いたりするのですが、スクラムマスターの役割について聞かれることがしばしばあります。 スクラムマスターの役割は、スクラムガイドには記載されていますが、私は実際このガイドの書き方では、インパクトが足りていないと考えています。 スクラムマスターの真の役割は、 『1スプリントでチームが『出荷可能な製品(Shippable Product Increment)』を作り、フィードバックサイクルを回せるようになる状態にする』 ことだと考えます。 本来、スクラムにおけるスプリントの成果物は、 『潜在的に出荷可能な製品の増分(Potentially Shippable Product Increment)』です。 ですが、ここで敢えて『出荷可能な製品(Shippable Product Increment)』として、『潜在的に(Potentially)』の
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか?」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか? そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでてこないなど、要素がすべて網羅されているわけではないことに注意が必要Visual AGILExicon Essential Scrumの著者Ken Rubin氏作のもの。
みなさんこんにちは。@ryuzeeです。 スクラムは、スクラムガイドで定義されています。したがってスクラムを学習したり実践したりする際には、まずスクラムガイドを読むのが大前提となります。 とはいえ、短時間で人に説明したり、リファレンスが必要になったりすることも多いので、ぼくが使っている用語集を共有します。 基本用語プロダクトオーナー開発するプロダクトにおける責任者である。そのプロダクトが実現するビジネス価値に対して責任を負う。 主な役割としてプロダクトのビジョンを明らかにして周りに伝える、プロダクトバックログのメンテナンス、プロダクトバックログアイテムの優先順位付け、リリース計画の立案、開発者が作成したインクリメントを受け入れるか受け入れないかの判断、ステークホルダーとの調整などをおこなう。作業自体は委任できるが、最終的な責任はプロダクトオーナーが負う。 実施中のスプリントをキャンセルする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く