敏捷开发框架_【项目管理（二）】敏捷开发知识框架-PART2

系列索引

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

（二）敏捷开发基本概念

（三）如何进行敏捷开发

敏捷开发知识框架

（二）敏捷开发基本概念

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经验不足、技术债务爆发等。

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