Ste*_*unn 8 agile extreme-programming
在设计后端系统时,您通常会为您的故事和任务提供什么样的粒度？
创建故事和任务的大多数示例通常以GUI应用程序为中心,故事是用户可以做的事情(例如,通过ISBN搜索书籍),每个任务都围绕启用此GUI功能.
在设计后端系统时,即没有用户界面但只是一堆服务与数据库,中间件等交谈的系统,您如何设计任务和故事？
Ass*_*one 12
基本上,我尝试将用户故事的大小保持在1到10个人日的范围内.这让我无法将Mike Cohn称之为"Epics"或"Themes"的内容作为用户故事传递给开发人员,而另一方面则阻止我的用户故事如此具体以至于暗示解决方案(他们应该描述问题,不应该如何解决).
就内容而言,我确保我的故事仅包含商业价值 - 它从未描述我(应该)如何满足需求,也不"需要"非用户领域知识来理解.
很好的例子:作为一名内容管理员,我希望所有用户在编写回复之前必须登录,以便拒绝他们发送垃圾邮件的能力.
错误示例:将验证码添加到网站.
另一方面,任务是解决方案的步骤 - 它们描述了需要添加/修改的组件和功能.这就是"Add Captcha"解决方案的用武之地.就尺寸而言,我试着让每个任务的大小在每天1/2到2-3天的工作之间.
任务还包括一组适用于每个功能/需求/问题/错误的标准任务,例如:
希望这有帮助,阿萨夫.