プロダクトバックログにおけるよくある質問と答え | Ryuzee.com
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。 なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。 そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。 「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか？パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、
スクラムがうまくいっている兆候
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 昨日Twitter上で@yujioramaさんから「これは成功すると思えたスクラム導入の兆しとか読んでみたいです!」という要望を頂いたので個人的な見解を書いてみたいと思います。 なお、僕は基本的に、技術力とかツールの話以前の話としてチームの態度や周りとの協調関係を重視しているので、主にそういう観点が多いことを念頭においておいてください。 プロダクトオーナープロダクトオーナーが明確なプロダクトバックログアイテムを書いている自分が書いたプロダクトバックログアイテムに責任をもっている。開発チームがプロダクトプロダクトバックログアイテムの中身についてプロダクトオーナーに確認できる開
スクラムマスター マニフェスト ver.1.2 の非公式翻訳 - kawaguti’s diary
Scrum Global Gathering London でまとめられた スクラムマスター マニフェスト なるものがあるということなので、翻訳しておきます。翻訳時点の原版のバージョンは1.2と表記されていました。この存在は InfoQの記事 ( InfoQ: Is the ScrumMaster a Full Time Role? Yes, According to the ScrumMaster Manifesto ) で知りました。 私たちは、スクラムマスターはフルタイムの役職であり、一つのスクラムチームにつき、一人のスクラムマスターが必要であると信じます。 12のスクラムマスター原則(ポケット版) 1. 専任デリバリー改善者 2. 継続的改善を促進する 3. 継続的改善を支援する 4. 権限委譲する、コーチする、デリバリーする (?) 5. チームを育てる 6. 透明なチームになる
カンバンを導入する間違った理由5個
みなさんこんにちは。@ryuzeeです。 ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。 5つの間違い1.ユーザーストーリーの多様性我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う 2.スプリントがうまくいかない1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う 3.ふりかえりミーティングがうまくいかないふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う 4. 人的リソースの共有と機能別組織開発チームが１つで、プロジェクト間でメンバーを共有
Scrum Gathering Tokyo 2011:Day2 に参加してきた #sgt2011 - Diary of absj31
Scrum Gathering Tokyo 2011:Day2 (写真：Day 2最後のセッション『WRAP UP!』、フィナーレの一幕。) 2011/10/19(水)に行われた有料イベント『Day1』に引き続き、Day2も参加してきました!! Day1及びScrum Gathering Tokyo 2011全体の内容についてはDay1のブログレポート及び派生リンク等をご参照下さい。 Scrum Gathering Tokyo 2011:Day1 に参加してきた #sgt2011 - Shinya’s Dairy Report 開催場所は早稲田大学理工学部55号館。XP祭りX以来の早大訪問となりました。 会場内に入ると、sgt2011の看板などが幾つか立てられており雰囲気を盛り上げておりました。 また、今回は以下の様に『Job Board』なるものもお目見え。(内容が内容なので一応ボカシ入
Agileと組織
Agileと組織 1. Agileと組織2011/10/8 Agile Tour OsakaRyutaro YOSHIBA http://bit.ly/nRQ6dC 2. 吉羽龍太郎アジャイルコーチhttp://www.ryuzee.com/ 3. ？？？ 4. Scrum Boot Camp 5. 本日の資料は後日公開します 6. よろしくお願いします 7. アジェンダ 企業のおかれた状況 „10分‟ なぜAgileなのか „10分‟ Scrumとは „15分‟ Agileな組織 „20分‟ まとめ・質疑応答 „5分‟※あくまで予定です… 8. http://bit.ly/ptKnqR1. 企業のおかれた状況 9. ビジネスをとりまく環境の変化 10. IT投資は業務効率化から戦略実現へ 11. 以前の競争http://bit.ly/rioQDZ 12. 現在の競争 競争の速度
スクラムの基本概念から拡張Tipsまでを俯瞰できる、「非公認スクラムチェックリスト by Henrik Kniberg」 を更新しました。 - kawaguti’s diary
以前訳した Henrik Kniberg (ヘンリック・クニベルグ) 氏のスクラムチェックリストの日本語版を更新しました。2010年10月4日のバージョン2.2を取り込んでいます。 スクラムの基本的な項目を、ヘンリックさんの視点でチェックリスト化しているのですが、非常にわかりやすいチェックリストだと思います。今回、２ページ目に使い方が追加され、誤った使い方が減るような工夫がされています。 ダウンロードはこちら (PDF 299KB) です。 オリジナルのサイトはこちら: Scrum Checklist : Are you really doing Scrum? ヘンリック氏の認定スクラムマスタ研修があります。 ヘンリックさんの認定スクラムマスタ研修(10月17日〜18日) も行われます。わずかですが残席がありますので、よかったらどうぞ。 どうやって使えばいいの？ (2ページ目の説明を抜粋し
ヒビノログ » Blog Archive » 第11回すくすくスクラムに行ってきた
第11回すくすくスクラムに行ってきました。 今回は「ユーザーストーリービギンズナイト」、講師は角 征典さん。 後でまとめたい気もするけど、ひとまずメモを垂れ流しておこう。 要求定義で困っていることは？ 進めるにつれて要求が変わる、知識が顧客と作る側で違う、とか。 スクラムの要求定義は「要求＋ビジネス価値」で考える。 ユーザーストーリーは３幕構成。 「（役割）として（性能・機能）が欲しい。それは（ビジネス価値）のためだ」 ⇒このあたりは「アジャイルな見積もりと計画作り」のおさらい的な。 不足分は対話で埋めていく。「言った言わない」にならない土壌作りが大事。 ⇒簡単なようで難しいけど、やっぱり越えなきゃならない壁。 3C（カード、対話、確認） 役割のロールをできるだけ詳しく分けるとよい ストーリーカードがすごく多くなったら？ ⇒ストーリーより粒度の大きい「エピック」のまま置いておく
Scrum Boot Camp 横浜に参加してきた - Diary of absj31
(本編終了間際、『ふりかえり』でのKPT作成資料。※なぜ『レッドブル』が置いてあるのかは後述。) 6月18日 Scrum Boot Camp 横浜(神奈川県) Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した 「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の１つで、 近年アジャイルな開発の手法として日本国内においても急速に採用事例が増えています。 一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないと いうケースも良く聞くようになりました。 そこで今回はこれからScrumを導入して開発を行うことを検討されている方もしくはトレーニングを受けない (受けさせて貰えない)ままにScrumチームに参加されている方を対象
スクラムにおけるイベントと出席者
アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります（スプリント自体もイベントですが他のイベントの入れ物なので除外しました）。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席
[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com
スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰？、スクラムマスタ
![[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/e28ac0c06090ef4280af681bdbe7af0aed6391ba/height=288;version=1;width=512/http%3A%2F%2Fwww.ryuzee.com%2Fimages%2Ffb.png)
チームサイズ・スプリント期間・プロダクトバックログアイテム数について
みなさんこんにちは。@ryuzeeです。 Peter Stevens氏が行ったオンライン調査（調査母数は85）をもとにしてチームのサイズとスプリント期間とプロダクトバックログアイテムの数におけるスプリントの成功への関連について以下で述べているので、それを元に考察してみましょう。 Success Factors in a Scrum Sprint なお、ここで言っているスプリントの成功とは以下のように定義されています。 チームのサイズとスプリント期間2週間スプリントを採用しているチームが規模に関わらずもっとも多く、半数以上を占めています。 4週間以上という回答もあるようですが、これはスクラムとしてはいただけません。 チームの規模が小さい場合や、プロダクトバックログアイテムの粒が小さい場合はさらに短い1週間スプリントは採用しやすいです。 一方で、人数が多いチームでは、必然的に開発するプロダクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
できることから始めよう
プロダクトオーナーパターン
実践知とリーダーシップ― 知識創造理論がシステム開発に及ぼしたもの
アジャイルチームへ上手く移行するには