一个真正有效方法 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个人聚在一起交流，滑雪，放松，并尝试找到共同点。从本次会议上达成的是一个所有参与者签署的敏捷软件开发宣言：

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

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

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

客户合作 高于 合同谈判

响应变化 高于 遵循计划

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

伪敏捷宣言

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

敏捷不是一个方法论……

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

敏捷事实

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

敏捷运动转移松散的、跨部门的软件工程方法到单一专注于软件开发的团队(排除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

我们遵循这些原则

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

原则1：给客户带来价值

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

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

原则2：变更 - 来吧!

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

敏捷伪敏捷拥抱变化，被看作为项目提交的积极部分。宁愿改变也不愿提交错误的东西。持续变更的请求成为计划糟糕、需求分析糟糕或者设计糟糕的媒介。变更通过任务列表(Backlog)的流程管理，以确保所有变更都是可控的。不会积压!变更缺乏管理，并影响时间表，交付时间，或者打破团队工作生活的平衡。变更范围是为了满足客户的经营目标。变更常常因为技术部门差劲表现导致的。

原则3：交付更短，收获更多

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

敏捷伪敏捷致力于分解大系统到更小的可部署可工作的组件特性。致力于发布2周内能完成东西。冲刺(Sprints)的长度能确保一个或者多个完整的用户故事能被交付开发活动被时间盒(timebox)陷住，并努力在这个时间盒里完成。"完成"(Done-Done)的定义理解得非常透彻，组件只有在符合标准时，才会部署。"完成"是在时间盒的尾声主观判断定义的。

原则4：成功需要参与

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

敏捷伪敏捷业务人员和技术人员在同一个地方共同工作，并持续协作配合。各个团队在简短的每日会议后，又各自回到自己的项目领域。各个团队视最终产品(交付的软件系统)为大家共同的交付(而不仅是开发人员的责任)。开发人员主导整个过程，并自己做出决定，因为他们比其他人更知道该完成些什么。冲刺(Sprint)中发现的问题(Issues)会被利益相关者(stakeholders)快速地解决。问题(Issues)会被推迟到任务列表(Backlog)，因为交付至上。每一天都一起工作，以此利益相关者(stakeholders)对解决方案和更优的用法有着直接的了解。利益相关者(stakeholders)没能投入他们所有时间和团队一起，他们只在危急时出现并常在此时调整方向。

原则5：授权给“合适的”的员工

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

敏捷伪敏捷成熟的、经验丰富的员工，能利用这些经验做出杰出的事情。员工由强有力的领导结构驱使，确保在冲刺(Sprint)的时间表内完成任务。团队成员由自我管理和自我确立目标而受到激发。团队成员被强势的组织结构驱动。团队成员确立冲刺(Sprint)的大小和范围，并为质量和完整性而调整其大小。领导确立任务列表(Backlog)的工作量，员工被要求按时完成。分心事宜(Distractions)，例如会议，被面对面的协作配合取代。分心事宜(Distractions)，例如状态会议，将是必须的，以便“控制”工作任务的完成。娴熟的角色(Skilled roles)促进确保完全的“我们都在这里一起”的环境。关键的角色(如，QA和BA)被“超级”开发人员取代，因为他们能做所有的事情。

原则6：协作不只是坐一起

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

敏捷伪敏捷团队成员坐在一起，不是把团队从组织中隔离出来，而是为了更高效的协作。不是所有团队成员都坐在一起。面对面交流能迅速地分享信息，但这并不能完全抛弃文档。鼓励团队成员所有的工作都通过口头沟通，并不要浪费时间在文档上。各个团队对产品交付的所有方面都负有责任，像一个团队般一起工作，以确保质量。各个团队常常在一块工作，但是对交付产品的质量几乎没有责任感。避免电子邮件成为主要交流沟通工具。认为电子邮件是令人满意的文档工具。

原则7：质量很关键

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

敏捷伪敏捷"完成"(Done-Done)的定义理解得非常透彻，组件只有在符合标准时，才会部署。进度是通过冲刺(Sprint)的完成情况和时间来衡量的。质量胜过进度，团队和领导对其的态度是言行如一的。进度胜过质量，成为潜规则。如果软件不能工作，那么就不交付它。交付和修复是开发过程中的一个策略。

原则8：不是死亡之旅(Not a Death March)

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

敏捷伪敏捷标准和流程，不是限制团队，而是使其加速和创新。框架是自由灵活的。流程是稳定的。标准和流程，不是过于官僚和限制，就是在解除团队限制时被完全精简掉了。项目过程像马拉松，由很多较小的冲刺(Sprint)组成。避免赢了冲刺，输了比赛。人员保持新鲜感。团队努力完成时间盒里的工作量。延长工作时间，周末加班成为常态。人员被视为商品(commodities)。

原则9：技术很关键

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

敏捷伪敏捷标准和流程并不官僚，反而能保持一致和加速开发。流程被抛弃、被“即兴(ad hoc)”的项目执行取代以追求更快的速度。失败更快。避免为了流程而流程。流程必须有其价值!没有任何流程。文档的请求会受到温和的批评，除非有价值、风险和回报的评估分析。回避任何文档请求。“敏捷不是反方法论的运动;事实上，我们大多数人希望恢复方法论这个词的可靠性(want to restore credibility to the word methodology)。 我们希望恢复到一个平衡。我们崇尚建立模型，并不是为了把这些文件图表放置公司布满灰尘的仓库里。我们拥抱文档，但不是几百页的、从不维护更新、极少使用到的大部头文档。 我们做计划，同时也知道计划在混乱环境中的局限。”

Jim Highsmith, 敏捷联盟

原则10：简洁 = 稳定 & 速度

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

敏捷伪敏捷致力于寻找最简单且质量足够的方式满足业务需要。致力于寻找最快速、最少编码的方式满足业务需要。足够简单有效的流程，被视为战胜拖拉，加快持续交付的法宝。精简流程步骤，比如，测试。经常认为是为交付而简化。任务列表(Backlog)成为守门员，对所有任务排上优先级再处理。工作量常常变化，因为优先级发生变化颠倒，十分混乱。

原则11：让团队闪耀吧

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

敏捷伪敏捷允许团队犯错误，提出他们的解决方案，交付产品，经常评估(回顾)，并从他们的成功(和错误)中学习。错误导致项目领导和被视为项目按时完成的诋毁者之间对峙。时间都浪费在“责备的游戏(blame game)”。鼓励团队一起工作，并让他们有权作出决定(界线模糊)。每个人都朝着同一个目标努力。一起工作但传统界线(如BA，QA，DEV)仍在。没有共同的目标，每个人看到自己不同的“工作”。做出最好的决定的那个人，是最接近这一决定的原因和影响的那个人。领导坚持复查和调整计划，以满足“政治”的时间表，而不是信任那些最接近实际工作的人。

原则12：回顾并向前

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

敏捷伪敏捷有组织地回顾审视优势，劣势，机会和威胁，并采取行动。不是完全无组织学习经验教训，就是有了结论却没有相应的行动。每一个团队成员都集中注意力在提高冲刺(Sprint)，发布(Release)和项目上。回顾会议被视为敏捷的一个必需的标志，并没有被认真对待。团队审视所有流程，努力确保所有活动步骤是必要的，优化后的，并能带来价值。团队审视所有流程，努力确保没有流程。

混合体 - ScrAgileFall

敏捷，Scrum和瀑布方法论的混合

它的工作原理是这样的?用户故事积压在任务列表(Backlog)里并排上优先级，但特定的用户故事累积列表有一个目标发布日期，这意味着他们都将被一起发布， 而不是单独发布。采用冲刺(Sprint)管理开发过程中设计，编码和单元测试阶段， 另在发布之前安排一个集成系统测试，测试“在范围内的”用户故事所有已完成的功能。

(It works like this. User stories are prioritized into a backlog but there is a targeted released date for a cumulative list of specific user stories, meaning they'll all be released together instead of individually. Sprints are then employed for the design, code and unit test phases of development but an integrated system test is performed prior to the release of all the completed features for the "in-scope" user stories.)

瀑布地规划和发布时间表，敏捷 / Scrum地设计和开发。

(It's waterfall planning and release schedules with agile/scrum design and development.)

对流程、文档到底意味着什么?

敏捷并不反对的流程。它反对没有价值的流程，反对不能使团队更有效的流程。

敏捷并不反对的文档。它反对那些对交付的解决方案没有帮助的文档。

敏捷流程和文档应该限制在最快的时间内交付高质量产品的最低水平。

敏捷测试

框架里的“独立的(Independent)”测试角色

“独立”并不意味着孤立一人。“独立”是指测试团队在价值链中所扮演的角色。独立不孤立。

测试不能被视为“最后一关”，不能仅会在所有冲刺(Sprint)的最后进行测试。测试需要持续集成到冲刺(Sprint)的每一部分。

测试不能被视为我们开发和他们测试之间对抗。为了成功，必须有一个团队意识。

在真正的测试驱动开发过程中，“独立的”测试将更少地在执行测试上，而更多地在确认上。

敏捷工具

这些测试工具在敏捷开发过程中能有一席之地吗?

敏捷测试工具 - Agile Accelerator 5.x

敏捷模板是基于Scrum的实践(比如，冲刺(Sprint)，史诗级(Epic)的用户故事，用户故事等等)。

QC模块自动同步，以便更容易管理冲刺(Sprint)。

单独的维基接口，以便更容易管理用户故事和任务。

标准的开发环境集成

Eclipse

Visual Studio IDE

TeamForge

Tasktop task-focused interface

敏捷表象(Fa?ade)

突破表象的策略

敏捷教练 - 当组织投向到敏捷时，确保有一个经验丰富的教练，然后让他指导你的团队!

风险管理 - 确保文档的请求是根据清晰的风险理解从而判断是否需要文档(Make sure requests for documentation are supported with a clear understanding of the risks associated with not producing them)。当风险成真后，确保领导能够接受影响。

突破职责的限制。参与到项目的每个方面。突出测试人员是解决方案的一部分，而不是问题的一部分。

故事复查(Review) - 主持正式和非正式用户故事的复查会议，以帮助确保每个人都有同样的理解。

结对测试 - 就像结对编程有助于提高开发的代码质量，结对测试能确保更好的测试覆盖率。一个开发人员搭配一个测试人员。

促进采用工具和方法论的“最佳实践”。促进利用之前那些离开的人的经验。

回顾会议 - 认真吸取经验教训。确保建立由PM或Scrum Master跟踪的并可操作的计划。

面对残酷的事实，但从不放弃希望。

度量，度量，度量 - 没有度量将一事无成(What get meatured gets done)。开始测量你的敏捷过程的有效性。

实现之后：事件与变更请求(Post Implementation: Incidents & Change Requests)

冲刺(Sprint)计划与实际情况

冲刺(Sprint)的测试计划与进度

不要成为受害者 - 控制你自己和你的团队。如果你需要，做好保卫它的准备，然后做好自己的事情，坚持不懈，以帮助你的项目成功。

译者注：

敏捷是一个热门、有争议的问题，文中观点仅为原文作者观点(当然不排除我的错误理解)。去年看到这篇好文，一直想翻译下，跟大家一起分享分享，由于种种原因，直到今天才搞定，虽然很晚了，也算了却一桩心愿。

此文来源一个PDF，格式自己用HTML实现，可能会有些问题。如果发现请大胆指出来。翻译得不好地方，也请指正。