我在这个敏捷软件开发系列的上一篇文章中讲述了我们团队计划sprint的过程。在这篇文章中，我将会进入执行环节，详述我们如何进行一个具体sprint的实施。在开始之前，首先来回顾一下我们是如何得到在sprint中需要实现的用户故事（UserStory）列表的：首先，团队会根据开发团队在以往sprint的经验中得出的团队开发速度评估，以及对产品待开发事项（ProductBacklog）的粗略的成本评估。基于这两个评估，开发团队从产品待开发事项中挑选出一个用户故事的候选列表，提交给产品利益相关者（St

我在这个敏捷软件开发系列的上一篇文章中讲述了我们团队计划sprint的过程。在这篇文章中，我将会进入执行环节，详述我们如何进行一个具体sprint的实施。在开始之前，首先来回顾一下我们是如何得到在sprint中需要实现的用户故事（UserStory）列表的：首先，团队会根据开发团队在以往sprint的经验中得出的团队开发速度评估，以及对产品待开发事项（ProductBacklog）的粗略的成本评估。基于这两个评估，开发团队从产品待开发事项中挑选出一个用户故事的候选列表，提交给产品利益相关者（St

全系列将涉及何为用户故事，面向客户价值编写故事，用户建模，产品待开发项的分类，故事颗粒度，故事的组织结构，等等若干问题，力求将此中问题尽量解决干净。本系列文章假设正在编写一个“敏捷开发管理软件”，因为来阅读的都是做敏捷开发的，又都是做软件的，会更熟悉一些。按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。 角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解