中式太极敏捷与西式敏捷的区别

敏捷有中式和西式之分。

Scrum 和 XP（eXtreme Programming，极限编程）是两种最著名的西式敏捷方法，有许多值得我们学习和借鉴的地方。

张恂提出的太极敏捷方法（以下简称“太极”或 Taiji）大体上赞成西式敏捷的价值观和原则，但在一些具体做法上结合中国本土国情，与 XP、Scrum 等西式敏捷方法有不少区别。

与 XP（极限编程）的不同

太极敏捷与 XP 在对软件工程本质的认识和哲学观上存在着明显的差异。根据太极敏捷的辩证法则和极限法则，我们认为 XP 有点偏激，极限和极端既是它的优点也是它的缺点。

TDD、CI 和 PP 是 Kent Beck 先生及其同事们发明的 XP 最知名的（也是争议最大的）三个核心做法。针对这三种做法，太极敏捷提出的替代解决方案是 UDD（用户目标驱动的开发，User-Goal Driven Development）、AI（Adaptive Integration，自适应集成）和 PoD（Pairing on Demand，按需结对）。

UDD

TDD（Test Driven Development）有一个别称叫 Test-First Programming，要求开发的第一步是根据需求，必须先写单元测试程序，然后再写实现程序让测试通过（符合需求）。

我们认为，一概而论，简单要求所有类型的敏捷项目开发都必须从写单元测试程序开始，显然有点僵化。对于很多种类的软件开发，以及有经验的中高级程序员来说，必须先写单元测试这一要求其实有点过度，是不必要的。有经验的程序员完全可以自主选择是否编写单元测试，以及何时编写单元测试。

测试驱动主要可以分为两种：UTDD（即经典的 TDD）和 ATDD（Acceptance Test Driven Development）。系统开发也有不同的类型，比如应用系统开发和软件框架开发。

软件框架开发，主要是为了重用，有很多对外公开的 Class 和 Interface，显然有必要对每一个公开的类和接口都进行单元测试。针对可重用框架、共享库（library）等 API 的开发，从编写单元测试开始，是相当高效和合理的。

对于常见的应用系统的开发，焦点不在 API 的单元测试上，而在整个系统的边界上。即便写在再多的单元测试，也无法验证整体系统的正确性和质量。这时盲目地采用 TDD 就可能造成主次不分、浪费精力，从编写系统测试或验收测试程序开始开发，显然更为合理。

系统测试从哪里来？来自系统需求。系统需求从哪里来？来自用户目标。

太极 UDD 方法提倡根据用户目标，编写软件需求，根据软件需求，编写系统（验收）测试。根据开发系统和项目的不同类型，有选择地采用 UTDD 或 ATDD。

AI（不是人工智能）

从软件工程的历史发展来看，上世纪九十年代经微软公司倡导而流行的每日构建（DB，Daily Build）技术可以说是持续集成（CI）技术的“祖宗”。

CI 要求我们缩短 build/integration 的间隔时间，一天之内持续不断地、连续进行系统的集成和测试，这当然是一种保证系统质量和稳定性很好的做法，是我们应该长期努力追求的目标，但在实际工作中，CI 对于微型、小型项目和系统是相当有效的，对于大中型系统和项目，CI 会有 scale up 的问题。总体上，我们认为 CI 有点理想化，也有点极限。太极观点认为，要取得质量和效率的平衡，并非只有采用 CI 这样一种极限、固定的做法不可。

DB 也是一种敏捷做法。我估计，恐怕国内还有一大半的软件开发团队连 DB 还没做到吧，谈 CI 有点超前了。在实践中，我们建议本土团队先从微软公司 15 年前已经做到的每日构建、每日集成做起，收到实际成效后，再谈 CI。

太极敏捷主张的是 AI（Adaptive Integration），集成的时机、间隔应该是自适应、可调节的。是否采用分支、合并的开发方式，也应该根据项目的实际情况进行选择。

PoD

相比 PP 要求所有的程序代码都必须由两个人结对在一台电脑上完成编写和测试，太极敏捷认为 PoD（按需结对）的做法可能更加灵活，也更加实用。

与 Scrum 的不同

...

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13633641/viewspace-615530/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13633641/viewspace-615530/