Soumettre la recherche
Mettre en ligne
ユーザーストーリーの分割
•
10 j'aime
•
6,695 vues
Arata Fujimura
Suivre
AEP読書会 第十二章発表資料
Lire moins
Lire la suite
Ingénierie
Signaler
Partager
Signaler
Partager
1 sur 19
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
例外設計における大罪
例外設計における大罪
Takuto Wada
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
Recommandé
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
シリコンバレーの「何が」凄いのか
シリコンバレーの「何が」凄いのか
Atsushi Nakada
ユーザーストーリー駆動開発で行こう。
ユーザーストーリー駆動開発で行こう。
toshihiro ichitani
例外設計における大罪
例外設計における大罪
Takuto Wada
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
ゼロから始める転移学習
ゼロから始める転移学習
Yahoo!デベロッパーネットワーク
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
sairoutine
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
Ore Product
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
ota42y
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
クラスメソッドベトナム設立しました
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
Contenu connexe
Tendances
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
Recruit Technologies
ゼロから始める転移学習
ゼロから始める転移学習
Yahoo!デベロッパーネットワーク
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
sairoutine
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
Yoshiyasu SAEKI
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
Ore Product
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
NTT DATA Technology & Innovation
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
Arata Fujimura
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
Reimi Kuramochi Chiba
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
ota42y
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Tokoroten Nakayama
Tendances
(20)
ビッグデータ処理データベースの全体像と使い分け
ビッグデータ処理データベースの全体像と使い分け
ゼロから始める転移学習
ゼロから始める転移学習
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
CEDEC2019 大規模モバイルゲーム運用におけるマスタデータ管理事例
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
ストリーム処理を支えるキューイングシステムの選び方
ストリーム処理を支えるキューイングシステムの選び方
オーバーエンジニアリングって何? #devsumi #devsumiA
オーバーエンジニアリングって何? #devsumi #devsumiA
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
入門 Kubeflow ~Kubernetesで機械学習をはじめるために~ (NTT Tech Conference #4 講演資料)
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
アジャイルな見積りと計画づくり勉強会
アジャイルな見積りと計画づくり勉強会
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
TLS, HTTP/2演習
TLS, HTTP/2演習
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
エンジニアから飛んでくるマサカリを受け止める心得
エンジニアから飛んでくるマサカリを受け止める心得
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Plus de 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
Plus de 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 おわり
Télécharger maintenant