Certified ScrumMaster

作者：辛光烁 在艾威的课程班报名了scrum master的培训课程后，我花了一段时间认真的重新将老师的网络课程以及scrum指南回顾学习了一次，以下是我对scrum master的一些感受。 我个人是从事传统汽车行业的，对于传统的汽车开发/甚至是传统的汽车软件开发模式，一般遵循的是瀑布模型，从分析，设计，开发，测试，所有阶段是分开的，当我们结束分析后再去进行设计，设计做好后在做开发，等等。这种模式属于传统和经典模式，在汽车行业中至今仍然在使用。一些车载软件的娱乐系统更新换代的周期在几年以上，在长周期背景下，将每一步做好也可以节省成本。 但是在软件开发中我意识到，如果开发软件的同时也有大量的需求的更改，那么存在两周情况，意识退回去重做，造成延误，二是不能响应市场的需求，这两者在基于互联网开发的背景下是致命缺陷。版本迭代周期过长，没有办法满足用户需求上的变化。于是我想学习一下敏捷开发是如何解决问题的。 通过学习，我自己的认识是，在敏捷中为了解决需求的变化，可以将分析，设计，开发和测试通过不同用户故事的条件下组成不同的开发周期，组成不同的条目，如果要增加需求，那么只需要增加相应的用户条目，由PO进行确认并排序优先级，或者相反的删除需求，对于整体项目的损耗就降低了很多。同时在开发的同时，也有机会对趋势重新进行分析，这样开发的产品永远都可以跟上市场的节奏，可以实现敏捷开发。 在多种敏捷开发的模式中，Scrum是一种敏捷开发的方式，它的特点是：灵活性、适应需求变化、更适合团队比较小的情况、每一个迭代均有产出、容易学习。 对于scrum的使用流程，在每一个Scrum开始的时候，需要进行sprint计划会，确定这个Sprint要做的事产品待办列表，随后大家开始执行。在每天开始时，进行每日站会。在这一个周期结束的时候，一般是2-4周后，开sprint审查会议，审查会议之后要开一个回顾会议.以上步骤完成后，再开始下一次的Sprint。 对于scrum中的角色分类，核心团队包括产品负责人、Scrum教练和开发团队。猪队中，最重要的角色就是产品负责人，因为这个项目失败的话，他和开发团队是需要承担责任的。Scrum教练不对项目里面的任何细节负责，他只对这个团队是否合理的使用Scrum负责。 对于scrum的框架，包括产品待办列表，要不断的把已知的所有需求记录到这里面来，sprint计划会是对这个Sprint进行规划的会议。它的主要的目标就是从产品待办列表里面选择一些任务，放到Sprint待办列表中。Daily Scrum是一个用于同步进度的会议。会议形式是每日站会来进行昨天做事情，今天做的事情以及遇到挑战的总结。Sprint审查会是一个用于Sprint总结的会议。会议形式会演示产品增量，目的是把之前做的Sprint新功能给大家进行演示。Sprint 回顾会是一个用于Sprint回顾的会议。会议目的是回顾组内成员在项目开发过程中做的怎么样。 但同时，在使用scrum的过程中也需要一些注意的方面，包括Scrum绝对不能代替传统软件开发方法，Scrum适合十人左右的团队，Scrum的一个Sprint时间为2周–4周，Scrum需要一个强有力的团队等等。虽然scrum可以实现敏捷开发，但针对传统汽车行业的项目也要确定是否团队适合Scrum应用，外界的需求变化是否会很多多，这是决定使用Scrum的出发点。如果决定了使用scrum，在确定团队，相应的scrum master，找到合适的工具，比如每日看板。 欢迎报名我的线上课程 - Scrum敏捷精髓

作者：曹天宇 Scrum指南读后感 本人从事传统汽车行业，敏捷经验或scrum经验为0，甚至没有软件开发经验，参加本次培训目的是对敏捷开发有个入门的了解，并结合传统汽车行业的开发流程做一定的思考，因为现在汽车上也会涉及到越来越多的软件。 以下是看完Scrum指南后自己归纳的重点（理解还是更多基于理论层面）： Scrum是一个框架 ，用于开发 交付 持续支持复杂产品的，在此框架中人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品。 Scrum 框架由Scrum 团队以及与之相关的角色、事件、工件和规则组成 Scrum的应用：最初是为了管理和开发产品而开发的 Scrum 的精髓在于小团队 Scrum 基于经验过程控制理论 Scrum 采纳一种迭代、增量式的方法来优化对未来的预测和控制风险 三大支柱：透明，检视，适应 4个正式事件： Sprint计划会议 每日Scrum站会 Sprint评审会议(review) Sprint回顾会议(retrospective) Scrum价值观：承诺commitment，勇气courage，专注focus，开放openness，尊重respect Scrum团队：产品负责人 + Scrum master + 开发团队， 跨职能的自组织团队 产品负责人：将开发团队开发的产品价值最大化，产品负责人是负责管理产品待办列表的唯一负责人 产品待办列表的管理包括： 清晰地表述产品待办列表项 对产品待办列表项进行排序，使其最好地实现目标和使命 优化开发团队所执行工作的价值 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作 确保开发团队对产品待办列表项有足够深的了解。 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定 开发团队：负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。在 Sprint 评审会议上，一个“完成”增量是必需的。只有开发团队成员才能创建增量。开发团队由组织组建并得到授权，团队自己组织和管理他们的工作， 规模3-9人 特点： 自组织的 跨职能的 不认可开发团队成员的任何头衔，他们都叫开发人员 不认可开发团队中所谓的“子团队“ 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队 Scrum Master: 负责根据 Scrum 指南中的定义来促进和支持 Scrum， 服务型领导 服务于产品负责人： 尽可能确保 Scrum 团队中的每个人都能理解目标、范围和产品域； 找到有效管理产品待办列表的技巧； 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项； 理解在经验主义的环境中的产品规划； 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值； 理解并实践敏捷性 按要求或需要引导 Scrum 事件。 服务于开发团队：