敏捷宣言的价值

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

    敏捷开发的第一条价值观就是"以人为本",强调" 个体（人）" 及" 个体" 间的沟通与协作在软件开发过程中的重要性。这个顺序不是偶然而为之的，敏捷开发将重视个体潜能的激发和团队的高效协作作为其所推崇的第一价值观。这意味着虽然流程和工具重要（尤其是大型组织），但是它们无法替换有能力的个体和高效的互动。个体的技能和他们之间的互动才是最关键的。 

（1）当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法

（2）在项目期间，产品管理和开发团队必须在一起工作

（3）在项目期间，架构师、设计师和测试人员必须每天在一起工作

（4）面对面沟通是极其重要的，它不能被其它形式完全替换

总结：沟通交流是解决问题的关键，在开发过程中，许多的Bug都是因为没有及时的沟通交流造成的，一方以为对方懂了，另一方则猜测对方表达的就是这个意思。结果无异于在机场造了一艘船。当面的沟通交流是最高效的协作方式。当然仅仅当面的沟通交流是无法解决所有问题的，好记性不如烂笔头，最终达成的共识还是要以文档的形式记录的。这样出现分歧时可有依据可查。

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

     敏捷开发的第二条价值观就是"目标导向"。同其他众多管理理论和模型一样，敏捷开发认同目标导向是成功的关键，因为没有目标也就无所谓成功。敏捷开发的价值观中清楚地阐明，软件开发的目标是"可工作的软件"，而不是面面俱到的文档。而遗憾的是，很多软件项目已经在纷繁的文档之中迷失了自己的目标。这意味着已集成、已测试、潜在准备发布的产品才是关键度量，它能够有效地跟踪项目进度和对发布做出决策。

（1）要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计

（2）设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的

（3）好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。

总结：有的时候，需求文档描述的天花乱坠可以造一艘航母，结果交付的只是一艘小破船。团队最终交付给用户的应该是可操作使用的软件，而不是详尽的功能文档。要让用户有真实的产品可以体验。

3.客户合作高于合同谈判

    敏捷开发的第三条价值观就是"客户为先"。虽然敏捷开发强调的第一价值观是"以人为本"，但敏捷宣言的缔造者们并没有忘记客户，相反他们真正的理解客户的需求、懂得如何与客户合作。敏捷价值观里强调的"客户为先"即不是简单地把客户当作"上帝"、刻板的推崇"客户至上"，客户要求什么、我们就做什么；也不是把客户当作"谈判桌上的对手"甚至"敌人"，去斗智斗勇。敏捷价值观把客户当成了合作者和伙伴，把自己的使命定位为"帮助客户取得竞争优势" 。这意味着我们应该超越谈判并尝试提升与客户的合作。我们还应该建立以合作为基础的关系，而不是靠公司内的正式接口。

（1）在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。

（2）在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。

（3）产品管理和开发应该密切合作，而不是通过契约或手续。

总结：有的时候完全按照合同约定，没有友好的沟通交流合作，双方关系则会僵硬，最终交付的产品客户也很难满意。我们应该时时刻刻以客户需求为先，与客户保持随时的友好联系。不要对客户有抵触心理。合同谈判太过于冰冷，应该与客户保持良好的合作关系。

4.响应变化高于遵循计划

    敏捷开发的第四条价值观就是"拥抱变化"。人们常说"世界上唯一不变的就是变化"，大多数人也相信事实确实如此。而以往很多的软件项目却忽视了这一点，或者更准确地说是他们不愿意"正视"。他们总是试图用详尽的计划去预先穷举这些变化，然后又试图通过严格遵循计划来控制变化的发生，而结果往往是被不断涌现的变化击垮。敏捷开发价值观中承认变化是软件开发的一部分、并相信正是客户在不断变化其需求的过程中明晰了其真正的需要。因而敏捷开发欢迎变化、拥抱变化，并可坦然应对变化，正是这些变化为客户和项目带来了价值。这意味着欢迎需求变化，哪怕是开发后期。

（1）首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。

（2）如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。

（3）为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性

（4）计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

总结：有时开发人员十分抵触需求的变更，一时做不到积极的拥抱变化，最终心不甘情不愿去实现新需求，也就埋下了Bug的隐患。 我们应该积极拥抱客户的需求变化，存在即合理。没有任何的产品是一成不变的。计划赶不上变化快，市场的真实需求不是预先的计划可以全部考量到的。开怀拥抱变化，积极地做出响应。也就拥抱了这个时时刻刻都在改变的世界。 

敏捷宣言的原则

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

    客户满意和有价值的软件是关键词。要确保我们开发的软件产品能够给客户带来真正的价值，这完全取决于在开发期间与客户的密切合作。产品管理是确保客户需求在开发期间被正确理解的关键。我们应该集中精力在对客户最有价值的工作上。

    尽早并持续交付的能力是满足客户的关键。及时交付部分功能比最后交付全量功能更好，至少我们应该给我们客户一个选择。

总结：闭门造车，只会脱离市场，无法紧跟市场节奏。及时的将产品交付，让真实用户体验，才能被客户和市场所接受。

2.欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。

    我们的目标是为了开发能够帮助客户提升价值的产品，要支持任何变化。变化不是一种否定，它体现了团队和产品负责人在敏捷开发过程中的一种工作方式。

总结：积极拥抱变化，不断满足客户多变的需求，提升产品的竞争力，同时也不断的提升了自己。

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

     开发周期和发布周期完全不同。尽管有发布周期，但我们的目标是短开发周期。发布周期的长度依赖业务决策，并且和客户的期望紧密关联。短开发周期的频繁交付缩短了反馈周期并增强了学习。频繁交付还能让团队及早暴露弱点并及时移除障碍，增加了敏捷性和灵活性。

总结：有时较长工期的交付产品，会面临更多的挑战，需求改动也更多，牵一发而动全身。我们应该较短工期不断交付可工作的软件，也是对团队工作的小结。提早发现问题，及时的修复。

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

    只要在业务和研发之间建立起桥梁，我们就能从中受益。业务人员和产品管理知道市场状况、客户需求和客户的价值。开发团队知道产品和技术可行性。如何将这两方面结合？我们需要作出睿智的决策。

总结：目前团队中，业务人员与开发人员沟通交流比较少，双方的思想无法碰撞。所以最终交付的产品可能和业务员人员想要的存在差异。

5.激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。

    知识类工作(比如软件开发)是由具有技能和激情的人来做的。为了激发个体的斗志和创造力，自由是最重要因素。要让角色去适应人而不是让人去适应角色。  

总结：给予团队成员最大的自由度和充分的信任，让成员迸发出自己最大的能量。

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

    面对面交谈在分布式开发中尤为重要。当我们看到人们彼此交谈时，信息更多以听说的形式被传递。文档(虽然它很重要)不能代替交谈，将每件事都写下来简直是不可能的。我们不应该只依靠写文档来传递重要信息。

总结：能面对面沟通交流的，绝不使用通讯工具。当面的交流有感情的沟通，而通讯工具则是冰冷的。

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

   Scrum增量交付的软件，是满足团队对“完成”的定义，增量是可以检视的，产品负责人是否决定真正发布它，增量必须是可用的

总结：可交付的产品，必须满足完成的定义。

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

    Scrum没有大而全的计划，每次迭代都增量滚动式的拉取产品待办列表，它为开发团队提供指引，能够促使开发团队向着同一目标前进，而不是孤立工作，迭代的周期固定，满足时间盒的限制。

总结：规定的时间内，团队齐心协力完成定下的 Dod计划。

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

    回顾会检视自身技术等多个方面，为下一个Sprint创建改进的机会，团队的各个成员要求具有成长性思维，追求卓越，Scrum固定的时间盒内拉取任务，让团队有时间处理技术负债，减少后期的麻烦。

总结：不断的总结回顾，是为了下一个Sprint更好的提高。温故而知新，不拘泥于过去，不断的改进。

10.以简洁为本，极力减少不必要工作量。

    架构简洁，面对面沟通，DOD以及DOR的明确定义，都是为减少沟通、交接过程中的浪费，去掉不必要的流程和工作。

总结：以最简洁高效的工作方式来推动工作团队的前进。

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

    追求持续改进，不断完善的框架；每次Sprint来自于Product Backlog，需求目标透明清晰，团队每个成员目标一致，整个团队共同承担责任，而不是单一职权负责制。

总结：自组织团队成员，齐心协力，追求一个共同的目标。

12.团队定期地反思如何能提高成效，并依此调整团队的行为。

    回顾会检视自身并创建下个Sprint的改进计划；对人、关系、过程和工具进行检视，并在下个Sprint列出改进措施，使大家能在下个Sprint中更高效更愉悦。

总结：定期回顾，不断反思，逐步改进。