摘要
项目成功？
为什么敏捷与精益出现在软件开发行业？
- 软件开发本质属性：复杂性、一致性、可变性、不可见性。
- 敏捷与精益本质上是帮助我们处理软件开发的复杂性、可变性。
- 敏捷的本质，是承认软件开发的复杂性。而且承认，这种复杂性，达到了这样一种程度：“无法通过足够充分的前期准备，而消除后续的风险。甚至于，前期准备得越是充分，后续的风险越大。”
- 敏捷软件开发是当前应对模糊需求、快速变化需求的最佳方式。
敏捷软件开发很流行
- 公司：Google，Microsoft，Yahoo，百度，腾讯，中兴，华为，......
- 书籍
- 会议，活动
软件项目成功？传统观点
- 成功的（Successful）：按时完成，费用不超过预算，而且所有特性和功能都符合原先的设计规格。
- 不太成功的（Challenged）：已完成并且可以运行，但费用超出了预算，没有如期完成，拥有的特性和功能少于原先的设计规格。
- 失败的（Impaired）：在开发周期的某个时刻被取消了。
软件项目成功？敏捷观点
- 为客户创造价值是评价成功的最重要标准。
- A：110 万收益，100 万成本，延期后果严重（普通外包项目）
- B：5000 万收益，100 万成本，延期后果可以接受（Google Earth, Gmail, Instagram）
- A 项目控制很重要（否则会亏损）；B 项目控制没有那么重要。
- 所有软件开发实践都应该以提升项目收益为首要目标！
IT 技术发展
软件过程与项目管理
敏捷软件开发知识体系
如何做到敏捷
- 敏捷并不仅仅是一种可以遵循的具体过程。
- 一种软件开发哲学、一组实践、一套互补的原则和一个社区。（Kent Beck 描述 XP）
- 敏捷软件开发是一种思考软件开发的方式：敏捷宣言和敏捷原则
价值观、原则和实践
- 如何学习敏捷软件开发
园艺师例子
- 一个朋友 A 是杰出的园艺师。
- 我会掘土、种植、灌溉和除草，但我不是一个好的园艺师。
差异？
- A 知道的技术比我多，并且我们共同知道的技术他比我更擅长。
- 技术是重要的，如果不掘土、种植，你就不是在做园艺。
- 实践。是你天天做的事情。
- 对实践进行详细描述是有用的，它们是明确和客观的。比如在编码前写测试代码，即使你不懂为什么，这种实践仍然是有价值的。
只懂实践？
- 即使我懂了 A 所知晓的所有园艺技术，我还不能被称为一个园艺师。
- 园艺方面什么是好的，什么是坏的，A 有高度发达的判断力。
- 我可能自豪于正确剪枝的能力，A 却可能认识到整棵树都应该除掉。
- A 对花园中有用的东西有个整体的概念，而我没有。
价值观
- 价值观是知识和理解的另外一个层次，价值观是在某种处境中我们喜欢或不喜欢某事情的根源。
- 沟通,简单,反馈,勇气,尊重（XP 价值观）
价值观与实践
- 没有价值观，实践很快会变成生搬硬套，缺乏目的或方向。
- 价值观和实践相结合程序员才能高效的执行实践。
- 实践是价值观的表现。
- 价值观是在一个高层次上的表达，可以以价值观的名义做任何事。
- “因为我重视沟通，所以写了这份 1000 页的文档”，也许是这回事，也许不是。如果每天 15 分钟的交谈更有效的话，文档就不能说明我重视沟通。
- 实践让价值观清晰可见。
- 实践是清晰明了的。每个人都知道我是否参加了早上的站立式会议，但我是否重视沟通并不是那么明确和具体的。
原则
- 在价值观和实践之间架起桥梁的是原则。
- 原则是生活中具体领域的指导方针。
敏捷宣言历史
2001 年，17 位超级极客齐聚犹他州的雪鸟滑雪山庄，共同探索有关软件开发未来发展的共同理念。其中包括 Scrum、极限编程、水晶、特性驱动开发等一些新生方法论的发起者。
与会者达成了一致意见，将这场“运动”命名为“敏捷”。他们授予自己“敏捷联盟”的称号，草拟出一份言简意赅的《敏捷宣言》。
背景：对软件开发现状的不满
1995 年 Standish Group 发布的年度“Chaos”报告中，详实地介绍了传统软件开发方法所造成的令人震惊的失败案例。报告指出，以传统方式运作的企业级软件项目中，只有 16% 可以按时按预算交付，31% 的项目被取消，还有 53% 的项目预算超标 189%。
我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
个体和互动高于流程和工具
- 敏捷力的基本宗旨之一就是，干活的人最清楚该如何完成工作。
- 你的团队总共 6 个人，全都赞成用计划扑克的方式做估算。现在，你筹备了一个新团队，你会指示他们必须使用计划扑克吗?
- 不！
- 可以建议他们用，让他们尝试，但不要规定！
- 流程和工具必须是为人服务的，而不是反过来。
工作的软件高于详尽的文档
- 如果文档着眼于创造价值和以有利方式推动项目进展，那就没问题。例如，对大多数产品来说，用户文档都是很有价值的组成部分。
- 但如果关注焦点不再是产品本身，而变成了流程文档，例如“你的测试规程说明报告，记得要用新封皮!”，那就有问题了。
- 人们普遍误以为敏捷团队是不写文档不做计划的，但实际上，敏捷团队是做计划的，因为计划需要不断地进行细化和更新。敏捷软件项目中的计划以各种形式出现在我们身边，例如用户故事、列表（backlog）、验收测试、和大型可视图表，它们组成了富沟通环境。
- 如果不是文档，敏捷团队该到哪里去找答案呢？你可以求助于可工作软件，它包含了最近构建、测试和集成的一切。
客户合作高于合同谈判
- 敏捷价值观着重强调，开发团队和客户之间要保持尽可能公开和顺畅的对话。
- 基于合同的项目侧重方向不对。相关各方就像是一群合伙人，齐心协力在规定时间和预算范围内努力构建最有价值的系统。
响应变化高于遵循计划
- 计划驱动型组织通常都有“变化控制”流程。
- 只有在变更可控的情况下，变化控制才会有效果。
- 创造价值才是衡量软件开发成功的标准！
尽管右项有其价值，我们更重视左项的价值
敏捷宣言遵循的原则
我们遵循以下原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
创新、研发、运维
精益创业
- 在当前环境下，不管是小型新创企业还是成熟企业都需要不断的创新来维持公司的持续发展，尤其是颠覆性创新。
- 创新是一种非常复杂并且具有高度不确定性的活动，它需要机遇、团队、技术、管理等等因素，任何理论都不可能涵盖到创新所需要的充分条件。
- 精益创业（lean startup，2011）是 Eric 等人一直在倡导的创业（创新）启动方法论，它的过程环主要是“假设（idea）”、“构建”、“检验”和“学习”等几个环节（快速），是一种经验学习型方法，通过不断试错来找到市场可接受的解决方案。
DevOps
“DevOps 是一套旨在减少从提交系统更改到将更改投入正常生产之间的时间，同时确保高质量的实践。”
DevOps 关于的是：
- 将“敏捷”方法引入运营
- 鼓励开发和运营人员之间的协作，让他们进行交流
- 开发（Devs）和运营（Ops）团队共享目标和团队合作
