Adding stories to a sprint in progress

往进行中的Sprint添加新的故事

敏捷的团队有时候因为需求更新或者细化后发现新的/隐藏的用户故事。这是因为在计划会议中大家忽略了。

非敏捷的团队习惯了在制定好计划后，觉得有些东西需要提高优先级，强行添加，从外部打断了敏捷过程。

Lack of sponsor support

缺少领导层的支持

敏捷的团队因为过于自组织，对于一些外部环境未必能够及时感知，比如和其它团队形成了竞争，浪费了资源。

非敏捷的团队认为自己能够管理自己，对领导成的风险控制反感，强行封闭自己，认为必须遵循不能干扰的原则。

Insufficient training

缺乏充足的培训

敏捷团队中有些成员能够完成一些任务，但是如果有更好的培训的话，能提高团队的生产率。

非敏捷团队往往就是随意根据需求抓人，连很多背景内容都没有讲解就强行开发。

Product Owner Role is not properly filled

Product Owner角色没有充分发挥自己的职责

敏捷团队中的PO因为信赖团队，降低了验收力度和沟通成本，从而带来风险。

非敏捷的团队的PO很多时候过多的干预了团队的既定任务和计划。

Teams not focused

团队缺乏统一的目标

Excessive Preparation/Planning

过多的准备和计划

敏捷的团队因为过于习惯了充分考虑一切，从而浪费了产品上线的最好时机。

非敏捷的团队因为没有良好的团队合作，从而在执行过程中不断的重新储备和修改计划

Problem-Solving in the Daily Scrum

在日例会中解决问题

敏捷的团队经常将几句话能说明的事情放到例会中讨论结束

非敏捷的团队直接将例会变成了讨论会。

Assigning Tasks

分配任务

敏捷的团队因为对某些人的信赖，不自觉的将一些任务推送给了特定人员

非敏捷的团队是直接分配任务给每个人

Scrum Master as a contributor

Scrum Master参与交付

敏捷团队的Scrum master有时候因为了解过多，不自觉的参与了交付过程中的某些任务。

非敏捷的团队习惯性的在团队中指定一个人作为Scrum Master

Lacking test automation

缺少自动化测试

Allowing technical debt to buildup

允许技术型的债务积累

敏捷团队经常喜欢研究更新的的技术，越级更新，缺少了中间的稳定版本。

非敏捷团队很少去更新技术和框架。

Attempting to take on too much in a sprint

试图在一个sprint里交付很多

敏捷团队经常在成功的累积产生足够的信心，想增加一部分，或者偶尔加班。

非敏捷团队完全不知道优先级和产品战略，直接就拼命的堆功能。

Fixed time, resources, scope and quality

限定时间，限定资源，限定范围，限定质量要求

很多公司纠结到底是什么时候允许需求变化，是因为他们还在意于每个交付周期的产出量。真正的敏捷过程，在一个产品的前期会有大量的failed的sprint。所以Git的流行就满足了这方面的需求。

3. Working software is delivered frequently (weeks rather than months)

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

有很多团队，觉得为了交付一个产品特性，需要很多底层构建，所以无法满足持续的交付可工作的软件。其实，这是因为在计划会议时，把很多非交付性的或者技术型任务加入了交付迭代中。所以合理的安排任务很重要，必须保证产品设计能够切分成足够独立的特性。对于那些不可分割的底层架构，需要单独的团队去完成。所以看板是很重要的工具，他能将不同的团队的工作协调起来。

4. Close, daily cooperation between business people and developers

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

5. Projects are built around motivated individuals, who should be trusted

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

敏捷团队的每个人都是独立的交付个体，他们进行自我管理，通过主动精神形成一个敏捷的团队。在这个过程中，需要整个外部环境的支持。要保证他们的资源需求，保证他们的培训力度，保证他们的团队建设，保障他们的个人利益，然后不要打断他们，才能形成一个敏捷的团队。 从来不会有一个敏捷团队能依靠自己的资源建设成功。

6. Face-to-face conversation is the best form. of communication (co-location)

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

7. Working software is the principal measure of progress

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

怎么衡量进度，任何口头，数面的确认都没有一个已经能够Demo的产品有说服力。所以，我们要拿Demo作为验收的关键点，没有完成Demo，就没有完成进度。

8. Sustainable development, able to maintain a constant pace

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

9. Continuous attention to technical excellence and good design

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

产品更新，不光是需求更新，还会包含技术和架构的更新。这也是一个敏捷的团队成功的标志之一。因为这是每个成员的主动精神的集中体现，愿意将自身的发展和团队的目标绑定一致。

10. Simplicity—the art of maximizing the amount of work not done—is essential

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

11. Self-organizing teams

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

自组织团队的标准可以认为是每个团队的成员的工作目的都是为了同一个目标，大家没有相互依赖，而是相互支持。同时，自组织也意味着团队的所有成员都是平级的，任务是自己选择的，而不是分配的。

12. Regular adaptation to changing circumstances

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

敏捷软件开发，又称敏捷开发。是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。

它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. 

敏捷软件开发是一个需求和解决方案不停演化的自组织，跨功能团队所拥有的一系列软件开发方法的集合。

It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.

它促进了自适应式规划，演化式开发，预先式交付，持续式改进，并鼓励快速和灵活的响应变化。

敏捷宣言从一个整体来说需要按如下顺序阅读读：

（要注意，敏捷宣言每一项是按顺序来的，也就是说有相互的依赖）

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

Individuals and interactions over Processes and tools

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

Working software over Comprehensive documentation

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

Customer collaboration over Contract negotiation

客户合作 高于 合同谈判

Responding to change over Following a plan

响应变化 高于 遵循计划

That is, while there is value in the items on the right, 

we value the items on the left more也就是说，尽管右项有其价值，我们更重视左项的价值

1. Individuals and interactions 

in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.

个人的重要性体现在自我组织和主动精神上。

而限制工作区域和结对编程都能带来良好的交互。

2. Working software 

working software will be more useful and welcome than just presenting documents to clients in meetings.

能够直接演示的软件远远比文档更容易被客户所接受。

3. Customer collaboration 

requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.

需求在软件开发周期的初始阶段是不可能充分获取的，所以和用户协作不断的探讨和更新需求是非常重要的。

4. Responding to change 

agile development is focused on quick responses to change and continuous development.

敏捷开发关注于快速的响应变化和持续开发。