第 2 章 前进 —— 敏捷教育全面铺开
1、敏捷的基础培训大纲
1）传统模式的问题
剖析瀑布模型的适应局限以及给业务部门和IT部门带来的痛点。
2）转向敏捷
什么是敏捷开发？它和瀑布模型最大的区别在哪里？具体方法和价值观是怎样的？
3）实施敏捷的好处
包括对业务部门和IT部门的好处。
4）如何开始？
具体的启动行动。
2、抛出一个问题：“大家听说过敏捷开发吗？听说过的请举手。”
3、“请问你能说说你理解的敏捷开发是怎样的吗？”
4、”在座的各位应该做过不少项目，大家能说说做项目最大的痛苦是什么吗？“
5、瀑布模型的开发过程，对业务部门的痛点有：
1）逾期交付；
2）超支；
3）看到成品时项目已接近尾声；
4）缺乏透明度，不知道具体进度；
5）很难变更需求；
6）最终发现开发出来的产品不是他们想要的；
7）贻误战机，丢失市场机会。
6、瀑布模型的开发过程，IT 部门的痛点有：
1）过度承诺；
2）难以一次性消化所有需求；
3）惧怕需求变更；
4）不断重做；
5）后期压力巨大；
6）加班！加班！加班！
7、分析造成这些痛点的原因
一个项目开始时，业务部门会给IT部门需求概要和期望交付日期。IT部门需要做估算和计划。而在项目开始的时候，只有预算和目标交付时间是确定的，下面的所有因素都存在不确定性：
1）范围与具体需求；
2）可能的需求变更；
3）人员（中途有人会放假甚至离职等）；
4）估算的准确性；
5）对现有系统的影响；
6）服务器环境的搭建（需要什么配置、何时能到位）。
瀑布模型的过程是需求分析、设计、编程、测试和发布等几个阶段。
8、瀑布模型过程存在的问题：
1）瀑布过程中每个阶段一环扣一环，设计、编程、测试都依赖于完整且稳定的需求，因此需求分析非常重要。我们期望能在这里花更多时间来挖掘所有的需求细节，然而在目标交付日期确定的情况下，在需求上花的时间多，后面的开发时间就会被压缩，从而形成矛盾。
2）也因为每个阶段的环环相扣，需求变化会牵一发而动全身，变更成本高，因此IT部门惧怕需求变化
3）在整个过程中，业务部门要在测试的后半部分，也就是用户验收测试阶段才能看到成品，这个时候已经临近目标交付日期，此刻用户才发现产品并非他们想要的已经太迟了，覆水难收。简单来说，瀑布模型适合确定性非常高的项目，而这样的项目凤毛麟角。软件开发过程充满不确定性，我们要管理和适应的正是这种不确定性。
9、软件开发最重要的是搞清楚用户到底想要什么！
10、我们要正确地做事（Do It Right），比如确保质量，但前提是我们做了正确的事（Do the Right Thing），交付用户真正想要的东西。
11、用户在看到成品前，可能都无法确定自己真正想要的是什么，因此需求变化是不可避免的，我们必须适应。
12、Scrum是个专有名词，它不是缩写，也没有中文翻译。
13、几个专有名词：
1）Product Owner（PO）
用户/客户/业务的代言人，就是可以做出业务决策的人，所谓业务决策包括需求与优先级。
2）Scrum Master
熟悉Scrum流程的人，指导和确保团队以Scrum的方式进行交付。
3）Sprint
Scrum中对迭代的说法。一个项目/产品的交付就是由一个又一个的Sprint构成的。
4）User Story
用户故事。具有业务价值的交付单位，一个项目/产品是由很多用户故事构成的。
5）Product Backlog
可以理解为项目的代办列表，由用户故事构成。
6）Sprint Backlog
一个Sprint的代办列表，确定Sprint里有哪些用户故事，框定Sprint的开发范围。
14、Scrum的整个过程
每个项目或产品的交付由若干个Sprint构成。Sprint的周期是固定的，以保持节奏。通常是2～4个星期，不建议超过4个星期。
Scrum的整个过程13、敏捷宣言
· 个体与交互胜于过程与工具；
· 可工作的软件胜于面面俱到的文档；
· 与客户的协作胜于基于合同的谈判；
· 响应变化胜于遵循计划。
14、敏捷所有的改变，就是为了一件事情——快速反馈：
· 短迭代开发——让PO更快、更早地看到成品，给予反馈；
· 每日站会——每天都能看到进度和阻碍；
· 回顾会议——每个迭代都反思改进点，形成持续改善的机制。
15、敏捷开发给业务部门带来的好处：
1）不再需要一次性解释所有的需求；
2）可随时提出需求变更；
3）进度透明；
4）确保最重要的需求能在目标交付日期获得；
5）确保得到正确的产品。
16、敏捷开发给 IT 部门带来的好处：
1）不再需要承诺一个未必能实现的计划；
2）更早地开工和交付；
3）为当前迭代进行更精确的计划；
4）适应需求变化；
5）适应不确定性；
6）开发正确的产品；
7）与业务人员的争执更少。
17、启动敏捷开发的几个建议
1）围绕已知的范围和需求定义用户故事和建立Product Backlog；
2）为用户故事排优先级；
3）商定Sprint的长度；
4）商定Spring计划会议和评审会议的日程；
5）商定发布计划；
6）准备相应的辅助工具。
18、DevOps
实现开发与运维一体化和端到端的持续交付，它融合了敏捷与精益的精神，涉及自动化、精益思想、量度和分享。
DevOps
本章知识点小结：
· 敏捷开发与瀑布模型的最大区别——迭代开发/增量开发；
· Scrum——Product Owner（PO）、Sprint、Sprint计划与评审会议、每日站会；
· DevOps——打破开发与运维的“墙”，实现端到端的持续交付。
网友评论