互联网的产品大都是面向海量用户的服务，且用户分布区域广泛，其教育水平、习惯也大多不同，具有高度不确定性，我们必须非常关注用户的行为和反馈。因而，在互联网产品服务的整个用户研究，需求分析、产品研发及交付服务的过程中，都采用探索式、适应性的研发理念进行产品的研发。通常，会把整个产品研发周期划分为若干个迭代，采用迭代式的演进过程，不断的去交付新的产品特性，并通过观察用户的行为和反馈获取，进而随时调整产品的思路和方向。一切以用户价值为核心是互联网产品最核心的特点，而以价值驱动的敏捷开发方法非常符合这一特点。

从阿里软件开始，内贸团队就一直在实行着敏捷项目管理实践，通过小步快跑，快速迭代、增量交付用户价值，不断获取用户反馈，持续、快速的调整产品，验证并适合用户价值。正是通过这些实践活动，我们以迭代的、增量的交付用户价值，最大限度的保证产品朝着符合用户实际需求方向发展。目前，在内贸团队应用较成熟的敏捷实践活动有：

1)、迭代计划(Sprint Planning Meeting)

2)、每日晨会(Daily Scrum Meeting) & 任务墙(Task Wall)

3)、功能预演(Spring Review)

4)、项目总结(Retrospect Meeting)

5)、结对编程(Pair Programming)

6)、其他技术实践活动等

 二、敏捷团队

１)、自组织文化

如google、facebook等互联网企业，他们很少甚至没有特定的项目流程，通常怎么敏捷怎么做，具有浓厚的工程师驱动文化。我们则有较完整的开发流程指导和规范我们的项目研发工作，相比而言，丧失了一些灵活性和积极性，不利于我们工程师自我管理、自我驱动意识的培养。臃肿、缺乏灵活性的流程同互联网产品快速更新、快速发展是不相适应的，同时也弱化我们的责任心意识。除了遵守详尽的流程，我们是否可以换个角度、换种方法，提倡和营造一种自我管理、自我驱动的开发文化，省却一些并不能给我们带来帮助却影响效率的流程呢？

敏捷团队的自组织特性弱化了团队技术领导这个角色，强调自我管理和自我驱动。虽然这对工程师的素质要求更高，相对技术能力更难提高。但是，团队导向很重要，我们努力营造这样的氛围，从小团队做起，逐渐锻炼和培养自组织团队。相信在这样的开发氛围下，会让我们做的更高效、更敏捷，可以走的更稳、更远。

２）、追求一体化

一体化团队作为敏捷开发方法中最具精益思想基因的实践，是指每个项目团队包括分析，开发，测试等角色，使团队满足一个需求从设计，开发到测试各个阶段顺利完成，达到符合质量标准并满足需求的软件。这种以项目/产品为单位的虚拟团队，坐在一起，全身心的为共同的目标而努力，可以更好的凝聚项目组中的各种角色，消除部门墙。 

 3）、追求全功能

这里所指的全功能是希望项目团队能打破工程师角色之间的边界，如研发、测试和前端工程师的界线，消除开发、测试流程中一些潜在浪费，提高效率。在项目团队内部通过角色互换，不限角色的结对工作，加强不同角色，不同模块间的知识传递，打破技术壁垒，帮助员工从不同视角理解项目，锻炼技能，进而增加团队均衡生产的能力。

为什么要提倡打破边界？项目整体效率依赖于项目过程中各环节的工作效率，而整体效率的优化往往依赖于均衡生产(精益思想的按需生产)，即消除生产的波峰(过度生产)和波谷(生产不足)，只有局部效率的增加无法直接转换为整体效率的增加(就象桶能装多少水，决定于最短的那块板)。整体效率的优化要求IT团队消除技能壁垒，培养多面手，根据计划的的变动，弹性地调整任务，达到各角色和流程之间的平衡。

三、质量保证

我们追求开发效率，同时也注重项目质量。如何去保证质量？就象美国的一位教授爱德化.戴明（W.Edwards Deming）所说：“我们应该停止依靠大量检验来保证质量，而是要改进工艺流程，从一开始就生产出优质的产品”。我们要在整个开发过程中多个环节去保证质量。同时，质量保证是整个团队的责任，就如同前面所说的追求全功能团队，打破边界。

至于在哪些环节采用哪些实践，我们先做个分类，按是否能被系统用户感知将质量问题区分内部质量和外部质量。外部质量指能直接被系统用户感知，如运行缓慢，不可操作或是操作复杂就属于外部质量低劣。而不能直接为系统用户所直接感知的要素，对产品键壮性、可维护性有深远影响的问题就属于外部质量，如系统设计的一致性、代码可读性、逻辑完整性等。内部质量对用户的影响比较间接，但比外部质量意义更深远。一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。

1）、外部质量保证

在外部质量保证上，大部分会在开发后期介入，可以通过性能测试、自动化测试及工程师的功能测试来保证，通过这些实践活动发现并保证例如运行缓慢、不可操作等质量问题不会存在。针对交互特别复杂的web应用，可以更多的考虑采用webui自动化测试工具，如selenium、pwaitr(b2b)、automan(淘宝)等，可以很好的完成那些简单、重复的TC用例，可以大大提高测试效率，解决测试工程师的资源瓶颈。

2)、内部质量保证

相对于外部质量，内部质量问题影响更为深远，在开发开始阶段就应该去保证。如通过单元测试、静态代码扫描(PMD\findbugs)、持续集成、重构、结对编程、code review等多种实践活动来保证项目代码的健康。

除了一些实践活动去检查代码质量外，更为重要的是研发工程师对内部质量的重视，如果工程师没有形成良好的质量意识，很可能这些实践也只是停留于形式，并不能带来较好的结果。如我们在开发过程中的编码规范、单元测试的质量及覆盖率，code review的及时性及问题是否持续跟进等等。此外，有选择的采用结对编程实践，有助于质量的提高。

以下为本人在公司内部关于项目质量和工作效率邮件回复的一此意见和想法。

1、 谈流程

不可否认流程的重要性，但我们需要根据具合格情况分析，不断的梳理和优化我们的流程，让流程更好的指导我们工作，而不是束缚。目前，我们的流程慢慢多了起来，感觉不如以前敏捷了。经过rpm改造后，无论在测试环节还是发布阶段，较之前失去了很大的灵活性。测试阶段，开发bugfix后想在测试环境验证，每次必须重走aone的流程及打包布署，相比之前的build效率真的差了好多。当然，也许是我们项目组对这个流程熟练度、方法还不够，很多环节有待改进。

发布阶段，目前统一由SCM来发布，必然会导致开发对线上环境及发流程更加陌生，同我们提倡的打破边界，敏捷响应有些相背。再者，SCM资源有限的原因，要支持ITU众多产品线，能否应付的过来，始终是个问题。发布统一管理有好处，同样也带来了弊端，ITU不同于网站，大多数的技术团队共同在维护在几个应用，而itu的应用多、规模相对小、环境各异，这样的产品线采用统一管理性价比不高。希望相应的owner，能不定期的搜集各产品线的意见和反馈，不断的优化，让我们的流程更合理。

2、 谈自测

我们团队一直在强调自测意识，也在这方面不断的总结和改进。我觉的要提高自测，首先应让每位开发同学形成较好的自测意识，而不是自上而下的命令式管理，只有自己有这方面的意，才会去思考、去想办法，去实践。再者，需要PM或技术经理去思考，目前阶段实行自测会有什么困难，如没有系统的自测方法、时间不充足（需要熟悉下阶段的UC、下迭代的设计、单元测试补写等），找到这些困难或问题，就容易对症下药了。最后，不断总结和积累自测方式，优化项目流程。自测不是一种形式，而要追求效果，开发自测同样需要计划和方法，所以我们需要向QA同学请教，总结过去 bug常犯的错误，整理自己的check项。相信通过这样的一些自测方法，能真正提高我们的项目质量，打破同QA的界线，我们的开发、测试资源比例可以得到更大的优化，将以前开发阶段紧，测试阶段松的状况加以改善，使整个项目过程中的紧张度趋于平缓。

3、 谈故障分

“尽量不要让故障分成为大家包袱，可以考虑被实施产品对事故级和A类才对个人计故障分，B和C类故障分记在主管头上！”，个人也比较支持骆驼的观点。目前大家对线上故障都小心翼翼，大家对质量的意识很高，这当然是好事，但同时带来的影响是效率低了。我的观点是，作为增值服务的互联网产品，我们更需要快速迭代增量提供用户价值，尽快获取用户反馈并改善产品，产品推出的迟早，不仅影响获得回报的时间，还影响到获得价值的多少，错过了一个时间窗口，产品可能就不再有任何价值。所以，我们需要找到一个平衡量点，可接受的质量状况达到最大的效率。

从客户第一角度谈质量，某些时候，客户可以接受服务偶而不可用重启下，却不能接受产品没价值、交互性太差，操作太复杂。所以，对于客户来说什么对他们更重要，就需要我们每个人去分析和评估。所以，我们一味只注重质量，而忽略客户真实需求，那就太悲哀。我的观点是，case by case，带着这样的观点去思考和解决问题。

4、谈敏捷项目团队

从打破边界，我想到了一体化的敏捷项目管理团队，一个目标一致、自我管理的团队，应该具备良好的目标意识和执行力，不仅能管好自己的一亩三分地，同时也能站在项目、团队的角度看待问题。PD出现了问题，开发积极去弥补；开发出现了问题，QA积极去弥补，项目团队的目标非常一致。每位项目组成员一定要把好每一关，万不可把问题向下抛，因为还有开发或QA会把关，所以差不多就行了，这样往往就是灾难的开始。

关于CodeReview的几点作用：

1、提高团队的编码规范，培养良好的coding风格
旨在提高整个团队的编码规范程度，统一编码风格。通过每次的codereivew，发现团队成员在实际开发中的一些细节问题，如不良的编码习惯、错误的调用方式等。通过多次的发现、解决问题，使大家都养成良好的编码习惯。review的内容一般包括：
1)、异常、日志的处理；
2)、常量的定义及使用；
3)、字符串处理、BigDecimal.ZERO等；
4)、代码的封装，提高重用性；
5)、代码注释情况；
6)、javascript文件的抽取情况；

2、检查业务逻辑
对项目实现的功能逻辑进行一次reivew，结合众人发散思维，检查业务逻辑是否有盲点或错误。通常需要参与review的成员能够静下心来深入地认真分析，比较耗费时间。

3、分享和培训
每个项目的工作安排相对来说都是比较紧凑的，所以每个团队成员在完成自己的开发任务完，没有太多的时间去了解或熟悉其他成员的功能实现。但对于敏捷开发来说，每个功能模块的开发者并不是固定的，根据项目需要，很有可能由非原开发人员来完成增值功能或重构，所以codereivew是一次不错的培训及分享机会，特别是对功能相对复杂的需求实现。可以让团队成员了解或熟悉基本的设计思想和相关的类定义，确保在今后接手这一块工作时，可以更快的上手或找到最到最合适的人去了解更深层的逻辑。

关于reivew的方式：

1、集体review;
项目成员一起参与codereive，成本比较大，一般一个项目组织一次。比较适合开发经验分享，以及新功能的实现介绍，利于其他成员了解、熟悉实现者的设计思路及代码结构，在后续项目接手这些新功能时，更加从容。

2、TM组织若干开发经验丰富的一起review;

3、分组、交叉review;
具有较好的灵活性，根据情况随时找相关人员一起对已实现的代码进行review，及时发现过程中问题并予以修正。比较适合分组\抱团开发，以2-3人为单位，对具体的功能模块负责，一起分析、设计、编码，每位成员对于功能逻辑都比较逻辑，对业务逻辑reivew有比较好的效果。

实际工作中，根据实际情况灵活选择合适的review方式，不应拘于某种形式。review过程，应有明确的目的，具有针对性，而不是停留于表面，避免逐渐成为一种负担，流于形式。另外，应对每次review结果，整理出一份问题列表，进行分析和总结，避免相同问题的重复出现。同时，也应按排相关人员跟进并解决问题。总之，通过codereivew这一手段，尽可能的在提交测试之前去发现代码中存在的一些实际问题，从项目经历中得到成长。