敏捷开发中，团队成员认领的是任务还是用户故事？
一次敏捷workshop上，有同学问：“敏捷软件开发中，团队成员自己主动认领的，是用户故事还是被分解成的任务？”同学们一时讨论热烈。
稍具敏捷开发实践经验的同学都应该知道，答案是——任务（Task）。
但我们不想就此打住。让我们从以下几个方面来探讨一下这背后的原因。
用户故事和任务
敏捷团队
敏捷需求估算
敏捷迭代的跟踪与管理
用户故事和任务
用户故事（User Story）和任务（Task）[1]是敏捷开发中管理和跟踪用户需求的主要工具。用户故事是首创于极限编程（XP）的管理用户需求的基本方法，目前已广为各个敏捷实践方法和技术所借鉴和使用。Scrum将用户故事作为最基本的需求管理工具，组成了称之为产品待办事项列表（Product Backlog）的用户需求列表。
用户故事从用户的角度描述用户渴望得到的功能和实现的价值。一个好的用户故事包括三个基本要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能以及这个功能带来什么样的价值。
用户故事关注的是交付给客户的最终价值，也就是能给客户带来什么样的最终效益。换句话说，用户故事面向的是具体客户的需求，而不太关心开发团队要怎样才能实现这个需求。用户故事不关心具体实现，使得它不关注具体的细节，因而有时候一个用户故事的粒度很大，甚至会有史诗故事（epic）；有时候一个用户故事的粒度有很小，可能一个小的软件缺陷（defect）也能作为一个用户故事。
而软件团队最终需要把承诺的用户故事，转变为可工作的软件，即使用具体的开发语言和工具，实现用户故事。可工作的软件才是敏捷开发真正关注的核心。软件团队需要和产品负责人（Product Owner）及Scrum Master一起，分析、评估具体的用户故事，详细、深入地了解用户故事所传达的用户价值，讨论该用户故事的故事点数（Story Point）以及具体的工作量，实现该用户故事所要做的事情，把这些事情分解为具体的任务，比如逻辑设计、数据库设计、界面设计、编码、测试（或自动化测试）、集成、验收测试、部署等工作。
由用户故事分解而来的具体任务，关注于该如何实现该用户故事而必须完成的工作，关注的是具体的技术细节和实现方法。不同的任务具有不同的技术要求，比如开发任务要求的是更加专业和高效的代码实现能力，而测试工作则专注于如何测试该实现以确保最终交付的可工作软件真正实现用户故事所体现的客户价值。因而每个任务的具体技术要求可能都不一样。
由此可见，团队成员更倾向于专注于具体的工作任务和自己专长的领域，而任务则正好适合团队成员专注于某个具体领域并培养自己在该领域的专长。团队成员主动认领自己擅长的任务并高效、高质量地完成之，也是符合敏捷开发原则的最佳做法。
敏捷团队
通常意义上，敏捷软件团队是指遵循敏捷宣言的精神和敏捷实践的具体原则，运用敏捷软件开发相关的技术、方法、工具和流程，从事软件开发和交付的自组织、跨功能团队。《Scrum Guide》[1]指出，Scrum团队包含产品负责人、开发团队和Scrum Master。Scrum团队是自组织且跨功能的。自组织团队选择如何最好地完成他们的工作，而不是由团队外的其他人来指使他们。而跨功能团队拥有完成工作所需要的全部技能，不需要依赖团队外部的人员即可完成开发和交付软件所需要的全部工作。Scrum团队模式的目的是最大限度地优化适应性、创造性和生产力。
由此我们知道，跨功能团队包括了完成软件开发和交付工作所需要的全部技能类别，开发、测试、QA、需求、设计、用户体验、数据库等。虽然当前“全栈工程师”的概念颇为流行，但随着现代软件工程向着更加精细的专业化、分工化发展，每一个细分的专业方向都差别巨大。后台数据库的设计和开发与前端界面的美丑、布局是否合理等，不仅仅体现在用户能接触到的多少。一个工程师不可能了解和掌握开发和交付软件所需要的全部技能。因而团队必然是各种技能工程师的组合，大家每人专注于开发和交付高客户价值软件所需要的各个方面，需求、编码、测试、设计、界面优化、用户体验等人员的工作紧密配合、相互协作才能交付高质量的软件。
纯理论上的跨功能团队有时也要求团队成员彼此在技能上尽量缩小差距，不同角色的成员了解和掌握其他角色成员所具备的技能，以便在需要的时候能够担负相应的职责。但从具体实践来讲，团队成员可以了解别的角色的技能，比如开发了解测试，测试工程师学习开发技术等，但精通掌握另一个角色的技能还是有比较大难度的。要想交付高质量软件，每个团队成员必须在自己最擅长的领域做出最可靠和最高效的贡献。专注于某一个具体技术领域，专注才能达到专业，专业才能高质量和高效。所以，敏捷团队必须能够让每个成员都能够在自己专长的工作上发挥最大功效，才能真正成为高效的自组织团队。因此，编码的Task不太可能由测试人员负责，而前端设计类任务也最好由擅长前端设计的人员来负责。
用户故事专注于交付给客户的具体价值，也就是该用户故事能够帮助客户实现什么样的功能和成就。而为实现用户故事，通常会把用户故事分解为一系列要完成的任务，比如最常见的设计、编码、测试、集成、部署等。所以不同角色的团队成员主动认领自己最擅长的任务并高效完成之，是最合理和高效的做法。
敏捷需求估算
产品负责人（Product Owner）根据来自各渠道收集到的信息，整理并创建出称之为产品待办事项的用户故事列表。而开发团队则负责将经过产品负责人整理和按照优先级排序了的用户故事转变为最终的可工作软件。在这个过程中，软件团队需要和产品负责人一道，分析具体的用户故事，评估实现该用户故事所需要完成的工作，估算具体的工作量。而后软件团队需要在每个迭代开始时，将承诺的用户故事分解为具体的任务。因而该过程需要完成2件事情：1）估算用户故事的故事点；2）将用户故事分解为任务。
敏捷参与者分为“鸡”和“猪”两种角色。“鸡”的角色者，参与项目工作，但不承诺任何结果。就Scrum而言，“鸡”并不是实际Scrum过程的一部分，但是必须考虑他们。“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。就像关于“鸡”和“猪”的那个经典笑话里所说的，“猪”要把自己身上的肉贡献出来。敏捷开发中需要的角色包括Product Owner、Scrum Master、Developer、需求、UI/UX、测试、部署等。一般的Scrum开发团队中，通常将Scrum Owner（产品经理）、Scrum Master（项目经理）、Developer、需求分析师作为猪类角色，而测试工程师、UI/UX工程师、QA、客户等作为鸡类角色。
“猪”类角色将用户故事估算完毕，所有的用户故事在经过Product Owner的排序之后，组成了产品待办事项列表。在每个Sprint的Sprint计划中，包括“鸡”类角色在内的团队针对优先级最高的用户故事，进行讨论、分析，并将之分解为一个个的任务，这些任务细化到实现和交付用户故事所需要采取的每一个步骤。不同的团队角色都要对用户故事的实现和交付做出必要的贡献。这个时候，每个角色根据自己的能力和优势，认领相应的任务，并估计自己所认领任务的工作时间。这就是“谁承诺任务，谁负责任务，谁估算任务”，因为“做这个事情的那个人是最了解那个任务的人，也是最适合对之做出估计的人”。
敏捷迭代的跟踪与管理
敏捷开发中，通常使用任务板来可视化地展示各个用户故事和相应任务的进展情况，并据此画出相应的Sprint 燃尽图（Burndown chart）[3]。作为敏捷开发中任务完成情况的可视化展示，任务板和燃尽图直观而生动地展示出了项目团队在目前工作上的进展情况和预期进展。
有些团队的任务板包括用户故事、任务列表、未开始的任务、已开始的任务（WIP）、完成的任务等。有些团队为了突出彰显任务的承诺者，还会在每个任务上写上认领者的名字，甚至贴上认领者的照片。
从迭代计划的跟踪和管理的角度看，敏捷团队需要跟踪和度量每个任务的完成情况。只有在按照团队“完成”（DoD， Definition of Done）要求，完成了DoD中所要求的全部任务时，一个用户故事才算完成。在IBM RTC里面，度量每个任务的完成时间。而每个任务是跟踪到团队角色的。所以，每个团队角色所认领的，也只是由用户故事分解而来的任务，而不是用户故事。
总结
用户故事专注于团队需要交付给客户的用户价值，而任务则关注于实现和交付由用户故事所体现出的客户价值的技术和底层细节。为实现和交付用户价值，敏捷团队角色需要主动认领属于自己职责和专业领域的工作，完成相应的任务。
当然，在某些情况下，为了更加明确项目产品待办事项的职责，会指定某个人负责跟踪和协调某个用户故事的所有任务，以确保在Sprint里面所承诺的所有用户故事需要的任务都能如期完成。但这种用户故事的负责人，不过是项目管理和项目工作跟踪与原理的一种方式，与敏捷开发中自组织、跨功能团队成员主动认领的需要承诺完成的工作是不同的范畴。
参考文献：
[1] 用户故事与敏捷方法，[美] 科恩 著； 石永超，张博超 译； 李国彪，滕振宇 校，清华大学出版社2010年4月出版。
[2] Scrum Guide， http://www.scrumguides.org/。 （中文版 http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CN.pdf#zoom=100 ）
[3] 敏捷估计与规划，[美] 柯恩 著； 宋锐 译，清华大学出版社2007年7月出版。