敏捷开发模式 与 TDD 的思考总结

“你有了解哪些开发模式？” “你了解的这几种模式有哪些不同” “测试方法与目的是什么？”
带着这些问题，我们来看看Agile 中的Scrum 与 TDD

Agile
敏捷开发模式，实质是一种以人为本的开发理念，重视团队沟通，重视客户反馈，重视产品迭代。
根据Agile的思想，我们主要有Scrum和XP两种开发实践，XP中又以TDD较为流行。

Scrum

项目经理从客户（产品经理）获取初步的需求，建立需求列表；
项目经理（可以分为PO与ScrumMaster）定一个sprint的周期（4周例如），按需求列表分配优先级，以此为前提，与开发小组讨论工作量backlog；
技术总监按backlog分配任务；开发小组集中速度开发。
项目经理每个sprint向客户递交可视化产品，评审并讨论迭代需求。
循环迭代，直至递交完整需求的产品。

优点：有效提升用户满意度，产品成功率；量化，透明的开发任务，增加效率；不同开发岗位之间的互动，培养了团队凝聚力，减少技术代沟产生的摩擦。

缺点：项目经理要求极高，对外部客户的需求更变所带来的backlog，经费以及质量控制要有明确的量化能力。对产品迭代需求的优先级划分要合理。对内部开发人员/QA的信息互换要即时。
对开发人员有更高的要求，没有完善的设计文档（UI/原型）约束，容易产生理解误差，不能解决反复修改需求带来的工作量积压问题，即递交产品前的开发工程量不变甚至更多。

Scrum小结： “敏捷”实质上是对产品需求完善的速率，不是加快工程速度，而是产品后续打入市场的速度！
正如微信等产品，通过用户反馈后迭代部分业务功能并及时更新即是agile的思想。

由上可知，Scrum对开发人员个人也提出了更高的要求，尤其是对需求的认识。

此时我们需要引入TDD的开发模式了，即先写测试后写业务代码。

T实际上能映射现实业务的需求，在“莽”代码前，开发人员先分析需求，完善测试，再按照测试要求完成代码书写。这样的功能模块跑起来才是有效的，这样的集成系统跑起来才是有质量，少返工，真前进的工程。

经过一些网络资源的阅读与大佬经验谈，TDD给我的第一印象是，前期引入较为困难，测试例的推导不全，后期补测试例的情况较多。如若在Scrum中引入TDD，开发人员Sprint工作量积聚上升，抱怨与抵触声随着backlog增加而来。

可以推断，TDD对技术总监的要求更高，需要对开发成员进行思想的指导与实践的论证，团队熟练掌握后，后期对于产品的质量的确会有进一步的保证。

总结：Scrum与TDD近几年的普及与实践都顺应了互联网瞬息万变的节奏，这两种开发模式都对开发人员个人，提出了更高的要求。

OK~屁文写完，继续补技术知识去了。