敏捷开发：让你的IT团队告别996

Posted 2021-05-19 CIO知识体系学习与实践随笔

记录分享CIO知识体系的学习与实践

拼多多懂不懂敏捷？

近年来，互联网公司盛行的“敏捷迭代、小步快跑”文化正在逐步席卷软件开发行业。

那么，互联网公司的人，都懂敏捷吗？互联网公司所谓的“快速上线”都是敏捷理论成功实施的结果吗？

我看未必。

通过延长工作时间“996疯狂交付"的公司不少，真正敏捷管理的公司不多。

今年1月份，微博有个拼多多员工上了热搜第一名。

因为曾经在淘宝网工作，我对老东家竞争对手拼多多的新闻总是格外关注些。

在视频的后半段，这位程序员提到一句话：

他说他要：同时面对着十几个同事（产品经理）提的需求。

他主管说：你可以合理地delay（延后）。

敏捷的内核到底是什么？

是快速交付？还是通过延长工作时间达到单位时间内产出？

在我看来，敏捷的内核应该是两点——

第一，时刻紧跟业务战略脚步，拥抱变化、调整产品功能优先级，达到最快速地做当下最要紧的事，即"做正确的事";

第二，通过找规律、流水线化作业、改善协作方式达到单位时间产能最大化，即"正确地做事" 。

开发方法要称之为敏捷，需要具备4个基本特征：增量的、协作的、直接的、适应性强的。

“增量”是指小版本、频繁发布。

“协作”是指客户和开发人员之间紧密沟通，经常工作在一起。

“直接”是指方法本身是容易学习和修改的。

“适应”是指能把刚刚发生的改变考虑进来。

4个基本名词解释

‍‍‍‍‍

• ‍‍Scrum：敏捷开发。是一个轻量级的软件开发方法和开发框架，是一个增量的、迭代的开发过程。

• Sprint：迭代。在这个框架中，整个开发周期包括若干个小的迭代周期，每个迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。

• Backlog：待办任务列表。在Scrum中，使用产品Backlog来管理产品或者是项目的需求。

• Story：任务详情。Backlog列表条目的体现形式通常为Story。也称用户故事，从系统各种用户的各自使用场景角度来描述的功能，类似软件需求规格说明。用户故事描述对用户，系统或软件购买者有价值的功能。

3个输出物

• Product Backlog：产品特性列表，类似需求列表，产品特性计划会议后的输出物。

• Sprint backlog：迭代任务列表，Sprint计划会议后的输出物。Sprint中挑选的需求经过Sprint计划会议上的分析，讨论和估算得到一个Sprint的任务列表，我们称为Sprint backlog。

• Burn-downChart：燃尽图，进度跟踪的图表工具。

3个角色

Product Owner：产品负责人，类似产品经理岗位。他的关注点是“做正确的事”

Scrum Master：Scrum活动管理者或教练，类似项目经理岗位。他的关注点是“正确地做事”

Scrum Team：实施团队，通常以研发、测试为主，也含运维、安全、UI

下面详细讲。

Product Owner：产品负责人，类似产品经理岗位。但是广义来讲，Product Owner可以是CEO，比如乔布斯、张小龙；可以是一个公司的产品总监，也可以是某一条产品线的产品经理；甚至可以将部分业务高管融入进来，形成一个2-3人产品决策委员会，共同决策共同担责。

Product Owner需要做的核心工作包含确定产品功能、根据市场价值定义产品功能的优先级、决定发布日期和内容、验收成果。在Product Owner中职责中，最重要的工作是决策“做什么”。资源永远是有限且宝贵的，市场机会是稍纵即逝的，因此必须有一个人站出来，决定现在做什么、不做什么，并且愿意为结果和成本负责。这个人就是Product Owner，产品的主人。我非常喜欢Product Owner这个原汁原味的写法，不舍得把它翻译成其他词汇。

Scrum Master：Scrum活动管理者或教练，类似项目经理岗位。Scrum Master一般翻译为敏捷教练，有的大厂会请一个专职人员担任；有的企业出于成本考虑，请技术负责人兼任；有的企业因为对项目交付周期有要求，请项目经理兼任。究竟哪种最为合理？

我们分析Scrum Master的核心职责后，发现，这个岗位应作为团队领导、资源的守护者、成本的负责人，和Product Owner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须确保团队资源充分利用、各成员良好协作、屏蔽外界干扰，以达到高产出的目的。

在没有预算聘请全职Scrum Master的企业里，我们可以找其他岗位兼任，例如项目经理、技术负责人等。但是必须要让这个人背上“资源利用率”的KPI。每个企业情况不同、每个IT团队员工擅长领域不同，可以因人设岗，将Scrum Master的职责分摊给1人或者多人兼任。我的做法：

1.由产品经理、项目经理承担“确保团队资源充分利用”、“屏蔽外界干扰”的工作。我给产品总监分配一个KPI叫做“研发版本之间无间歇”，要求Product Backlog 里永远都有“紧跟企业战略变化的、实时更新的、排好优先级、拆分到最小颗粒度的”需求队列。研发组只要做完前一个Sprint，即可直接开始投入技术预研、评审、开发。

2、由研发负责人承担“保证开发按进度进行”、“解决开发中的障碍”的工作，如遇到测试、安全、运维等跨部门协调的工作，需要他主动带头解决，不用实时依赖产品经理团队去推动，而是更加自发主动地提醒协作部门。这样可以有效的保护产品团队，让他们集中在Product Owner的核心职能里，去创新、去思考，而不必被琐碎的事务拖累。

Scrum Team：实施团队，通常以研发、测试为主，也含运维、安全、UI

敏捷导师需要打造一条标准化生产的流水线，将业务、运营、产品经理、交互、视觉、研发、测试、运维、安全，编制在虚拟流水线中合适且固定的位置；通过「规章制度」和「时间计划表」，让每个岗位在规定时间，以规定标准，做计划内的事。

此外，每个岗位角色都要背上一个“品控验货”的KPI，验收前序环节是否为“合格品”，并拥有“收货”或“拒绝收货”的权利。

• 如果产品经理的需求文档不详细，逻辑漏洞百出，那么研发有权不收货。
  

• 如果研发的代码质量不够标准，一测就是bug，那么测试有权不收货。

• 如果产品经理验收时候发现与设计不符，那么产品经理有权不收货。

这样做带来的红利，一是大家更谨慎地去审视上一环节的输出成果，避免其错误蔓延到自己的环节；二是强化了时间观念，当临近交货日期时，负责品控验货的岗位，就会密切关注他的上一环节，能不能准时交货，以防耽误自己“验货”。

在配合比较默契的团队，基本投入研发环节后，产品经理的精力，就可释放掉90%了。

‍‍‍‍‍

5个会议

• Product Backlog Refinement：产品Backlog梳理会议，产品特性计划会，类似产品范围规划活动。一般是Product Owner内部会议，可以拉决策层进来讨论。

• Sprint Planning Meeting：Sprint计划会议，类似项目需求澄清、任务分解活动。一般可以理解为技术评审。

• Sprint Review Meeting：Sprint评审会议，类似软件集成活动。

• Sprint Retrospective Meeting：Sprint回顾会议，类似项目回顾及反思总结活动。

• Daily Scrum Meeting：每日站会，每日简会，类似日工作汇报活动。

我记得腾讯的Daily Scrum要求非常严格，无论你在干什么，到了会议时间都会被项目经理强行拎到项目看板边开会。称作每日站会，最恰当不过。每个人1-2分钟发言，讲三个要点：昨日已完成工作、今日待办工作、需要什么帮助。Daily Scrum最适合安排在每天早上。早上最容易懈怠，一般看看新闻，喝喝茶，一两个小时就过去了。每日站会，有助于帮助成员快速进入工作状态。Team Leader要多参加团队站会，在站会结束时给团队加加油鼓鼓劲。

敏捷开发的好处

敏捷开发的好处。

一是灵活，船小好调头。以最小颗粒度迭代，时时刻刻拥抱变化，紧跟战略，只做正确的事；随时放弃“因业务战略方向变更而变得不重要”的功能。

二是省时，通过提升协作效率，提升了团队单位时间的生产力，实现了敏捷交付，快速上线。敏捷理论运用的较为成熟的团队不会996，不会有十几个产品经理扑过来提需求；更不会有任何工作时间的闲聊喝茶。每个人的精神在工作时间高度集中，在休息时间充分放松。

三是省人，敏捷组织大约只需要5-9人，就可以满足一条独立产品线或一个独立系统的日常迭代。

四是省心，敏捷模式解放了管理层的生产力，彻底让管理层从琐碎的事务中解放出来潜心研究战略；团队成员通过协作编排，实现高度自治。

结语：找准你的位置

结语：

在敏捷实践中， 最重要的是找准你的位置。

如果你是 Product Owner，就专注在新功能商业价值的思考，让团队做正确的事。

如果你是Scrum Master，就保护好你的团队成员，并时时刻刻找到让团队更高效的解决方案，让团队正确地做事。

IT敏捷实践，就是软件流水线的生产力革命！

鸣谢

感谢研发负责人蔡哲提供部分理论知识素材

感谢UI独立设计师胡锦成的PPT图样设计