CSM培训总结 为期4天的CSM培训结束，自己对敏捷有了更深的认识，scrum是一种轻量级的框架，但却有着功能强大的价值观，原则和实践，主要体现在团队能在短期内能够尽快地响应变化，交付产品，快速反馈，适应变化，连续提升，相比较使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就会降低。
在scrum 三个角色当中，我觉得SM相对来说比其他两个角色重要，SM作为team leader和PO紧密地工作在一起，可以及时地为团队成员提供帮助。他的职责在于以下五点：
保证团队资源完全可被利用并且全部是高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review 和Sprite Retrospective。 SM除了主持Daily Scrum之外，还有三个主要职责：
SM需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。 SM需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的条目。 SM还必须仔细考虑进展中的任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。 SM需要找出阻碍 Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。
现在的工作模式基本是按scrum来运作的，在迭代开始前，会有需求清单(Product Backlog)，PO会把Product Backlog排出优先级，识别出更有价值的需求排在靠前，团队从需求清单中选择迭代中要完成的US(Sprint Backlog)，由SM给每个成员做任务划分，然后成员根据开发的周期输出自己计划，将US拆分成每天要完成的Task，每天上班先进行Daily scrum，反馈前一天完成了哪些任务，今天要完成的内容，其中遇到的一些问题，SM通过沟通，协调资源等多种途径解决在Daily scrum中反馈的问题，Sprint Backlog完成形成Increment，由PO和用户验收，之后团队进行Sprite Retrospective，总结出急需改进的Top问题以及继续保持的点。
不过还是有些差异，比如Scrum角色中的PO，只能定位作为一个决策者，团队在迭代过程中遇到解决不了的问题以及与其他团队协作问题等，才由PO来沟通，解决；而需求条目的澄清则由团队中专门负责需求整理输出的同事来承担，这可能是由于商业合作产生的这种模式。再比如迭代的周期都比较长，一个迭代至少3周甚至更长才能完结，迭代的交付时间中固定的，团队只能通过施压的形式，来要求团队成员按照交付时间点来完成产品Increment。
– CSM学员 宋
Scrum敏捷管理学习心得 敏捷开发是一种能应对快速变化需求的软件开发能力，包含Scrum、极限编程（XP）、晶体、特征驱动开发等多种方法。其中Scrum是最被广泛使用的一种方法，旨在指导团队进行产品的快速迭代和增量交付。
敏捷软件开发宣言：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：个体的互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。
敏捷宣言遵循的原则：
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 2、欣然面对需求变化，即使在开发后期也一样，为了客户的竞争优势，敏捷过程掌控变化。 3、经常的交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。 5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 6、不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。 7、可工作的软件是进度的首要度量标准。 8、敏捷过程倡导可持续开发。责任人、开发人员和用户能够共同维持其步调稳定延续。 9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 10、以简洁为本，它是极力减少不必要工作量的艺术。 11、最好的架构、需求和设计涌现于自组织团队。 12、团队定期地反思如何提高成效，并依此调整自身的举止表现。
敏捷的五个核心价值观：专注、公开、承诺、勇气、尊重。
Scrum的三个核心角色：Product Owner（PO）、Scrum Master（SM）、Scrum Term（团队）。
其中 PO的核心工作为：对团队对外交付的价值负责，定义需求、定义需求的优先级和验收标准、定义产品发布内容与日期。
SM的核心工作为：帮助团队遵循Scrum框架，持续改进，促进团队工作，帮助团队排除影响生产力的障碍、保护团队不受干扰。
Scrum Team则对交付结果负责，敏捷团队是自组织的团队、小而美，一般团队成员定义为5-9个人。
Scrum的3个工件：Product Backlog（产品待办列表）、Sprint Backlog（Sprint待办列表）和Increment（可交付产品增量）。
Product Backlog即产品视角的需求清单，由PO负责维护，并根据优先级进行排序，优先级高的颗粒度更细，优先级低的对应颗粒度粗。用户故事是其中一种最佳实践，每项需求都应该描述其外部价值。
Sprint Backlog即冲刺周期内规划要完成内容，来源于Product Backlog，由团队评估和选择Product Backlog中哪些放入Sprint Backlog，同时团队需要一起定义完成的标准。
Increment即冲刺结束后可对外发布的产品功能增量部分。
Scrum的5个事件：Product Backlog梳理会议、迭代计划会议、每日站会、迭代评审会、迭代回顾会：
Product Backlog梳理会议贯穿整个Scrum项目的始终，主要保持产品待办列表有序、凸显价值。
迭代计划会议作为Sprint的开始，决定在迭代中完成哪些待办列表，明确任务和战前鼓舞。会议时长对应Sprint周期每周2小时。
每日站会，会议时长建议为15分钟，检视上一个工作日做了什么，当天的工作计划和存在的问题，阐述最好是可视可量化的，问题不发散，做好时间管理。
迭代评审会议：会议时长一般每周对应1小时，在sprint结束时团队和相关干系人一起评审sprint的产出、完成工作是否符合需求预期，并展示当前产品增量情况。
迭代回顾会议：会议时长一般每周对应45分钟，在sprint结束后，scrum团队开会反省和检讨，对迭代周期内做的好的进行表扬和鼓励，不好的，提出改善方案和完成计划。
Scrum敏捷开发的优势：拥有快速反应的能力，精确要求，精准结果，更大的灵活性和稳定性、提高团队绩效，降低成本，失败的代价降低。劣势：敏捷注重人员的沟通，文档维护难度增加，在新员工较多未形成战斗力时，老员工较累。
结合当前项目实际情况的分析：
1）团队人员数量超出了Scrum的最优定义，站会易超时； 2）PO是新人，没有明确的职责定义，对产品认识度不够。 3）验收标准有时候没有很明确的定义，在长期不上线使用的情况下，拉通联调的支持周期过长，容易“带病”到后面的迭代。 4）新人较多，效能提升，共同价值目标磨合需要时间沉淀。 5）对于迭代评审会议，目前做的不够，没有很好的展示迭代输出成果。 6）奖惩制度不合理，在不断的高压冲刺中，难以长期的保持团队成员的斗志和凝聚力。 相信每个SM在Scrum交付过程中，总会遇到由内到外、由外到内等各种问题，需要不断地反思、学习、总结，所有的管理问题，最终都是人的问题，唯有持之以恒的学习反省，才能走的更远。 限于时间精力和篇幅，先写这么多吧，望谅解！
CSM考试学员：徐某 2020-12-23
敏捷交付 对于敏捷交付培训与实际运用中，我理解为我们需要持续不断的及早交付满足客户有价值的的软件，在交付过程中不断通过变化，通过及时沟通，标准的流程，统一化的工具，进行可持续，高效的交付。
在软件开发中，领导阶层的指挥控制方式（经理创建详细的工作细分结构、向团队分配任务，并告诉他们每项任务要花多长时间完成的方式）存在问题。敏捷方法从业者认识到，实际执行工作的人才是制定这些决策的最佳人选。开发人员确定他们的任务，他们执行自己的评估，他们自愿挑选任务，他们自行分担工作量。在本质上，他们就像一个高效运转、自行组建的团队，没有明确定义项目经理职位。相反，该团队指派某个人作为团队领导，帮助推进整个流程，让团队成长，让团队在缺少SM这个角色后，还能依然运转。
我从如下几点详细描述我了解的敏捷交付:
产品路线图， 项目目标与里程碑， 团队成员责任划分， 团队流程与工具管理， 项目风险管理， 团队反思。 第一，产品路线图。 在产品路线定下来以后，根据产品的背景、前景和价值，让团队意识到该项目的重要性，了解产品的主要交付路线，产品主要需求的优先级，以及大致上线时间点。
第二，项目目标与里程碑。 主要是对产品路线的补充，对交付功能模块的细化，项目完结交付的所有功能点，SM基于产品路线和需求进行模块拆解，澄清所有功能点，对总目标功能点的里程碑设定，以及每个里程碑各个职能组完成的主要任务；
第三，团队成员责任划分。 主要是基于项目功能，明确团队成员和职责，让团队对每个人所负责有概念认识，基于功能和流程，明确团队成员和职责，对项目开展的相关环节的必要说明，大家共同遵守的团队规则章程，明确团队共识的协作方式。
第四，团队流程与工具管理。 为了确保共识计划得到落地执行，团队保持高效交付，那么就需要借助一些研发管理工具，辅助我们进行项目开展实施，同时在项目交付的过程中不断优化交付流程，代码管理，需求管理，人员管理，交付件的管理，将产品需求、项目任务、测试Bug以及其他事项都及时录入到项目管理工具，持续跟进、督促、检查，争取将所有事务录入项目管理工具，包括未被考虑的事情，让团队自己给自己建任务。
第五，项目风险管理。 主要是向团队成员告知个人任务进度和安排，以及需要支持的相关事项，及时暴露风险和问题；同时交付过程中存在需求理解，表达不清晰的地方，人员理解不一样的地方，要及早暴露出来这些风险，通过与客户沟通及视补救，沟通过程流程与工具能够尽早把风险扑灭。
第六，团队反思。 团队定期的反思如何提高效率，并以此调整自己的能力，让团队没个人都能够成长，同时淘汰不符合团队的人，让团队人员更加稳定延续，人员稳定才能保证项目的稳定，让团队成员执行力强，凝聚力强，没有旁观者、推诿者，共担解决；能力强，独挡一面，人人都是神枪手。 通过这6点，我们能够提醒、督促、辅助我们落地美好计划，让团队管理更加透明，让项目实施更加具体、让项目风险更加可预期，同时也可以加速交付节奏，做到极限编程，有着稳定的工具，流程，人员，并以即时的方式来让项目投资获得最高回报。
– CSM 学员陈某
敏捷公开课 如果下面的课程计划中没有找到合适的时间和地点，还可以填写表格（表达课程兴趣，足够的人数即可单独联络开课）
CSM 课程计划 成都 2020年10月31日 - 11月01日 | 我要报名 线上 2020年11月07日 - 11月08日 线上 2020年11月14日 - 11月15日 | 我要报名 深圳 2020年12月05日 - 12月06日 | 我要报名 CSPO 课程计划 敏捷教练训练营 上海 2020年12月17日 - 12月20日 课程介绍 CSM课程 敏捷教练训练营
作者：辛光烁
在艾威的课程班报名了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联盟了解你作为Certified ScrumMaster®所面对的障碍壁垒。获得认证是敏捷之旅中的第一步，我们在这里为你提供独家的好处，以帮助你持续进步。让我们与高质量培训、资源、工具以及全球最大的、活跃的Scrum认证社区一起前行。仅在你拥有ScrumAlliance认证后才能使用所有这些好处。
1）专用工具 更新你的认证将授予你 使用各种工具的专有权限。 诸如” Comparative Agility Personal Improvement（PI）”之类的工具仅提供给Scrum Alliance现有的Certified ScrumMaster。通过认证的ScrumMaster可以使用此工具评估其当前的技能水平，找到成长的机会，并通过社区与同行进行讨论。在社区委员会中，你会发现可以直接与认证的敏捷专家联系。你在PI工具中找到的资源将帮助你成长为ScrumMaster，为你提供在团队中取得成功所需的技能以及其他更多的职业机会。该 ScrumMaster的PI工具 -包括社区委员会- 仅适用于当前有效的认证ScrumMaster 。
有效的ScrumMaster认证中包括 赠送订阅”比较敏捷”，价值每年299美元。该工具专注于团队开发，并利用了全球最大的敏捷评估数据库。你将能够快速进行基准测试并收集信息，获取见解并为你的团队和组织采取行动。与其他敏捷组织相比，这将使你能够评估敏捷团队的绩效，从而为整个公司带来持续改进的思想。
2）认证和培训 学习可能是你敏捷旅途中最艰难的部分之一。通过认证，你可以获得行业领先的教练、资源和培训。Scrum联盟认证是敏捷社区中最受认可的一些认证。我们的课程会定期更新，以确保你了解最新的敏捷和Scrum最佳实践。由行业专家培训师主持的课程将使你受到教育和启发。NPS得分这个维度，我们为CSM培训师的平均得分为+81而感到自豪。你可以通过投资敏捷认证来开始成为认证的ScrumProfessional®（CSP）的途径。
通过证明你对敏捷之旅的奉献精神，脱颖而出成为申请人。我们的课程包括访问授权内容、培训、网络研讨会和志愿者机会，这将使你获得Scrum教育单位（SEU）。需要获得SEU来续费你的认证。这很容易帮助你在市场上保持竞争力。当你通过Scrum Alliance认证后，你将加入一个拥有超过一百万名认证会员的社区。你可以放心所学的内容是基于行业中最新的Scrum教育标准。
3）社区和支持 最后，我们了解 社区 是成功学习和分享你在此过程中获得的知识的关键。在32个国家/地区拥有 150多个用户组，你可以与世界各地的敏捷和Scrum从业人员连接。与敏捷社区同步将为你提供可以验证你所做的艰苦工作的经验。有了所获得的知识，你便可以自由地塑造Scrum的未来，改变你的工作世界！通过志愿服务机会，你将可以直接服务于敏捷社区。除了我们的面对面聚会和虚拟聚会外，Scrum Alliance社区还可以帮助你在事业中蒸蒸日上。
访问 中国敏捷社区小组 - 由Scrum 联盟支持
Scrum Alliance是501（C）（6）非营利组织，这意味着你的续费可以帮助推动世界各地的社区和用户群体，包括服务于欠缺的社区。我们的使命是帮助每个想要改善Scrum和敏捷之旅的人。我们正在改变工作世界。立即续费你的认证以支持全球新的Scrum和敏捷社区 。
原文 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 事件。 服务于开发团队：
转自学员Leon的总结
5.16 ~ 5.17 参加了捷行与 Bob 老师组织的 CSM 双 CST 讲师认证课程，收获远超出预期。
我是编程出身，11 年开始，一直从事互联网行业，17 年正式使用 Scrum 作为敏捷开发框架，也开始接触 Agile，过程中慢慢学习、摸索和运用 XP、TDD、BDD、DDD 等思想和方法，从 Coding 到 Team Leader（兼职 Scrum Master），到现在全职做 Scrum Master。
本以为自己”经验丰富”，对 Scrum 框架的理解”非常透彻”，想通过 CSM 认证后，向 A-CSM 进阶。然而两天的课程下来，还是给我带来不少收获。
两位老师都有各自的风格，Jim 老师有国际软件公司的经验，Bob 老师有一线互联网公司的经验，两位老师轮流教学，虽然部分内容会重合，但是在不同的场景与角度下，总能让人 ~ Aha / Wow / Ya。
记录 因为疫情的原因，我们两天的认证课是通过 Zoom 在线学习，我们小组在共创的过程中，还用到了石墨和 Teambition。
在线的好处就是打破了地域的边界，能和不同地方的学员一起交流，以北上广深居多，学员们来自各行各业，除了互联网行业，还有制造业、传媒业，金融业等，有开发、技术管理、项目管理、咨询师、数据分析师、产品经理（噢！为什么不参加 CSPO）等。虽然大家对 Scrum 的经验各有不同，但都有强烈的好奇心和学习的热情，哈哈。
在线的坏处就是互动不方便，有时候会受网络波动的影响，当然两位老师设计了不少互动的环节，通过 warm-up、在线画画、分组交流、小组课堂练习、课堂提问等，让大家保持互动与反馈，当网络抖动的时候，也会停顿休息下，保证课程的质量。
课堂中老师会通过画布，边讲边画，让课堂变得有趣，从而抓住大家的注意力，很赞。
两天的学习内容很多，节奏也很紧凑，从 Agile 的思想，到 Scrum 的 3355、PBI、DoD、Kanban 等等，经过这次体系化的学习，让我把所积累的知识再串联与梳理一遍，特别是 Day 2 下午的课堂练习，模拟了 3 个 Sprint，让我们每个人都 Inspect 自己的学习成果，十分受益。
