Embed Size (px)
Citation preview
Scrum�Gathering�Tokyo�2011Scrum�Gathering�Tokyo�20112011年10⽉22⽇
ワイクル株式会社�取締役⾓�征典⾓�征典�a.k.a.�kdmsnrkdmsnr
1/110
本⽇の想定する参加者参加者ソフトウェア開発ソフトウェア開発の関係者であるスクラムスクラムの基礎知識があるユーザーストーリーユーザーストーリーを使ったことがない／うまく使えないQ.「対象外対象外の⼈はいますか？」
対象外対象外であっても楽しんでいってください＞＜
2/110
⾓�征典�-�kdmsnrkdmsnr�
http://www.slideshare.net/SukusukuScrum/no01101suc3rum20100225
3/110
⾓�征典�-�kdmsnrkdmsnr�
4/110
⾓�征典�-�kdmsnrkdmsnr�鋭意翻訳中!!鋭意翻訳中!!
5/110
�グループグループづくりできるだけ知らない⼈同⼠知らない⼈同⼠でうまく「多様性多様性」ができるようにn⼈n⼈のグループを作ってください
6/110
�ネームプレートネームプレートづくり(5分)A4⽤紙でネームプレートを作ってください
1⼈ずつ⾃分の名前⾃分の名前とその⽂字その⽂字を紹介して、グループの⼈に1⼈1⽂字ずつ1⼈1⽂字ずつ書いてもらってください。
※�本名が嫌ならIDやニックネームでもOK※�⽂字数や⼈数が⾜りなければ、適宜調整してください
7/110
これからお話お話すること⽬標⽬標「ユーザーストーリーの思考⽅法思考⽅法を⾝に付ける」
第1部：ユーザーストーリーの物語物語第2部：実例実例による仕様第3部：パターンパターン、リーンリーン、ユーザーストーリー
8/110
10分経過
13:3013:30
残り110分
9/110
第1部第1部ユーザーストーリーの物語ユーザーストーリーの物語
10/110
⽯⽯のスープのおはなしおはなし
『せかいいち�おいしいスープ』（マーシャ・ブラウン）http://www.amazon.co.jp/dp/4001112175
11/110
ユーザーストーリーユーザーストーリーのスープそれ⾃体は⼤したことがない⼤したことがない要求を網羅した仕様書ではない仕様書ではない
会話のきっかけきっかけとなるものみんなで情報情報や⼀時成果物⼀時成果物を集める
最初から最終成果物はわからないわからない創発的創発的�（emergent）なものである
12/110
XPのストーリーカードストーリーカード�
『Extreme�Programming�Explained:�Embrace�Change』（Kent�Beck）1999年1999年
13/110
�＜＜お話お話を聞かせてください））開発者が要求を「記述記述」していてはうまくいかない。要求の「⾃由⾃由」と「責任責任」をビジネスと分担するのがいいと思う。ビジネスが積極的に関わってくれるような「形形」が⼤事だ。
http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison
14/110
ユーザーストーリーの⼿法化⼿法化�
『User�Stories�Applied:�For�Agile�SoftwareDevelopment』（Mike�Cohn）2004年2004年
15/110
アジャイルソフトウェア要求ソフトウェア要求�
『Agile�Software�Requirements:�Lean�RequirementsPractices�for�Teams,�Programs,�and�the�Enterprise
』（Dean�Leffingwell）2011年2011年
16/110
ユーザーストーリーユーザーストーリーって何？
ユーザーや顧客のシステム要求システム要求が完完了了できるように、関係者全員がわかる⾔葉で理解していく理解していくためのもの。―⾓�征典
※※なかなか良い定義がなかったから⾃分で定義した!!
17/110
ユーザーストーリーユーザーストーリーって何？(1)�システム要求システム要求がビジネスとソフトウェアの間（海⾯）
(2)�完了完了できるように終わり終わりが⾒えなければいけない
(3)�理解していく理解していくためのもの記述記述ではなく段階的に共有理解段階的に共有理解する
18/110
�これユーザーストーリーユーザーストーリー？理由理由も⼀緒に話し合ってください（8分）1. アンドゥは50回まで2. 10/22までにシステムを利⽤可能にする3. 画⾯遷移なしでカートに商品を追加できる4. Ruby on Rails 3.1で開発する5. JSONでデータを出⼒する6. 出荷済商品を検索できる7. システム導⼊後の売上を1.5倍にする8. VOCの数値を⼊⼒する
19/110
�これユーザーストーリーユーザーストーリー？「場合による場合による」ことが多いけど……。
1. △ アンドゥは50回まで2. ✘ 10/22までにシステムを利⽤可能にする3. △ 画⾯遷移なしでカートに商品を追加できる4. ✘ Ruby on Rails 3.1で開発する5. △ JSONでデータを出⼒する6. ◯ 出荷済商品を検索できる7. ✘ システム導⼊後の売上を1.5倍にする8. △ VOCの数値を⼊⼒する
20/110
25分経過
13:4513:45
残り95分
21/110
三幕構成三幕構成�by�1.� <役割役割>として、2.� <対象対象>を（に）<⾏為⾏為>したい。3.� それは<価値価値>のためだ。
参考：『アジャイルな⾒積りと計画づくり』http://www.amazon.co.jp/dp/4839924023
これは覚えて帰ってください!!これは覚えて帰ってください!!
22/110
三幕構成三幕構成は「物語物語の形式」物語を書くように物語を書くようにユーザーストーリーを書く
1.� 設定設定（誰誰がどんな状況状況なのか）2.� 葛藤葛藤（何ができないできないのか）3.� 結末結末（何が⽋かせない⽋かせないのか）『映画を書くためにあなたがしなくてはならないこと』http://www.amazon.co.jp/dp/4845909278
23/110
たとえば、映画「ロッキーロッキー」1.� 設定設定：ペットショップの店員に恋ペットショップの店員に恋する三流ボクサーする三流ボクサーとして、
2.� 葛藤葛藤：世界チャンピオンとのタイ世界チャンピオンとのタイトルマッチトルマッチに挑戦挑戦したい。
3.� 結末結末：それは⾃分がゴロツキでは⾃分がゴロツキではないことを証明するないことを証明するためだ。
参考：http://ja.wikipedia.org/wiki/ロッキー_(映画)
24/110
�設定設定を探せ（2分）sgt2011sgt2011に来てるのはどんな⼈？まずは⾃分の設定設定をカードに書いてみよう。
（例）スクラムに興味があるマネスクラムに興味があるマネージャージャとして、sgt2011に⾏きたい。
25/110
�設定設定を作るヒント既知の事実事実（⾃分や知⼈から）観察観察やインタビューインタビューContextual�Inquiry師匠と弟⼦モデル
葛藤葛藤から仮説→調査調査勝⼿な想像でペルソナペルソナを作るくらいなら、実在の⼈物実在の⼈物を設定する
26/110
�結末結末を探せ（5分）sgt2011sgt2011に⾏った結末は？
まずは⾃分の結末結末をカードに書いてみよう。続いてグループで⾃分以外のストーリー⾃分以外のストーリーを書いてみよう。
（例）スクラムに興味があるマネスクラムに興味があるマネージャージャとして、sgt2011に⾏きたい。それは実際の導⼊事例を知る実際の導⼊事例を知るためだ。
27/110
�設定設定と結末結末を⼤切に葛藤葛藤はいろいろあるけれど、
物語はすべて「⾏きて帰りし物語⾏きて帰りし物語」である。28/110
（参考）価値価値を重視した記法フィーチャーインジェクションテンプレート1.� <価値価値>のために、2.� <役割役割>として、3.� <対象対象>を（に）<⾏為⾏為>したい。
29/110
45分経過
14:0514:05
残り75分
30/110
良い良いユーザーストーリーとは？INVESTINVEST�by� �Bill�Wake
[I]ndependent - ⾮依存 [N]egotiable - 交渉可能 [V]aluable - 価値がある [E]stimatable - ⾒積り可能 [S]ized Right - 適切な⼤きさ [T]estable - テスト可能
次の計画づくりに使えるかどうか計画づくりに使えるかどうかが⼤事
31/110
良い良いストーリー（物語）とは？続き続きが気になるもの
http://ja.wikipedia.org/wiki/シェヘラザード32/110
�もっと詳しく詳しく（8分）1⼈が⾃分のストーリーを発表してみんなでオープンクエスチョンオープンクエスチョン *をしてみましょう。時間が余れば、次の⼈が⾃分のストーリーを発表してください。
[*]�答えがYES/NOにならない質問
33/110
�ここまでのまとめユーザーストーリーユーザーストーリーは、
⽯⽯である物語のように三幕構成三幕構成で書く続きが気になったら質問質問する
34/110
55分経過
14:1514:15
残り65分
35/110
第2部�実例による仕様第2部�実例による仕様Specification�by�ExampleSpecification�by�Example
36/110
3⾏3⾏でいいの？楽勝www楽勝www問題いい時もあれば悪い時もある「記述記述」が最終⽬標じゃないよ！「横横」が決まったら次は「縦縦」
37/110
INVESTT�by� �Bill�Wakeテスト可能テスト可能であること完了完了や受⼊受⼊が可能であること
38/110
「テストテスト」って⾔葉が微妙微妙すぎ原因原因はもちろん�⇒�
2000年にXPメーリングリストで提唱（その後、論争）
http://c2.com/cgi/wiki?AcceptanceTest
39/110
MF's�Bliki�-�実例実例による仕様
XP/Agile�Universe�2002でSbEに⼼を奪われた
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?SpecificationByExample
40/110
（例）年次有給休暇�-�⽇数
http://ja.wikipedia.org/wiki/年次有給休暇
41/110
（例）年次有給休暇�-�⽇数表表にするとわかりやすい!!
※実際には有効期限（2年）があるので⾯倒だけど。http://ja.wikipedia.org/wiki/年次有給休暇
42/110
INVESTT�by� �Bill�Wakeテスト可能テスト可能であること完了完了や受⼊受⼊が可能であること
実例実例が思い浮かぶことストーリーカードの裏側裏側にメモる
43/110
ストーリーの裏書裏書こわい!!
『ナニワ⾦融道�(2)』（⻘⽊雄⼆）http://www.amazon.co.jp/dp/4062605511
44/110
INVESTT�by� �Bill�Wakeテスト可能テスト可能であること完了完了や受⼊受⼊が可能であること
実例実例が思い浮かぶことストーリーカードの裏側裏側にメモる書きすぎ書きすぎて契約みたいになると困る
45/110
「受⼊可能受⼊可能」なのに
「書きすぎない書きすぎない」って何なんだよ！
46/110
裏書裏書のヒントヒント
47/110
1.�チームで⼀緒⼀緒に作る
『Wiki�Way�コラボレーションツールWiki』でチーム萌え
48/110
2.�実例実例（例えば...例えば...）から開始テストは段階的に段階的に整理していく
49/110
3.�ツールの記法ツールの記法を参考にするいずれもユーザーの視点ユーザーの視点から（ATDDATDD）表形式FIT/FitNesse,�Selenium,�Robot�Fw
テキスト形式Exactor,�TextTest
Gherkin（GWT）形式Cucumber,�Cuke4Nuke
50/110
GWTGWTの⽇本語化⽇本語化$ cucumber --i18n ja | feature | "フィーチャ", "機能" | | background | "背景" | | scenario | "シナリオ" | : :
GGiven�⇒�前提前提�...WWhen�⇒�もしもし�...TThen�⇒�ならばならば�...
51/110
4.�晴れの⽇晴れの⽇と⾬の⽇⾬の⽇のシナリオ晴れの⽇晴れの⽇（正常系）を中⼼に⾬の⽇⾬の⽇（異常系）を追加的に
降⽔確率はかなり⾼め!!
52/110
（例）ATM利⽤の晴れの⽇晴れの⽇顧客として、ATMからお⾦を引き出したい。シナリオ:�お⾦を正常に引き出す前提�⼝座に10万円⼊っている⼝座に10万円⼊っているもし�⾦額に30,000円と⼊⼒する⾦額に30,000円と⼊⼒するならば�3万円が引き出されているこ3万円が引き出されていることと
53/110
ヒント1〜41〜4のまとめ
チームで⼀緒⼀緒に実例実例を使いながら、ツールの記法ツールの記法を参考に晴れ晴れと⾬⾬を意識する。
54/110
�⾬の⽇⾬の⽇のシナリオ（8分）顧客として、ATMからお⾦を引き出したい。シナリオ:�[__________________]前提［______________________］もし［______________________］ならば［____________］いること
グループでいくつか作ってみてください。55/110
�ここまでのまとめ最初からテストテストを⽬指さない実例実例を使う（例：10万や3万）チームチームで⼀緒に考える⾃動化ツール⾃動化ツールの記法で考えるとりあえず晴れの⽇晴れの⽇を考える
56/110
75分経過
14:3514:35
残り45分
57/110
（参考）GWTも三幕構成三幕構成である前提�⼝座に10万円⼊っている⼝座に10万円⼊っている⇒�状況や設定状況や設定もし�⾦額に30,000円と⼊⼒する⾦額に30,000円と⼊⼒する⇒�葛藤や⾏動葛藤や⾏動ならば�3万円が引き出されているこ3万円が引き出されていることと⇒�理由や結末理由や結末
58/110
第3部�パターン、リーン、第3部�パターン、リーン、ユーザーストーリーユーザーストーリー
59/110
「物語物語はありません」問題
「仮⾯ライダー�W＆ディケイド�MOVIE対戦2010」より60/110
物語のない2つ2つの難しさ難しさComplicatedComplicated（⼊り組んだ）全体�＝�合計(部分)例：機械の部品
ComplexComplex（複雑な）全体�≠�合計(部分)例：⽣命的なもの
61/110
ComplicatedComplicated
http://www.amazon.co.jp/dp/B002YK5T9G
62/110
ComplicatedComplicated
http://www.amazon.co.jp//dp/B004S8MKW6/
64/110
ComplexComplex
http://www.amazon.co.jp/dp/B004S8MKJY※魂を持つ「超ロボット⽣命体」
65/110
�2つの難しさ難しさ（3分）⾝近にある�ComplexComplex�なものとComplicatedComplicated�なものについて、グループで話し合ってください。※�これ⾃体が「難しい」ワークショップですが＞＜
66/110
複数の難しさ難しさに対応するクネビンフレームワーククネビンフレームワーク
http://en.wikipedia.org/wiki/Cynefin
67/110
ComplexComplexの対応指針何がわからないかわからない探索探索�→�把握�→�対応環境環境を整えて実験実験を繰り返す相互交流相互交流とコミュニケーションコミュニケーションパターンパターンを創発創発する『ハーバード・ビジネス・レビュー』2008年3⽉号
68/110
パターンパターンを創発創発する
69/110
ComplicatedComplicatedの対応指針「わからない」と認識している把握把握�→�分析�→�対応因果関係因果関係を探せば⾒つかる意思決定に時間がかかる時間がかかる『ハーバード・ビジネス・レビュー』2008年3⽉号
70/110
意思決定に時間がかかる時間がかかる
↓�探せば⾒つかる
71/110
ザ・トヨタウェイ：原則13
意思決定意思決定はじっくりコンセンサスをつくりながら、あらゆる選択肢あらゆる選択肢を⼗分に検討するが、実⾏は素早く⾏う実⾏は素早く⾏う（根回し）。
72/110
パターンパターン＆リーンリーンを思い出せ�
参考：http://objectclub.jp/event/2010alexande
73/110
パターンパターン、Wiki、XP�
74/110
都市はツリーツリーではない
『パターン、Wiki、XP』（江渡浩⼀郎）p.17より
75/110
都市はツリーツリーではない
『パターン、Wiki、XP』（江渡浩⼀郎）p.21より
76/110
ストーリーはツリーツリーではない
※写真はイメージです
77/110
アレグザンダーの6つの原則6つの原則1.� 有機的秩序の原則有機的秩序の原則2.� 参加の原則参加の原則3.� 漸進的成⻑の原則4.� パターンの原則パターンの原則5.� 診断の原則6.� 調整の原則※⻘⾊⻘⾊はユーザーストーリーと関係のある原則参考：『パターン、Wiki、XP』（江渡浩⼀郎）
78/110
�17章.�EPISODES�製品始動計画パターン市場のおさらいパターン暗黙の要求事項パターン暗黙の要求事項パターン翻訳が悪い（Implied：暗⽰的暗⽰的）
作業待ち⾏列パターン79/110
ユーザーストーリーはパターンパターンである
80/110
パターンパターンであれば、パターンのように⽣成パターンのように⽣成……できるはず。
81/110
パターンパターン�by�C.�アレグザンダー
ある「⽂脈⽂脈」で繰り返し起きる「問問題題」を「解決解決」する⽅法。その⽅法にはいくつかの「制約制約」が課せられてい
るかもしれない。― 結城浩
http://www.hyuki.com/dig/patlang.html
82/110
パターンパターンの構造構造
83/110
パターンのように⽣成⽣成する1.� うまくいっているうまくいっている事例から2.� うまくいっていないうまくいっていない事例から3.� 理論的理論的な側⾯から
参考：パターンランゲージ2010Class�#5�Pattern�Mining（井庭�崇）
http://gc.sfc.keio.ac.jp/cgi/class/class_top.cgi?2010_25136
84/110
パターンの構造構造と⽣成⽣成・ うまくいっている事例 ⇒ 「ソリューション」起点・ うまくいっていない事例 ⇒ 「問題」起点・ 理論的な側⾯ ⇒ 「⽂脈」「制約」起点
85/110
（例）勤怠管理勤怠管理を導⼊したいテーマをソリューションソリューションに仮置き仮置きして開始
86/110
（例）勤怠管理勤怠管理を導⼊したいそれが解決しそう解決しそうな問題問題を列挙
87/110
（例）勤怠管理勤怠管理を導⼊したい問題を持っていそう持っていそうな⽂脈⽂脈を想像
88/110
（例）勤怠管理勤怠管理を導⼊したい⽂脈は同時に制約制約を決める決める
89/110
（例）勤怠管理勤怠管理を導⼊したいソリューションソリューションを⾒直す⾒直す
90/110
（例）勤怠管理勤怠管理を導⼊したいぐるぐるぐるぐる回していく（順・逆⽅向）
91/110
（参考）問題問題と制約制約の違い
切るなら「問題問題」残すなら「制約制約」
http://www.flickr.com/photos/mrimperial/135375001/
92/110
�在宅勤務在宅勤務を導⼊したい4⾊カード4⾊カードで書き出してみてください（8分）・ うまくいっている事例 ⇒ 「ソリューション」起点・ うまくいっていない事例 ⇒ 「問題」起点・ 理論的な側⾯ ⇒ 「⽂脈」「制約」起点
93/110
�在宅勤務在宅勤務を導⼊したい(3分)「⽂脈⽂脈」「問題問題」「制約制約」から3枚1組3枚1組の組み合わせを
いくつか作ってみてください。※�要素は重複しても構いません。
94/110
パターンはボトムアップボトムアップ⼿法
ボトムアップデザインボトムアップデザインは、ソフトウェアがどんどん複雑化複雑化していくなかで⼀層重要⼀層重要になってきている。―�『On�Lisp』（ポール・グレアム）
95/110
100分経過
15:0015:00
残り20分
96/110
リーンリーンの概念⾃働化⾃働化�-�品質の作り込みTDD・ATDD・CI⾒える化・職能横断型組織
JITJIT�-�ムダ・ムラ・ムリの排除PBI・PO・スプリントプルベース・作業の平準化
http://www.toyota.co.jp/jpn/company/vision/production_system/
97/110
ComplicatedComplicatedなら分割分割できる5つのなぜ5つのなぜで発掘（トップダウン）
98/110
（参考）ストーリーの分割分割データ境界操作の境界横断的な関⼼事パフォーマンス制約優先度『アジャイルな⾒積りと計画づくり』12章
99/110
(参考)�ストーリータイプストーリータイプで分割分割1つのストーリーの4つ4つの側⾯
基本機能派⽣機能ビジネスルールユーザビリティhttp://storyotypespaper.gerardmeszaros.com/
100/110
パターンパターン＆リーンリーンの使い分け「かたい」ところはリーンリーン把握把握�→�分析�→�対応時間をかけて意思決定ソフトウェア要求・ドメインモデル・アーキテクチャ
「やわらかい」ところはパターンパターン探索探索�→�把握�→�対応コミュニケーション・実験・創発システム要求・UI・イノベーション
101/110
使い⽅使い⽅を間違えてはいけない
『ゆとりの法則』（トム・デマルコ）の⽅がいいなぁ
102/110
�ここまでのまとめ物語物語がないなら2つの難しさ難しさがあるストーリーの源流はパターンパターンだパターンの構造構造を参考にして、ストーリーをボトムアップボトムアップで⽣成する
アジャイルはリーンリーンでもある⼊り組んで⼊り組んでいれば、ツリーのようにトトップダウンップダウンで分割できる
103/110
105分経過
15:0515:05
残り15分
104/110
参考書
105/110
�今⽇のまとめまとめビギンズナイト・スクラムガイド⽯・三幕構成・続きは質問条件はみんなで実例とツールを2つの難しさ・パターン・リーン
106/110
�ふりかえり（2分）今⽇のワークショップワークショップを受けてみて、現場現場に戻ってやってみたいことを三幕構成三幕構成で書いてみてください。
107/110
�みんなでふりかえり（5分）
108/110
112分経過
15:1215:12
残り8分
109/110
