Scrum敏捷开发培训后有感

By 老彦

从⻓长远来看，你的组织可持续的竞争优势就是具有比对⼿更快的学习能⼒。

—— 彼得.圣吉

开端

2021年在即将辞旧岁和迎新年后，公司组织了两次Scrum敏捷开发企业级实训，2月初和3月初各一次。我有幸能参加第一次的培训，俗话说的好：输入只是学习的开始，输出是学习的检验和深化。在第二次培训结束后，感受到很多同事对敏捷开发方法还是有很大的意愿去尝试的。经过几天的思来想去，认为公司刚开始做敏捷转型，有必要做一个简单的文字记录，写下这次有意义的活动，同时也可供其他同事未来日常参考。本文简单小结了这次培训涉及的内容，以及结合了我自己工作中的一些思考，其中有部分文字是之前日常反思中记录下来的，此情此景，正好移花接木一下，希望大家原谅我的懒惰。

内容

通过这次培训，公司软件研发部门的同事从以下几方面了解了敏捷将带给我们的新的软件开发理念。

01 : 敏捷思维和理念

敏捷的核心思维让我们关注：价值驱动；适应变化；自组织团队。

  • 价值驱动– 聚焦最高价值的目标

    敏捷最短时间创造最大价值，以终为始，聚焦最重要的目标，从为什么开始。敏捷可以更快、更早地交付价值，优先交付高价值的需求。

    • 瀑布模式强调单一职责，不同职能部门的工作交接和延迟阻碍价值交付，行政边界导致局部优化，筒仓之间的连接和沟通难以管理。
    • 敏捷模式围绕价值流（共同的目标）建立跨职能团队，加速价值交付。

    明确什么是高价值的需求、需求条目化和价值排序；聚焦高价值的目标、优先交付高价值的需求；围绕价值流建立跨职能团队和可视化看板，加速和持续优化交付价值。

  • 适应变化– 掌控和管理不确定性

    预定义过程和经验性过程的区别，预定义过程制定详细的计划和执行步骤，按计划执行直到所有计划执行全部结束；经验性过程从愿景和高价值的目标出发，小步快走，不断确认和调整，直到目标达成结束。在传统开发模式中，我们假设可以制定出详细的计划，一切都能按计划执行。在敏捷开发模式中，我们承认无法在一开始就明确详细的计划，存在不确定性， 整个过程中很多事情在变化。理解不确定性和涌现式需求；通过迭代、增量建立频繁交付、频繁确认、及时调整、修正，以建立快速的反馈；学习循环，以此降低交付错误产品的风险。

  • 自组织团队– 释放团队的内驱力

    过去的命令和控制式的管理方式已经越来越局限，在知识性工作环境下自组织型团队更是深得人心。自组织要求我们从命令与控制到目标驱动；从微观管理到领袖、教练和服务式领导；通过授权、支持、引导、反馈，所有的决策及交付活动中团队参与、共担责任。

  • Scrum和敏捷概要

    敏捷软件开发宣言。

    image-20210329150627873

    Scrum是一 个管理框架，Scrum用于新产品开发、 项目或团队的管理 。Scrum源自于软件开发，目前已经用于各个管理和创新领域。Scrum的理论基石是检视、透明、调整。

    image-20210329150425241

敏捷文化是我们倡导的一种思维方法，敏捷实践是一系列新的工作方式。敏捷实践和文化要相匹配和适应。敏捷运动是一场关于组织和个体的适者生存的进化，文化变革才是这场运动的核心。敏捷转型中文化变革要打头阵。

02 : Scrum 框架

  • Scrum五个价值观：

    • 承诺-愿意对目标做出承诺；
    • 专注-把你的心思和能力都用到你承诺的工作上去；
    • 开放-把项目过程中的一切开放给每个人看；
    • 尊重-承认每个人都有他独特的背景和经验；
    • 勇气-有勇气挑战更高目标，做出承诺，履行承诺，表达不同的见解。

  • Scrum三个角色的职责：

    image-20210329150758813

    Scrum团队的构成：Scrum 团队由一名产品负责人、开发团队和一名Scrum Master 组成，Scrum 团队是跨职能的自组织团队，团队具备完成项目工作的所有能力

    • Scrum开发团队是特性团队，团队内具备交付一项工作所需要的各领域的必需技能，例：分析、设计、编码、测试等；自组织团队，承诺工作，不是被指派，团队决策，共同担责，决定团队内如何进行决策。拥有共同的愿景、价值观和工作协议的团队文化。

    • Scrum Master是团队的教练，对Scrum流程负责，ScrumMaster每天的工作原则上就是确保团队用正确的姿势，高效地交付，同时，确保团队的文化保持在一个敏捷认同的氛围中。

    • 产品负责人的职责是最大化产品的价值；产品负责人管理产品，帮助团队看到产品愿景和路线图，对需求进行优先级决策，准备并解释用户故事等；产品负责人和开发团队密切合作，随时都能响应团队的需要。

  • Scrum五个活动（在一个迭代中经历的活动）。：

    • 产品Backlog梳理，对接下来迭代的需求进行预梳理，讨论初步的工作量和需要识别的风险。

    • Sprint计划会，团队对本次迭代的用户故事理解，分解，工作量细化评估。

    • 每日站会，每天团队内部分享进展，第二天的计划，识别的风险及需要的支持。

    • Sprint评审会，团队与干系人一起，演示迭代工作成果，验证迭代交付的产品增量。

    • Sprint回顾会，团队内部改进，检讨的过程。产生改进流程和实践的建议并共同负责跟进。

由龙舟比赛角色想到的：产品端和交付端要合作博弈。产品推进需要结合交付端的能力，交付端需要根据自己的实际能力承诺，有勇气做出合理的承诺。交付端对每次迭代的交付范围有决定权，开发核心成员必须进行相应的判断，与产品端灵活沟通并引导期望。我们要做质量交付，而不是数量交付。产品管理者要有全局观，实事求是，平衡好产品端需求和交付端能力的因素，不可顾此失彼，更不可用KPI来控制某一方的诉求，进而实际分裂了整个团队共同的目标。在敏捷交付中，传统项目经理的职责被由PO，SM，和开发团队所共同分担。组织刚开始做敏捷，碰到问题，属于正常。作为敏捷领导者团队的一员，我经常自我反思，也帮他人反思，如何帮团队顶住压力，给团队注入动力。我想这是我们的课题。

03 : 敏捷产品和需求

  • 产品 Backlog

    产品Backlog的定义：是用户需求的集合，是按一定的优先级颗粒度排放的用户故事（需求）、缺陷、风险、技术工作等。具有以下特性：

    • Detailed 合适的详细程度

    • Emergent 涌现式的

    • Estimated 经过估算的

    • Prioritized/Ordered 排列好优先级的

  • 用户故事

    用户故事的定义：用户故事描述对客户或用户有价值的某一个需求描述（功能），用户故事要有验收条件。具有以下特性：

    • Independent 独立的

    • Negotiable 可协商的

    • Valuable 有价值的

    • Estimable 可评估的

    • Small 足够小的

    • Testable 可测试的

军事上，我们都知道一个简单道理：集中优势兵力，对敌人各个击破。分兵乃兵家大忌。当年秦始皇统一中原大地，也是通过远交近攻，逐一征服的策略。心中虽有华夏全局，但清楚自己的目前实力，暂时压抑自己的想法，绝不分兵同时征服。最终统一中华！产品开发上也是一样，虽胸有全局，也要根据优先级远近决定舍还是取。团队同时分散在过多任务，最差会让每个任务都无法按期完成，团队也会遭到诟病，从能力上被外界否定。敏捷团队，你关注的是“想要”还是“结果”？这就是我们要做敏捷产品管理的初衷。

04 ：估算、计划、规模化

  • 敏捷估算

    • 估算目的：计算成本、周期；了解投资回报；做计划；记录团队速度：团队速度是一个 Scrum 团队在一个 Sprint 中实际完成的故事点数。
    • 相对估算法：不必在意一个故事点的绝对时间是多少 因为团队成员的能力不同，每个人所花的绝对时间也不同。
    • 故事点：挑选一个较小的、高频出现的故事定义为一个故事点 ，并把它作为参考基准。估算的是相对的体量大小，而不是时间，不是周期。
    • 通过规模和速度推算时间表。

  • 敏捷产品规划

    • 敏捷产品规划的五个层次：产品愿景/产品路线图/版本规划/迭代规划/每日规划。
    • 敏捷产品研发发布模式一：MVP+ 小迭代持续优化。
    • 敏捷产品研发发布模式二：大版本迭代。

  • 规模化敏捷

    未来，我们将从目前的小型产品团队到大规模产品团队，会有几个甚至十几或几十个这样规模的团队。

后记

培训后反思

Scrum的生产力源于：首先选择正确的工作，然后高效完成选定的工作。产品负责人确定产品Backlog的优先顺序。然而，团队如何实现生产力最大化？由谁负责指导团队使生产力最大化？在Scrum中，团队自行寻找生产力最大化的方法，计划和执行任务完全由团队完成。敏捷教练和其他人可为团队提供指导、建议和信息，但团队必须承担自我管理的责任。团队从被管理到自我管理的转变过程十分困难，但在生产力和工作愉悦度方面的回报显著。敏捷教练的职责是引导团队成功转型。引导团队利用Sprint规划会议进行评估、制定计划和充分理解需求；利用每日Scrum站会检查和适应引导自身工作；利用Sprint评审会议进行工作成果的确认并调整下一个Sprint的工作；利用Sprint回顾会议检讨团队自身、流程和技术实践，使下一次Sprint敏捷实践更加精进。

这是一场敏捷的Scrum方法入门培训，基础的方法和概念比较多，通过工作坊形式让培训效果更加生动，授课与互动相得益彰，我们即是学生，也是老师，现学现用，加深理解。上了一天的敏捷培训课，对我来说温故知新，特别有感触。培训课程给了我们很好的理论指导，而实践是我们的试金石。同时，不建议在一堂课，听了老师的只言片语，就以为找到了自己团队的在某个方面的最佳方法，就像一件漂亮的衣服也不是适合每个美女，对吧？方法的采用能否成功跟环境，时机，人都有关系，所谓的天时、地利、人和。要结合实际情况去分析，消化和尝试，然后再反思总结，最终形成适合自己团队的最佳实践。

敏捷转型对组织的意义

敏捷最大的好处是：在复杂的环境中帮助我们找到正确的事情。敏捷的快体现在让我们更早更频繁的交付，让试错的成本变得更低。打造敏捷组织的关注点是多个方面的，敏捷方法的导入只是行为层面上的体现，行为背后的思维模式才是最重要的。而思维模式的改变需要从组织结构设计、组织文化牵引、流程及制度、绩效及奖惩措施多个维度来考虑。

很多时候后被问到：敏捷是什么？我的理解：

  • 敏捷是流程：我们有Scrum来规范流程，更有条理，更有节奏，像心跳一样，且更有愿景感。

  • 敏捷是文化：我们拥抱变化，随需而变，跨职能合作，永远在学习的路上，不断修正自己的问题和目标，绝不延迟。

  • 敏捷是价值：我们的价值是客户的认可（含显性和隐性），一切不能被认可的工作，在迭代内我们是要尽量避免的，有效的价值流动，是我们的使命。

  • 敏捷是改进：我们的改进没有终点，我们一定要比上一个迭代做的更好，这是我们的目标，即使比过去有了很大的改善，也决不满足于当前所处的效能。我们不断学习，想办法提升，在固定时间内为组织持续创造更多价值，即便这意味着我们可能以减少交付数量为代价。

  • 敏捷是变革：我们做的是一件革新的事情，会面对来自内部和外部的各种不理解，质疑甚至是阻力，如何帮助团队改进，帮助干系人理解并获得支持，树立信心，如星星之火而燎原是我们的课题。

培训唤醒人，人促进文化，最终从传统研发管理到敏捷开发管理的转变，这个过程也会伴随着组织敏捷领导力的导入。我的愿景是，这次培训以后，组织能够逐步产生更多的Scrum Master和Product Owner，充实未来的组织敏捷人才梯队。当然，一次短暂的培训离敏捷转型成功还有很多的路要走，但这至少是一个好的开端。让我们可以有更多的期待。其实敏捷转型成功到现在也没有一个明确的定义，即使组织敏捷已经做的很好了，我们也永远都在改进的路上。

—

END

感谢你阅读本文，希望能在评论区学习到大家的经验和想法~

如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。