用户故事背后的智慧

在Extreme Programming和Scrum过程中,敏捷开发团队往往用用户故事(User Story)来管理客户的需求。在传统的软件团队(使用CMM过程或者RUP)利用用例(Use Case)来管理软件系统的需求。两者本质的到底区别是什么?为什么敏捷开发都建议用用户故事来管理软件需求?
用例图通过描述角色用户与系统的交互,来描述系统的功能。很多软件开发团队往往用UML工具或者Word文档等方式使用用例图进行系统的功能设计(概要设计),然后移交给开发团队去具体实现。而用户故事从表面来看仅仅是卡片上的一句话。其实
Ron Jeffries的三C最能说明用户故事的玄机。
第一个C代表卡片(Card)。用户的需求是卡片上的一句话(“作为。。。我能。。。因此。。。”)。尽管只有简单的一句话,其实卡片背后隐含的玄机是“每个卡片代表一个要解决的问题,而不是一个功能设计实现”(当然还有很多人把很详细的需求写到了纸片上,其实他们还没有真正理解用户故事的意义)。很多软件项目的失败就是因为团队过早关注具体实现(功能实现与技术实现),还没有明白客户的真正问题是什么,就过早地进入功能设计,提出方案,从而导致设计出的系统不能满足客户的需要,扩展性不够。因此用户故事卡片其实反映了是精益思想中的推迟决定(Delaying Decisions)的思想,只有真正着手实现的时候,才开始细化,设计具体方案。
第二个C代表沟通(Communication)。用户故事卡片并不是需求,仅仅是一个Placeholder,真正的需求是在团队准备着手开发这个故事时,团队集体设计的结果。敏捷开发鼓励使用有效的沟通方式(面对面+白板),需求往往是在坐在一起的团队成员(产品负责人、开发人员、测试人员)一起参与设计,确定合适的方案,但是具体的建模方式可以是UML,可以是Word文档,也可以是白板上的图,关键是保持信息的及时有效。多数敏捷过程中都提倡使用并行开发(也就是需求,开发以及测试是同时进行,不停的向前演进)。对于一个卡片上要解决的用户问题,一般都可以有多种方案,软件团队能够在很大程度在多种功能实现方案之间权衡,使得系统能够更好的符合用户的需求,真正对客户有价值。但是设计用例往往将用例画到UML工具或者Word文档中,而且这个往往是由商务分析师负责,其他的团队成员只是参与角色。分析师做出用例之后移交给开发团队,其实是一种小的串行模式,大大加长了反馈的时间。尽管软件团队也可以用用例方式来涉及多个方案,但其实是一些小的串行开发,经济成本以及时间成本比并行开发要高不少。
第三个C代表确认(Confirmation)。这其实就是用户故事的验收条件。在敏捷团队中,测试人员以及产品负责人往往把用户故事写成客户测试(Customer Test),变成可运行的需求。因为用户故事是一个开放性的客户问题,因此需要定义一个结束条件,也就是验收标准,Confirmation其实就是起了这个作用。
总之我认为用户故事管理软件需求最大的好处就是:
  • 关注客户的问题
  • 推迟决定,尽量避免过早关注细节
  • 鼓励团队沟通
  • 鼓励并行开发

 

Share

One comment

请输入正确的验证码