在****项目一期迭代二中我们的团队算是开始走进了敏捷开发，迭代二结束后就一直想关于敏捷为主题总结一下，刚好本周又听了来自阿里B2B的一名项目经理孔琳琳关于敏捷的一个分享，和我们团队的实践有一些微小的差异，当然不见得B2B的实践就一定正确和可行，毕竟他们也是在做一些尝试性的实践，所以简单做一下对比和总结，希望我们通过看别人关于敏捷的实践，对我们自己敏捷的推行起到一点借鉴和启示的作用。

传统的瀑布流程大家都很熟悉，但是这种串行的项目推进和执行势必会造成很多资源出现等待等情况，造成资源的浪费；而我们作为一家互联网企业，产品的研发本身就需要具有快速响应、快速变化的特征。这本身就具有了敏捷的一些特性；我们做一个项目最终要达成的一个目标是在保证产品质量的前提下，更快速、更省资源的给客户交付产品；从而为客户产生价值。那么我们如何做到又要减少浪费还要快速交付，快速收到市场的反馈并制定相应的调整策略？这就引发了很多人关于敏捷项目的思考。

在传统的瀑布模型的开发中，我们更多的是根据系统分析人员给出的一系列的规范计算出需要的人月和成本；但是在敏捷中，我们对每一个环节的人员都提出了更多的要求。先说对需求方的要求：需要提供更多的时间来参与到项目开发的整个流程中来。这样开发人员才能快速的响应客户需求的变更。敏捷除了对团队成员的技能提出了跟多的要求，对团队成员的素质也有了更高的要求。我们知道敏捷项目中我们更关注团队成员之间及时的面对面的交流而非刻板的文档，怎么才能让团队成员之间积极地交流？影响积极交流非常重要的一点就是这个团队必须十分的Open，当然这个要求对于咱们公司来说应该不是问题（阿里的文化很Open）。以下是我认为值得我们借鉴的几点关于敏捷的实践：

1、 关于用户故事：

大家都知道敏捷推广的难点在于意识的转变和技能的提升；所以能否打破老的意识流由排斥敏捷走向拥抱敏捷很关键，另外，对技术的要求也多了一些，比如TDD、结对编程等。

我们也知道User Story的描述是以：“作为一名xxx,我要xxx,这样我可以xxx”的形式去写的，为什么要这样去写？其实这是用户价值驱动的一种体现，只有这样去描述一个功能点才能使后续的开发中可以对用户原汁原味的需求做到最准确的把握。

2、 关于迭代的划分：

关于迭代的划分需要结合业务和技术两方面的因素来划分，首先需求方需要对写好的用户故事进行需求优先级排序，这个阶段可以有多个相关的部门参与，以其结果的最大准确性，比如邀请法务、合规等部门的人员参与。

当需求方对User Story的优先级排序完成后（优先级分数不重复），交给开发负责人去组织开发人员打出每个User Story的资源评分（即我们所说的故事点，****项目一期迭代二中是以填写收货地址为基准故事—3个故事点；而B2B的分享中他们的基准故事点是以3个人日来衡量；颗粒度的把握影响所有User Story故事点的评价，所以依据具体项目选取合适的基准故事比较关键）；然后由开发人员依据实际情况评估出一个迭代能接受的总的故事点，让需求方依据这个总的故事点数给开发一个迭代需要做的User Story（类似于一个背包问题，总故事点（总重量）一定，让业务方去往迭代（背包）中放User Story，使得优先级（价格）之和最大的组合方案），这样就保证了在第一个迭代所产出的产品是业务上最有价值的产品，也就是对客户最有价值的产品。之后的迭代划分采取类似的方案；直至所有用户需求开发完毕（这种小步快跑的方式可以较好的解决需求方临时修改需求等尴尬情况）。

3、 关于Sprit计划会议：

关于Sprit计划会议B2B的分享中给出了这样的一副图：

上图比较清晰的描述了Sprit计划会议的输入和输出。在****项目一期迭代二的Sprit计划会议中我们开发人员和测试人员基本上等于是自娱自乐；自己写的故事、自己评估技术分数（需求方好像都没有评需求优先级，开发代劳在JIRA上标出优先级），然后按照优先级进行开发。而B2B的做法是需求方排除优先次序之后，由需求方在迭代计划会上给开发详细讲解每一个User Story，然后由开发评出每个User Story的故事点。个人感觉这样更有利于开发人员对技术实现难度和资源的评估。当需求方详细讲解了一个User Story的业务需求之后如果开发人员给出的故事点差距比较大（B2B他们也没有具体衡量的标准）的话，由业务方重新讲解该User Story，当各个开发人员对该User Story给的技术故事点差距不是很大就直接取平均值。类似于下表所示的操作方式：

而具体某一个开发人员领取了这个User Story后所需的故事点是需要乘以一个系数k之后作为该名开发人员的实际开发故事点，这个系统k是由三方面的因素决定：

A. 投入系数（该名人员可能非Full Time投入）

B. 历史数据（如果有历史数据可以参考的话）

C. 成长系数（主要针对新员工）

B2B的分享中也没有给出具体各个维度所占权重以及加权的公式；暂时也还是一种感性的评估。

在迭代二中我们的操作方案不是取平均值，而是由差异较大的人员讲解这样评分的理由，然后大家讨论最后达成一致；个人感觉这样有好处，就是能让大家都明白队友这样打分的理由，也容易发现一些大家都没有发现的技术实现的盲点；但是缺点就是比较浪费时间，可能会造成争执不下的局面；这样就不符合敏捷开发中会议、文档从简这一理念；当然无论哪种方式最终达成的故事点对于具体到某个开发人员手中后一般都不可能十分精确；我们能做的只是让这种误差降低到最小。

4、 关于故事点的评估：

对需求方或者业务方透明的工作量应该尽量在迭代会议上被覆盖到，比如我们在迭代二的实践中覆盖到了单元测试等，但是遗漏了添加缓存、系统框架升级等一些业务上透明的工作量。

5、 关于几点开发实践：

关于开发方面实践，我总结了一下主要有以下三点值得我们借鉴：

A. 单元测试

这个我们也有一些硬性的要求，但是对于遇到老的系统单元测试覆盖率一直是一个问题；B2B在操作的时候对新旧系统的单元测试覆盖率的要求不同，但是都有明确的量化需求，这样就有了一个明确的指标；我们也不妨给老系统定一个覆盖的指标；这样就不会出现以老系统为推辞而忽视单元测试的情况。

B. TDD

这个我们虽然没有做，但是这个可以和对编程结合起来施行，结对的一方写单元测试，另外一方依据单元测试实现代码，然后共同重构代码。

C．结对编程

TDD和结对我们暂时没有施行，这也和开发人员的技能现状有关系，比如我在迭代二之前连单元测试尚且写不太好，做TDD就有了一些难度；所以自身技能的提升是敏捷的精益化的实施的有力保障。

施行这些敏捷的实践有哪些好处？大体总结一下可有如下几点:

A. 节约时间

B. 直面变更，大胆重构

C. 代码即文档

D. 专注

E. ……

6、 关于持续集成：

这个在迭代二中我们有实践，但是一直是开发人员在做，测试同学没有参与，持续集成的作用是为了尽早的将问题暴露；而为了尽早将问题暴露，测试同学需要提前全投入到敏捷的团队中；持续的关注每一次集成的结果；这样会对软件质量的走势和稳定程度有更深层次的把控。

7、 关于阶段性回顾：

关于这一点迭代二中我们做的不是很足，我们没有及时的对每周的工作情况进行总结，随意对出现的问题每天的站立晨会上有提出，但是没有对这些问题进行归集整理；这样对以后出现类似的问题的解决不能起到很有效的管理和解决；而B2B在实践中每周会有一次阶段性的回顾会议，对一周中出现的问题进行归集整理并排定优先级，对于一些重要紧急的问题排定跟进计划进行解决，并做归纳，形成一个问题解决的知识库。每周总结会议的方式也选择了一些轻松的方式。关于问题的归集方案如下图：

8、 关于节奏感：

要在开发中能形成一种节奏感；就需要不断进行演示支付；这种阶段性的功能演示可以使团队在开发当中更具有阶段性的成就感；进而提升团队的开发效率；也容易更早的发现一些业务需求理解方面的偏差。在迭代二中可能有业务方参与度较低的一些原因导致基本上没有进行阶段性的功能演示；这也是导致在预发布确认时一些User Story出现功能丢失或者功能过度设计；有一定的资源浪费。

通过迭代二的实践和这段时间的学习反思，暂时总结出上面八点实践与B2B实践的区别；不一定B2B的实践方案就一定好，即使好也不一定适合我们团队目前的状况，但是不得否认的是B2B在敏捷实践方面要比我们团队目前做的更加细致、更加精益化；希望我们的同学在以后的项目实践中能从中借鉴一二，使团队的敏捷开发更加细致和成熟。