日志
Scrum详解
2020-07-07 14:54
一、什么是Scrum
Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。 二、Scrum角色  图1 Scrum流程图 Scrum主要流程如上图所示，主要包括3个角色、3个工件、5个活动和5个价值观。 2.1 三个角色 2.1.1 Product Owner 职责： a.清楚知道产品的 愿景，分为近期和远期。 清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。 b.获取外界的诉求并分析整理成UserStory 外界：用户、运营部门、其他业务方。 User Story：需要实现的功能，以客户的角度，描述“我需要功能A，来达到我的什么目的”。 c.对整理好的UserStory所需要的资源进行个方向协调并得出“是否可行，什么时候可行”的结论 一个功能的实现，有时涉及各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通。尽最大努力避免在开发过程中才发现问题，这时候再和其他系统沟通影响面就很大了，其他业务系统的人员很可能拒绝进行协助，业务紧急强行要求协助会打乱其他团队的开发计划。 d.根据产品的近期目标，对UserStory进行优先级排序；期间有更好的Idea需要对UserStory进行优化，这是一个持续过程 注意：只有一个1一个2...一个10。不要把这些功能放的同等重要，这期全部都要实现，全部都是1，这就失去了优先级的意义。 e.需要从外界到PO手里的时候，不应该一味的紧缩一线开发人员的时间 PO的责任不仅仅是满足外界的诉求，还应考虑Team人员的工作状态和情绪，他们可是实现你“蓝图”的一线人员。因此，Po应该全面考虑团队的目前状态，有时督促团队全速前进，有时应该是Team的保护伞，这些都是为了公司的蓝图更快、更好的执行。 f.初步决定Team每个Sprint要完成哪些Story任务 这里只是初步决定，精确的结果要在下面的PlanMeeting中Team对其进行时间评估，最后根据该Sprint的任务饱和度，进行Story的裁剪和增加。 g.在一个Sprint开始后结束前，如果有紧急需求进入，需要站出来保护团队，因为很多需求都是认为紧急而已 尽量避免Team受外界影响，这时候插入紧急需要往往会打乱开发节奏，从而引发各种风险和问题。这个“紧急”需求，如果经过讨论和仔细分析后，大家得出的结论还是紧急并重要的话，那么这个需求形成的Story就要插入此次的Sprint，优先级列表在这个时候就起作用了，可以在此次Sprint的优先级列表中移除一些低优先级Story。 2.1.2 Scrum Master 职责： a.协助Product Owner整理需求 开发是最熟悉每个业务流程以及可能的牵涉方，要完成列表中的Story，需要协调哪些资源，以及协助评估现在的资源能否顺利完成这些Story。 b.作为ScrumTeam的带头人，需要确保团队的合理运作，清除Sprint开发中的障碍，引导Team高效的完成每日工作 c.组织团队工作，Sprint planning meeting、daily standup meeting、sprint review、retrospective meeting组织各项会议开展 d.帮助大家接收敏捷的理念，推动团队按照敏捷价值观和原则所倡导的方法做出决策 不要过高的高估团队的适应能力，当然也不要过低的评估团队的适应能力。推行敏捷是一个长期的过程，Team人员有着不同的工作mubiao经验，不同的公司、不同的文化背景，以及现在公司的企业文化影响，推行一套理念都需要专注于明确的目标（Focus）、反馈（Feedback）、纠正（Fix）--3F原则，然后依次循环，长期的反复过程。 e.尽量保证团队在每个Sprint中不被打扰 如果发现有影响团队工作的任务来临，要敢于说“NO”，如果确实是重要紧急的需求，而该Sprint工作量已经饱和的情况，就有必须要协商移除之前优先级最低开始的UserStory，以保证工作的顺利进行。 2.1.3 Team 职责 a.学习和使用敏捷的理念，反馈工作或流程中存在的问题，甚至提出解决方案 b.积极去推动任务的进展，提高自我执行力 c.高效的沟通，尽量避免通过第三方传达的沟通方式 d.高质量完成Sprint开发需求，按期交付 2.2 三个工作 2.2.1 Product Backlog 指有优先级的产品待办事项列表。Product Owner收集来自各方的需求、期望、诉求等，并整理成UserStory表达形式的产品待办列表中，评定优先级。 2.2.2 Sprint backlog 每个Sprint的任务开发列表。 2.2.3 Burndown chart 燃尽图，能够直观的看到在每个Sprint剩余工作时间和任务完成情况，有效的把控Sprint功能交付的风险。 2.3 五个活动 2.3.1 Sprint 冲刺，一个固定的时间周期（通常为2-4week,新项目可以是1week）。 2.3.2 Sprint Planning meeting 通过会议得出本轮迭代任务。Sprint开始的时候，Product Owner、Scrum Master和Team根据团队的资源和能力，从Product Backlog中按照优先级选取这个Sprint要做的UserStory，并且对Team提出的问题进行解释和澄清，最终形成本轮的Sprint Backlog。Team负责将这些UserStory拆分成一个个小的Task，给出完成每个Task的时间估算，一般可在6小时内完成（6小时一般是一天的高效时间，其他时间可作为Buffer），达到可量化。 2.3.3 Daily Standup meeting 每日站会，一般选在早上，15分钟左右。每个人讲诉进展情况（昨天做了什么，今天准备做什么，遇到什么问题），遇到了Block的问题，需要ScrumMaster出面来扫清障碍保证Team能够专注的完成任务。这样能及时的暴露出开发过程中遇到的问题，能够有效的评估风险以及及时讨论解决方案。通过这样透明化的披露，可以将个人和他人的工作结合起来，会更好的考虑到自己的工作是否会影响到别人。通过每个人进展的汇报，整个Team随时可以了解到离完成我们的Sprint目标还有多远。 2.3.4 Sprint Review 在Sprint周期结束，需要进行一次评审会议，向Product Owner和利益相关方展示完成的功能。回答利益者相关问题，并记录期望的更改。评审会议可以让其他人了解团队在做些什么，并得到反馈。 2.3.5 Retrospective meeting 回顾会议，通常在SprintReview会议之后开始。回顾会议是团队内部针对本次Sprint内发生的做的好的进行积累，可以改进的、存在问题的作为Fix项，Fix项作为下一轮Sprint任务，也就是持续积累和改进的过程。将好的吸取，不好的改进，那么流程就会越来越完善。 2.4 五个价值观 2.4.1 专注 只专注每个Sprint要完成的事情，团队和个人能力精力都是有限的，在有限的时间内专注最有价值的事情，以取得好的结果。 2.4.2 勇气 团队完成任务的过程肯定都会遇到一些棘手的问题，需要有勇气去面对和挑战。 2.4.3 公开 Sprint的进展，遇到的问题都应该对所有人透明。这样团队才能彼此了解，彼此尊重，同时也能暴露问题。 2.4.4 承诺 团队在Sprint开始时做出承诺，并在迭代中全力去完成，达成功能交付。 2.4.5 尊重 尊重各个团队以及团队的成员。不要越界议论，相信他人的专业能力。 三、结语 采取高效的沟通方式，除非情非得已，不要由中间人转接各自的诉求，直接沟通，减少交流成本。Scrum是一套工具，实施主要还是看人，其中的流程并非一定完全硬套，工具是死的，人是活的，可以根据实际情况对某些流程进行调整、替换甚至删除，总结一套适合团队的流程最重要。 |
下一篇： 无
上一篇： NDK交叉编译问题求帮助