用户故事 与 TDD

用户故事 与 TDD

用户故事参考：http://www.woshipm.com/user-research/1725827.html

用户故事是需求的一种表达形式；

用户故事有三要素：
谁，干什么，有什么价值

who 谁要使用这个
what 要干嘛
why 为什么，有什么价值

一个好的用户故事需要遵守6个原则：

有价值的：让团队的每个人去思考，做的东西是否有价值；（并不是一味听取产品的，每个人都可以发表意见）

独立的： 要尽可能的让用户故事相互独立（类似单一职责原则），让用户故事的范围更加清晰，便于排出优先级，也让用户故事往更小的方向发展；

小的： 用户故事要尽可能的小，便于评估时间，减小误差；

可评估的： 计划会议里重要的一环，故事点的估计，对用户故事进行粗力度的估计，以便团队了解该用户故事的复杂度，后续开发需要尽可能按照估计的来完成；

可测试的： 用户故事是要可以测试的，以确保它的完成；要保证可测试的，就必须写验收标准
	
可协商的： 可以沟通协商调整；


用户故事实现了需求到开发的桥梁
验收标准实现需求到开发和测试的桥梁

用户故事鼓励延迟细节：我们可以先得出一个起始目标和占位意义的故事，当迭代时间紧张时，可以实现优先级高的用户故事，后续再对故事进行细化；

一个简单的用户故事参考：

用户故事和TDD

参考：https://mp.weixin.qq.com/s/KCrkL4NeuZeZvTu5Sc6B_g

TDD：测试驱动开发，简单来说就是，先写单元测试再开发，将报红的测试变成绿色，再重构，我们在编写单元测试的时候，为了满足可测试性（足够小才能测试），会引导我们对代码的结构的思考，进而驱动开发；
输出的产物是：单元测试代码

UTDD：单元测试驱动开发，UTDD按我的理解应该只是TDD代码层面的实现方式，先写单元测试再写代码；

ATDD：验收测试驱动开发，用户故事中的验收标准来驱动开发；
输出产物：验收标准

BDD：TDD是开发人员编写的程序代码，非技术人员难以参加讨论，BDD强调的是使用更通用的语言，表达用户故事，结合DDD来说，BDD适合跟领域专家一起讨论，得出更加准确的行为和通用语言；
BDD的格式，使用Given-when-then的结构
输出的产物是：测试规格书

总结：ATDD是基础，需要用户故事中明确的验收标准，进而进行到BDD对行为的再次讨论（BDD强调的是大家沟通，发掘真正的通用语言），再是UTDD单元测试的落地，而且保证代码质量和为重构提供前提；

BDD与DDD结合看待： 就是划分清楚限界上下文，发掘domain的行为，对建模提供明确的指导意义

最近自己刚从贫血模型转成带着DDD思想的充血模式，但是在编码过程中，还是常常带着面向数据的思维去思考问题，而不是面向对象去建模，这个后续需求在脑海中强化训练的；