RACIマトリクスを使ってスクラムでの責任分担を見える化する
こんにちは。@ryuzeeです。 開発プロジェクトを進めるときには、ご存知の通り多くの人が関わります。一方で以前から何度か書いているようにいきなり人が集まっただけの段階だと、まだ組織やチームとしてはうまく機能せずさまざまな混乱が起こることになります。 たとえばスクラムを採用した場合で、かつスクラムに関する経験があまりない状況の場合、それぞれが持つロールを十分に果たせなかったり、そもそもどんな責任を持つべきなのかも分からずに声の大きい人の言いなりになったり、上司や外部からのコントロールを受けすぎてしまったりといった混乱も起こります。 そこで、初期の形成期や混乱期を早めに終わらせるために、それぞれの役割が持つ責任を見える化するのをお勧めします。（混乱した現場でこれをやると、想像以上に全員の認識が違うことがよく分かります） 以下の表はRACI（レイシー）マトリクスと呼ばれるものです。縦軸にタスク
InfoQ: プロダクトオーナーを成功させる
スクラムにおけるプロダクトオーナーの役割は強力ですが、それを適用するのは能力が試されることがあります。れに成功した企業は、顧客（製品管理）と開発との間の新しい健全な関係の恩恵を受けるでしょうし、競争上の優位性を経験しやすいでしょう。これには相当な代償が必要です。この役割を効果的に応用するためには、しばしば組織的な変化が必要とされます。この記事では、プロダクトオーナーの役割を上手く適用する方法に対する洞察を提供します。本稿はプロダクトオーナーとして成功するために必要なものを皆さんが理解するのを支援します。 強力な接着剤 スクラムのプロダクトオーナーは重要な役を演じます。決して昔からある役目につけた新しい名前ではなく、この役割はビジネスと開発/ITとの間の関係を再定義します。もはや要件がプロジェクトの最初に完全に述べられ、凍結され、それから開発へと引き渡されることはありません。顧客担当者がプロ
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
ストーリーポイントとファンクションポイント法の比較 - プログラマの思索
ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。 ラフなメモ書き。 【元ネタ】 InfoQ: ストーリーポイントは複雑さや時間と関係があるか？ InfoQ: ストーリーポイントとは何か？必要ものなのか？ InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする InfoQ: 価値とベロシティ、そしてバリューベロシティの比較 InfoQ: ストーリーポイントの間違った使い方。 今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。 ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。 ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。 あくまでも固有のプロジェクトでしか通用しない規模の単位。 元来、開発規
アジャイル・ブームの再来
はじめに "アジャイル"という言葉が、ソフトウエア開発現場において、広く知られています。皆さんも1度は耳にしたことがあると思います。 筆者は、開発者として、新人時代、社外常駐時代、プロジェクト・リーダー時代に、アジャイル開発に携わりました。本連載では、これらの経験から得たアジャイルの知見を示します。 第1回では、アジャイルの経緯と現状など、事前に知っておくべき内容を説明します。2000年代前半に立ち上がったアジャイルが「試行錯誤の時代」を経て再び注目されるようになった要因について解説します。 アジャイルに共通する4つの価値と12の原則 あらためて、アジャイルとは何かをおさらいします。 アジャイルとは、いくつかのソフトウエア開発手法の総称です。数多くのアジャイル開発手法が存在します。以下は、具体的なアジャイル開発手法の例です。 Agile Modeling Agile Unified Pro
RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう
Rubykaigi2010参加して本当に良かった。運営の皆様、スポンサーの皆様、参加してくださった皆様、Rubyを普段から支えてくださっている皆様。本当に有難う御座います。私もRubyに大変お世話になっていますので、少しでも私に出来ることはないかと思い、個人スポンサーとなって参加させて頂きました。そしてこのブログを残します。 本当のアジャイル 私がRubyKaigi2010に参加して一番痛感したことは、「今までの私はアジャイルをやっていなかったこと。むしろウォーターフォールに近いことをやっていた」と思い知らされたことです。 ウォーターフォールを御存知ですか？半年や１年の開発見積りを行い、それに従って開発を進めるが、見積りが合わなくなり（大抵は見積が足りない）、しかし見積は変えず、デスマーチと呼ばれる慢性的な長時間残業を行うようになり、自分への投資（技術の学習等）を行う時間を犠牲にする開発体
最近盛り上がってきた「かんばん」、ソフトウェア開発における「かんばん」（Kanban）とは何か
ここ数カ月、ソフトウェア開発の話題で「かんばん」（英語でも「Kanban」）という言葉を目にする機会が増えてきました。かんばんとは何で、どのようなものなのでしょうか？ 勉強がてら、いくつかのサイトを紹介していきましょう。 ビギナー向けの「Kanban101」 今年3月にかんばんビギナー向けのサイト「Kanban101」が立ち上がりました。このトップページがかんばんの特徴をよく表しています。 ソフトウェア開発におけるかんばんとは普通に日本語の「かんばん」のことで、誰でも見えるところに置かれて、ホワイトボードや黒板になっていて、記入したり、この画面のようにポストイットを貼って運用するのが一般的です。 かんばんの効果とは、このかんばんを模した画面に書かれているように「仕事のみえる化」「仕掛かりを減らす」「流れを見えるようにする」ということ。このサイトは英語ですが説明がとても簡潔で分かりやすいもの
スクラムを失敗させる方法
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しな
Microsoft – クラウド、コンピューター、アプリ & ゲーム
在庫限り。人気のSurface Duo 2 が再入荷され、最大 36% OFF 中。ご購入はお早めに。
スクラム（アジャイル）での「設計」と「ドキュメント」と「テスト」の位置づけについての疑問 - Natural Software
テストに関する疑問 | Ryuzee.com scrum の要素を試す中で、設計とテストのイメージできないことを、金曜日の OSC で劉爺さんたちに聞いてみたところ、このような話になった。 ウォーターフォールとスクラムでの開発の流れ 話の背景としてはウォーターフォールとスクラムでの流れの関連に対しての疑問からきている。 ウォーターフォールでの開発は一般的にこのような流れになると思う。 要件定義 → 設計 → 実装 → テスト → リリース これがスクラムではこのような流れになるというのが今の理解 バックログ策定 → 実装 ＆ 単体テスト → リリース → 実装 ＆ 単体テスト → リリース 「実装 ＆ 単体テスト → リリース」が一つのスプリントになる。 期間一か月、１スプリント、１週間のイメージはこんな感じ ここで疑問が出てきた 設計はいつやるの？ ドキュメントはいつ書くの？ システムと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Backlog Refinement Meeting - CollabNet Scrum Training Part 2
Subversion LDAP Authentication with Apache
Dreamforce 2008 : Behind-the-Scenes @ Salesforce.com R&D: How We Deliver 3 Major Releases a Year
James Shore氏「アジャイルの衰退と凋落」
スクラムのスクラムをせずにスクラムをスケールする
Scrumでの非機能的な要求の対処
Introduction To Scrum
2007-12-05 - m_pixyの読書日記