《轻松scrum之旅》读书笔记

《轻松Scrum之旅——敏捷开发故事》

出版社: 电子工业出版社
出版年: 2009-12

scrum和精益的关系，为什么阅读本书

2018年左右，我工作的外企推行精益管理，所以找了几本和精益相关的图书，这是其中一本，虽然现在看来，scrum和制造业的精益差异别较大。

scrum是软件开发行业中的一种敏捷方法论，虽然我是化学行业的研发人员，希望能从中找到一些共同的方法论和操作，应用于自己现在和未来的工作之中。

2018年第一次阅读本书，更多是理解什么是敏捷开发，囫囵吞枣读完本书；2022年重新阅读本书，一是顺便复习PMP的敏捷知识，二是进一步理解scrum的具体工具和流程，思考如何应用到工作之中。

两种产品开发方法：瀑布开发流程和敏捷开发流程

下图来自网络，也常见于PMP培训资料，非常直观地表达了两种开发流程的区别。

图：瀑布开发流程和敏捷开发流程

传统的瀑布开发流程（预测型项目管理），强调客户需求是精确的和100%完备的，一开始就很清楚最终客户想要什么样的产品，所以项目管理最重要的部分是规划阶段，制定详细的项目管理计划，拆解任务到可执行层面、执行、复盘，PDCA，最终就会得到最终的产品。

而敏捷开发，需要不断的跟进需求，持续迭代，客户在项目过程中不断明确自己的需求，通过共同努力和持续沟通，最终获得符合客户需求的产品。

产品开发，最怕的就是客户需求不完善、不明确或后期发生了变更，等要交付最终产品时再作出改变，为时已晚。有时是客户无法一开始清晰的描述自己的目标，有时候是环境变化太快，客户需求也要随着改变。敏捷开发的价值是，针对客户需求不清楚，可以和客户一起快速改变，给客户有价值的产品。

现在是一个VUCA时代（Volatile 不稳定、Uncertain 不确定、Complex 复杂、和Ambiguous 模糊），这也是敏捷开发或敏捷项目管理更适合项目管理和产品开发的时代，下面摘抄书中的关键内容。

敏捷(Agile)是一种关注价值、消除浪费、以人为核心、迭代、循序渐进的开发方法。

什么是敏捷开发?它是一种开发方法学(Methodology) ,可以应对客户快速变更的需求。它强调以人为核心,采用迭代的方式,循序渐进地开发软件。在敏捷开发过程中,软件项目被划分成多个相互联系但也能独立运行的子项目。这就使得每个子项目在开发、测试直至完成的过程中一直保持可使用的状态。这个过程实际上就是要形成开发过程中团队之成员之间更加有效的合作关系,使其灵活性更高,以适应不断变化的需求。敏捷开发过程与传统开发过程的最大的不同之处在于,在敏捷开发过程中,团队是有激情、有活力的,能够适应更大的变化,生产出更高质量的软件。 ”

敏捷开发的价值观：我们开发软件时的首要任务是通过尽早地、 持续地交付有价值的软件来使客户满意。

敏捷宣言：

  • 个体和交互重于过程和工具
  • 可以工作的软件重于面面俱到的文档
  • 客户协作重于合同谈判
  • 随时响应变化重于循规蹈矩

敏捷开发方法的核心思想概括起来就是“ 适应变化” 和“ 以人为本。

敏捷开发的理念是信任开发团队,信任每一个人。试想一下, 如果你们这个团队对你们的项目充满激情,而老板又充分信任你们,那么你们必然会将更多的时间花在如何有效地提高生产率、如何创新地完成某个功能等方面,而不是按老板的意思按部就班地工作了,这样还会节省很多时间并简化流程,例如开会、向老板报告、请示老板、等老板批准等。就像咱们刚才的那个游戏结果所揭示的那样,充分调动参与项目的人员的主动性,让他们自我组织、自我管理,由团队自身来掌握项目进度,比老板整天催促反而更有效率。

“当然,敏捷开发的团队也需要管理,但这些管理是非命令式的,很多时候是战略指导和服务性质的。在敏捷开发中,管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等。 ”

敏捷开发所追求的是一种平衡。

显然,敏捷更真实地符合现实并顺应了管理的趋势,那种从上到下高压式的控制管理方法已经过时了,不单是在软件开发领域,在很多领域都已经被抛弃了,那其实是工业时代的产物。

总而言之,我认为敏捷开发的本质,第一是一切活动以价值为导向,第二是以人为本。以价值为导向可以帮助我们大大提高软件开发的效益,以人为本的精神可以帮助我们大大提高软件开发的效率。

敏捷对人的要求是什么，作者强调的软素质是“A very good team player, excellent communication skills, open minded, pro-active, and self-motivated.” 这也是我们每个职场人士不断磨练的软技能。只有具有积极向上的工作态度的员工，才能成为自我管理的员工。 这让我想起了《从优秀到卓越》中的“先人后事”的观点，只要找到优秀的员工，然后放在合适的岗位上，设定好公司的大目标框架，然后就充分发挥员工的主观能动性。

一、人生重要的选择大于努力

作者在前两章谈到自己的的职业经历，一开始为何选择加入民营公司X公司，两年工作的遭遇；为何萌生了跳槽的冲动；面试外企的经历，对外企的认识变化；以及最终更换工作之后的感慨。

男主角一开始为何选择加入民企，因为民企“没有天花板，公司很快就会上市”，这最能打动冲劲十足和愿意当鸡头的优秀应届毕业生；但事实如何呢，男主角在旧东家那儿每天累死累活，因为工具落后、流程不规范，管理层级森严，明明有巨大的浪费又无力改变，只能耗费大量的公司和个人资源在原本可以避免的返工上；天天加班，工作做了很多，“产品没有真正开发完成，到现在也没有一个客户埋单”，再努力的人，这时候也会面对巨大的成就感的落差，思考当年的选择是否正确，对方画的大饼是否能够实现。

等到了新公司，发现跨国公司E公司鼓励创新，内部大力推广敏捷开发，保证研发人员的价值创造是有意义的。正式入职之后一边学习敏捷开发，一边参与总部的产品开发工作，这种成就感，自然让男主角发出感慨，“对于成功，选择大于努力”。

总结和思考：世上充满无数的选择和努力,但对于成功,选择大于努力。敏捷开发是一种选择。

敏捷开发思维和工具是一种高效率选择，可以避免很多无谓的努力。

当然，如果工作岗位中的自由度很大，除了通过跳槽选择更先进的工作方式，我们也可以在自己可控的范围内选择更高级的工具，也是一种积极主动和把控自己的体现，简单的就像效率软件，复杂的就像本书的敏捷开发方法。

另外，不论工作还是生活，我们都有两个自我改进角度：“努力+方法”，两者都很重要，又能有协同作用，过度侧重一方面，都是低效率，所以这儿有一个balance的问题。 不同的图书有不同的侧重，比如稻盛和夫的《活法》更强调努力&态度的价值。

2022年4月23日重读本书前四章，对“选择大于努力”有了新的理解，因为重读本书的时间点，正好是换工作的时间点。民企和外企之间如何选择，平台的意义有多大，民企的发达机会是否只是个大饼，本书的故事给我们一个小小的启发。

二、渐进明细——明确大方向，避免过早陷入细节

  1. 渐进明细：对于复杂的项目，我们和客户都无法一开始就明确目标的全部细节，甚至实现路线都需要“摸着石头过河”，所以一开始就做到100%任务拆解，既不现实又没必要，而要渐进明细，达到一个最佳的平衡状态！
  2. “照明弹”策略：当你不知道该从哪下手时，先确保方向是否正确，这就是书中的“照明弹”的价值所在，先粗略找到对的方向，先战略，再战术；先粗略，再详细。
  3. 频繁沟通：开始做之前，如果有不明确的地方，一定要沟通清楚，下属和领导沟通清楚，团队和客户沟通清楚，千万不能想当然，“客户应该想要的是这个，客户应该想要的是那个”。这是新手特别容易犯的错误，我也如此。
  4. 《Principles》：这本书中强调概念（Concepts）和细节（Detail）的关系，也是渐进明细的另一个表达方法。作者强调不同level的思考，不要层次混乱，以概念思考为主线，同时研究必要的细节，但是又不要陷入细节而忘记主线。 这也是整体和局部的关系，见森林也要见树木。

三、Scrum与精益方法

第三章“准备scrum之旅”，作者介绍了常见的敏捷开发方法，包括极限编程、RUP（rational unify process）和Lean（精益软件开发方法），当然还有本书展开介绍的scrum。

不论是哪种精益工具，最终的核心目标都是“提高客户价值”，只不过实现过程的侧重点各有不同。 丰田推行的精益的核心是消除浪费，将时间花在增加客户价值的事情上； 六西格玛的核心是减少波动，提高质量，从而提高客户价值。

《两秒精益》给出了制造业中“精益管理”的几个具体方法，比如可视化对比改进前后的情况，以清晰直观的呈现出精益的效果，提高员工的认同感。

精益编程，同样是通过消除浪费的方式，提高软件开放的效率。比如尽早交付、加强反馈和沟通，增强对需求变化的灵活性，让客户需求推动工作，而不是先听取客户需求，然后闭门开发两个月甚至两年；授权给团队，让开发人员参与决策，让团队成员发挥自己的潜力。

我们是scrum是一种具有很强操作性和具体流程的精益方法论，因为scrum工具和流程同样是减少了浪费，提高了交付给客户的价值。比如自组织的团队具有更强的动力，去掉不必要的层级汇报同样可以节约大量时间，频繁的沟通以保持对客户需求的更新和准确认识。

四、Scrum具体方法论

上面介绍了敏捷的价值观，这儿简单介绍书中的软件开发方法论。

Scrum强调目标分解，长期和短期任务，每日站立会议，总结复盘，持续迭代，和客户的紧密沟通。

scrum实施过程中的3个会议

  1. scrum计划会议：所有成员一起讨论下个sprint（迭代、冲刺）的需求，并排好优先级。如果有需求不清晰或过于庞大，相关开发人员要对需求进行拆解。每个需求的时间以小时为单位，且最好不要超过8小时（一天）。（项目优先级排序，项目分解成任务）
  2. 每日scrum站会：各个成员相互同步项目进度，让每个成员对项目进度都有清晰认识。下班之前沟通，主要内容是“我完成了哪些工作？我将完成哪些工作？有没有什么事情阻碍了我的工作?”，如果有问题，站会后相关人员要商讨解决方案。scrum站会不要超过10分钟。 （每天及时沟通项目进展，每天的生活总结也是如此。）
  3. scrum总结回顾会议：总结上一个sprint遇到的问题，商量解决这些问题的方法，避免这些发生过的问题再次发生。scrum总结会的宗旨是：scurm团队如何在下一个sprint做得更好。

scurm中有3种角色,他们是产品负责人（product owner，PO）, 敏捷教练（scrum master，SM） 和scrum团队，他们各自的职责如下：

  1. Product Owner（产品负责人，PO）：客户需求的代言人，确定产品的功能和完成时间，并对产品的受益负责，要根据市场需求确定产品功能的优先级。在每个sprint开始之前，product owner可以修改功能和优先级。而且，product owner有权接受或否决各个sprint的工作成果。
  2. scrum master（敏捷教练&流程教练）：为scrum团队服务，监督整个scrum项目进程，调整项目计划，确保开发团队成员的能力能够胜任产品的开发。促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍，保证开发团队不受外力的干扰和阻扰，掌握产品开发进度。在实际工作中，一般以开发组的leader来担当。
  3. scurm团队：一般由5~10个全职工作的成员组成。团队成员横跨各个职能，通常包含前后端开发，测试，运维等等

scurm管理软件：scrum works，IBM RationalTeam Concert，XPlanner等等，Excel也是一种。（对我来说，更重要的是方法论，自己根据工作类型变通）

backlog—用户故事–任务

Story、Backlog、Task(任务) ,它们之间的关系是怎样的呢?在 Scrum 中,产品要完成的功能清单叫做产品 Backlog。每一个 Backlog 项通常也叫 Story,因为它是由 User Story 来描述的,一个 Story 是由一个完整的 User Story 来描述的。有时候,一个比较复杂的 Story 也可以分解若干个成更小的 Story。
Task 是任务, 在具体实现每个 Story 的时候都要将其分解成具体的任务, 比如编码、测试、调研、Code Review 等,这些都是 Task,而不能称为 Story。

计划扑克（Planning Poker）：用扑克牌游戏估算完成时间，分配任务

通用领域的产品开发和项目管理，如何使用scrum

软件开发之外，如何使用scrum。

scrum的核心价值观：为客户创造价值，以人为本。

项目管理，任务管理：客户需求分析，用户故事，目标拆解，优先级排序，等

Scrum强调目标的短期和长期分解，每日站立会议，总结复盘，持续迭代，和客户的紧密沟通。

项目管理：项目分解成任务，任务分配，讨论。

用户故事：从客户角度阐述需求

参考文献：

revision

  • 2018.3 阅读图书后写本读书笔记草稿
  • 2019.5 欧洲旅游，梳理发表，后续重读上面的参考资料和本书highlight，再更新本博文。 重要的是亲身实践！
  • 2019.6.2 重复，更新
  • 2022-4-23 最近学习PMP，想到几年前读过的这本书（当时更多是一种视野开阔，知道敏捷的概念），所以重读本书，顺便大幅度更新本读书笔记。 等学完PMP敏捷开发，再继续更新本文。
  • 2022-5-15/16 简单更新