敏捷开发、DevOps和云计算（一）

1.敏捷开发

1.1敏捷宣言

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

尽管右项有其价值，我们更重视左项的价值

右项的内容正好是传统瀑布式开发的相关要求，通过左右对比，可以发现敏捷开发与传统开发的理念区别。

敏捷宣言并未否定或贬损“右项”的价值，在敏捷开发的价值观中承认“流程和工具”、“详尽的文档”、“合同谈判”以及“遵循计划”的重要性，只是两相比较，“更重视左项的价值”。

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

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

• 当我们开发产品、解决问题或改进工作方式时，我们要寻找改进互动和提高能力的方法
• 在项目期间，产品管理和开发团队必须在一起工作
• 在项目期间，架构师、设计师和测试人员必须每天在一起工作
• 面对面沟通是极其重要的，它不能被其它形式完全替换

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

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

• 要以小步增量的方式构建产品：做一些分析、设计，然后开始编码和测试以验证设计
• 设计需要做，比如敏捷建模工作坊(设计与文档不一样)。如果需要传递信息给客户、维护工作的人员，简易文档还是必要的
• 好架构是持续开发产品的关键，架构是设计出来的，建立一个可实现的简单架构是持续化开发的第一步。随着时间的推移，架构会演进，所以持续追求卓越技术和好设计能够增强产品敏捷性。

1.1.3 客户合作高于合同谈判

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

• 在实践中，意味着产品经理、市场或销售人员在产品开发期间要经常从客户那里请求反馈并排列优先级。
• 在与我们自己的业务方合作中，我们应该寻找开发期间增进和改善合作的方法。
• 产品管理和开发应该密切合作，而不是通过契约或手续。

1.1.4 响应变化高于遵循计划

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

• 首先，预先知道所有需求是不可能的。每个项目都会有浮现和继承的需求。
• 如果我们对客户需求变更做的好，我们就会增强客户的竞争优势还有我们自己。
• 为了鼓励响应变化并使其更容易操作，需要建立流程和工作方式。承认计划的不确定性
• 计划是必要的，但计划必须适应变化：我们需要持续调整计划。前期花很长时间制定详尽的计划的结果会导致大量的返工。同时，我们需要有足够的计划水平来评估业务需求和对其长期影响的判断。这是一种平衡的艺术。

下一篇：敏捷开发、DevOps和云计算（二）