本文主要是介绍反对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....
这篇关于反对N-1方法，支持同步N方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
