読書会 5th 2014.12.03 ディスカッション
t-kitamura edited this page Dec 14, 2014
·
8 revisions
- **[北村]**要件の詳細化をスプリントの中でやるとして、複雑なドメインの場合は一つ一つのPBIのデリバリー期間が長くなると思うので、スプリント期間も長くなるのかな？
- **[亀田]**改良し続けるとあるが、ユーザーストーリーを改善するキッカケを作る必要はないんでしょうか？勝手に「そろそろ改善しようか」みたいなテンションになる？
-
**[北村]**スクラムでやる場合に要件定義書って作るのか？
-
**[北村]**第2回の中で作ればいいじゃないというような話が出たが、この章を読むと疑問に感じる。
-
**[北村]**基本設計やモデリングみたいなものは必要だと思うけど
-
**[北村]**もし、要件定義（要求定義）をやるとしたら、ユーザーストーリーを洗い出してから？それとも要件定義を元にユーザーストーリーを洗い出す？
-
**[北村]**ユーザーストーリーをマップにして要件定義書を作るのが良いのかな。
-
**[北村]**実際に、ユーザーストーリーの受け入れ条件ベースのATDDをやった経験はありますか？
-
[前川] 満足条件・受け入れ条件・完了の定義・開発で行うテスト、あたりの関係性がよくわかんない。
- [前川] こういった詳細化のレベルを上手く表現しようと思うと、紙のストーリーカードでは限界があるような気がする。RedmineなりZiraなりVSOなりで電子化したくならないかなー。
- [前川] 技術的ストーリーの取り扱い方の「開発チームの開発の定義が厳格なものであったら・・・」あたりで言いたいことがよくわからない。完成の定義に、例えばビルドの自動化やカバレッジ率などは暗黙的に含まれるってこと？
- **[北村]**技術的負債を解消する事をPOに価値があると認めてもらうためにはどんな手段をとっている？
- [亀田]「実装始めるのに十分なユーザーストーリーになった」とみなすのは、誰がやるとかあるんでしょうか？メンバーの判断基準は一致しているわけではないと思うんだけど、みんなが納得するユーザーストーリーができあがるものなのか？
- [亀田] 実装する人自身が納得すればいいんだという気がしてきました。実装する上で十分に詳細化されてればOKだし、まだ十分な詳細化ができてないことに気づいたら、そのときに改善する、というのでいけそう。
- **[北村]**著者は非機能要件はユーザーストーリー形式で書きだすけどプロダクトバックログには入れないと言っている？
- **[北村]**完成の定義に含められなかったものはどのように管理している？
- [前川] 実際にリスクの価値を見積もった後に、スパイクに費やすコストを評価する、ってのはあたりまえだけど分かりやすかった 👍
- **[北村]**ユーザーストーリーの収集には具体的にどんな事をやっている？
- **[北村]**ストーリーマッピングをやったことがない。やってみたい。