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 学员陈某
什么是Certified Scrum Product Owner (CSPO) 简介 如果您想了解“业务方面”如何进行Scrum转型的话，那么您会渴望获得Certified Scrum产品所有者®（CSPO®）认证的合适人选。 虽然CertifiedScrumMaster®（CSM®）帮助Scrum团队共同学习和实施Scrum，但作为CSPO，您可以创建产品愿景，排序产品待办列表，并确保完成最佳工作以使客户满意。
CSPO认证的好处如下：
扩展你的职业发展机会，跨越敏捷实践的各个领域 证明你获得了Scrum的核心知识 学习Scrum的基础与产品负责人角色 与持续改进的一批敏捷从业者进行交流 除了履行产品负责人的角色外，所有新的Scrum Alliance认证持有者都可获得认证的免费两年会员资格。加入本地用户组和在线社交网络，获得对Gathering大会的大幅折扣等。
要求 上两天的CSPO课程（只有CST才能授课），最新排课计划 完成课程后，登录Scrum联盟网站，接受并同意认证的协议，完善会员信息。 维护CSPO需要获得Scrum Education Units® (SEUs)，每两年需要更新你的证书。
有关SEU信息 什么是CSM 更新你的证书 CSM/CSPO课程如何申请PDU
原文链接
行动 每日问题 你要更新CSM/CSPO/CSD证书吗，有什么问题吗？欢迎给我写信： bob@bobjiang.com 与BoB面对面 报名BoB的敏捷认证课程 订阅邮件列表 关于作者 BoB Jiang
中国北方的第一位CST（Certified Scrum Trainer）
敏捷变革中心（Center for Agile Transformation）合伙人
Bob的博客、《Scrum精髓》译者 欢迎加入自由职业者俱乐部 微信群，请加微信： hiblocknet ； 添加微信后，发送消息 dream 版权声明 本文采用 CC BY-NC-SA 3.0 许可协议。
更新（维护）Scrum联盟的证书 入门认证、高级认证及专家级认证 简言之， CSM证书的更新需要 $100 + 20 SEU
你为这个认证已经非常努力了。不要让它失效！立即更新并保持两年的认证。 更新CSM®，CSPO®和/或CSD®认证可以：
通过从最大、最成熟、最有影响力的敏捷认证机构获得对您的技能、知识和能力的认可，使您自己与所在领域的其他人区别开来 打开职业晋升机会与提高收入潜能的大门 参与志愿者的机会与影响Scrum的未来 持续认证路程并获得更高级的认证 展示电子证书以提升你的成就 为了验证您的参与以及对Scrum基本原则和实践持续的熟练程度，您需要通过完成教育培训或学习机会来获得Scrum教育单元®（SEU）。 这很容易做，并将帮助您保持市场的相关性（和竞争力）。 注意：所有用于更新的SEU必须在过去两（2）年内获得。
学习对于您的持续旅程至关重要，SEU是实现这一目标的简便方法。 以下是获取SEU的各种方法的示例： 注：SEU的6个分类，点击这里 - 观看社区研讨会 - 某种方式回馈敏捷社区的志愿者 - 参与本地用户组 - 参加 Global/Regional Scrum Gathering® - 写Scrum或敏捷博客 - 读有关Scrum或敏捷的书籍
下面SEU的要求从2019年2月4日起生效（更新费用不变）：
两年期的证书 需要的SEU 每期的费用 CSM®, CSPO®, or CSD® 20 $100 A-CSM ， A-CSPO 30 $175 CSP®-SM, CSP®-PO 40 $250 原文链接
