敏捷开发------学习笔记

一：瀑布模型存在饱受诟病3 个方面：

1.研发周期过长，导致研发跟不上业务发展的节奏。在瀑布模型中，所有的工作都是串行的，只有前序环节完成后，才能展开后序环节，大量的人力与时间成本就在这段时间里被白白消耗掉了，等产品开发出来再推向市场，很有可能市场已经没有了，或者业务已经发生了很大变化。

2.研发不能很好地响应需求变化，导致客户满意度低。要知道，我们很难在设计之初就把所有的需求都想清楚，而需求又是不断变化的，因此客户在看到真正的产品出来之前，对产品很可能是无感的，正如上面项目中的客户，他们在看到并试用了产品后才觉得这里应该这样，那里应该那样。瀑布模型是直到项目最后，才一次性地向客户交付产品，当产品被开发出来之后，客户才发现他们需要的不是这个东西，这是非常可怕的事情。

3.不能很好地管控风险。这是因为研发到最后才一次性交付产品，所以项目中很多风险在前期很难被完全识别出来，那等到最后发现时再想处理，就要付出更大的代价了。

二：敏捷开发原则和管理

我们先来看一下敏捷的价值观。2001 年，17 个轻量级方法论的大师在美国的犹他州，发布了敏捷宣言，阐释了它的 5 条价值观：

1.个体和交互胜过过程和工具。

2.可以工作的软件胜过面面俱到的文档。

3.客户合作胜过合同谈判。

4.响应变化胜过遵循计划。

5.虽然右项有价值，但我们更重视左项。

敏捷的原则：正确理解敏捷的基石上面我带你重新理解了敏捷的价值观，但对于它来说，只有价值观还不够具体，为了能更具体地指导工作，由它的价值观又引出了 12 条原则：

1.我们最优先要做的是，通过尽早地、持续地交付有价值的软件使客户满意。

2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5.围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6.在团队内部，最具有效果并且富有效率地传递信息方法，就是面对面地交谈。

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

8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9.不断地关注优秀的技能和好的设计会增强敏捷能力。

10.简单——使未完成的工作最大化的艺术——是根本的。

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

12.每隔一定时间，团队会针对如何才能更有效地工作进行反省，然后相应地对自己的行为进行调整。

这 12 条原则是正确理解敏捷的基石，所以在这里，我会结合开篇那几条对敏捷的误解，对这其中的几条原则做个详细的解读。

如何保持“可持续的开发速度”呢

通常都是这样做的：他们在迭代开始的时候，不会过度承诺，也就是能完成多少工作，就承诺多少工作。严格遵守纪律。他们在迭代开始以后，原则上不会再增加需求，如果一定要往他们的迭代待办事项列表里增加其它需求，就要同时从中拿走等量的需求。这么做有什么好处呢？我认为这可以使开发团队聚焦在自己的事情上，不受干扰，效率更高，这样就能形成稳定的开发节奏；而稳定的开发节奏可以加强我们的预见性，这样我们预计的上线时间才可能是精准的。

敏捷开发管理

管理员：Scrum Master

任务工具：conference、jira、禅道
管理版本工具：Jenkins

1.一般来说，一个教练一次只能带 2～3 个团队，否则一个教练的精力是没办法照顾到每个团队的。

2.每个团队都是有开发、测试、业务和迭代经理的、独立的功能。

3.“站立会议”：每天定时定点地开个短会来共享一下彼此的工作内容和状态。

4.及时和客户交流，确认任务的优先级。

5.每个团队根据所在环境和条件确定一个合适的迭代长度，一般建议2~4周。在实践中，一般早期密集开发迭代较快（1周），中期功能补充迭代放缓（2周），后期维护更新迭代就固定稳定下来（3-4周）。

6.当小团队数量多于 5 个时，如果你用的是 Spotify 这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用管理小团队的方法就不够用了。

7.站立会议是有时间盒的，一般不会超过 1 个半小时。在前几次会议中，团队成员会提很多问题，但我们的时间有限，所以如果问题几句话就能解释明白，通常我会当场解释清楚，否则我会安排专门的时间答疑解惑，而不会把会议拖得太长，占用过多时间。你可以看到，这个会议其实也有查漏补缺的功能，可以让你发现团队成员在哪些方面有困惑，或者哪些敏捷知识储备不足，后面你可以安排其它时间来帮助他们专门补齐。

8.它分两层，下面一层是 Squad，指的是一个个全功能小团队，每个小团队中都有自己的业务分析师、开发人员、测试人员和迭代经理（Iteration Manager），能端到端负责一个需求或者产品。一般来说，团队中的人数要限制在 5～9 人，当团队人数超过 9 人时，也要分拆成不同的 Squad。而当 Squad 超过 5 个时，就要考虑把它们划分到不同的 Tribe（部落）中去，它是组织结构的第二层。在敏捷中，我们就是按照从 Tribe 到 Squad 这样的线条去管理团队的。

9.从大的组织结构来讲，我们的团队应该组成一个个小的特性团队，团队是固定的，团队成员也要基本是固定的，这样项目来的时候我就不需要再花费那么长的时间去组建团队、磨合团队了。从需求梳理的过程来看，我不会一次花 2 个半月去梳理需求，并且在最后才给客户看我们梳理的结果，我会边梳理边跟客户交流。我会把需求按优先级排序，形成需求池，迭代地进行研发。我会让客户积极地参与我们的研发过程，包括前期的需求调研梳理和后面的开发测试上线，在迭代有产出时就让客户来验收，让他们提意见和建议，以便我们在后面的迭代中随时调整。

Scrum 框架

Scrum 框架看起来很简单，很多人以为它不过就是“三三五五”：3 个角色（产品负责人、团队、Scrum Master），3 个工件（产品待办事项列表、迭代待办事项列表、产品增量），5 个会议（迭代计划会议、每日站会、迭代回顾会议、迭代评审会议、产品 Backlog 梳理会议），5 个价值（承诺 、专注、开放、尊重、勇气），以为只要把上面这些事都照搬过来做完，就万事大吉了。但其实 Scrum 也是有约束条件的，如果你不按照这些约束条件去使用它，是用不好这个方法的。关于 Scrum 的约束条件，这里我举最重要的两条来说明：在迭代计划会议开始前，产品负责人需要准备好需求条目，使需求达到准入标准；Scrum 讲究时间盒，包括迭代的周期、各个会议，这些都要遵守时间盒的约定。如果不遵守第 1 条约定，你会发现你的团队即使用了 Scrum，研发节奏仍然会被打乱；如果不遵守第 2 条约定，你会发现你的团队会被耗在各个会议上，会议效率又很低，团队成员很快就会感到厌烦。所以说，Scrum 是有纪律的，如果不遵守它的纪律，自由自在无约束，那么使用它注定是痛苦的，也达不成既有目的。