sn#2 ver1.0min

スクラムナイト#2

2014.２.26

スクラム道関西


スクラムナイト#2 2

はじめに

本日はスクラム道関西のイベント、スクラムナイト#2 にお越しいただき、どうもありがとうございます！

会場を提供いただきました Yahoo!JAPAN大阪さん、どうもありがとうございます！



自己紹介

名前：宇野泰三（うのたいぞう）

職業：自称スクラムマスター

主に基幹系システムの受託開発に従事

社内外でスクラムの布教・提案活動（2013年度）

IT経営に関するコンサル（2014年度～現在）

所属：株式会社オージス総研＋スクラム道関西



本日のテーマ

4



本日のテーマ

5

プロダクトバックログの悩みを、

いっしょに解決してみませんか？



イベントの背景




スクラムを始めるにあたって、プロダクトバックログ、どうすりゃいいの？そんな質問をよく受ける。

7




確かに、スクラムガイドを読んでもいまいちピンとこない。

8




学びの場は意外と少ない。

9




CSMやCSPOでさえも、ときには腫物のように、ときにはよそよそしく扱う。

10




さわらぬ神に祟りなし、と言わんばかり。

11




決めゼリフは、「コンテキストに依存する」

（出ました！コンテキスト！！）

（よっ！コンテキスト！！）

12




確かに正解は自ら見つけないといけない。

13




なぜならスクラムはフレームワークだから。

14




そのわりには、実装サンプルがあまりにも少なすぎやしないか？

15




このままでは、世の中のコマンドラインは Goodbye, Scrum! で溢れかえってしまうではないか！

16




もう少し踏み込んでＮＮＤをぶつけ合う、そんな場が欲しい！

*1)なんやねん？なんでやねん？どないやねん！の略式表現

17

*１




そして今、スクラムナイト＃２がここにある。

18



イベントの目的




悩みや疑問をぶつけ合うことによって、参加者のプロダクトバックログに関する知識や理解を深めることを狙いとします。

20




そんなわけで本日の内容は参加者全員で検討します。

21



スクラムガイドは熟読してきましたか？

22

ところで、、




プロダクトバックログ概要

（おさらい）～スクラムガイド2013より～




プロダクトに必要なものが並べられた一覧であり、プロダクトに対する唯一の情報元

プロダクトのフィーチャ・機能・要望・修正が一覧になっている

内容・可用性（要は使い物になるかどうか）・並び順はプロダクトオーナーが責任を持つ

24




並び順が上の項目ほど詳細化されている

スプリントでの開発対象であるプロダクトバックログアイテムは「準備完了（Ready）」でなければならない

プロダクトの項目に詳細・見積・並び順を追加することをプロダクトバックログのリファインメントと呼ぶ

これは開発チームとプロダクトオーナーが協力して継続的に行う

25



プロダクトバックログリファインメント




イベントの目的達成のためのプロダクトバックログを用意しています。

プロダクトバックログの詳細化を手伝ってください。

27




初期のプロダクトバックログ

28

＃アイテム説明見積（min)

状態

１プロダクトバックログの概要を知っている

スクラムガイドに書かれている内容程度にプロダクトバックログとはどういうものかを知っている【完了の定義】スクラムガイド2013を読んでいる

？ Done

２プロダクトバックログの知識・理解がより深まっている

120

３プロダクトバックログの作成を支援できる

・・・

４プロダクトバックログについて教えることができる

今回の対象



（ステップ.1）

プロダクトバックログに関するNNDを書き出し、チーム内で共有してください。

29


？？？




すべてのチーム分を壁に張り出し、マージします

30





投票制で優先順（取り上げる順番）を決定します

31





最終的なプロダクトバックログはプロダクトオーナーが決めます :p

32


優先順



（ここまでの整理）

プロダクトバックログは、チームでメンテする

提案歓迎・交渉重要

より良い成果のために

最終的にはプロダクトオーナーが判断

33




NNDの Buzzセッション



本日出てきたNNDについて、知識や理解を深めるために、Buzzセッションの形式で議論していただこうと思います。

35

NNDのBuzzセッション



Buzzセッションとは？

ブレストの変型版

議題を取り上げ、6人チームで6分間で議論する

今日はNNDが議題となる。

人数・時間は調整可

チームの代表者は、出た意見を発表する

必ずしも意見を一つにまとめる必要は無い

36




さて、先ほどのワークでプロダクトバックログが出来上がりました

37




実はまだ出来ていません v_v.。

38




（Buzzセッションの練習）

プロダクトバックログであるためには、どうなっていないといけないのでしょう？

Buzzセッションの練習を兼ねて議論してみてください。

39




プロダクトバックログとは何か？



（おさらい）

スクラムのチーム構成

41

スクラム

マスター

開発

チーム

プロダクト

オーナー

・スクラムの理解と成立に責任を持つ。・チームのサーバントリーダーである。

・開発チームの作業とプロダクトの価値の最大化に責任を持つ・その作業は、組織・スクラムチーム・個人によって、大きく異なる・プロダクトバックログの管理に責任を持つ

・各スプリントの終わりにリリース判断可能な「完了」したプロダクトのインクリメントを届ける





大抵の仕事は、依頼と応答で進んでいきます

42

依頼

応答




（質問）

スクラム以前、開発者は作業のためのインプット情報をどこから得ていましたか？

43

開発者

？？？

依頼

応答




（例）

要件担当者

ビジネス分析者

設計担当者

プロジェクトマネージャー

技術リーダー

システムアーキテクト

顧客、オンサイト顧客（XP)

44



偉大なるスクラムの発明品

45


開発者

PO 依頼

応答

------- -------- --------

プロダクトバックログ

プロダクトオーナー（PO)は、プロダクトバックログによってのみ開発者に作業を依頼することができる。



依頼であって指示・命令ではない

提案や交渉の余地がある

依頼内容は、実施可能でなければならない

46




（質問）

みなさんは何を使ってプロダクトバックログアイテムを表現していますか？

ユースケース

ユーザーストーリー

或いは、他の何か

47




（質問）

どんなふうにプロダクトバックログアイテムを伝え／聴いていますか？

口頭でのコミュニケーション中心

ホワイトボード等で詳細ディスカッション

詳細なドキュメント（仕様書）

48




（質問）

要求と仕様の違いは分かりますか？

49




利用環境

インターフェース

要求と仕様

要求：システムを利用することで実現したいこと

要求は曖昧で移ろいやすく、そのまま実装できない

仕様：システムが何をしなければならないのかを明確化したもの

実装できるようにするために、仕様が介在する

50


システム

仕様

実装

要求



（質問）

プロダクトバックログは要求でしょうか、それとも仕様でしょうか？

51




現実のシステム開発の“システム”は、階層構造になっている。

52


--- ---

--- ---

--- ---

--- ---

--- ---

--- ---

--- --- 依頼

応答

--- ---



それぞれの階層における関心事

53


依頼

応答

抽象的概念的

具体的説明的

--- ---

--- ---

--- ---

--- ---

--- ---

--- ---

--- ---

--- ---



スクラムにおける “システム”はシンプル

54


開発者

PO 依頼

応答

------- -------- --------



チームや製品の成熟度に合わせて、依頼内容は異なってくる

共通言語の獲得

ベースとなる製品

55




プロダクトバックログを探求する




57





58

プロダクトオーナー





59






60



1 ～の管理に責任を持つ




ー終わりの始まりー



終わりの始まり



本日の振り返り



ありがとうございました！

sn#2 ver1.0min

Documents