ユーザーストーリー:ファースト・ジェネレーション

5.5K Views

October 22, 11

スライド概要

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

ScrumGatheringTokyo2011 2011年10⽉22⽇ ワイクル株式会社取締役 ⾓征典a.k.a.kdmsnr kado.masanori@waicrew.com 1/110

2.

本⽇の想定する参加者 ソフトウェア開発の関係者である スクラム の基礎知識がある ユーザーストーリー を使ったこと がない/うまく使えない Q.「対象外の⼈はいますか?」 対象外であっても楽しんでいってください>< 2/110

3.

⾓征典-kdmsnr http://www.slideshare.net/ SukusukuScrum/no01101suc3rum20100225 3/110

4.

⾓征典-kdmsnr 4/110

5.

⾓征典-kdmsnr 鋭意翻訳中!! 5/110

6.

グループづくり できるだけ知らない⼈同⼠で うまく「多様性」ができるように n⼈のグループを作ってください 6/110

7.

ネームプレートづくり(5分) A4⽤紙でネームプレートを作ってください 1⼈ずつ⾃分の名前とその⽂字を紹介して、 グループの⼈に1⼈1⽂字ずつ書いてもらってください。 ※本名が嫌ならIDやニックネームでもOK ※⽂字数や⼈数が⾜りなければ、適宜調整してください 7/110

8.

これからお話すること ⽬標「ユーザーストーリーの 思考⽅法を⾝に付ける」 第1部:ユーザーストーリーの 物語 第2部:実例による仕様 第3部:パターン 、リーン 、ユーザ ーストーリー 8/110

9.

10分経過 13:30 残り110分 9/110

10.

第1部 ユーザーストーリーの物語 10/110

11.

⽯のスープのおはなし 『せかいいちおいしいスープ』(マーシャ・ブラウン) http://www.amazon.co.jp/dp/4001112175 11/110

12.

ユーザーストーリー のスープ それ⾃体は⼤したことがない 要求を網羅した仕様書ではない 会話のきっかけとなるもの みんなで情報や⼀時成果物を集める 最初から最終成果物はわからない 創発的(emergent)なものである 12/110

13.

XPのストーリーカード 『ExtremeProgrammingExplained:EmbraceChange 』(KentBeck)1999年 13/110

14.

<お話を聞かせてください) 開発者が要求を「記述」していて はうまくいかない。 要求の「⾃由」と「責任」をビジ ネスと分担するのがいいと思う。 ビジネスが積極的に関わってくれ るような「形」が⼤事だ。 http://c2.com/cgi/wiki? UserStoryAndUseCaseComparison 14/110

15.

ユーザーストーリーの⼿法化 『UserStoriesApplied:ForAgileSoftware Development』(MikeCohn)2004年 15/110

16.

アジャイルソフトウェア要求 『AgileSoftwareRequirements:LeanRequirements PracticesforTeams,Programs,andtheEnterprise 』(DeanLeffingwell)2011年 16/110

17.

ユーザーストーリー って何? ユーザーや顧客のシステム要求 が完 了できるように、関係者全員がわかる ⾔葉で理解していく ためのもの。 ―⾓征典 ※なかなか良い定義がなかったから⾃分で定義した!! 17/110

18.

ユーザーストーリー って何? (1)システム要求 が ビジネスとソフトウェアの間(海⾯) (2)完了できるように 終わりが⾒えなければいけない (3)理解していく ためのもの 記述ではなく段階的に共有理解する 18/110

19.

これユーザーストーリー ? 理由も⼀緒に話し合ってください(8分) 1. 2. 3. 4. 5. 6. 7. 8. アンドゥは50回まで 10/22までにシステムを利⽤可能にする 画⾯遷移なしでカートに商品を追加できる Ruby on Rails 3.1で開発する JSONでデータを出⼒する 出荷済商品を検索できる システム導⼊後の売上を1.5倍にする VOCの数値を⼊⼒する 19/110

20.

これユーザーストーリー ? 「場合による」ことが多いけど……。 1. 2. 3. 4. 5. 6. 7. 8. △ アンドゥは50回まで ✘ 10/22までにシステムを利⽤可能にする △ 画⾯遷移なしでカートに商品を追加できる ✘ Ruby on Rails 3.1で開発する △ JSONでデータを出⼒する ◯ 出荷済商品を検索できる ✘ システム導⼊後の売上を1.5倍にする △ VOCの数値を⼊⼒する 20/110

21.

25分経過 13:45 残り95分 21/110

22.

三幕構成by 1. <役割>として、 2. <対象>を(に)<⾏為>したい。 3. それは<価値>のためだ。 参考:『アジャイルな⾒積りと計画づくり』 http://www.amazon.co.jp/dp/4839924023 これは覚えて帰ってください!! 22/110

23.

三幕構成は「物語の形式」 物語を書くようにユーザーストーリーを書く 1. 設定(誰がどんな状況なのか) 2. 葛藤(何ができないのか) 3. 結末(何が⽋かせないのか) 『映画を書くためにあなたがしなくてはならないこと』 http://www.amazon.co.jp/dp/4845909278 23/110

24.

たとえば、映画「ロッキー」 1. 設定:ペットショップの店員に恋 する三流ボクサーとして、 2. 葛藤:世界チャンピオンとのタイ トルマッチに挑戦したい。 3. 結末:それは⾃分がゴロツキでは ないことを証明するためだ。 参考:http://ja.wikipedia.org/wiki/ロッキー_(映画) 24/110

25.

設定を探せ(2分) sgt2011に来てるのはどんな⼈? まずは⾃分の設定をカードに書いてみよう。 (例)スクラムに興味があるマネ ージャとして、sgt2011に⾏きたい。 25/110

26.

設定を作るヒント 既知の事実(⾃分や知⼈から) 観察やインタビュー ContextualInquiry 師匠と弟⼦モデル 葛藤から仮説→調査 勝⼿な想像でペルソナ を作るくら いなら、実在の⼈物を設定する 26/110

27.

結末を探せ(5分) sgt2011に⾏った結末は? まずは⾃分の結末をカードに書いてみよう。 続いてグループで ⾃分以外のストーリーを書いてみよう。 (例)スクラムに興味があるマネ ージャとして、sgt2011に⾏きたい。 それは実際の導⼊事例を知るためだ。 27/110

28.

設定と結末を⼤切に 葛藤はいろいろあるけれど、 物語はすべて「⾏きて帰りし物語」である。 28/110

29.

(参考)価値を重視した記法 フィーチャーインジェクションテンプレート 1. <価値>のために、 2. <役割>として、 3. <対象>を(に)<⾏為>したい。 29/110

30.

45分経過 14:05 残り75分 30/110

31.

良いユーザーストーリーとは? INVESTby BillWake [I]ndependent - ⾮依存 [N]egotiable - 交渉可能 [V]aluable - 価値がある [E]stimatable - ⾒積り可能 [S]ized Right - 適切な⼤きさ [T]estable - テスト可能 次の計画づくりに使えるかどうか が⼤事 31/110

32.

良いストーリー(物語)とは? 続きが気になるもの http://ja.wikipedia.org/wiki/シェヘラザード 32/110

33.

もっと詳しく(8分) 1⼈が⾃分のストーリーを発表して みんなでオープンクエスチョン *を してみましょう。 時間が余れば、次の⼈が⾃分の ストーリーを発表してください。 [*]答えがYES/NOにならない質問 33/110

34.

ここまでのまとめ ユーザーストーリー は、 ⽯である 物語のように三幕構成で書く 続きが気になったら質問する 34/110

35.

55分経過 14:15 残り65分 35/110

36.

第2部実例による仕様 SpecificationbyExample 36/110

37.

3⾏でいいの?楽勝www問題 いい時もあれば悪い時もある 「記述」が最終⽬標じゃないよ! 「横」が決まったら次は「縦」 37/110

38.

INVESTby BillWake テスト可能 であること 完了や受⼊が可能であること 38/110

39.

「テスト 」って⾔葉が微妙すぎ 原因はもちろん⇒ 2000年にXPメーリングリストで提 唱(その後、論争) http://c2.com/cgi/wiki?AcceptanceTest 39/110

40.

MF'sBliki-実例による仕様 XP/AgileUniverse2002でSbEに ⼼を奪われた http://capsctrl.que.jp/kdmsnr/wiki/bliki/? SpecificationByExample 40/110

41.

(例)年次有給休暇-⽇数 http://ja.wikipedia.org/wiki/年次有給休暇 41/110

42.

(例)年次有給休暇-⽇数 表にするとわかりやすい!! ※実際には有効期限(2年)があるので⾯倒だけど。 http://ja.wikipedia.org/wiki/年次有給休暇 42/110

43.

INVESTby BillWake テスト可能 であること 完了や受⼊が可能であること 実例が思い浮かぶこと ストーリーカードの裏側にメモる 43/110

44.

ストーリーの裏書こわい!! 『ナニワ⾦融道(2)』(⻘⽊雄⼆) http://www.amazon.co.jp/dp/4062605511 44/110

45.

INVESTby BillWake テスト可能 であること 完了や受⼊が可能であること 実例が思い浮かぶこと ストーリーカードの裏側にメモる 書きすぎ て契約みたいになると困る 45/110

46.

「受⼊可能」 なのに 「書きすぎない」 って何なんだよ! 46/110

47.

裏書 のヒント 47/110

48.

1.チームで⼀緒に作る 『WikiWayコラボレーションツールWiki』でチーム萌え 48/110

49.

2.実例(例えば...)から開始 テストは段階的に整理していく 49/110

50.

3.ツールの記法を参考にする いずれもユーザーの視点から(ATDD) 表形式 FIT/FitNesse,Selenium,RobotFw テキスト形式 Exactor,TextTest Gherkin(GWT)形式 Cucumber,Cuke4Nuke 50/110

51.

GWTの⽇本語化 $ cucumber --i18n ja | feature | "フィーチャ", "機能" | background | "背景" | scenario | "シナリオ" : : Given⇒前提... When⇒もし... Then⇒ならば... 51/110

52.

4.晴れの⽇と⾬の⽇のシナリオ 晴れの⽇(正常系)を中⼼に ⾬の⽇(異常系)を追加的に 降⽔確率はかなり⾼め!! 52/110

53.

(例)ATM利⽤の晴れの⽇ 顧客として、ATMからお⾦を引き出したい。 シナリオ:お⾦を正常に引き出す 前提⼝座に10万円⼊っている もし⾦額に30,000円と⼊⼒する ならば3万円が引き出されているこ と 53/110

54.

ヒント1〜4のまとめ チームで⼀緒に 実例を使いながら、 ツールの記法 を参考に 晴れと⾬を意識する。 54/110

55.

⾬の⽇のシナリオ(8分) 顧客として、ATMからお⾦を引き出したい。 シナリオ:[__________________] 前提[______________________] もし[______________________] ならば[____________]いること グループでいくつか作ってみてください。 55/110

56.

ここまでのまとめ 最初からテスト を⽬指さない 実例を使う(例:10万や3万) チーム で⼀緒に考える ⾃動化ツール の記法で考える とりあえず晴れの⽇を考える 56/110

57.

75分経過 14:35 残り45分 57/110

58.

(参考)GWTも三幕構成である 前提⼝座に10万円⼊っている ⇒状況や設定 もし⾦額に30,000円と⼊⼒する ⇒葛藤や⾏動 ならば3万円が引き出されているこ と ⇒理由や結末 58/110

59.

第3部パターン、リーン、 ユーザーストーリー 59/110

60.

「物語はありません」問題 「仮⾯ライダーW&ディケイドMOVIE対戦2010」より 60/110

61.

物語のない2つの難しさ Complicated(⼊り組んだ) 全体=合計(部分) 例:機械の部品 Complex(複雑な) 全体≠合計(部分) 例:⽣命的なもの 61/110

62.

Complicated http://www.amazon.co.jp/dp/B002YK5T9G 62/110

63.

Complex http://www.amazon.co.jp/dp/B000S0HZYG/ 63/110

64.

Complicated http://www.amazon.co.jp//dp/B004S8MKW6/ 64/110

65.

Complex http://www.amazon.co.jp/dp/B004S8MKJY ※魂を持つ「超ロボット⽣命体」 65/110

66.

2つの難しさ(3分) ⾝近にあるComplexなものと Complicatedなものについて、 グループで話し合ってください。 ※これ⾃体が「難しい」ワークショップですが>< 66/110

67.

複数の難しさに対応する クネビンフレームワーク http://en.wikipedia.org/wiki/Cynefin 67/110

68.

Complexの対応指針 何がわからないかわからない 探索→把握→対応 環境を整えて実験を繰り返す 相互交流とコミュニケーション パターン を創発する 『ハーバード・ビジネス・レビュー』2008年3⽉号 68/110

69.

パターン を創発する 69/110

70.

Complicatedの対応指針 「わからない」と認識している 把握→分析→対応 因果関係を探せば⾒つかる 意思決定に時間がかかる 『ハーバード・ビジネス・レビュー』2008年3⽉号 70/110

71.

意思決定に 時間がかかる ↓ 探せば⾒つかる 71/110

72.

ザ・トヨタウェイ:原則13 意思決定はじっくりコンセンサスを つくりながら、あらゆる選択肢を⼗分 に検討するが、実⾏は素早く⾏う(根 回し)。 72/110

73.

パターン &リーン を思い出せ 参考:http://objectclub.jp/event/2010alexande 73/110

74.

パターン 、Wiki、XP 74/110

75.

都市はツリーではない 『パターン、Wiki、XP』(江渡浩⼀郎)p.17より 75/110

76.

都市はツリーではない 『パターン、Wiki、XP』(江渡浩⼀郎)p.21より 76/110

77.

ストーリーはツリーではない ※写真はイメージです 77/110

78.

アレグザンダーの6つの原則 1. 有機的秩序の原則 2. 参加の原則 3. 漸進的成⻑の原則 4. パターンの原則 5. 診断の原則 6. 調整の原則 ※⻘⾊はユーザーストーリーと関係のある原則 参考:『パターン、Wiki、XP』(江渡浩⼀郎) 78/110

79.

17章.EPISODES 製品始動計画パターン 市場のおさらいパターン 暗黙の要求事項パターン 翻訳が悪い(Implied:暗⽰的) 作業待ち⾏列パターン 79/110

80.

ユーザーストーリーは パターン である 80/110

81.

パターン であれば、 パターンのように⽣成 ……できるはず。 81/110

82.

パターン byC.アレグザンダー ある「⽂脈」で繰り返し起きる「問 題」を「解決」する⽅法。その⽅法に はいくつかの「制約」が課せられてい るかもしれない。― 結城浩 http://www.hyuki.com/dig/patlang.html 82/110

83.

パターン の構造 83/110

84.

パターンのように⽣成する 1. うまくいっている 事例から 2. うまくいっていない 事例から 3. 理論的な側⾯から 参考:パターンランゲージ2010 Class#5PatternMining(井庭崇) http://gc.sfc.keio.ac.jp/cgi/class/class_top.cgi? 2010_25136 84/110

85.

パターンの構造と⽣成 ・ うまくいっている事例 ⇒ 「ソリューション」起点 ・ うまくいっていない事例 ⇒ 「問題」起点 ・ 理論的な側⾯ ⇒ 「⽂脈」「制約」起点 85/110

86.

(例)勤怠管理を導⼊したい テーマをソリューションに仮置きして開始 86/110

87.

(例)勤怠管理を導⼊したい それが解決しそうな問題を列挙 87/110

88.

(例)勤怠管理を導⼊したい 問題を持っていそう な⽂脈を想像 88/110

89.

(例)勤怠管理を導⼊したい ⽂脈は同時に制約を決める 89/110

90.

(例)勤怠管理を導⼊したい ソリューションを⾒直す 90/110

91.

(例)勤怠管理を導⼊したい ぐるぐる 回していく(順・逆⽅向) 91/110

92.

(参考)問題と制約の違い 切るなら「問題」 残すなら「制約」 http://www.flickr.com/photos/mrimperial/135375001/ 92/110

93.

在宅勤務を導⼊したい 4⾊カードで書き出してみてください(8分) ・ うまくいっている事例 ⇒ 「ソリューション」起点 ・ うまくいっていない事例 ⇒ 「問題」起点 ・ 理論的な側⾯ ⇒ 「⽂脈」「制約」起点 93/110

94.

在宅勤務を導⼊したい(3分) 「⽂脈」「問題」「制約」から 3枚1組の組み合わせを いくつか作ってみてください。 ※要素は重複しても構いません。 94/110

95.

パターンはボトムアップ⼿法 ボトムアップデザイン は、ソフトウ ェアがどんどん複雑化していくなか で⼀層重要になってきている。 ―『OnLisp』(ポール・グレアム) 95/110

96.

100分経過 15:00 残り20分 96/110

97.

リーン の概念 ⾃働化-品質の作り込み TDD・ATDD・CI ⾒える化・職能横断型組織 JIT-ムダ・ムラ・ムリの排除 PBI・PO・スプリント プルベース・作業の平準化 http://www.toyota.co.jp /jpn/company/vision/production_system/ 97/110

98.

Complicatedなら分割できる 5つのなぜで発掘(トップダウン) 98/110

99.

(参考)ストーリーの分割 データ境界 操作の境界 横断的な関⼼事 パフォーマンス制約 優先度 『アジャイルな⾒積りと計画づくり』12章 99/110

100.

(参考)ストーリータイプで分割 1つのストーリーの4つの側⾯ 基本機能 派⽣機能 ビジネスルール ユーザビリティ http://storyotypespaper.gerardmeszaros.com/ 100/110

101.

パターン &リーン の使い分け 「かたい」ところはリーン 把握→分析→対応 時間をかけて意思決定 ソフトウェア要求・ドメインモデル ・アーキテクチャ 「やわらかい」ところはパターン 探索→把握→対応 コミュニケーション・実験・創発 システム要求・UI・イノベーション 101/110

102.

使い⽅を間違えてはいけない 『ゆとりの法則』(トム・デマルコ)の⽅がいいなぁ 102/110

103.

ここまでのまとめ 物語がないなら2つの難しさがある ストーリーの源流はパターン だ パターンの構造を参考にして、スト ーリーをボトムアップ で⽣成する アジャイルはリーン でもある ⼊り組んで いれば、ツリーのようにト ップダウンで分割できる 103/110

104.

105分経過 15:05 残り15分 104/110

105.

参考書 105/110

106.

今⽇のまとめ ビギンズナイト・スクラムガイド ⽯・三幕構成・続きは質問 条件はみんなで実例とツールを 2つの難しさ・パターン・リーン 106/110

107.

ふりかえり(2分) 今⽇のワークショップを受けてみて、 現場に戻ってやってみたいことを 三幕構成で書いてみてください。 107/110

108.

みんなでふりかえり(5分) 108/110

109.

112分経過 15:12 残り8分 109/110

110.

何か質問はありますか?(8分) kado.masanori@waicrew.com twitter:@kdmsnr http://www.slideshare.net/kdmsnr 110/110