单元测试，大的误区是很多人以为是先完代码，然后写测试代码来测试已写的函数。其实不然，而是先按照业务场景先写测试函数，这样便于程序员通过输入输出、函数的定义、函数的串联来达到深刻理解业务需求。所以说，单元测试，其核心是测试驱动。

　　敏捷测试，想做到测试同步，必须开发人员和测试人员都按照同样的业务场景去分析思考，测试根据场景分析得到测试用例，开发根据场景分析得到单元测试代码。这是同宗同源的。只有这样工作，才能真正保证测试用例编写和开发人员编写代码是同步的。

　　敏捷测试和敏捷开发的本质是让代码质量持续保持稳定，以便于可以随时发布。

　　敏捷设计的核心是用户故事（咱们叫用户流程场景，在UML中变形为用例图），这是敏捷测试、敏捷开发共同的源头，这样测试才好验证代码是否符合场景。可以采取咱们前段时间做的组织结构-岗位职责-一级流程-二级流程-功能点+UI草稿，这样来把用户流程场景和功能点映射在一起，并且容易做项目计划估算。用户故事有优先级，咱们也有。用户故事要求独立，咱们也是把一般和特殊分离，力求每个功能点归类成Grid/Form/Report。用户故事有一点比咱们做的先进，是每个故事都必须具备验收条件，咱们以后也需要这么做。

　　敏捷项目管理的核心是20个工作日迭代一次。每个迭代周期包括详细设计、开发、测试、演示冲刺四个部分。分到每个环节也是5天，所以必须持续稳定、同步测试。为了保证20个工作日迭代一次，不能在这个迭代小周期内中途变更需求、变更设计。这些变更必须在下一个迭代周期去解决。通过有限的工作日来限定有限的需求，有限的人力。也使需求稳定、人员稳定，这是开发效率开发过程不出异常的两个基础保证。

　　敏捷项目管理的任务是按小时来计算的。我们现在做不到按小时是因为我们想在软件设计初期深刻理解每个功能，但其实不可能做到。而敏捷可以，是敏捷不需要在初期深刻理解每个功能，而只需要把范围缩小到本迭代周期内要实现的功能聚焦思考即可。持续滚动迭代，会逐步思考精确。而且按小时算有个好处，每个迭代周期有多少小时是一定的（20天x8小时x人数），你放进本迭代周期的任务超出时间了，那当然无法执行了，这也保证了迭代时间估算的准确性。

　　在这些支撑下，燃尽图只是一个类似丰田可视化看板而已。很多人误认为燃尽图是敏捷SCRUM的核心，其实不然，燃尽图只是表象，支撑它的东西才是核心。不过燃尽图中的正在排队的任务，正在开发的任务，已经开发完成的任务，需要返工修复的任务，还没有计划的任务，这些分类的任务在燃尽图中倒是一清二楚，令团队的每个人都很快明白进展和问题，并且认识信息一致。

　　至于：规划会、变更会、立会、周会、冲刺演示会，所有这些会议，全体团队成员（产品经理、PM、设计、开发leader、开发、测试、QA）都要一起参加；平时工作，项目团队都要坐在一起。这些方法都是为了让信息快速共享同步。这些敏捷项目管理方法大家平时已经在用了。

　　20天出一个小迭代版本，60天出一个大迭代版本，这是我们一切思考敏捷创新敏捷尝试敏捷的源泉。大家以此为根，把不以此为目的的旁枝措施都砍掉。否则极有可能走向照猫画虎邯郸学步，成了片面追求敏捷模式了。

　　以上上述所有能力和基础要想摸索通、准备好这些基础和人员能力模型提升、和咱们现状结合有效、并且产生规模效应，没有2-3年的努力是无法做到的，尤其在我们连年大量新人加入的情况下。所以新人培养模式如何快速培养新人是关键的前提，新人提升不快，咱们这些所有的高级职责和工作要求无法执行。