Download as PDF, PPTX
![4. 並べる (3/5)
ブレスト結果からユーザーストーリーを作成しま
しょう。INVESTを考慮するのを忘れずに。
Independent (他のストーリーとの独立性があるか)
Negotiable (交渉の余地を残し適切な粒度か)
Valuable (顧客にとって価値があるか)
Estimable (見積り可能か)
SizedRight/Small (適切なサイズか)
Testable (テスト可能か) [役割]として
[機能など]を出来る
それは[価値・理由]の為だ
10分間 22](https://image.slidesharecdn.com/youandiws-130222100753-phpapp01/75/slide-22-2048.jpg)
Uploaded byＹｏｕ＆Ｉ
ユーザーストーリーワークショップ実践編
第50回名古屋アジャイル勉強会午後の部の発表資料 http://blogs.yahoo.co.jp/nagoya_agile_study_group/37223482.html
![[AWSマイスターシリーズ] AWS CLI / AWS Tools for Windows PowerShell](https://cdn.slidesharecdn.com/ss_thumbnails/20140115aws-meister-regenerate-awsclipowershell-140130055421-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
ユーザーストーリーワークショップ実践編
- 1. 2013/02/23(土) 第50回名古屋アジャイル勉強会 You&I ユーザーストーリー ワークショップ 実践編
- 2. ジコ、ショウカイ。 H/N： You&I(読み：ユーアンドアイ) 出身： 生まれも育ちも名古屋市 年齢： 30代中盤 本職： 商学部出身の職業プログラマ 言語： C++, C#, VB6.0, 日本語COBOL 日記： http://d.hatena.ne.jp/youandi/ 所属： プログラミング生放送 名古屋支部 名古屋アジャイル勉強会 2
- 3.
- 4.
- 5.
- 6.
- 7. ATTENTION 本資料は後日公開致します。 資料の内容について全ての メモを取る必要はありません。 セッション内容に集中して 頂ければ幸いです。 7
- 8. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 8
- 9. 1. 踏まえる (1/2) ユーザーストーリーワークショップ基礎編では、ユー ザーストーリー作成に関する基礎的な事をやりま した。 その基礎的な事を前提に午後の実践編では、 ユーザーストーリーを中心にして、どのようにして固 定されたタイムボックスの中で作業を行っていくの かを体験して頂きます。 実践編でも、お題についてユーザーストーリーを 洗い出していくやり方は同じです。 9
- 10. 1. 踏まえる (2/2) ワークショップに入る前に席替えを行います。 今回は、昨年に映画館で映画を観た回数で順 番に並んで下さい。 各テーブルに着席したら、午前のワークショップで 使った自己紹介の用紙を使って、１人１分程 度で自己紹介を行って下さい。 5分間 10
- 11. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 11
- 12. 2. 考える (1/3) 何はともかく、まずはお題から。 お題「新規OSの開発」 今回はファシリテーター役をやっている私が顧客と なります。 弊社では、最高の性能を持ったハードウェアの開 発に成功しました。 いち早く世にこのハードウェアを出す為に既存の OSを実行させてみましたが、満足のいくものでは ありませんでした。 12
- 13. 2. 考える (2/3) そこで各グループの皆さんには、このハードウェアの 性能をくまなく活かす事ができるように新規にOS の開発を行って頂きたいと思います。 何を作る必要があるのかは、プロダクトバックログ を作成して管理を行います。 まずブレインストーミングで、今回のプロダクトであ る新規OS製作について色々と案を出してみま しょう。書式は特に指定はなく自由形式とします。 13
- 14. 2. 考える (3/3) 最高性能のハードウェアを活かせるOSについて、 どのような機能・実装が必要になるかブレインス トーミングでアイデア出しをしましょう。 尚、当該ハードウェアには一般的なPC等に搭載 されている機能、HDMI、USB、無線LAN、 USBカメラ等は実装されており、またタブレット形 式の端末であり持ち運びもできるデバイスとします。 付箋紙１枚につき案を１つ書き出しましょう。 15分間 14
- 15. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 15
- 16. 3. 絞る (1/3) 製品の売りを決める為に、製品責任者(プロダク トオーナー)を決めましょう。 まずプロダクトオーナーとは・・・ 顧客に一番近い立場。でもチームの一員。 従来のやり方におけるプロジェクトマネージャーとは役 割が大きく異なる。 製品の成功に責任を持つ 製品のビジョン・ゴール・ PBI(プロダクトバックログ項目)につ いて開発チームと明確に共有し、開発チームが次にやるべ き事を明確にする。 開発チームの成果物を受け入れるかどうか判断する。 16
- 17. 3. 絞る (2/3) アジャイル開発における役割(ロール) 1. 顧客 今回は私 2. 製品責任者(プロダクトオーナー) New! 今から1人選出 3. 開発者 New! 実作業を行う人たち 4. スクラムマスター(今回はなし) 何の権限は持たないが、チームに対する干渉からチームを守る 17
- 18. 3. 絞る (3/3) 製品責任者(プロダクトオーナー)を決めるにあた り、まずはブレインストーミングした結果を同じ内 容・系列のものでグルーピングしましょう。 そして今回のお題であるOSに対して、明確なビ ジョンを持った人を製品責任者(プロダクトオー ナー)として選出しましょう。 選出に当たっては、ビジョンを決める事から始める と良いかも知れません。 5分間 18
- 19. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 19
- 20. 4. 並べる (1/5) 製品の方向性が決まったら、次はユーザーストー リーを作成しましょう。ユーザーストーリーはフィー チャーの粒度で書いていきます。 顧客のやりたい事 サーガ エピック フィーチャー エピック フィーチャー フィーチャー フィーチャー 製品の方向性が決まったら、次はユーザーストーリーを作成しましょう。 エピック エピック フィーチャー フィーチャー フィーチャー フィーチャー フィーチャー 20
- 21. 4. 並べる (2/5) フィーチャーは、エンドツーエンド(例：画面操作 ～DB登録)になっている事が望ましいです。 http://blogs.itmedia.co.jp/hiranabe/2012/09/agile-and-data-modeling.html http://www.agileproductdesign.com/downloads/patton_incremental_releases_handouts.pdf 21
- 22. 4. 並べる (3/5) ブレスト結果からユーザーストーリーを作成しま しょう。INVESTを考慮するのを忘れずに。 Independent (他のストーリーとの独立性があるか) Negotiable (交渉の余地を残し適切な粒度か) Valuable (顧客にとって価値があるか) Estimable (見積り可能か) SizedRight/Small (適切なサイズか) Testable (テスト可能か) [役割]として [機能など]を出来る それは[価値・理由]の為だ 10分間 22
- 23. 4. 並べる (4/5) ユーザーストーリーが書けたら、次は作業の優先 順位を決めましょう。 優先順位の決め方は、以下の通りです。 1. 顧客価値が高い 2. 難易度が高い(技術的・作業量的) 優先順位付けするにあたり、必ず順位は一意 になるように、上から並べ替えましょう。同列は 認めません。 10分間 23
- 24. 4. 並べる (5/5) 今回はやりませんが、優先度を決めるやり方とし て狩野モデル(かのうモデル)というものもあります。 魅力的品質と当り前品質 http://ci.nii.ac.jp/naid/110003158895 狩野モデルでは、３つのカテゴリーに分けて優先 順位付けを行います。 1. 当たり前、または必須のフィーチャー 2. 線形、一元的なフィーチャー 3. 魅力的、わくわくするフィーチャー 24
- 25. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 25
- 26. 5. 見積もる (1/10) アジャイル開発において、見積を行う際の基準と なるのがベロシティです。 ベロシティとは、チームの生産性を示す値で、固 定化されたタイムボックス(イテレーション/スプリン ト)において、そのチームが完了させる事のできた ユーザーストーリーの大きさの合計値です。 このユーザーストーリーの大きさの事をストーリーポ イントと呼びます。 26
- 27. 5. 見積もる (2/10) ベロシティはタイムボックス毎に変化する指標とな ります。開発の最初の頃はタイムボックス毎の増 減が大きいですが、開発が進むにつれて安定した 値となります。この変化を見る事でチームの状況 を知る事ができます。 アジャイル開発ではチームメンバーは固定化する 事が推奨されていますので、作業内容は変わっ たとしても、チームメンバーが同じであればベロシ ティは同じです。逆にメンバーが替わった場合はベ ロシティは変わってしまい、再計測が必要です。 27
- 28. 5. 見積もる (3/10) アジャイル開発では、開発を始める前にスパイク などを通してチームのベロシティを計測・見積した 上で作業を始めます。 今回のワークショップでは、サイコロを振って算出 した値をチームの基準とするベロシティ値として利 用します。 各テーブルで、1人１回ずつ20面体のサイコロを 振り、その平均値を算出して下さい。その際に端 数は切り捨てで計算して下さい。 2分間 28
- 29. 5. 見積もる (4/10) ユーザーストーリーの見積は・・・、 1. プロダクトオーナーと開発チームメンバーで行います。 プロダクトについての知識のある人・ない人を含めて行い、 属人性を排除した見積を行います。 2. ユーザーストーリーの見積は相対的な指標を用いて 行います。 一般的に、見積において10倍を超える規模の差が出ると、 見積の精度が悪くなります。 大小の基準を決めて三角測量にて見積を行います。 3. ストーリーポイントを決める方法としては、プランニング ポーカーが使われる事が多いです。 29
- 30.
- 31. 5. 見積もる (6/10) プランニングポーカーの数値は、フィボナッチ数列 (1・2・3・5・8・13・20・40・・・)になっています。 この数値がそのままストーリーポイントになります。 ２ptに対して5ptの作業は2.5倍の規模の差がある 事を示します。 それ以外に、自分の意思表示を行う目的のカー ドがあります。 ?,∞：見積もれない・判断できない 0：作業としては発生するが別計上だったり、本当に作 業量しては些細なもの。 31
- 32. 5. 見積もる (7/10) プランニングポーカーは色分けされているので、一 人一色ずつ持ちます。間違ってもシャッフルしない ようにして下さい(´・ω・`) ポーカーと名前が付いていますが、揃えるのは自 分の手札ではなく、チームメンバー全員の出した 札が同じになる、又は近いものになるように、ワイ ドバンド・デルファイ法(広帯域デルファイ法)を 使ってユーザーストーリーについて意見を出したり 意識合わせしながら見積ります。 32
- 33. 5. 見積もる (8/10) プランニングポーカーの前準備 小規模と大規模の指標と対象のストーリーを使って 三角測量の要領で見積を行っていきます。 小規模未満 小規模以上、大規模未満 大規模以上 最初に基準となるストーリーを２つ決めましょう。 小規模(3ポイント位) 大規模(13ポイント位) ※決めずに進める事も可 基準となったストーリーの右上にポイントを書きましょう。 33
- 34. 5. 見積もる (9/10) プランニングポーカーの進め方 1. 各ストーリーについてどのような内容なのか整理して、 コンテキストを合わせます。 2. １つストーリーを選び、それが「ストーリーポイント」幾 つになるかを各自が考えて、「せーの！」で一斉に手 札からカードを1枚出す。 3. 値が一致しなかったら、最大・最小値の人にその理 由を聞いたりして、コンテキストを合わせます。３回 繰り返して一致しなかったら後回しにします。 4. 確定したストーリーポイントは付箋紙の右上にその 値を記入しましょう。 34
- 35. 5. 見積もる (10/10) それでは早速プランニングポーカーで作業量を見 積もってみましょう。 作成したユーザーストーリーについて、まず基準と なる小規模・大規模のストーリーを決めて下さい。 そして優先度の高いものから順次見積もりを進 めて下さい。 20分間 35
- 36. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 36
- 37. 6. 見せる (1/5) ここまでのワークショップでは、プロダクトバックログ の作成を行ってきました。 1. 考える →アイデア出し 2. 絞る →目的決め 3. 並べる →優先順位付け 4. 見積もる →見積 実際のアジャイル開発(Scrum)での開発の流 れは・・・ 37
- 38. 6. 見せる (2/5) 顧客のやりたい事 プロダクト プロダクト バックログ プロダクト インクリメント スプリント バックログ レビュー グルーミング デイリー スクラム スプリント計画 プロダクトオーナーの担当 ミーティング (オプション) 開発チームの担当 スプリント レト ロスペクティブ スプリント バックログ 38
- 39. 6. 見せる (3/5) 開発作業を進める上で、プロダクトバックログやス プリントバックログの進捗状況を見える化するのに 使われるのが、バーンダウンチャートです。 アジャイル開発の源流である、リーンソフトウェア 開発において、プロジェクトをトラッキングする際に は、チェックする項目は減らすべきであるとされて います。 39
- 40. 6. 見せる (4/5) 従来のプロジェクト管理でよく使われているWBS (Work Breakdown Structure)のようなもの では、以下の項目をトラッキングしていますね。 1. 作業項目 2. 作業時間 3. 担当者 対して、バーンダウンチャートでトラッキングしてい る項目は・・・ 1. スプリント毎のストーリーポイントの残数 40
- 41. 6. 見せる (5/5) それでは早速プロダクトバックログから、スプリント 開始前のリリースバーンダウンチャートを作成して みましょう。 A3用紙を横向きにして、現在のPBI(バックログ 項目)のストーリーポイント合計値を書き込んで 下さい。 ス ト ー リ ー ポ イ ン ト スプリント 5分間 41
- 42. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 42
- 43. 7. 回す (1/13) さて、ここまでプロダクトバックログを作成して、固 定化されたタイムボックス(イテレーション/スプリン ト)で作業を進める為の準備をしてきました。 先程も紹介した、実際のアジャイル開発 (Scrum)での開発の流れは・・・ 43
- 44. 7. 回す (2/13) 顧客のやりたい事 プロダクト プロダクト バックログ プロダクト インクリメント スプリント バックログ レビュー グルーミング デイリー スクラム スプリント計画 プロダクトオーナーの担当 ミーティング (オプション) 開発チームの担当 スプリント レト ロスペクティブ スプリント バックログ 44
- 45. 7. 回す (3/13) まだほんの入り口ですね(^^;) ここから漸く本格的な実行作業に入ります。 図に示した通り、Scrumのスプリント作業は以 下の流れを繰り返し行います。 1. スプリント計画ミーティング(第1部＋第2部) 2. デイリースクラム＋日々の作業 3. スプリントレビュー 4. スプリントレトロスペクティブ(※オプション) ここで重要になってくるのが作業の完了判断です。 45
- 46. 7. 回す (4/13) Doneの定義(1/4) 今回のワークショップでは明確には行っていませんが、 ユーザーストーリーには完了条件を明確にする事がと ても重要です。INVESTではValuableやTestable がそれに当たります。そしてSized Right/Smallも重 要な要素です。 アジャイル開発では、その源流であるトヨタ生産方式 の特徴の１つである１個流し生産を受けて、作業は １つずつ完了させてから次の作業へと入ります。 これを実現する為に、作業量・作業単位の平準化と して、ユーザーストーリーを今まで作成してきました。 46
- 47. 7. 回す (5/13) Doneの定義(2/4) 相対見積で見積もられたユーザーストーリーは、理想 時間で見積もられたタスクに分割される。 １タスクは1日で完了させられる作業量が目安。 サーガ 顧客のやりたい事 エピック エピック ユーザーストーリー ユーザーストーリー エピック タスク タスク タスク タスク 製品の方向性が決まったら、次はユーザーストーリーを作成しましょう。 ユーザーストーリー タスク タスク ユーザーストーリー ユーザーストーリー タスク タスク タスク タスク 47
- 48. 7. 回す (6/13) Doneの定義(3/4) ユーザーストーリーの完了条件は、PBI作成時や、ス プリント計画ミーティング第1部などで、プロダクトオー ナーと開発チームとで合意して決めます。 そしてスプリントレビューにて、開発チームがスプリント 作業で作成したプロダクトインクリメントを受け入れる かどうかをプロダクトオーナーが判断します。 これらにより、従来の開発では「９割できました！」か らずっとそのままだったり、作業を並行して進めすぎて プロジェクト終盤にならないと、動作する成果物が出 来上がらない状況を回避します。 48
- 49. 7. 回す (7/13) Doneの定義(4/4) Doneの定義を明確にしないままスプリント作業を 行ってしまっては、緊張感もなく単なる流れ作業に なってしまいます。 そこで今回のワークショップはDoneの定義として、スプ リントの開始で１回サイコロを振って頂き、それをNG の目とします。そのスプリントのベロシティがNGの目と 同じだった場合は、そのスプリントで行ったストーリーの １つがDone出来なかったものとします。 49
- 50. 7. 回す (8/13) スプリントワークショップルール(1/2) 1. スプリント計画ミーティング第１部を行い、そのスプリ ントで行うユーザーストーリーを、先程出したチームの 基準とするベロシティ値の範囲内で決めて下さい。 2. スプリント計画ミーティング第２部で行う、ユーザース トーリーからタスクへの分解は今回は省くものとします。 3. デイリースクラムも今回は省きます。 4. 日々の作業の部分は簡略化し、チームの基準ベロ シティを算出した方法と同じく、そのスプリントのベロ シティはチームメンバーが１回ずつサイコロを振った平 均値(端数切り捨て)とします。 50
- 51. 7. 回す (9/13) スプリントワークショップルール(2/2) 5. スプリントレビューでは、Doneの定義のNGの目とそ のスプリントのベロシティの判定を行って下さい。 6. スプリントが終了したら、そのスプリントの実行結果を バーンダウンチャートに反映して下さい。その際にはベ ロシティ値もバーンダウンチャートに書き込んで下さい。 7. 以上で、１スプリント終了となります。引き続きPBI が無くなるまでスプリント作業を行って下さい。 51
- 52. 7. 回す (10/13) ス ト ー リ ー ポ イ ン ト SP0 SP1 SP2 SP3 SP4 SP5 ・・・ スプリント 13pt 12pt 15pt 17pt 10pt 20pt 52
- 53. 7. 回す (11/13) ストーリーポイントの扱い方 チームの基準ベロシティ＝１５ptの場合 1. スプリントで作業予定とするユーザーストーリーのストーリー ポイントは合計１５±３pt以内にする。大きすぎる、足り ない場合などはユーザーストーリーの分割を行いましょう。 スプリントのベロシティ＝２０ptの場合 2. NGの目でなければ、１で選択したストーリーは完了。 スプリントのベロシティ＝１０ptの場合 3. NGの目でなければ、１で選択したストーリーの内、合計１０pt 分までは完了。 スプリントのベロシティ＝NGの目の場合 4. Doneにならなかった事にするストーリーを１つ選ぶ。 53
- 54. 7. 回す (12/13) ではスプリント作業を始めてみましょう。 1. スプリントで行うストーリーを決めましょう。 2. Doneの判定サイコロを１回振りましょう。 3. メンバーが１回ずつサイコロを振りその平均値を出し てスプリントの達成ベロシティを求めましょう。 4. Doneの判定を行いましょう。 5. スプリントの最後にバーンダウンチャートも更新しま しょう。各スプリントの達成ベロシティ値をバーンダウン チャートに記入して下さい。 6. 以上をPBIがなくなるまで繰り返しましょう。 15分間 54
- 55. 7. 回す (13/13) お疲れ様でした。PBI(プロダクトバックログ項目) は全て消化できましたでしょうか？ 各テーブルで作成したプロダクトがどんなOSになっ たのか共有したいと思います。 以下の３点についてA3用紙にまとめて下さい。 発表時間は２分以内に収まるようにして下さい。 1. 何が売りのOSなのか 2. OSはどこまで完成させられたか(使えるか) 3. ユーザーストーリーを中心としたやり方はどうだったか 10分間 55
- 56. AGENDA 1. 踏まえる 2. 考える 3.絞る 4. 並べる 5. 見積もる 6. 見せる 7. 回す 8. まとめる 56
- 57. 8. まとめる (1/2) 顧客のやりたい事 プロダクト プロダクト バックログ プロダクト インクリメント スプリント バックログ レビュー グルーミング デイリー スクラム スプリント計画 プロダクトオーナーの担当 ミーティング (オプション) 開発チームの担当 スプリント レト ロスペクティブ スプリント バックログ 57
- 58. 8. まとめる (2/2) 今回は、ユーザーストーリーワークショップ実践編 として、ユーザーストーリーを主体として、固定化 されたタイムボックス作業を行っていく流れを体験 して頂きました。 今回はScrumを主体とした流れでワークショップ を行いましたが、eXtreme Programmingに おいてもほぼ同様の流れとなります。 ユーザーストーリーの作成方法や、タスクへの分 割などは一度で覚えるのは難しいです。是非皆 さんも現場でやってみましょう。 58
- 59. 参考にした文献等 アジャイルな見積りと計画づくり ISBN:978-4839924027 アジャイルなゲーム開発 ISBN:978-4797369731 スクラムガイド http://www.scrum.org/Scrum-Guides アジャイルサムライ ISBN:978-4274068560 59