项目管理敏捷开发知识框架

Posted 2021-04-25 地瓜码农

本系列对敏捷开发的相关基础知识做一个大概的梳理，后续各部分将会结合作者自身的工作经验详细的介绍。

敏捷开发是指一套软件开发方法，鼓励干系人之间持续合作并快速、频繁以小增量的方式交付有用的功能。敏捷方法种类繁多，其中最流行的包括Scrum、极限编程、精益软件开发、特性驱动开发以及看板方法。敏捷方法基于以前的迭代和增量式软件开发方法（最早见于Boehm 1988；Gilb 1988；Larman and Basili 2003）。

各种敏捷开发方法各有千秋，但是本质上都离不开适应性（有时称为“变化驱动”）方法，而非预测性（有时称为“计划驱动”）方法（Boehm and Turner 2004；IIBA 2009）。预测性方法视图在软件开始构建之前通过周密的策划和文档将项目的风险降到最低，比如瀑布开发就是预测性方法；项目经理和业务分析师要在开始构建之前就确保所有干系人都准确了解要交付什么产品，只有需求从一开始就得到充分理解，并且在项目期间能够相对稳定，这种方法才能可以很见效。敏捷方法等适应性方法旨在适应项目中发生的不可避免的变化，它们对需求高度不确定或波动的项目也很有效。

目录索引

（一）与传统的瀑布模型对比

（二）敏捷开发基本概念

（三）如何进行敏捷开发

（一）与传统的瀑布模型对比

如果我们把通常软件工程的普遍环节划分为分析、设计、实现、测试和交付，并将其按此顺序重叠为一个完整物体（类似于盖房子）。那么对于传统的瀑布模型来说，是以垂直方向累积成果的，各个环节之间存在着前后的依赖关系，各环节投入的人力成本与积累产物百分比并不相关，并且对于变更的适应性和应对风险的能力都较差。

一般在瀑布开发项目中，为了尽量使整个需求集合“正确”，团队会投入大量的精力；即便如此，也几乎没有项目会使用完全串行的瀑布方法，在各阶段之间总会有某些重叠和反馈。

在从完全固定的、预测性的项目到完全不确定、适应性的项目之间的范围中，关键区别在于从某个需求创建到基于这个需求的软件交付给客户所经过时间的长短。

与之相对应的敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。对于需求范围不明确，需求变更较多的项目而言，可以很大程度上响应及拥抱变化。 敏捷开发可最大程度体现80/20法则的价值，通过增量迭代，每次都优先交付那能产生80%价值效益的20%功能。能最大化单位成本收益。

借用一个形象的例子，可以生动的诠释二者的区别：

• 敏捷开发 客人到餐馆来点菜（新项目）
• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
• 根据图文菜单，客人点了个菜（根据原型和设计稿，基本确定了需求）
• 后厨开始准备（项目启动）
• 配菜、炒菜，先上了两盘，让客人尝了尝味道（先提供可用实例给客户用）
• 客人说还不错，后厨继续准备后面的菜，陆续上菜（不断迭代，不断测试）
• 上菜过程中，客人突然发现有个菜的味道太淡了，让后厨加了点盐又端上来了（敏捷的好处，可以不断测试和需求变更）
• 又上了两盘，不够辣，又拿到后厨加了辣（敏捷的坏处，需求没有提前明确，反复迭代，增加了工作量）
• 到最后两盘时，客人要求换两个菜，还好没炒（迭代的好处，随时接受需求变更） 客人吃完，很满意（基本满足了全部的要求）
• 瀑布模型开发
• 客人到餐馆来点菜（新项目）
• 不确定客户想吃什么的时候，通常选好餐厅后会先看看餐厅的菜单（客户往往提不出具体的需求）
• 根据图文菜单，客人点了十个菜（根据原型和设计稿，基本确定了需求）
• 后厨开始准备（项目启动）
• 根据客人的下单配菜，炒菜（基本上不会主动去了解完整需求）
• 半个小时了，菜还没上桌，客人饿极了（项目启动后很长一段时间客户什么都看不到）
• 再过了二十分钟，十个菜都一起上来了（项目最终一次交付）
• 客人说，有几个菜挺好的，但是有个菜味道淡了，有两个不够辣，还有两盘重复了想换掉（我是买单的，我要变需求）
• 这时候大堂经理来了，说，“味道淡了可以加盐，不辣可以加辣，但是换菜不行，已经炒好的那两盘菜也是要算成本的”（瀑布的坏处，需求变更比较麻烦）
• 于是，后厨只给客户加了盐，加了辣
• 客人吃完，不是很满意，下次不来了（没有满足需求）

但总的来说，在现在管理项目过程中，并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用，如果选择了某一种模式（这种选择可能是在经营层层面上的），那么就一定要按照方法论结合自身公司或项目的实际情况，严格的实施，才有可能从这种模式中获得对公司或项目的益处，否则只会徒增成本，徒劳无功。

（二）敏捷开发基本概念

1.角色

在敏捷开发中的，主要涉及到以下几个角色：产品负责人（Product Owner，PO）、敏捷专家（Scrum Master，SM）、Team Leader、开发人员（DEV）、测试人员（SIT）；开发人员和测试人员组成了一个相对固定的开发团队（Team）。

产品负责人主要负责对产品需求的提炼，将偏业务化的需求描述过渡到业务与技术结合的方式，构建业务与技术双方能够流畅沟通的桥梁。需求条目化可以更好的分解一个庞大的需求，分清主次，梳理出需求的核心，以此为基础进行可持续的设计、开发和交付。那么对于已经分解的需求，还应按照一定的规则排列优先级，具体以何种规则，并没有统一的规范，这取决于业务的要求、需求的形态、开发团队的能力等诸多因素，需要进行综合的评估和考量。

敏捷专家的工作贯穿整个敏捷开发的生命周期，通常来说，标准的敏捷方法并非适应所有的情况，不同的组织或者团队会依据自身的情况，对敏捷规范进行修正；那么，敏捷专家的工作，就是要保证所制定的规范能够保质保量的实施落地，没有规矩不成方圆，好的流程控制，能使得整个项目工作井然有序，步步为营。

一个完整的开发团队包含了开发人员（前端、后端）和测试人员，这里主要谈一谈开发人员在团队中或者说在项目中承担的工作。对于代码工作部分，最主要的当然是对领取的故事任务进行开发，在开发过程中，还包含了自行验证和测试的工作，例如静态检查、复杂度测试、编写测试用例进行功能测试等；当本地测试完成后，即会通过Git的push操作向本次分支进行代码提交，触发持续集成（Continuous integration，CI），在这里Team Leader会对代码进行评审（Code Review），判断代码是否可以并入分支被仓库接纳，对于大型的项目，代码评审可以借助一些工具，如Gerrit、Review Board等；评审未通过的代码将被退回并要求修改至重新评审。在开发团队中，还有另一部分的工作，是对于项目环境的构建和维护，对于大型团队，会有专门的负责环境的人员对代码库和项目环境进行管理；对于小型团队，这一部分的工作很大可能性是落在了开发人员的身上，既需要对开发环境进行管理，又需要对测试等环境进行支持。

2.清单

清单主要有两个，一是主要面向业务人员的产品待开发项（Product Backlog，PB）；另一个是主要面向技术人员的迭代待开发项（Sprint Backlog，SB）

PB清单是从业务价值角度理解的产品功能列表，功能、缺陷、优化等都可以是待开发项；对于PB中的每一条事项，其优先级应该是以业务价值为导向的其描述的重点是放在如何制造这个目标或者说完成这个目标，而并非是如何使用；越高优先级的条目越应有详尽的描述，因为这些条目是很有可能会进入迭代周期而被实现的，越详尽的描述，对于需求的理解、拆解、设计也会越准确，如果某一条目的需求内容过多，那么它可能被拆分至多个迭代进行实现，每一个迭代中实现的需求工作总量应被控制在0.5-10人天（前提是一个迭代内完成多个需求），确保在一个迭代整体内能够完整交付所需实现的需求，并能够持续的对项目进行交付。

SB清单是从开发技术角度理解的迭代开发任务，它把一个产品待开发项分解为沟通、设计、后端、前端、UI等开发任务，由各个执行人员评估各部分所需的资源（人力、环境等），得出总体的资源总数。

3.会议

会议部分主要有四个，即敏捷计划会（Sprint Planning Meeting）、每日立会（Daily Stand-up Meeting）、敏捷评审会（Review Meeting）和敏捷回顾会（Retrospective Meeting）。

敏捷计划会的目的是为了制定当前迭代周期的开发目标以及需要完成的工作，在会议开始前，PO需要准备用户故事和产品功能列表。该会议的参会人员包括：业务人员、项目负责人、技术负责人、开发人员、测试人员和运维人员等。这个会议中，由项目负责人公布本周期项目的目标和度量标准；接着，由业务方确定需要完成的业务的优先级，当确定了本周期内需要完成的需求后，开发团队一起进行业务需求的拆分并逐项进行工作量的评估，这里如前述所说，可能涉及到需求的拆分或者对于需求的渐进明细，根据评估的结果和团队的经验，最终确定本次迭代的工作范围。敏捷计划会会给项目带来若干的成果，有形成果诸如带有优先级的用户故事或任务列表，根据该列表开发人员可以进行开发，测试人员可以进行功能确认 ；无形成果诸如统一团队对于需求的理解、业务知识和专业知识在评估的过程中进行了高效率的流动、PO对于团队的现状有了更深的认识、暴露项目风险等。

优先级排序在这个会议中是最重要的，通常使用的方法是MoSCoW方法。在这个方法中，将需求分为Must、Should、Could和Would not四级。Must表示在这个迭代中一定要做的，Should表示在这个迭代中应该做，但若没有时间就算了；Could表示在这个迭代中不太需要的，如果有就更好了；Would not表示在这个迭代中不需要做的。我们都知道，一个迭代周期中的资源数是有限的，通常我们会为Must分配60%的资源，Should分配25%的资源，剩下10-15%为浮动余量以解决突发性问题。这样的分配并非一成不变，甚至在不同的迭代周期中可以采取不同的分配比例以满足项目的需要。

每日立会是由开发团队执行的，目的是梳理当前开发过程中的进度、问题以及期望；对应回答三个问题：从昨天的立会到现在，完成了什么？从现在到明天的立会，计划完成什么？有什么阻碍了进展，风险和困难暴露？根据这三个问题的回答，可以明确本次迭代截止当前的情况，为后续工作的开展提供依据。

敏捷评审会比较灵活，可以安排在迭代周期的中后段，目的是为了向业务方或客户展示在本次迭代周期中的成果，并获取反馈。结束后，可以根据反馈情况做适量的调整和修改，当然，如果涉及到变更，那么还应该依照标准的变更流程进行执行。

敏捷回顾会是对本次周期内经验教训的总结，如果迭代周期出现了问题而最终没能完成目标，还应对失败的原因进行分析。经验教训的总结通常分为定性分析和定量分析，定量分析可以借助工具和图表来完成，工具如：atlassian confluence wiki，图表如：迭代速率、迭代燃起燃尽图（Burn Down Chart）、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境BUG数、生产BUG解决时间及用户故事等。迭代周期失败的原因，通常可能是团队成员突发性调整、PO经验不足、技术债务爆发等。

以上即是在敏捷开发中涉及到的基本概念，其实对于敏捷来说，并非是一套固化的标准，各个部分之间均是可以灵活的调整，一切的理论均应与实际相结合，死板的教条主义只会让原本已经纷繁复杂的项目变得更加混乱，以至于最后的失败都成了必然。

（三）如何进行敏捷开发

1.客户参与

对于敏捷项目，客户（或者代表客户的产品负责人）会持续参与整个项目，在某些敏捷项目的初始规划迭代中，客户与项目团队一起对用户故事进行识别和排优先级，使这些用户故事形成初步的产品开发路线图；相比传统的功能性需求，用户故事通常没有那么详细，因此需要客户在迭代中为设计和构建工作提供输入和澄清；迭代中的构建阶段完成后，他们还要对新开发的特性进行测试并提供反馈。

2.文档的细节

在敏捷项目中，客户与开发人员的紧密协作通常意味着不必像传统项目那样详细记录需求；业务分析师或其他需求负责人会在必要时候以必要的精确度进行沟通和记录（IIBA 2003）。

敏捷方法提倡创建最基础的文档，只要足以用于准确指导开发人员和测试人员的工作；除此（或者满足规模或标准所需的基本文档）之外的任何文档都是浪费；某些用户故事有少量细节，其中只有最具有风险或影响最大的功能才有更详细的说明，并且通常采用验收测试的形式。

3.Backlog和排优先级

敏捷项目中的产品Backlog包含团队采取行动的请求清单（IIBA 2003），产品Backlog通常用用户故事来填充，但也有些团队使用其他的需求、业务处理过程和待修正的缺陷来填充；每个项目应当只维护一个Backlog（Cohn 2010），因此，在Backlog中的缺陷需要与新用户故事一起排优先级；有些团队会将缺陷改写为新用户故事或者原有老用户故事的变种。Backlog可以使用故事卡片或者在工具中加以维护。

对Backlog排定优先级是一项持续的工作，需要从工作项中选择哪些进入随后的迭代以及哪些应当从Backlog中剔除；分配给待办项的优先级无需一成不变，只要适用于下个迭代即可（Leffingwell 2011）；追溯Backlog项的业务需求有助于加速优先级的排定；不只是敏捷项目，所有项目都应对Backlog中剩余工作的优先级进行持续的管理。

4.确定时机

敏捷项目的需求工作类型与传统开发项目基本相同，一样需要从用户代表那里收集需求、分析需求、详略得当地记录需求并确认需求能够达到项目的业务目标。然后，在敏捷项目开始的时候，根本不会记录详细的需求；相反，在项目早期，高层需求通常以用户故事形式收集并填充到产品Backlog中，用于规划和排定优先级。

如下图所示，用户故事分配到特定的迭代中实现，每个故事的细节都在迭代中得以进一步澄清；需求在整个项目中进行小部分的开发，甚至持续到产品发布之前。然而，尽早了解非功能性需求也很重要，以便设计的系统架构能够达到关键的性能、易用性、可用性和其他质量目标。

5.史诗、用户故事和特性

用户故事是一段简要说明，用以阐明用户的需要并以此为起点进行沟通，进一步充实细节。

用户故事的大小要求能够在单一迭代中完全实现。

Mike Cohn（2010）如此定义史诗：“规模过大以至于无法在单一迭代中完全实现的用户故事。”将史诗拆分成更小的史诗，然后拆分成用户故事，这种方式通常称为故事分解（IIBA 2013）

特性是能够为用户提供价值的一系列系统能力。在敏捷项目环境中，特性可以包含单个用户故事、多个用户故事、单个史诗或者多个史诗。

以业务需求为目标，识别出最低层的故事，以便能够确定团队能够交付给客户并为其提供价值的最小功能集合，这个概念通常称为“最小适销特性”（minimum marketable feature，MMF）

在敏捷项目中开发需求时，不要纠结于到底称为“故事”和“史诗”，还是“特性”，要更专注于开发高质量的需求，指导开发人员将能力用于满足客户需要上。

6.期待变更

在敏捷项目中，需求发生变化时，要做的最大调整是学会拒绝：“等等，这不在范围之内”或者“我们需要走正式流程来加入这个变更”，而不是说“好吧，我们来谈一谈这个变更”。这会鼓励客户协作，参与创建和变更用户故事，并且根据已有Backlog对每个变更请求排定优先级。与所有项目一样，为了减少变更带来的负面影响，敏捷项目团队也要对变更进行精心管理，但他们更期待甚至拥抱正在变化的事实。

要明白，虽然能够应对变化，但这并不意味着可以一味忽视未来并且只关注于眼前已知的信息；抬头向前看仍然很重要，要看得更远一些，虽然开发人员无法为未来所有可能的需求进行设计，但只要多看两眼未来，就能创造出一套更加可扩展和健壮的架构或设计，以便日后加入新的功能。

变更还包括从范围中移除待办项。待办项之所以要从迭代范围中移除，原因有多种，概括如下：

• 存在实现问题，使得某个待办项无法在当前时间窗口内完成；

• 产品负责人发现了问题或在测试中发现了问题，使得某个故事的实现不可接受；

• 高优先级待办项需要替换迭代规划中不那么重要的待办项；

7.敏捷转型，怎么办

下面这些建议可以帮助为转为敏捷方法：

• 确定你在团队中的角色。有些敏捷项目有专门的业务分析师，而另一些却由其他岗位的人员开展业务分析工作。要鼓励所有团队成员专注于项目目标，而不是他们各自的角色或者头衔（Gorman and Gottesdiener 2011）；

• 充分理解用户故事、验收测试、Backlog排优先级以及为什么直到项目或版本结束后敏捷业务分析师才能“完成”工作。