敏捷 vs 伪敏捷

　　敏捷 vs 伪敏捷

　　一个真正有效方法 vs 一个混乱的借口

　　你可能是伪敏捷：

　　抵触所有的文档，因为“敏捷不需要文档”，也不需要需求文档。

　　2周的冲刺(Sprint)完成了，只是在所有人强制把6周努力“塞到”这2周里面的情况下完成的。

　　用户故事描述的细节比一条微博还要简短，史诗级的(低优先级，更大块的)用户故事描述的是项目大多数的悲剧地方(Epic describes the proportions of most project catastrophes)【译者注，后半句不太明白】。

　　要么没有回顾会议，要么没有采取任何行动，要么行动没有分配到具体负责人那里。

　　功能演示或用户验收测试完全取代了标准测试(如单元测试，系统测试，集成测试或性能测试)。

　　最终用户被迫接受不达标的功能特性和忍受使用中的大量问题，并接受功能将会改进优化的承诺。

　　你的敏捷教练并没有进行指导。

　　燃尽图成了一个真正的燃尽图(The burn down chart is really a burn out chart)【译者注，应该是想表达没有关注曲线数据的含义】。

　　你试图组建一个分布在大企业中或者跨地域的虚拟敏捷团队。

　　“完成”的定义跟日期，版本构建，部署或者除可工作的软件以外的任何其他机制相关。

　　自组织团队退化，恶徒把他们的意愿强加到其余团队成员上。(Self Directed Teams have degraded into bands of thugs imposing their wills upon the rest of the team.)

　　你试图重新定义，测试实际是什么，如声明单元测试和系统测试对应的活动。

　　你企业的PMO和资金(关卡)(Your Enterprise PMO and Funding (Tollgate))模型非常适应瀑布模式项目，但你强迫他们去适应到敏捷。

　　“团队”不愿意做在他们职位的“工作描述”之外的事情(例如：开发人员测试，测试人员开发)。

　　你看到积极的行为和产出，并认为都是你的敏捷实践的直接结果，然而忽视所有不好的行为和产出，并认为都是个人的问题。

　　敏捷软件开发宣言

　　在2001年2月11日至13日，在犹他州Wasatch山脉中雪鸟滑雪胜地的小屋中，17个人聚在一起交流，滑雪，放松，并尝试找到共同点。从本次会议上达成的是一个所有参与者签署的敏捷软件开发宣言：

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

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

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

　　客户合作 高于 合同谈判

　　响应变化 高于 遵循计划

　　也就是说，尽管右项有其价值，我们更重视左项的价值。来源：agilemanifesto.org

　　伪敏捷宣言

　　交付的速度 高于 交付的质量

　　敏捷不是一个方法论……

　　……但是方法论的一个分类

　　敏捷事实

　　敏捷是一种没有相关技术的运动。

　　敏捷运动转移松散的、跨部门的软件工程方法到单一专注于软件开发的团队(排除QA和运维)[The Agile movement shifts the broad, inter-departmental process of software engineering to one that is focused on software development to the exclusion of QA and operations.]。

　　敏捷运动通过源代码的频繁变更，把需求的所有权从业务转移到开发[The Agile movement transfers business ownership of requirements to development ownership of requirements through frequent source code changes.]。

　　敏捷实践，致力于更少更快的工作，以便得到持续前进的反馈。

　　敏捷宣言里没有的，却又和它的原则相关的几个词：质量保证，测试，运维。

　　敏捷是一个以开发人员为中心的运动。

　　“敏捷困境”

　　当企业对速度和灵活性的追求被曲解时，内在的风险和混乱就产生了。比如，敏捷可能不适合所有组织或项目时，依然强制推广开展以开发人员为中心的敏捷运动。

　　28%的敏捷践行宣布他们是成功的。

　　19%的报告表示冲刺(Sprint)如预期一样，在制定的时间内完成了所有工作。

　　44%的报告表明他们并不知道什么是返工等级。

　　67%的缺陷是在产品发布后的第4个冲刺里被修复的。

　　59%的敏捷项目里商务人员没有适当参与到其中。

　　Voke 研究：市场报告：敏捷的现实情况 2012.7

　　我们遵循这些原则

　　我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。以简洁为本，它是极力减少不必要工作量的艺术。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。可工作的软件是进度的首要度量标准。最好的架构、需求和设计出自自组织团队。业务人员和开发人员必须相互合作， 项目中的每一天都不例外。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。团队定期地反思如何能提高成效，并依此调整自身的举止表现。来源：agilemanifesto.org原则1：给客户带来价值

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

　　敏捷伪敏捷可工作的软件，以更短周期、可管理的方式，开发部署到生产环境，为客户最大化价值。集中精力在2周的冲刺(Sprint)里，开发代码再部署到生产环境，以便满足项目的时间表。专注于提交可工作的软件。专注于提交的周期。更快地为客户带来价值，带来更高质量的产品。为客户带来的价值有限，客户必须忍受有缺陷的软件，直到被修复为止。原则2：变更 - 来吧!

原文转自：http://blog.csdn.net/o2o_o2o/article/details/8873688