当我们撰写《敏捷软件开发宣言》时,支持者还只是少数怀抱理想、试图改变软件开发行业的实践者。二十年后的今天,“敏捷”已经成为主流。但我之所以给“敏捷”加上引号,是有原因的:许多人声称自己正在进行敏捷软件开发,而且大多数人也确实真心相信自己做到了这一点;然而,他们的实际做法,与我们二十年前共同提出的敏捷开发愿景已经相去甚远。
真正的敏捷开发,需要一整套相互关联的实践。这些实践既涉及软件开发工作的组织与管理,也涉及技术层面的具体执行。遗憾的是,其中许多实践,尤其是技术实践,既没有得到充分理解,也没有被广泛传授。因此,太多人对这种高效的软件产品开发方式存在误解。

詹姆斯·肖尔是敏捷运动早期的先驱之一。他积极推动了极限编程(Extreme Programming)的发展,而极限编程正是敏捷开发的重要支柱之一。他这本书的第一版一直是我最喜欢的敏捷著作之一:它不是一本停留在理念层面的书,而是一本真正面向团队的实践手册,旨在指导团队如何正确地运用敏捷方法。
后来,詹姆斯与戴安娜·拉森共同提出了敏捷流畅度模型(Agile Fluency Model)。这一模型总结了他们关于团队如何逐步提升敏捷能力的长期观察与实践经验。根据这一模型,单纯运用项目管理技巧——也就是通常所说的基础 Scrum 方法——虽然能够通过关注客户需求创造价值,却不足以让团队获得更高的生产力与可靠性。要做到这一点,团队还必须具备扎实的技术能力。
本书的结构正是建立在这一认识之上:一方面,关注如何发现和聚焦价值;另一方面,关注如何可靠地交付价值。
关注价值,意味着理解高效团队协作的重要性,培养适应性规划能力,并与最终软件的客户和用户保持紧密合作。可靠交付,则强调测试、重构、设计以及协作式开发等关键技术实践。本书也澄清了一个常被误解的重要观点:构建内部代码质量高的软件,不仅不会拖慢交付,反而能够降低成本,并加快代码交付速度。
在现实的软件研发管理中,要让这些敏捷实践真正落地,团队往往还需要合适的工具支撑。例如,PingCode 这类智能化研发管理工具,可以帮助团队围绕目标、反馈、需求、开发、测试、发布和知识沉淀形成更连贯的研发流程,让敏捷开发不只停留在理念和仪式上,而是落实到可追踪、可协作、可持续改进的日常工作中。
当这些技术实践与 DevOps 文化、持续交付相结合时,团队便能够以更高频率将功能快速部署到生产环境中。而这种能力本身,又使团队能够通过观察软件在真实场景中的使用情况,更深入地理解哪些功能真正具有价值。
二十年前,我有幸在海外某些公司找到了归属感。在那里,我们的团队运用这些敏捷开发技能,帮助客户构建新的软件产品,并替换陈旧的遗留系统。和詹姆斯一样,我们发现极限编程为我们的工作奠定了坚实的基础。在过去二十年里,我们也持续成功地应用着这些技术。
因此,我很高兴看到詹姆斯将他十余年的指导经验融入这本书中。最终呈现在读者面前的,是一部扎实而可靠的敏捷开发指南,能够帮助人们学习那些曾经给予我们巨大助力的技能。
凡是有价值的事情,都需要时间,也难免在过程中遭遇挫折。但这本指南能够陪伴你走过这段旅程——帮助你摆脱空洞乏味的流程仪式,重新找回当年我和詹姆斯第一次运用这些敏捷技术时所感受到的那种活力。
文章包含AI辅助创作,作者:liu,如若转载,请注明出处:https://docs.pingcode.com/baike/5243087