第 11 章 : 敏捷工程实践


一 敏捷工程实践

实践技术

• 用户故事
• 结对编程
• TDD(测试驱动开发)
• 持续集成
• CodeReview
• 发布规则

用户故事

  • 用户故事是一个用来确认用户和用户需求的简短描述
  • 典型的描述句式为:作为一个XXX客用,我需要XXX功能,能够带来XXX好处。
  • 用户故事是站在用户角度描述需求的一种方式;
  • 每个用户故事须有对应的验收测试用例;
  • 用户故事是分层分级的,在使用过程中逐步分解细化;
关键点
I – Independent,可独立交付给客户
N – Negotiable,便于与客户交流
V - Valuable ,对客户有价值
E - Estimable ,能估计出工作量
S - Small ,分解到最底层的用户故事粒度尽量小,至少在一个迭代中能完成
T - Testable,可测试
好处
  • 站在用户视角便于和客户交流,准确描述客户需求;
  • 用户故事可独立交付单元、规模小,适于迭代开发,以获得用户快速反馈;
  • 用户故事强调编写验收测试用例作为验收标准,能促使需求分析人员准确把握需求,牵引开发人员避免过度设计。

用户故事便于团队站在用户角度分解细化需求并制定验收标准

故事样例

在这里插入图片描述

故事特征
  • 体现客户(用户)价值,轻量级的点位符
  • 遵循3C原则
 卡片(Card):作为XX,我希望XXX,这样可以XXX
 对话(Conversation):不描述到细节,由团队通过持续对话细化,激发大家的深度理解
 确认(Confirmation):有明确的验收标准

卡片

用户故事描述的传统形式是手工书写的用户故事卡,卡片上应该只有几句话来捕获需求的精髓或目的。

通常的格式:作为一个<角色>, 我想要<功能>, 以便于 <商业价值>
在这里插入图片描述

会话

会话指的是卡片上所记录的用户故事是可以进行讨论和细化的,它包括利益相关人(客户/用户)、产品负责人及开发团队之间进行更细化地讨论用户故事的可行性。用户故事经过会话确认后,才能正式进入开发阶段(用户故事实现)。

敏捷开发的流程完整体现了用户故事(需求)的流转过程

用户故事的流转过程(以Scrum为例)
  • 1.产品负责人负责整理user story,形成product backlog。
    —— 用户故事整理
  • 2.发布计划会议:product owner负责讲解user story,对其进行估算和排序,会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。
    —— 用户故事确认
  • 3.迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,终每个任务都有明确的负责人,并完成工时的初估计。
    —— 用户故事分解
  • 4.每日立会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。
    —— 用户故事实现
  • 5.演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。
    ——用户故事的二次整理

确认

  • 用户故事确认可以理解为对用户故事是否达到验收标准的检测。用户故事需要一系列的验收测试用以保证故事功能的完成及软件按照预期运行。同时要保证这个用户故事最后实现是可以带来商业价值的。
  • 用户故事的确认由测试人员完成。测试人员在测试版本所关联的用例列表里执行用例,完成测试,然后生成测试报告。
  • 测试报告是对用户故事实现程度的最直接体现。如果一个用例执行失败,可以直接由这个测试用例创建一个Bug,由开发人员进行二次开发和修复,直到测试通过。
用户故事大小级别

• 史诗故事(1-2个月)
• 特性故事(1-2周)
• 冲刺故事(1-2天)
• 任务(几小时):可分工执行

用户故事INVEST标准

  • 独立性(Independent):故事之间松耦合,具有独立性,不应该依赖于其他的用户故事。
  • 可协商(Negotiable):开始仅用于做占位符,逐步细化。
  • 有价值(Valuable):用户故事对于最终的用户是有价值的,因此应该站在用户的角度去编写。
  • 可估算(Estimatable):设计、开发、测试团队可估算工作量和成本。(不可估算的原因:太大需要分解,或信息不全需要进一步探索)
  • 短小(Small):故事应该尽量的短小(如两周冲刺,故事一般是2天以内的)
  • 可测试(Test):有相应测试验收标准。

用户故事约束(验收条件)

在这里插入图片描述

非功能性需求如何表达?

在这里插入图片描述

知识获取性故事如何表达?

在这里插入图片描述

如何收集用户故事

  • 用户故事写作研讨会,产生首批用户故事
  1. 参与者:PO、SM、Team、内部干系人、用户
  2. 方法:头脑风暴、人物角色、思维导图、故事地图
  3. 时间:几小时到几天
  • 故事地图
  1. 史诗故事按时间流横向排开
  2. 纵向按优先级排序

敏捷工程实践:结对编程

在这里插入图片描述

敏捷工程实践:测试驱动开发(TDD)

在这里插入图片描述

敏捷工程实践:持续集成(CI)

在这里插入图片描述
在这里插入图片描述

敏捷工程实践:Code Review

在这里插入图片描述

敏捷工程实践:产品发布规则

在这里插入图片描述

二 敏捷工程实践训练

在这里插入图片描述

总结

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_44627608/article/details/111313681