一个真正有效方法 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

　　伪敏捷宣言

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

　　敏捷不是一个方法论……

　　但是方法论的一个分类