Scrum精髓之咀嚼篇一

前两天刚刚完成了和几个部门大佬们的deep dive，结果负责的产品线受到了很大的关注。一方面大佬们发现了各个部门对我们产品依赖性极强，另一方面大饼画的足够好，大佬们发现了未来的发展空间。比较严重的是，我们组开发人数稀少，成了被需求侧同事炮轰的对象【手动捂脸】。作为刚入职的PM，只能停下了摸鱼的生活，被迫营业了

与此同时，我发现了几个较为严重的问题：

作为PM自身虽然独立负责过很多需求，但是对于整个项目管理知识相对匮乏，老板提到的backlog、sprint planning等概念之前并未有过任何了解，感觉自己像个白痴
组内产品需要对技术有较深的理解，需要深入到AI算法、训练框架、推理引擎等多个层面理解产品，需要有一定高度的规划
组内资源匮乏，但是承接项目过多，技术支持、需求响应等支线任务繁多，产品迭代周期较长。其他组同事需要我们的时候，我们只能第一时间给予一个温暖的拥抱

总结一下，找到合适的项目管理对策，合理利用资源并深入结合产品特性进行规划和迭代，对我至关重要。搜索老板提到的backlog、sprint planning后我找到了这本救命稻草----Scrum精髓

Scrum到底是个啥？

没办法，搜索这几个关键词，豆瓣知乎都刷了刷，Scrum精髓这本书基本是用过的都说好，你买不了吃亏，你买不了上当，你什么也买不了，你个小辣鸡…

闲话少说，这本包含了老板所提出的Backlog、Sprint Planning的神作，主要讲了什么？Scrum到底是什么呢？这里给出我的理解（不对别打我，反正我在这里不会给你复制定义的）：

是涵盖了整个团队在内的敏捷开发和项目管理的一种方式
建立产品列表（Product Backlog）竭尽所能完成优先级最高的任务
在一个较短的迭代周期制定冲刺计划（Sprint Planning）我要开始冲了！！
产出、回顾、做出调整

其核心在于团队如何小口快速地吃一个大西瓜，听懂掌声！！
吃瓜群众

为什么用Scrum

因为短小精悍！！啊呸…
最主要的原因是产品特性所决定的，正如书中所说，如果你的产品是复杂的，那你应该考虑Scrum，那么什么是复杂呢？书中的复杂意味着：

处理的问题不可预测，事后才可能涌现正确答案
需要根据经验调整策略
需要你聪明的小脑瓜提出一些比较Creative的方法
需要创建一个能够忍受你失败的环境
需要大量的互动和交流

Scrum角色

产品负责人：
产品负责人职责
Scrum教练：
你确信你们还有Scrum教练？？？别做梦了，说的还是你，我亲爱的产品经理朋友们！
Scrum教练职责

流程

在网上找了找流程图，或多或少总是不完全匹配书中内容，这里我有空自己画一个补充进来～

按照书中顺序记录了每一步核心要解决什么问题，并丧心病狂贴了一波我的笔记！

产品列表（Product Backlog）—主要是一个列表，你的景愿是什么、一条一条的分解特性、优先级是怎样的
冲刺规划（Sprint Planning）—开发工作有哪些、团队+利益相关人的评审、更像是承诺或对结果的预测
冲刺列表—详细的任务、分解到每一步该如何设计、构建、集成
冲刺执行—每日例会、进展同步、调整计划
潜在产品增量—产出物
冲刺评审—利益干系人+团队共同检视
冲刺回顾—回望Scrum过程并作出实用性调整

前方高能！！！！我的笔记如下（不由得感叹，老夫这字真TM丑啊）

下期预告

要回家了，下期我们一起来看看产品列表（Backlog怎么写），另外我相结合工作来谈谈我是怎么来设计我自己的Backlog的，后续可能会放出我司某些大佬常用模版（画大饼时间）嘿嘿～

我是爱你们的PM东城吴彦祖，我们下期再见～记得双击么么哒！！