反对N-1方法，支持同步N方法

    现在，很多团队已经开始使用Scrum进行软件开发。在实践Scrum过程中，必然要面对一个开发team和测试team如何协作，如何安排二者迭代（iteration or sprint）次序的问题。很多Agile培训机构给出的一个经典方式，N-1模式，如下图1。  但是，我个人非常反对这种方法。我推荐大家使用图2的同步N的方法。当然，所谓同步N的方法也不是什么标准的名词，我好像也没有听说过相关的定义，只是先随便用个名词与大家探讨这件事情，只要大家会意就好。

 

图1  N - 1的方法

 

 

 图2  同步的N的方法

 

一、解释N-1方法

       所谓N-1方法，也即测试滞后开发一个迭代周期（Agile里边的一个迭代是2-6周）。宏观上来说，也就是测试team在迭代N里边测试开发team在迭代N-1里边开发的软件。具体来讲这里的测试狭义上指FVT（Function Verification Test）。因为如果加上SVT，BVT，GVT，TVT，etc，模式会更加复杂。

 

二、N-1方法的缺点

 1 使用N-1方法，很难实践Scrum的真谛

        Scrum最核心的东西就是尽早、持续的提供可用的稳定的软件给Stakeholders，  并从Stakeholders那里得到反馈，形成产品连续优化的循环。但是使用N-1的方法，我们在开发期间似乎永远无法给Stakeholders一个真正的可用的稳定的软件。在迭代N结束的时候，如果你把迭代N-1的软件介质给Stakeholders用，那些介质里边迭代N-1的代码其实都没有被测过；如果你把迭代N的软件介质给客户用，新增的迭代N的功能则没有被测试过。

 2 使用N-1方法，开发和测试team目标会不统一

        由于开发和测试的目标不同，因而二者在被对方block的时候，总是很难从对方那里得到最高的优先级去扫除这些Block Issues，并且双方相互Push的过程只能给对方带来压力；让一个原本应该精诚合作的团体成为测试和开发两个对立面。比如测试team在测试过程中发现了N-1迭代的defects，并被这些defects block不能继续工作，需要开发团队马上fix。但是此时开发团队未必有这个优先级去做这件事，因为开发团队有自己在迭代N的开发任务；如果去fix这些上个迭代的defects则很有可能影响本迭代的代码质量，造成恶性循环。于是双方都陷入了郁闷的状态，两个team的进度状况也许很快就会同时亮红灯。

 3 使用N-1方法，造成效率低下

        Agile及其他相关研究里边有这样一个观点，事情一次做完效率最高。因此，将同一个功能拖到2个甚至更多个迭代中去做，效率显然不会很高。试想开发团队在迭代N-1开发了功能，却要在2周、4周、6周，甚至8-10周后回过头来Fix defects效率可想而知。此时，估计很多东西早已忘到九霄云外了，developer要重新整理思路，熟悉code，有时甚至需要重新搭建环境，等等，白白浪费很多时间。

另外，大家还知道，dependency也是妨碍高效的罪魁祸首之一。N-1的模式中，开发团队在需求理解、知识传递上很容易成为测试团队的dependency。假设开发团队获得需求、design、相关知识需要时间是X, 开发团队将这些信息传递给测试团队，两个团队的时间加起来就是3X。但如果测试团队可以shift left，和开发团队同步，这个时间测试2X。

 

 

 三、解释同步N方法

 

1基本模型（理想模型）

        所谓同步N方法就是要开发、测试team协同工作，在一个迭代里共同完成相同的功能（Story）。正如图2所示，

       首先，两个team同时选择Stroies，分析需求；测试团队从一开始就和开发团队站在同一起跑线上，避免dependency。

       而后，双方共同完成开发设计和计划。开发团队做code 部分的设计；测试团队做测试计划设计。

       接下来开发团队写code，做UT，而测试团队则细化test case或是搭建测试环境。

       最后，测试团队执行正式的FVT，开发人员fix defects。

2完善模型（真实模型）

       当然，上面的模型只是一个基本的模型。

      真是环境中，由于具体工作的差异，图2中开发和测试两条线并不一定总是同步；有的时候开发的工作多一些，有的时候测试的工作多一些。此时，需要Team，Scrum Master，PM，或是其他长官从中动态协调双方资源。当然，这样的协调需要developer，tester各自扩展一些对方的技术，需要双方的素质在横向上都有一个提升。

      另外，虽然图里的两条线是平行的，但是协调的需求首先从客观上打破了平行。其实，我们主观也希望两条线能够很好的交叉。也就是说们希望开发、测试能够互相帮助，有一个较好的配合。开发和测试的人思维模式往往有些差异，而我们恰恰希望利用这些差异、整合双方的观点使产品做得更好、更全面。而实际操作中有很多问题对另一方往往不是问题，我们也希望通过这种整合提高双方的效率。

 

 

四、同步N方法的优点

 

1 相对于N-1，这种方法可以及时为Stakeholders提供可用、稳定的软件。

2 开发测试可以为共同的目标奋斗、而不再成为敌人。

3 提高了效率

   团队可以一次把一个功能彻底做完。

   消除了dependency。

   开发测试协同工作提高效率。

4 整合开发、测试的不同视角提高质量。

5 测试team也可以更多的contribute需求分析，Story分析和设计。 

 

五、同步N方法的案例

 ITCAM  for RT

 

六、对同步N方法的质疑与回答 

 

1 问： Developer和Tester相互拓展对方的技能是不是使双方都不专业了？

   答：我们经常会对自己的技能进行拓展或者叫充电，这是IT人必须的。对于Developer或Tester在纵向拓展自己本领域的技能，我举双手赞同。但我同时也认为，适时、适度的抬头在横向上涉猎或提高也是很有益的。我做过developer也做过tester，我知道他们的思想和技能有很大的不同，各自也有很大的局限性。如果二者可以相互借鉴，二者都能做得更好。同时，我相信大部分IT人是愿意接受这种提高的。

2 问： 对Developer和Tester的工作做互换，双方能适应吗？

   答：这个转化是很痛苦，所以需要在协调的时候讲究一些技巧。你肯定不能让tester明天就去写code，让developer马上就去跑点。培训是必须的，循序渐进更是要点。我的建议是从双方互相帮助开始，根据需要逐渐深入。随着team逐渐走向成熟，双方磨合更加到位，这些痛苦也就不存在了。

3 问：能否让Developer把FVT也包了？

   答：有些team确实这样做了，我作为Developer也做过FVT，可是感觉效果不好。自己写code自己测，有些问题是测不出来的，因为自己在测试环境、内容、方法上都会有assumption。所以，专门留出测试的role还是有必要的。

 Writing....