敏捷开发：让你的IT团队告别996
近年来，互联网公司盛行的“敏捷迭代、小步快跑”文化正在逐步席卷软件开发行业。
那么，互联网公司的人，都懂敏捷吗？互联网公司所谓的“快速上线”都是敏捷理论成功实施的结果吗？
我看未必。
通过延长工作时间“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要多参加团队站会，在站会结束时给团队加加油鼓鼓劲。
感谢研发负责人蔡哲提供部分理论知识素材
感谢UI独立设计师胡锦成的PPT图样设计