【Scrum敏捷软件开发】第十四章 Sprint

“可工作的软件胜于全面的文档”。

这句话是敏捷宣言中的四大价值之一,也说明了对于每一个Sprint而言,交付一个可工作的软件非常重要。但是在短短的一个Sprint当中很难交付一个完整的应用,所以应当做到“潜在可交付”,潜在可交付有如下特征

  • 潜在可交付意味着测试过。测试过指的是经过测试,且不存在重大的问题。
  • 潜在可交付并不意味着系统功能的完整。有可能只是实现了一部分的功能特性,但是这部分功能特性是需要我们测试过的,且可运行。
  • 潜在可交付意味着集成已做好。这里的集成指的是来源于不同人不同团队的代码之间的集成。例如程序员A写的代码和程序员B写的代码组合在一起才能实现一个“潜在可交付”,那么这两份代码必须继承做好。

在每一个Sprint中都要提供一些“有价值”的东西,这里的有价值指的是对客户有价值,即客户可用的功能。这里所说的客户不代表终端客户,有可能是你所服务的“客户”。比如在我们团队中BP小组做的东西的客户可以是Integration小组。

另外一个关于Sprint的最佳体验是,在当前Sprint中抽出一定的精力为下个Sprint做好准备。而在一个Sprint中只塞入能够完成的任务量。

在一个大的团队当中,各个小团队之间应随时保持深度协作,最好不要出现产品从一个团队交到另一个团队手里,又依次传递下去的情况。这样的传递不光在团队之间需要避免,也需要避免在不同Sprint之间进行传递,也就是说不要出现“特定活动的Sprint”。特定活动的Sprint指的是某个Sprint专门做分析,下个Sprint专门做开发,再下个Sprint专门做测试,这样的体验很不好。

作为UX,自己的设计工作有点时候很难和项目其他成员的工作很好的协作。原因是传统项目中习惯将用户体验设计UI设计全部完成再开始工作。UX的设计工作是应该提前,但是也可以尽量切分成一个个小的模块进行设计。这需要很多的经验。

对于Sprint的时间性应保持绝对严格,一个Sprint的长度必须要固定,且不能出现延长。

推荐阅读更多精彩内容