敏捷开发的精髓：如何透过本质实现灵活的开发流程

最近，社群对于敏捷开发的讨论又掀起了一波热潮。自从 2001 年敏捷宣言诞生以来，敏捷开发模式一直都是个拥戴与反对声浪都不小的开发模式。几乎每隔一段时间，社群就会展开一轮有关敏捷开发的讨论。这些讨论通常从抱怨敏捷的现状开始，随后会有支持者强调：「你讨论的并不是敏捷的真正本质」。最终，这些讨论常常得出一个结论：「问题不在敏捷，而在于错误的实践方式。」

虽然说我们不是敏捷专家，但因为待过的团队不算少，有号称用敏捷但非常瀑布流的团队，也有没特别提敏捷但运作非常敏捷的团队，因此从这些经验中，也有一些对于敏捷的心得。

敏捷开发的核心原则：回归敏捷宣言

谈到敏捷开发，就不能不提 2001 年被提出的敏捷宣言。这个宣言是当初多位资深软体工程师 (例如 Robert C. Martin) 共同提出的，该宣言的内容如下：

从该宣言又延伸出了 12 项「敏捷宣言背后的原则」，以及后续业界出现了各种实务方法 (例如 Scrum) 来实践敏捷的开发精神。不过不幸的是，许多团队在套用这些方法时，不知不觉就走偏了。

避免敏捷开发中的常见误区

许多实践敏捷开发的团队经常落入「形式化」的陷阱。举例来说，很多使用各类敏捷方法的团队，经常有很多大大小小的会议。然而，敏捷背后的原则是要「经常交付可用的软体」，如果长时间花在开会上，压缩了能经常交付可用软体的时间，就会变得与敏捷背后的原则牴触。

又或者许多公司在导入流程与工具时，会很死地要求团队必须要照着做，即使某些流程在落地后几乎变得没有意义，但仍是为了做而做。但敏捷宣言提到「个人与互动重于流程与工具」。

如果真的要做到敏捷，针对每个会议、流程与工具，应该要回到第一性原理思考，检视其是否真的有意义，而不是死硬着要开某个浪费时间的会议，或者死硬着要求照做某个冗余的流程。若你对第一性原理思考不熟悉，请参考这篇介绍：第一性原理思考。

正确的敏捷实践：避免由上而下的控制

在许多会抱怨敏捷的文章中，经常会看到抱怨老板由上而下的陨石。然而这种陨石或流星雨式的征兆，似乎与「以积极的个人来建构专案，给予他们所需的环境与支援，并信任他们可以完成工作」这个原则相抵处。

理论上，一个敏捷的团队，要可以自己决定怎么样的方式运作 (ownership)。当发现问题，也应该自行间起责任来解决。举例来说，假如团队因为没有写测试，导致某个功能出问题上线后才发现。

比起是由上而下要求加上流程 (例如把写测试这件事塞入流程中)，把如何解决交还给团队决定，由团队负责，会是更符合敏捷的做法。否则，当越来越多问题发生，就会越加越多东西，导致最后流程变得超级冗长，进而变得毫不敏捷。

敏捷开发与瀑布开发的对比

谈到敏捷，就不能不谈在敏捷之前业界主流的瀑布式开发 (waterfall)。所谓的瀑布式开发，是从需求，到设计，到实作，到测试，最后到部署与为运，一个阶段往下一个阶段，就像瀑布一样开发。

过往业界对瀑布式开发有许多批评，包含瀑布式开发这种分阶段的方式，极度缺乏弹性。又或者瀑布式开发到测试阶段已经很后面，所以当测到问题后前面整段重来的成本很高。

然而，众多批评当中，最严重的问题会是瀑布式开发到上线后已经很晚，要实际收到使用者回馈也会很晚。这将导致一个严重的问题，那就是经历各个阶段后、花很多时间后，才发现做出对使用者没价值的成果，导致前面的大量投入全部白费。

但敏捷的核心是追求「满足客户需求」，是追求更频繁的回馈回圈 (feedback loop)，这能避免做出对使用无价值的成果。

使用者很多时候，其实没办法说清楚自己真正想要什么。所以单纯的前期使用者访谈，虽然能做为方向的指引，但很多时候不会是马上就能精准抓对方向。因此更有效的方法，是根据需求做出原型，接着给使用者用用看，同时搜集回馈来迭代。

很常见的状况，是使用者访谈后，根据最开始搜集到的需求后做出的原型，拿回去给使用者测试后，使用者说这不是自己要的。虽然觉得很无言，但在敏捷的做法下，验证到真正的需求成本会远小于瀑布的做法。

然而，如果没有不断验证、不断迭代、不断精练对使用者需求的理解，就代表跟敏捷的精髓有所偏离。

从本质出发自然就敏捷

最后，如开头提到的，过去我们曾经待过，在开发模式上完全没提敏捷，但是实际运作起来高度敏捷的团队。之所以能做到这样，是因为在团队运作的本质上，与敏捷的原则不谋而合。

因此，推荐比起导入各种方法或流程，不如回到原则面来看敏捷的本质。抛开那些方法与工具，直指核心地问自己所在的团队：

是否做到「及早并持续地交付有价值的软体」？
是否做到「满足客户需求」？
是否做到「招募积极的成员到团队，并给予所需的环境与支援」？
是否做到「用高效的方式沟通」？
是否做到「持续追求优越的技术与优良的设计」？
是否做到「给予团队自主」？
是否做到「定期自省如何更有效率，并据之适当地调整与修正自己的行为」？

当团队对于上面这些问题的回答都是肯定的，那即使不导入 Scrum 或 Kanban 等方法，也能够跑得很敏捷。

最后，在我们过去的经验中，能良好体现敏捷本质的团队成员，多半对组织脉络有一定的掌握，知道组织的架构、知道不同产品之间的定义与上下游关系，并能透过系统性的思考，把这些资讯整合起来。当能够做到这样，将能够更容易地实践敏捷。