敏捷事实

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

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

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

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

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

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

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

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