敏捷的方法与误区

如今越来越多的事情被定义为“敏捷”，尤其是那些试图向我们出售产品的人。如果我们问造纸厂商什么是“敏捷”，他们可能会说，如果买了他们的纸，在纸上写下用户故事就是“敏捷”；如果问咨询顾问，可能会听到，“敏捷”是一种开发软件的方法，如果购买了他们的服务，那团队就可以学习到这种方法；如果跟鞋的厂商交谈，他们可能会说，“敏捷”的关键是开会的时候每个人都要站起来，所以你的鞋子越舒服，团队就会越“敏捷”……

什么是敏捷？

事实上，大多数宣称自己是“敏捷”的事物，实际上并不是“敏捷”。“敏捷”的实际定义来自敏捷宣言，宣言明确表明了“敏捷”不是一种方法论，也不是进行软件开发的特定方法，更不是一个框架或流程。

敏捷实际上是一套价值观和原则，围绕它大部分的讨论，都与各种理论方法，甚至特定的敏捷开发软件有关，尽管这些东西可能会帮助一个团队建立“敏捷”，但这些方法和工具本身并非“敏捷”。

例如，举行每日站立会议可能会对团队很有帮助，但之所以有这种会议形式，只是因为团队遵循了“敏捷”的原则和价值观。这很容易就能看出，敏捷实际上就是一系列理念，在软件开发工作中，团队可以用这些理念来更好地做决策。

敏捷宣言

我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

也就是说，尽管右项有其价值，但更重视左项的价值。

敏捷开发12条原则

我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

敏捷的方法与误区

敏捷实际上是开发过程中做决策的最好基础。例如，一个程序员正在为客户开发一个产品功能，但是要实现这个功能，首先需要一个数据库。如果这个程序员信奉“敏捷”的价值观并试图遵循“敏捷”的原则，他会认为建立新的数据库意味着，这个产品将不得不延迟交付给客户，如果能找到一种方法，来解决开发此功能所需的数据库支持，那这个方法会更好地符合我的原则。

工作中，大家一旦了解到强大的“敏捷”团队是如何工作的，就会很容易去模仿他们的做法，然而这种方法并不会让团队变得更“敏捷”，与其模仿，不如去了解他们为什么用这种方法工作。

随着时间的推移，一个优秀的“敏捷”团队，可能会不断完善团队之间合作的方法。比如，一个团队最开始可能用“Scrum”模式，后来发现“看板”是一种更好地向客户交付价值的方法；另一个团队开始用敏捷扑克牌估算估算任务工时，代替了故事点的方式。所以敏捷开发模式要根据自己的实际情况去运用，而不是简单去套用别人的“敏捷”实践。

遵循“敏捷”的原则和价值观，才能变成敏捷团队，如果你选择了某种实践，是因为它遵循了“敏捷”原则，这可能是一个不错的起点。如果原则是错误的，即使是一样的实践也并非会带来好的结果。

敏捷的价值观和原则具有足够的灵活性，可以让不同类型的团队，以最适合其特定情况的方式去进行项目的开展，帮助团队不断朝着自己的方向前进。