• Share
  • Email
  • Embed
  • Like
  • Private Content
ユーザーストーリー:ファースト・ジェネレーション
 

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

on

  • 8,424 views

 

Statistics

Views

Total Views
8,424
Views on SlideShare
5,776
Embed Views
2,648

Actions

Likes
40
Downloads
106
Comments
4

18 Embeds 2,648

http://d.hatena.ne.jp 978
http://www.waicrew.com 534
http://capsctrl.que.jp 376
http://mj89sp3sau2k7lj1eg3k40hkeppguj6j-a-sites-opensocial.googleusercontent.com 275
http://studiosamente.wordpress.com 235
http://localhost 121
http://paper.li 47
http://a0.twimg.com 19
http://192.168.1.35 17
http://www.techgig.com 13
http://b.hatena.ne.jp 6
http://us-w1.rockmelt.com 6
http://s.deeeki.com 5
http://webcache.googleusercontent.com 5
https://si0.twimg.com 4
https://twimg0-a.akamaihd.net 3
http://tweetedtimes.com 3
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

14 of 4 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • ScrumGatheringTokyo2011 2011年10⽉22⽇ ワイクル株式会社取締役 ⾓征典a.k.a.kdmsnr ⾓征典 kdmsnrkado.masanori@waicrew.com 1/110
    • 本⽇の想定する参加者 参加者 ソフトウェア開発の関係者である ソフトウェア開発 スクラム の基礎知識がある ユーザーストーリー を使ったこと がない/うまく使えない Q.「対象外 対象外の⼈はいますか?」 対象外であっても楽しんでいってください>< 対象外 2/110
    • ⾓征典-kdmsnr kdmsnr http://www.slideshare.net/ SukusukuScrum/no01101suc3rum20100225 3/110
    • ⾓征典-kdmsnr kdmsnr 4/110
    • ⾓征典-kdmsnr kdmsnr 鋭意翻訳中!! 5/110
    • グループ グループづくりできるだけ知らない⼈同⼠ 知らない⼈同⼠でうまく「多様性 多様性」ができるようにn⼈のグループを作ってくださいn⼈ 6/110
    • ネームプレート ネームプレートづくり(5分)A4⽤紙でネームプレートを作ってください 1⼈ずつ⾃分の名前 その⽂字を紹介して、 ⾃分の名前とその⽂字グループの⼈に1⼈1⽂字ずつ 1⼈1⽂字ずつ書いてもらってください。 ※本名が嫌ならIDやニックネームでもOK※⽂字数や⼈数が⾜りなければ、適宜調整してください 7/110
    • これからお話 お話すること⽬標「ユーザーストーリーの 思考⽅法を⾝に付ける」⽬標 思考⽅法 第1部:ユーザーストーリーの 物語 第2部:実例 実例による仕様 第3部:パターン 、リーン 、ユーザ パターン リーン ーストーリー 8/110
    • 10分経過 13:30残り110分 9/110
    • 第1部ユーザーストーリーの物語 10/110
    • ⽯ のスープのおはなし おはなし『せかいいちおいしいスープ』(マーシャ・ブラウン) http://www.amazon.co.jp/dp/4001112175 11/110
    • ユーザーストーリー のスープ それ⾃体は⼤したことがない ⼤したことがない 要求を網羅した仕様書ではない 仕様書ではない 会話のきっかけ きっかけとなるもの みんなで情報 ⼀時成果物を集める 情報や⼀時成果物 最初から最終成果物はわからない わからない 創発的(emergent)なものである 創発的 12/110
    • XPのストーリーカード ストーリーカード『ExtremeProgrammingExplained:EmbraceChange 』(KentBeck)1999年 1999年 13/110
    • <お話を聞かせてください) < お話 )開発者が要求を「記述 記述」していてはうまくいかない。要求の「⾃由 ⾃由」と「責任 責任」をビジネスと分担するのがいいと思う。ビジネスが積極的に関わってくれるような「形」が⼤事だ。 形 http://c2.com/cgi/wiki? UserStoryAndUseCaseComparison 14/110
    • ユーザーストーリーの⼿法化 ⼿法化 『UserStoriesApplied:ForAgileSoftware Development』(MikeCohn)2004年 2004年 15/110
    • アジャイルソフトウェア要求 ソフトウェア要求『AgileSoftwareRequirements:LeanRequirementsPracticesforTeams,Programs,andtheEnterprise 』(DeanLeffingwell)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: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分) sgt2011に来てるのはどんな⼈? sgt2011 まずは⾃分の設定 設定をカードに書いてみよう。 (例)スクラムに興味があるマネ スクラムに興味があるマネージャとして、sgt2011に⾏きたい。ージャ 25/110
    • 設定 設定を作るヒント既知の事実 事実(⾃分や知⼈から)観察やインタビュー観察 インタビュー ContextualInquiry 師匠と弟⼦モデル葛藤から仮説→調査葛藤 調査勝⼿な想像でペルソナ を作るくら ペルソナいなら、実在の⼈物 実在の⼈物を設定する 26/110
    • 結末 結末を探せ(5分) sgt2011に⾏った結末は? sgt2011 まずは⾃分の結末 結末をカードに書いてみよう。続いてグループで ⾃分以外のストーリーを書いてみよう。 ⾃分以外のストーリー (例)スクラムに興味があるマネ スクラムに興味があるマネージャとして、sgt2011に⾏きたい。ージャそれは実際の導⼊事例を知る 実際の導⼊事例を知るためだ。 27/110
    • 設定 結末を⼤切に 設定と結末 葛藤はいろいろあるけれど、 葛藤物語はすべて「⾏きて帰りし物語 ⾏きて帰りし物語」である。 28/110
    • (参考)価値 価値を重視した記法フィーチャーインジェクションテンプレート1. <価値 価値>のために、2. <役割 役割>として、3. <対象 対象>を(に)<⾏為 ⾏為>したい。 29/110
    • 45分経過14:05残り75分 30/110
    • 良いユーザーストーリーとは?良い INVESTby INVEST BillWake [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:15残り65分 35/110
    • 第2部実例による仕様SpecificationbyExample 36/110
    • 3⾏でいいの?楽勝www3⾏ 楽勝www問題 いい時もあれば悪い時もある 「記述 記述」が最終⽬標じゃないよ! 「横」が決まったら次は「縦」 横 縦 37/110
    • INVESTby T BillWake テスト可能であること テスト可能 完了や受⼊ 完了 受⼊が可能であること 38/110
    • 「テスト テスト」って⾔葉が微妙 微妙すぎ 原因はもちろん⇒ 原因 2000年にXPメーリングリストで提唱(その後、論争) http://c2.com/cgi/wiki?AcceptanceTest 39/110
    • MFsBliki-実例 実例による仕様 XP/AgileUniverse2002で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
    • INVESTby T BillWake テスト可能であること テスト可能 完了や受⼊ 完了 受⼊が可能であること 実例が思い浮かぶこと 実例 ストーリーカードの裏側 裏側にメモる 43/110
    • ストーリーの裏書 裏書こわい!! 『ナニワ⾦融道(2)』(⻘⽊雄⼆) http://www.amazon.co.jp/dp/4062605511 44/110
    • INVESTby T BillWake テスト可能であること テスト可能 完了や受⼊ 完了 受⼊が可能であること 実例が思い浮かぶこと 実例 ストーリーカードの裏側 裏側にメモる 書きすぎて契約みたいになると困る 書きすぎ 45/110
    • 「受⼊可能 受⼊可能」 なのに「書きすぎない 書きすぎない」って何なんだよ! 46/110
    • 裏書のヒント ヒント 47/110
    • 1.チームで⼀緒 ⼀緒に作る『WikiWayコラボレーションツールWiki』でチーム萌え 48/110
    • 2.実例 例えば...)から開始 実例(例えば... テストは段階的に 段階的に整理していく 49/110
    • 3.ツールの記法 ツールの記法を参考にするいずれもユーザーの視点 ユーザーの視点から(ATDD ATDD) 表形式 FIT/FitNesse,Selenium,RobotFw テキスト形式 Exactor,TextTest Gherkin(GWT)形式 Cucumber,Cuke4Nuke 50/110
    • GWTの⽇本語化GWT ⽇本語化$ cucumber --i18n ja | feature | "フィーチャ", "機能" | background | "背景" | scenario | "シナリオ" : : G iven⇒前提 前提... W hen⇒もし もし... T hen⇒ならば ならば... 51/110
    • 4.晴れの⽇ ⾬の⽇のシナリオ 晴れの⽇と⾬の⽇ 晴れの⽇(正常系)を中⼼に 晴れの⽇ ⾬の⽇(異常系)を追加的に ⾬の⽇ 降⽔確率はかなり⾼め!! 52/110
    • (例)ATM利⽤の晴れの⽇ 晴れの⽇顧客として、ATMからお⾦を引き出したい。 シナリオ:お⾦を正常に引き出す 前提⼝座に10万円⼊っている ⼝座に10万円⼊っている もし⾦額に30,000円と⼊⼒する ⾦額に30,000円と⼊⼒する ならば3万円が引き出されているこ 3万円が引き出されているこ と 53/110
    • ヒント1〜4 1〜4のまとめ チームで⼀緒 ⼀緒に 実例を使いながら、 実例ツールの記法を参考にツールの記法晴れと⾬を意識する。晴れ ⾬ 54/110
    • ⾬の⽇ ⾬の⽇のシナリオ(8分)顧客として、ATMからお⾦を引き出したい。 シナリオ:[__________________] 前提[______________________] もし[______________________] ならば[____________]いることグループでいくつか作ってみてください。 55/110
    • ここまでのまとめ最初からテスト テストを⽬指さない実例を使う(例:10万や3万)実例チーム で⼀緒に考える⾃動化ツールの記法で考える⾃動化ツールとりあえず晴れの⽇ 晴れの⽇を考える 56/110
    • 75分経過14:35残り45分 57/110
    • (参考)GWTも三幕構成 三幕構成である 前提⼝座に10万円⼊っている ⼝座に10万円⼊っている ⇒状況や設定 状況や設定 もし⾦額に30,000円と⼊⼒する ⾦額に30,000円と⼊⼒する ⇒葛藤や⾏動 葛藤や⾏動 ならば3万円が引き出されているこ 3万円が引き出されているこ と ⇒理由や結末 理由や結末 58/110
    • 第3部パターン、リーン、ユーザーストーリー 59/110
    • 「物語 物語はありません」問題「仮⾯ライダーW&ディケイドMOVIE対戦2010」より 60/110
    • 物語のない2つ 難しさ 2つの難しさ Complicated(⼊り組んだ) Complicated 全体=合計(部分) 例:機械の部品 Complex(複雑な) Complex 全体≠合計(部分) 例:⽣命的なもの 61/110
    • Complicated http://www.amazon.co.jp/dp/B002YK5T9G 62/110
    • Complex http://www.amazon.co.jp/dp/B000S0HZYG/ 63/110
    • Complicated http://www.amazon.co.jp//dp/B004S8MKW6/ 64/110
    • Complex http://www.amazon.co.jp/dp/B004S8MKJY ※魂を持つ「超ロボット⽣命体」 65/110
    • 2つの難しさ 難しさ(3分)⾝近にあるComplex ComplexなものとComplicatedなものについて、Complicatedグループで話し合ってください。※これ⾃体が「難しい」ワークショップですが>< 66/110
    • 複数の難しさ 難しさに対応する クネビンフレームワーク http://en.wikipedia.org/wiki/Cynefin 67/110
    • Complexの対応指針Complex 何がわからないかわからない 探索→把握→対応 探索 環境を整えて実験 環境 実験を繰り返す 相互交流とコミュニケーション 相互交流 コミュニケーション パターン を創発 創発する『ハーバード・ビジネス・レビュー』2008年3⽉号 68/110
    • パターン を創発 創発する 69/110
    • Complicatedの対応指針Complicated 「わからない」と認識している 把握→分析→対応 把握 因果関係を探せば⾒つかる 因果関係 意思決定に時間がかかる 時間がかかる『ハーバード・ビジネス・レビュー』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
    • パターンbyC.アレグザンダーパターン ある「⽂脈 ⽂脈」で繰り返し起きる「問問題 」を「解決 解決」する⽅法。その⽅法にはいくつかの「制約制約」が課せられているかもしれない。― 結城浩 http://www.hyuki.com/dig/patlang.html 82/110
    • パターンの構造パターン 構造 83/110
    • パターンのように⽣成 ⽣成する1. うまくいっている 事例から2. うまくいっていない 事例から3. 理論的な側⾯から 理論的 参考:パターンランゲージ2010 Class#5PatternMining(井庭崇)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⾊カードで書き出してみてください(8分)4⾊カード・ うまくいっている事例 ⇒ 「ソリューション」起点・ うまくいっていない事例 ⇒ 「問題」起点・ 理論的な側⾯ ⇒ 「⽂脈」「制約」起点 93/110
    • 在宅勤務 在宅勤務を導⼊したい(3分)「⽂脈 ⽂脈」「問題 問題」「制約 制約」から 3枚1組の組み合わせを 3枚1組いくつか作ってみてください。 ※要素は重複しても構いません。 94/110
    • パターンはボトムアップ ボトムアップ⼿法 ボトムアップデザイン は、ソフトウェアがどんどん複雑化 複雑化していくなかで⼀層重要 ⼀層重要になってきている。―『OnLisp』(ポール・グレアム) 95/110
    • 100分経過 15:00残り20分 96/110
    • リーンの概念リーン ⾃働化-品質の作り込み ⾃働化 TDD・ATDD・CI ⾒える化・職能横断型組織 JIT-ムダ・ムラ・ムリの排除 JIT PBI・PO・スプリント プルベース・作業の平準化 http://www.toyota.co.jp /jpn/company/vision/production_system/ 97/110
    • Complicatedなら分割Complicated 分割できる 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:05残り15分 104/110
    • 参考書 105/110
    • 今⽇のまとめ まとめビギンズナイト・スクラムガイド⽯・三幕構成・続きは質問条件はみんなで実例とツールを2つの難しさ・パターン・リーン 106/110
    • ふりかえり(2分)今⽇のワークショップ ワークショップを受けてみて、現場に戻ってやってみたいことを現場三幕構成で書いてみてください。三幕構成 107/110
    • みんなでふりかえり(5分) 108/110
    • 112分経過 15:12残り8分 109/110
    • 何か質問 質問はありますか?(8分) kado.masanori@waicrew.com twitter:@kdmsnr http://www.slideshare.net/kdmsnr 110/110