Post by "St.Valentine", 04-18-2007, 14:13
-----------------------------------------------------
敏捷是什么？为什么你应当关注？
作者 Mishkin Berteig译者 Jason Lai 发布于 2007年4月12日 下午8时0分
社区 Agile 主题 方法论, 交付价值, 故事和案例分析
敏捷方法包含一系列实践和原则，通过向团队赋予更多权力、增进学习和消除损耗的方式，帮助团队和组织更加有效地工作。
在某个组织中，一支敏捷团队在为期五个月的项目的头两周工作中，发现他们原先计划好的工作最终将变得徒劳无功。为什么呢？通过与客户的协作，他们发现，在另一件工作上花费精力实际上可以获得项目80%的价值，而他们原先的计划对于交付这个价值是徒然无益的。团队向管理层申请废置现有的计划，并获得批准。于是，团队暂停工作进行重新计划，然后启动了另一个为期四周的迭代，在迭代中他们交付了一个可运行的系统，实现了与预期相符的80%的价值。尽管项目剩余的20%的价值被认为不足以证明团队的付出是有效的，但是他们仅浪费两周时间在当前被复制的原定计划上，而且可以很快着手进行其他更有价值的项目上。管理层和客户都欣喜若狂，团队成员对结果也很满意：他们出人意料地为组织的净利润做出了比原定计划大得多的贡献。
在另外一个组织最初的敏捷试航项目中，他们成功地在仅有两周的时间内交付了可工作的软件。因为无法敲定最终需求（这种情况称为“分析停滞”），该项目之前被搁置了两年半的时间。对于项目最初交付的并不完美的结果，客户很是满意。项目利益相关人参与项目团队的可工作软件的演示，并为下周交付的提供更多功能的新版本提供了有价值的反馈。项目团队对于他们的成果引以为豪，并为获得的真正的反馈雀跃不已。每一周项目团队都会交付系统的一个可运行版本，包含更多的功能，以及对以前构建的功能的改进版本，使之能够更好地工作。客户表示，他非常喜欢这样的过程，如果可以自由选择的话，他今后绝不参与任何非敏捷的项目。
敏捷带来的好处
对于业务人员或者软件系统的最终用户来说，敏捷方法带来的好处是显而易见的：敏捷方法能使项目团队在更快地获取投资回报的同时，构建出更高质量的系统。团队一旦进行构建，客户就可以了解其情况，而不必在一开始就“一步到位”。固有的短反馈周期能够迅速提供满足客户真正需求的特性。同时敏捷方法也比传统项目管理方法提供了更多的管理变更和风险的可选方案。此外，它们还允许项目团队以组织——客户、用户和其他部门——能够真正看见、评估和使用的方式，展现他们的创造力和解决问题的能力。
敏捷存在哪些不利因素？
敏捷方法很难正确实施！简简单单按图索骥的做法，是难以确保你迈向成功的。要采取敏捷方法，需要保证高度的自律性、对错误的包容心、信任感、坦诚精神、可见度、真诚心、耐心、对卓越的渴求，以及孜孜不倦的工作。在某些工作场所，所有这样的努力和良好意愿的成果可能很快就被组织的混乱和官僚主义冲得烟消云散。但是敏捷方法会以不断递增的方式将这些努力引导到一个学习周期中。
既然如此，敏捷到底是什么呢？
敏捷是一个范畴，包含从纯粹关注管理到纯粹面向技术的一系列方法。我们可以举几个众所周知的例子，如极限编程（Extreme Programming，或叫XP）、Scrum、动态系统开发方法（Dynamic Systems Development Method）、特性驱动开发（Feature-Driven Development）和精益软件开发（Lean Software Development）。此外，还有其他地方，它们常常是某些组织按照自身情况改进自一至两种常见敏捷方法的结果。
XP以它与众不同的“结对编程（pair programming）”而“臭名昭著”。结对编程要求所有生产代码由坐在同一台电脑前的两个人共同编写。然而，XP又普及了XUnit测试框架的应用，包括JUnit、NUnit和HTMLUnit。所有这些测试框架都在一个称为测试驱动开发（Test-Driven Development，TDD）的敏捷实践中采用。这项实践，因其能使人们以卓越的设计质量和超低的缺陷率创建软件，而受到广泛赞誉。
包括Scrum和XP的一些敏捷方法以其短迭代性开发周期而著称。通过快速迭代，可运行的软件得以不断交付，并且随后的计划也不断得到调整，以适应项目利益相关人的反馈。这样的适应性计划方法，相较于传统阶段性开发生命周期，给软件的用户/客户带来了两大优势：首先，在项目的进展过程中，客户可以根据他们所了解的情况，对实际的可运行软件提出修正的请求；其次，每个迭代结束之后，客户可以选择在软件当前的状态下投入实际使用，从而开始通过它带来的好处收回投入的成本。因为迭代周期不可能超过30天，其间产生的任何错误都能够得以及时发现并解决，而不会在数月甚至数年的软件开发工作的末期才爆发危机。
我们应当有多敏捷呢？
目前业界还有许多其他的敏捷实践，包括从持续集成（Continuous Integration），任务板（Task Boards）和用户故事（User Stories）到财务建模（Financial Modeling）和适度度量（Appropriate Metrics）等一系列方法。每一个敏捷方法都定义了特有的明确的实践方法和规则集合作为出发点。然而，选择某一项具体方法开始实施敏捷，并不是一个至关紧要的决定。相反，成功的关键因素是不受限制的、坦率的交流，以保证学习过程。一旦项目团队对于定期、透明地讨论他们的工作感到习以为常的时候，他们会发现每个实践都有它们适用的场合，以及自身带来的益处和挑战——并且每个实践都可以对应一项实际需求进行实现，而不是照本宣科依葫芦画瓢。敏捷特性植根于团队更改自身工作过程的能力，并且总是伴随着为企业带来更多价值，减少损耗的视角。这样，敏捷企业才能在面对不确定因素乃至面临竞争对手时，创造实际价值。
扩展阅读
敏捷软件开发的前提条件是价值和原则，而不是没有生命力的条条和药方。下列网页是这项运动得以蓬勃发展的奠基石：
敏捷软件开发宣言（Agile Manifesto for Software Development）
敏捷项目管理互依赖声明（Agile Project Management Declaration of Interdependence）
敏捷工作公理（Agile Work Axiom）
关于作者
Mishkin Berteig是一位敏捷方法教练和培训师，现居住于多伦多。Berteig先生在为项目团队和组织提供极限编程，精益软件开发和Scrum方法的实施培训方面，具有广泛经验。目前，他正在开发一种可以运用于非软件环境的敏捷方法。他常在Agile Advice网站上发表关于敏捷方法的个体和组织方面的文章。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图