高效敏捷的十大经验法则.doc

高效敏捷的十大经验法则敏捷是一种应对快速变化的需求的一种软件开发能力，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。本文是VersionOne 公司CEO Robert Holler，一家专注于敏捷开发工具和敏捷培训的公司。Robert总结了这十年来的敏捷软件开发经验，缩减成十条经验法则，希望对热爱敏捷的公司、团队和个人有所帮助。1. 简单至上由于软件和组织架构的复杂性，这就需要我们能够清楚地分辨出什么是重点，什么是非重点。敏捷，虽然从概念上理解起来很简单，但实际上它是相当复杂的。即使是很小的团队，他们也关乎着整个架构的调整以及复杂的网络通信。与迭代式开发相比两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。此外，成功的敏捷人士需要具备不同的业务能力以适应与他们一起工作的相关人员，包括企业的相关利益者，产品企划人员、开发者，测试人员等等。Holler称很多公司在建立敏捷平台时，每当面对有独特需求的用户时，他们很容易使自己陷入困境。2. 定义自己的节奏面对公司日常的冗长会议时你会做什么？需要时刻提醒自己如何削减时间，不浪费会议时间。在会议开始之初，不要一个一个提问问题，让员工在会议之初就把问题准备好并且能够以快速、简洁的话语表述出。当你的敏捷模式进行实施的时候，你需要依靠这些问题的答案来优化你的流程并衡量项目的成败。3. 敏捷就是纪律Holler曾听说过一些公司对敏捷的一些描述及案例。有的公司甚至推崇“Cowboy Coding”牛仔式编码。他说真正的敏捷团队恰恰与之相反的。事实上，灵活的自动化和高效的纪律性是通向敏捷团队成功的重要一步。好的敏捷团队在纪律上能够比其他团队更加严谨，尤其是在计划区域，单元测试、持续集成以及自动化测试等方面。4. 软件很难Scale，但是敏捷却不持怀疑论者并不认为敏捷能得到很好的扩展。相反，如果一个组织架构中心发生改变或者缺乏纪律，此时软件开发规模则不受控制。对于大多数团队、项目、程序以及投资者而言，敏捷能够很好的扩展。因为敏捷更多关注的是业务的而不是一些琐事。5. Think of the Big Picture 把自己当做统观大局的人从大局开始，然后再思考某个特性，然后进行修复，那么你才算真正完成。在这里，系统思考非常重要，这就需要一个真正成熟、能够深入探究复杂与冲突议题的团队，否则改变系统可能会带来一定的风险。此外，沟通很重要。在项目的初期，各个项目组（至少每个组有部分人）应该集中在一起工作，这样有助于项目组之间人员今后的沟通。在这个期间，有这样的事情需要完成，互相了解、做一些关键决定。6. 失去信仰有人说，敏捷就是一门宗教，需要人们虔诚地去尊重其各项规范。但灵活性对于敏捷来说非常重要，敏捷内部应用实践需要运用哪些生存法则？比如NASA（美国航空航天局）需要迭代、实地测试、了解所有的操作以便当发射太空时不会发生重构。因此，你要做的是适应敏捷需求。通常开发团队比业务部门更能适应不同的操作周期。因此，为了适应不同的节奏，你应该尽可能的与敏捷迭代方面保持密切联系。也许这个很难做到自动化，但是很多开发者运用一些灵活的做法，难题自然会迎刃而解。7. 持续关注商业价值许多敏捷团队在做Technical Storys Delivery以速度来考量总体的商业价值。这是个错误的想法，千万不要这么做。团队中的成员需要纵观全局以最大限度地降低项目开发周期。8. 敏捷不只是为软件部们这实际上有利于开发部门的敏捷转型，如果（Ops，业务部分）也可以在他们的团队中敏捷转型。当然我们也能看到业务部门、系统管理以及UX/设计部门的敏捷成功转型案例。此外，你必须同时考虑技术层面，改进质量并支持工程师、测试人员以及其他进行编码实施工作的人。9. 持续规划Winston Churchill（温斯顿-丘吉尔）说：“计划的意义很渺小，但规划却是必不可少的。” 每天给自己设定计划以便能适应日常的工作流程，从而确保你的价值最大化。产品路线必须要适应敏捷策略，但是路线图依然是战略趋势和产品长期版本之间重要的调节方法。10. 做敏捷但不要做重复的敏捷你应该时刻保持敏捷并遵循“敏捷”之外的敏捷。尽管这些都是小事，或许对你有很大的成效。有人说，成功实施敏捷的团队与没能完成敏捷实施的团队之间最简单最大的区别就在于，他们使用了一块真正的实体白板。请别光说不练，行动永远比空谈有效，你无法预见将发生的所有困难与问题，直到你真正开始去做敏捷模式。你花在空谈如何去做却从不开始的时间越长，越可能建立