我们目前快不起来，不在于我们是否采取敏捷方式，而是我们基础太薄弱
1、开发人员不理解现有业务
2、开发人员不理解现有代码
3、开发人员不理解现有数据表关系、关键字段变化、VIEW、SP、报表
4、开发人员不理解MAP在典型场景中的实际应用，不了解MAP到底有多少函数可以帮助开发
5、开发人员大多是新人，对开发过程规范不了解。我们目前采取CMMI开发过程规范，光主节点就有78个。开发部门的老人也大部分只是只开发过一个子系统，对其他子系统的业务、代码、数据库也不了解。只是MAP和开发过程规范比武汉开发新人熟悉一些。
6、我们的设计人员也大多是新人，不了解现有业务和系统功能
7、我们的自测没有方法，多了工序，耗了人工和时间，但效果并不明显。
8、我们的代码审查没有方法，多了工序，耗了人工和时间，但效果并不明显。
9、我们的大数据量测试、多场景并发测试、集成跨子系统影响测试、安装部署测试、环境兼容性测试、权限点测试、帮助文件测试也是没有优化，消耗大量时间。
只有先把这些基础补起来，我们的开发效率、开发质量就会比我们现在好很多。所以我们今年大力启动多项针对性的关键行动计划来提升各个方面。但这些做到后我们也并不能做到3个月快速发版。
当然，我们还可以继续优化：
1、需求规划不能滞后，这是常见挤压下游设计、开发、测试时间的原因。需求分为功能增强和BUG修补。对于BUG，ERP3.0会提供BUG自动发回功能，让需求收集需求规划阶段能够优化缩短。
2、开发Leader在功能设计中期就进入，理解业务，设计数据库，设计功能代码实现和代码修改方案、设计接口、识别公共代码。
3、平台提供大量稳定性功能、代码审查工具、性能优化数据库设计指引，平台还提供日志、异常、输入规则校验底层框架，把这些都从业务代码中抽取出去，简化代码开发。平台应用架构组也梳理子系统代码分层解耦、JS代码缩减，力求业务子系统开发少写代码，只写业务代码。
4、设计部门进行设计模板化，平台应用架构组也提供代码模板，开发也尽量模板化COPY修改。简化开发，提高效率和质量。
但要想更快起来，我们必须引入敏捷项目管理、敏捷设计、敏捷开发、敏捷测试。
敏捷测试的核心是要和开发一起并行，把BUG消灭在开发的每天中，而不是在后期集中测试集中爆发。这要求咱们并行写测试用例、并行做自动化测试、并行持续每日自动构建自动脚本测试。咱们目前设计方法和测试方法不一致所以无法并行测试用例，这今年会解决；咱们代码各异没有模板，所以自动化测试跑不起来；我们功能自动化测试经验也尚浅需要加强；
光靠敏捷测试是不够的，保证代码稳定还得主要靠开发人员。所以敏捷开发需要开展单元测试靠开发人员主力保证代码稳定，在单个开发人员编码能力不强的状况下可以采用开发leader编写代码骨架普通开发人员填肉的配合结对编程，而且还得实时进行重构防止代码逐步腐烂导致开发进度开发质量连年下降。这两项也是咱们的空白。
单元测试，最大的误区是很多人以为是先完代码，然后写测试代码来测试已写的函数。其实不然，而是先按照业务场景先写测试函数，这样便于程序员通过输入输出、函数的定义、函数的串联来达到深刻理解业务需求。所以说，单元测试，其核心是测试驱动。
敏捷测试，想做到测试同步，就必须开发人员和测试人员都按照同样的业务场景去分析思考，测试根据场景分析得到测试用例，开发根据场景分析得到单元测试代码。这是同宗同源的。只有这样工作，才能真正保证测试用例编写和开发人员编写代码是同步的。
敏捷测试和敏捷开发的本质是让代码质量持续保持稳定，以便于可以随时发布。
敏捷设计的核心是用户故事（咱们叫用户流程场景，在UML中变形为用例图），这是敏捷测试、敏捷开发共同的源头，这样测试才好验证代码是否符合场景。可以采取咱们前段时间做的组织结构-岗位职责-一级流程-二级流程-功能点+UI草稿，这样来把用户流程场景和功能点映射在一起，并且容易做项目计划估算。用户故事有优先级，咱们也有。用户故事要求独立，咱们也是把一般和特殊分离，力求每个功能点归类成Grid/Form/Report。用户故事有一点比咱们做的先进，就是每个故事都必须具备验收条件，咱们以后也需要这么做。
敏捷项目管理的核心是20个工作日迭代一次。每个迭代周期包括详细设计、开发、测试、演示冲刺四个部分。分到每个环节也就是5天，所以必须持续稳定、同步测试。为了保证20个工作日迭代一次，就不能在这个迭代小周期内中途变更需求、变更设计。这些变更必须在下一个迭代周期去解决。通过有限的工作日来限定有限的需求，有限的人力。也就使需求稳定、人员稳定，这是开发效率开发过程不出异常的两个基础保证。
敏捷项目管理的任务是按小时来计算的。我们现在做不到按小时就是因为我们想在软件设计初期就深刻理解每个功能，但其实不可能做到。而敏捷可以，是敏捷不需要在初期深刻理解每个功能，而只需要把范围缩小到本迭代周期内要实现的功能聚焦思考即可。持续滚动迭代，会逐步思考精确。而且按小时算有个好处，每个迭代周期有多少小时是一定的（20天x8小时x人数），你放进本迭代周期的任务超出时间了，那就当然无法执行了，这也保证了迭代时间估算的准确性。
在这些支撑下，燃尽图只是一个类似丰田可视化看板而已。很多人误认为燃尽图是敏捷SCRUM的核心，其实不然，燃尽图只是表象，支撑它的东西才是核心。不过燃尽图中的正在排队的任务，正在开发的任务，已经开发完成的任务，需要返工修复的任务，还没有计划的任务，这些分类的任务在燃尽图中倒是一清二楚，令团队的每个人都很快明白进展和问题，并且认识信息一致。
至于：规划会、变更会、立会、周会、冲刺演示会，所有这些会议，全体团队成员（产品经理、PM、设计、开发leader、开发、测试、QA）都要一起参加；平时工作，项目团队都要坐在一起。这些方法都是为了让信息快速共享同步。这些敏捷项目管理方法大家平时已经在用了。
20天出一个小迭代版本，60天出一个大迭代版本，这是我们一切思考敏捷创新敏捷尝试敏捷的源泉。大家以此为根，把不以此为目的的旁枝措施都砍掉。否则极有可能走向照猫画虎邯郸学步，成了片面追求敏捷模式了。
以上上述所有能力和基础要想摸索通、准备好这些基础和人员能力模型提升、和咱们现状结合有效、并且产生规模效应，没有2-3年的努力是无法做到的，尤其在我们连年大量新人加入的情况下。所以新人培养模式如何快速培养新人是关键的前提，新人提升不快，咱们这些所有的高级职责和工作要求就无法执行。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/