Submit Search
Upload
ユーザーストーリーの分割
•
10 likes
•
6,691 views
Arata Fujimura
Follow
AEP読書会 第十二章発表資料
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 19
Download now
Download to read offline
Recommended
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
例外設計における大罪
例外設計における大罪
Takuto Wada
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
Recommended
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
例外設計における大罪
例外設計における大罪
Takuto Wada
ゼロからはじめるプロダクトマネージャー生活
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
「顧客の声を聞かない」とはどういうことか
「顧客の声を聞かない」とはどういうことか
Yoshiki Hayama
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
Leanstartupをリーンにヤル #リーンスタートアップ
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
PFD(Process Flow Diagram)の書き方紹介
PFD(Process Flow Diagram)の書き方紹介
Noriyuki Mizuno
アジャイルジャーニー
アジャイルジャーニー
toshihiro ichitani
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
Yagi Natsuki
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
Takaaki Umada
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
Takaaki Umada
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
Takaaki Umada
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
More Related Content
What's hot
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
Yusuke Hisatsu
PFD(Process Flow Diagram)の書き方紹介
PFD(Process Flow Diagram)の書き方紹介
Noriyuki Mizuno
アジャイルジャーニー
アジャイルジャーニー
toshihiro ichitani
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
Yagi Natsuki
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
Yoshiki Hayama
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
Masahito Zembutsu
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
Takaaki Umada
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
Yoshiki Hayama
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
Takaaki Umada
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
Takaaki Umada
What's hot
(20)
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
心理的安全性を 0から80ぐらいに上げた話
心理的安全性を 0から80ぐらいに上げた話
PFD(Process Flow Diagram)の書き方紹介
PFD(Process Flow Diagram)の書き方紹介
アジャイルジャーニー
アジャイルジャーニー
ストーリーポイントで見積もるということ
ストーリーポイントで見積もるということ
アジャイルとスクラムとは 原則、価値、プラクティス
アジャイルとスクラムとは 原則、価値、プラクティス
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
テストコードの DRY と DAMP
テストコードの DRY と DAMP
ユーザーインタビューするときは、どうやらゾンビのおでましさ
ユーザーインタビューするときは、どうやらゾンビのおでましさ
IT系エンジニアのためのプレゼンテーション入門
IT系エンジニアのためのプレゼンテーション入門
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
xOps: エンジニアがスタートアップの成長の原動力となる日
xOps: エンジニアがスタートアップの成長の原動力となる日
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
「UXデザインとは」からはじめる「本流」のUXデザインはじめの一歩 | UXデザイン基礎セミナー 第1回
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
コミュニティマネジメントとは何か、なぜ今重要か / これから始めるコミュニティマネジメント入門 (1)
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
リーンスタートアップにおける良い仮説、悪い仮説
リーンスタートアップにおける良い仮説、悪い仮説
More from Arata Fujimura
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
Arata Fujimura
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
Arata Fujimura
スクラムマスター募集中
スクラムマスター募集中
Arata Fujimura
変化に強い、継続的に学習する組織に変わるためのステップとは
変化に強い、継続的に学習する組織に変わるためのステップとは
Arata Fujimura
クラスメソッドにおけるスクラム開発の光と影
クラスメソッドにおけるスクラム開発の光と影
Arata Fujimura
モダンオフショア開発のすすめ
モダンオフショア開発のすすめ
Arata Fujimura
スクラムワークショップ
スクラムワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
Arata Fujimura
登壇勉強会 〜それぞれの流儀がそこにある〜
登壇勉強会 〜それぞれの流儀がそこにある〜
Arata Fujimura
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
Arata Fujimura
PdMワークショップ
PdMワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
Experience DevOps Implementation Support Service
Experience DevOps Implementation Support Service
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
俺のレアジョブ利用法
俺のレアジョブ利用法
Arata Fujimura
DevOps導入支援、始めました
DevOps導入支援、始めました
Arata Fujimura
プラクティス厨から始めるアジャイル開発
プラクティス厨から始めるアジャイル開発
Arata Fujimura
More from Arata Fujimura
(20)
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
DevOpsを支える原則、3つの道
DevOpsを支える原則、3つの道
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
スクラムマスター募集中
スクラムマスター募集中
変化に強い、継続的に学習する組織に変わるためのステップとは
変化に強い、継続的に学習する組織に変わるためのステップとは
クラスメソッドにおけるスクラム開発の光と影
クラスメソッドにおけるスクラム開発の光と影
モダンオフショア開発のすすめ
モダンオフショア開発のすすめ
スクラムワークショップ
スクラムワークショップ
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
登壇勉強会 〜それぞれの流儀がそこにある〜
登壇勉強会 〜それぞれの流儀がそこにある〜
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
PdMワークショップ
PdMワークショップ
最高のScrumキメた後にスケールさせようとして混乱した話
最高のScrumキメた後にスケールさせようとして混乱した話
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Experience DevOps Implementation Support Service
Experience DevOps Implementation Support Service
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
俺のレアジョブ利用法
俺のレアジョブ利用法
DevOps導入支援、始めました
DevOps導入支援、始めました
プラクティス厨から始めるアジャイル開発
プラクティス厨から始めるアジャイル開発
ユーザーストーリーの分割
1.
1 2014年5月21日 GMOインターネット株式会社 次世代システム研究室 藤村 新 AEP読書会 第十二章 ユーザーストーリーの分割
2.
どんなに優先順位が高か ろうと、ユーザーストーリー の大きさが1回のイテレー ションでは完了できないの であれば、2つ以上に分 割せざるを得ない。
3.
1.ユーザーストーリーをいつ分割するのか ストーリーが大きすぎて1回のイテレーションに は収まらないような場合 いま計画を立てている次のイテレーションには もう他のストーリーが入っていて、そのストーリー を入れる余地がない 一部なら実装できるが、すべては無理 大きなストーリー(エピック)を分割するのは、よ り正確な見積りが必要な場合に有用
4.
2.データ境界に沿って分割する 例1)ユーザーとして、バランスシートの情報を入力できる ユーザーとして、バランスシートのデータをサマリで入力できる 入力項目は、資産、負債の2つ ユーザーとして、バランスシートのカテゴリごとの入力ができる 現金預金、投資有価証券、不動産、短期貸付金など ユーザーとして、入力を間違えないような入力値のバリデーションが欲 しい 負の値も入力できる、入力値の端数は自動的に四捨五入して丸 める ユーザーとして、貸付金の詳細を入力できる このストーリーで扱う詳細情報が貸付金に限定されているため小 さくなった 他のストーリーの雛形として使うことができた
5.
2.データ境界に沿って分割する 例2)自動FAXシステム システムの設定を変更可能にする 米国内の電話番号と国際電話番号とにストーリーを分割 例3)ローンの返済を処理するシステム 借主として、ローンを返済したい 借主が誤って返済額以上の小切手を送ってしまったらどうするの か? 払い戻し小切手を借主に郵送しなければならない この対応は返金額が¤2以上の場合に限られる 借主として、ローンを返済したい。このとき、払い過ぎてもかまわな い。 借主として、もし返済し過ぎてしまったら、 ¤2以上の場合に限り、 払い戻しできる。
6.
3.操作の境界で分割する 例1)きわめて複雑な検索画面 画面の上半分には数十個の入力項目 中央には入力内容を元にデータベースへのクエリを構築できるク エリビルダ その下には複雑なデータ表示用グリッド 3つに分割 1. 基本的なユーザーインターフェイス 検索条件の半分を扱う
クエリビルダ 検索結果数だけを表示 2. データ表示用のグリッド 開発にかかる時間が読めなかったため2番目にした 3. 残りの検索条件を入力する項目
7.
3.操作の境界で分割する 例1)コーチとして、チームの選手を管理できる(SwimStats) CRUD(Create, Read, Update,
Delete)操作を境界として分割 コーチとして、新しい選手をチームに追加できる コーチとして、チームの選手の情報を編集できる コーチとして、チームから抜けた選手を削除できる
8.
4.横断的な関心事を分離する 例1)データを検索して、その結果を表示する 表示する結果はそのユーザーに閲覧が許可されているデータに限定し なければならない 表示する検索結果の制約を無視する 最初のイテレーションでは、ユーザーはすべての検索結果を見 ることができる 例2)ユーザーとして、システムを利用したければユーザー名と パスワードを入力してログインしなければならない セキュアでないログインとセキュアなログインの2つのストーリーに分離 横断的な機能の別のストーリーへの分離を検討すること。 その場合、横断的な機能を含まないストーリーと、含むストー リーの2つに分けること。
9.
5.パフォーマンス制約をストーリーにする 「動くようになってから、速く動かすことを考えろ」(カーニハン &プローガー) 例)株価をグラフ表示させる 満足条件 的確な折れ線グラフ表示 データが存在しない場合の対応 パフォーマンス パフォーマンスのためのキャッシュ機能は欠かせない要素 別の新規ユーザーストーリーにして、次のイテレーションで開発する 大きなストーリーの機能要求と非機能要求とをそれぞれ個別 のストーリーに分割することを検討せよ。
10.
6.優先度に沿ってストーリーを分割する 例)ユーザーとして、システムにログインしなければならない 満足条件 ユーザーが正しいユーザー名とパスワードを入力した場合に限り、 アクセスを許可する ユーザーが間違ったパスワードを3回連続して入力するとログインで きなくなる。ログイン制限を解除するにはカスタマサービスに連絡しな ければならない ユーザーがログイン制限されたら、そのユーザーに対して、そのアカ ウントを使ってログインしようとした形跡があったことを知らせるメー ルが送信される 大きなストーリーを分割する場合には、サブストーリーの優先 度に沿って分割すること。
11.
7.ストーリーをタスクに分解してはならない 悪い例) ユーザーインターフェイスを実装する 中間層を実装する システムを「曳光弾」で照らす。(ハント&トーマス) 「曳光弾」とは、あるフィーチャに必要なシステムの論理層すべ てをまたいで実装することを指す。 大きなストーリーをタスクに分解するのではなく、ストーリーを曳 光弾にするための作戦を考えること。
12.
8.関連する変更への誘惑を断つ ストーリーを適切な大きさへと首尾よく分割できたとしても、そ こに作業を追加してしまえば、分割した意味がなくなる 「ついでにこの変更もやれるじゃないか」 他のフィーチャと同様に優先順位を付けなければならない 適切なサイズに分割したストーリーに、関連する変更を上乗せし てはならない。 ただし、関連する変更の優先度が同じ場合はこの限りではない。
13.
9.ストーリーをまとめる あらゆるストーリーを最初からなるべく小さくしておきたくな るかもしれないが、ガイドラインの狙いはそうではない。 イテレーション期間:2週間 2日から5日で完了できる大きさにストーリーを分割する のが適切 イテレーション期間:1週間 ストーリーはもう少し小さく分割した方が良い イテレーション期間:2週間以上 イテレーション期間2週間同様、2日から5日が適切 1つにまとめたストーリーは、個別の小さな見積りを足し合わせる のではなく、全体を1つの数値で見積もる。(バグレポートなど)
14.
話し合ってみよう 1. 現在の、または最近のプロ ジェクトで、分割するのが 難しかったストーリーは?こ の章を読んだ後なら、どう やって分割するだろうか?
15.
個人的回答 パスドラクローンのパズル部分 のストーリー。 「3.操作の境界で分割する」を 参考に、ページ上部のエフェクト 部分、ページ下部のパズル部分 等に分割した。
16.
17.
話し合ってみよう 2. ストーリーをタスクに分 解して、そのタスクを ユーザーストーリーのよう に扱うと、どのような問 題が起きそうだろうか?
18.
個人的回答 計画の基準がフィーチャではなく タスクになってしまい、プロダクトを 正しい視点で捉えられなくなる。 その結果、ユーザーに直接価値を 提供することができなくなる。
19.
19 おわり
Download now