ユーザーと開発者が集まって、どんなシステムやサービスを実現したいかをユーザーにヒアリングします。インセプションデッキを作って、5W1H(なぜそのシステムを作ろうとしているのか、リリース時期の確認、ステークホルダーの確認)を明確にすることで、ユーザーと開発者が意識を合わせます。ユーザーが話をしているうちに、やりたいことに気づくことがあることも実際に膝を突き合わせて話をするメリットです。
ユーザーストーリーとは? 1. ユーザーストーリーとはhttp://www.flickr.com/photos/cannedtuna/4674434821/ 2. 吉羽龍太郎 (@Ryuzee) アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/ 3. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外
みなさんこんにちは。@ryuzeeです。 Roman Pichler氏によるユーザーストーリーの書き方の資料が分かりやすいので紹介します。 https://www.romanpichler.com/wp-content/uploads/2013/06/WritingGreatUserStories.pdf より良いユーザーストーリーを書くための10個のヒントシステムの利用者に焦点をあてるストーリーの記述ではユーザーロールを意識するユーザーストーリーをもとに議論するユーザーストーリーはチームとステークホルダー間の議論を活性化させるための道具ユーザーストーリーは仕様ではなく、機能に関する議論のエッセンスであるユーザーストーリーを書くのはチーム全体の仕事ユーザーストーリーを書くのに全員が協力するユーザーストーリーをより良くするために定期的にバックログリファインメントを行うシンプルに保つあいまいな
なぜ必要なのか? アジャイルにしたら全体像が見えなくなる。 なんて、よく聞くことはありませんか? スクラムの場合、製品の全体像を決めるものは、プロダクトバックログです。 プロダクトバックログを単調な優先順位とストーリーポイントのリストにしてしまうと、確かに全体像が見えにくい場合があります。 例えば、以下の様なユーザストーリーのリストを見ると、確かに少しわかりづらいです。 電子メール管理システムの場合 1.ユーザは電子メールを検索できる。 2.ユーザは電子メールをファイリングできる。 3.ユーザは電子メールをキーワードで検索できる。 4.ユーザは電子メールを移動できる。 5.ユーザはサブフォルダを作ることが出来る。なぜならそこに電子メールを移動させたいからだ。 6.ユーザはひとつのフィールドで電子メールを検索できる。 7.ユーザはひとつ以上のフィールドで電子メールを検索できる。 8.ユーザは
何年にも渡り、私は相応量の製品戦略、ロードマップ、プロジェクトガントチャートを作成しました。しかし、もうこれらの資料を作ることはありません。以下に説明する優れた代替策を見つけたからです。 まず、以前のやり方はこちらです。 注釈: 戦略 ロードマップ プロジェクトプラン 実行 アジャイル このプランニング方式だと膨大な仕事が必要です。株主全員の同意を得るだけでも大変だと言うのにROIはかなり低くなります。プランはあっという間に現実と一致しなくなり、期間が長いほど、乖離も大きくなります。私の作ったすてきなロードマップやプロジェクトガントチャートが公開する時点で既に古くなっていると気づいたのは、少し経ってからでした。このプランニングもウォーターフォールのひとつなので(有名な ウォーターフォール・モデル とは異なります)、即応性はほとんど期待できません。トップで変更があると、それが波及しボトムでの
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く