沈义 · 沈潇灵 译
如果你只有5分钟的时间来学习敏捷（和Scrum），你应该学习敏捷软件开发宣言的4个值和12个原则（也简称为敏捷宣言）。Manifesto for Agile Software Development
这些价值观和原则将为你提供理解敏捷和Scrum的坚实基础。也就是太多所谓 “专家” 都没有的基础。
以下和一些我自己的评论入列，
敏捷宣言的四个价值观
敏捷价值＃1
工具和过程不如个人和互动
要注意这些值语句中的“不如”词。这当然意味着“不如”之后的事物比“不如”之前的事物更重要。
这不是说这些其他事情不重要。只是它们不是其中最重要的。
因此，如果你的Scrum项目未能定义并强制使用质量过程和工具，那么它就不是敏捷法。这是无政府状态。不要称之为敏捷或Scrum项目，然后声称Scrum不起作用。如果你做错了，那不是Scrum的错。
敏捷价值＃2
综合文档不如工作软件
你的团队是否放弃了所有文档，支持面对面交流和工作软件？如果是这样，就太过分了。你还需要文件。
敏捷价值＃3
合同谈判不如客户协作
你是否经常听说敏捷项目太难以预测，无法锁定合同 – 特别是固定价格合同？并非如此。 （固定价格可以使用Scrum吗？可以！）Scrum on a Fixed Bid? Yes, You Can!
敏捷价值#4
遵循计划不如响应变
敏捷是否意味着你没有计划？没有啊！你还需要一个计划。你需要做好准备并愿意在高价值功能出现时更改计划。
更重要的是，你需要有一个过程（我敢说一个计划吗？），以便在此过程中积极寻找和最大化机会。
敏捷宣言的12条原则
持续交付
我们的首要任务是通过尽早和持续交付有价值的软件来满足客户。
你是否在每个sprint中提供有价值的软件？如果没有，这样做不对了。
是的，我多次听说有时某些功能太大而无法融入单个sprint里。然而，如果团队愿意学习如何以不同方式开发软件，我总能找到一种为每个sprint提供价值的方法。
我们都钦佩苹果以不同的方式做事并挑战现状。我们为什么都不能从他们的榜样中学习呢？别说不可能。弄清楚如何做到这一点。新的想法就是真正的进步。
这是一个关注客户的问题，而不是所谓的最有效的软件开发方式。太多软件开发人员以牺牲项目为代价来优化他们的工作。这与制造或运营中的局部优化问题相同，看起来是正确的做法，但最终会使整个过程效率降低。
更快地交付（不完整的，次优的）并获得客户反馈，比完成所有工作，揭开它，然后发现它不是客户需要的更有价值。
迎接改变
欢迎不断变化的要求，甚至在开发后期。敏捷过程利用变化来实现客户的竞争优势。
项目的重点是提供价值。如果你在项目后期发现某些事情，或者市场条件发生变化，那么抵制对项目进行有价值的改变就是短视的。
经常交付
要经常提供工作软件，从几周到几个月，优先考虑更短的时间尺度
我们从瀑布式方法中学到的最重要的事情是，通过获得客户对工作软件的频繁反馈而不是通过详尽的文档来了解客户的需求会更加有效。
与商界人士的日常协作
商务人员和开发人员必须在整个项目中每天合作。
能够每天向商务人士提问，这非常有价值。这个能力可以为你节省大量时间并重新工作以快速获得答案。
找到合适的人并将需要的东西给予他们
在有动力的人那里建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
你可以使用具有明确定义，可预测和常规的某些角色的初级甚至无动机的人。不是那些具有高度不确定性的项目 – 就像每个软件开发项目一样。
你需要一支经验丰富，能力强，积极主动的团队，以便有效地处理困难项目中出现的所有问题。
面对面的对话
向开发团队内部和内部传达信息的最有效方法是面对面交谈。
坦率的面对面交谈非常有助于建立关系，我也不知道到底是什么原因。这样的对话里可以更快地得到答案，并且可以更轻松地获得澄清。这可以加速项目并帮助你避免重复工作的辛苦。
报告不如结果
工作软件是进步的主要衡量标准。
这就是努力的意思，对吧？ 通过频繁提供有价值的软件向客户证明你正在取得进步。
依靠报告而不是工作软件是在每个人都意识到项目无法实现之前浪费数百万美元。
可持续的速度
敏捷过程促进可持续发展。 赞助商，开发者和用户应该能够无限期地保持稳定的步伐。
不要再多的死亡行军，熬夜，长周末，大推…… ……如果你这样需要付出非凡的努力才能弥补，就是表明你做得不对。了解如何更顺利地管理项目，以便建立并保持可持续的步伐。
优势
持续关注技术卓越和良好的设计可提高敏捷性。
你需要小心地建立技术卓越的平衡，这种平衡介于过度设计所有内容（软件开发人员喜欢做的事情）和只是一起破解一次性代码。
编写良好的代码将允许你接受更改而不会破坏所有的内容。
目的不是要让一切都完美。而是为变化做好准备。
简单
简单性 – 最大化未完成工作量的艺术 – 至关重要。
我喜欢这对简约的定义。你要通过谈论自己的工作，抓住每个机会简化。也要找到不需要做的事情并应用80/20原则。
更简单的代码更稳定，更易于维护，并且以后可以通过高价值功能更轻松地扩展。
自我组织团队
最好的架构，要求和设计来自自组织团队。
如果你拥有一支高级专业人员团队，那么你应该依靠他们来决定团队中谁是最适合每个功能的人。
不要将自组织团队与非管理团队混为一谈。项目经理仍然需要做很多工作才能为成功的项目创建环境，计划，规则等。你仍然负责领导和管理团队。
自组织只是意味着你了解到优秀的团队成员通常（尽管不总是）最好的决定谁应该做什么，哪些工具和过程最有效，等等。
持续的进步
团队要定期反思如何变得更有效，然后相应调整其行为。
乐意接受持续的改进。也要帮助你的团队成员接受。高绩效团队经常反思他们如何在团队中更有效并改变他们的工作方式来抓住机会。
你的敏捷计划或Scrum项目未能实现吗？ 如果是，要阅读Scrum失败的两个主要原因。
