国企敏捷大冒险！ | 第7期 - 《践行者》

在国企内引入敏捷是怎样的感受？我们应如何使用敏捷思维为传统项目管理赋能？本期《践行者》，让我们与资深项目管理专家王抒音老师一起聊聊她的国企敏捷之旅！

一、国企敏捷大冒险

针对敏捷转型这一话题，王抒音老师认为不论是Scrum、XP还是LeSS，本质都是在解决项目中的某一问题时衍生出来的最佳实践。因此当自己进入国企的项目中时，首先要解决文档产出速度慢以及文档产出质量低的问题。在解决这个问题时，王老师开始在文档交付中引入迭代的实践，通过规划文档交付计划、固定的迭代周期以及设定文档的“DoD”、文档规范，来保证文档输出质量。

也正是在敏捷化文档输出流程的同时，王老师开始在国企内部、管理层中引入敏捷项目管理的概念，并进行了相关培训。事实上，当大部分的企业开始转型敏捷的时候，未必需要在最初就将所有框架、实践套进来，而是可以从一个小的问题点入手，通过实际效果突显敏捷的真正价值。

接下来到了第二阶段：在国企内引入敏捷。在这个过程中也相继出现了很多问题：

敏捷项目所强调的快速迭代、快速交付和传统式项目所制定的里程碑相冲突怎样解决？
在转向快速迭代的过程中，原有项目团队的协作问题如何解决？
如何获得领导层的支持？
如何获得团队成员的支持？
如何在团队中引入敏捷文化？
……

以上是敏捷转型过程中经常遇到的问题，在此次直播中，王抒音老师将上述问题的答案融进了自身的敏捷实践故事中，绝对满满干货！想了解国企内部实践敏捷的更多分享，欢迎大家扫描上方二维码观看直播回放~

二、问答实录

此次话题毫不意外地引发了大家激烈的讨论，在这一过程中，王抒音老师也对大家的问题进行了回答，和我们一起回顾一下吧：

Q1：国企有部门墙吗？需怎么解决？

A: 任何企业或公司都会有部门墙，需要去持续打破、持续解决。

作为员工来讲，要保障企业盈利，因为企业如果不盈利，我们自然而然就拿不到薪水，除非你换一家企业。当我们跟自己的领导或兄弟部门有一些摩擦时，尽可能要站在他们的角度上考虑，他们这个角色有这样的决策，最终的诉求到底能不能达到我们最终的目的，也就是实现企业利益呢？大家还是要本着帮助企业去解决问题，帮助企业去创收，更低成本地去交付项目，这个才是打破部门墙的一个很重要的原则。就像大河没有水，小河自然也就干了。

Q2：为什么要强依赖文档，是因为人员能力不足？

A: 首先对于大型项目来讲，文档的留存是非常必要的，我们不能简单粗暴地认为人员能力不足，其实更多的是项目本身的需要。

国企或这种大型的传统企业，他们的系统很复杂，背后涉及的审批流程、涉及到的合同金额，都是不允许出错的。这类企业在做一个项目，投入的成本会比较高，周期也会比较长，这期间难免会有人员的更替。文档其实是减少人员更替成本的一个方面，同时这样做也可以有效规避项目中的一些风险。在这样的项目背景之下，还是更多地依赖文档的。

当然，更多时候，我们可以根据项目的实际情况去看是否需要强依赖文档，比如我们能够用简单的用户故事把需求讲清楚时，文档可能就会变得更轻量级。

Q3：在敏捷中如何拆分较大、关联性较强的需求？

A: 需求拆分需要因项目而异，有的项目可以分模块，有的项目可以分流程，有的项目可以分业务，需要具体问题具体分析。当我们开始一个比较大的项目，如果它的需求关联性比较强，并且同时使用敏捷，在这两个因素都要存在的情况下，这时，我们首先要看它的关联性。如何保障某一个流程的关联性，保证它完整的基础之上，再去拆分需求。

关于更多需求拆分方法，欢迎大家登录融·软件项目管理实践库RRPL查看。RRPL中有很多种需求拆分的方法，大家可以在RRPL里找到相应的实践学习、参考。

Q4：在敏捷转型初期，如何获得团队包括老板的真心支持？在开发任务中，有什么好方法能让团队看到敏捷的收益？

A: 在敏捷转型开始前，我们需要问自己和问老板一个问题：我们为什么要做敏捷转型？是老板想做敏捷转型，还是我们自己想做敏捷转型，要先把这个要区分开。如果老板想做敏捷转型，我们需要跟老板沟通，明确为什么要做这件事，挖掘背后的原因和动机，再去做敏捷转型。这样会更多地得到老板真心的支持，因为他知道敏捷转型在帮助企业解决问题。

在我们做敏捷转型的过程中，我们也要让老板更多地参与进来，共同去推动这件事，通过这样的方式在公司上下达成共识，大家一起去推动敏捷转型。

Q5：敏捷中的角色和会议是否需要严格执行，在研发中需要特别注意的点有哪些？

A: 敏捷中几大角色与会议要根据项目的实际情况执行，虽然 Scrum Guide说，如果你没有全部执行，那就不能说是在做Scrum，但不做Scrum又能怎样？把Scrum中所有的框架和实践全部拿过来严格执行，就能真的敏捷吗？效果真的会好吗？不一定。也不要去纠结到底是不是在严格做Scrum，因为这只是表面上的遵守，倒不如把Scrum中的元素尝试做到位，真正理解Scrum的精髓，效果会更好一点吧。

研发中特别需要注意的，比如DoD（完成的定义）是非常重要的，因为很多团队还没有养成做DoD的习惯，而且DoD其实不是只给研发做的，需要研发、测试、产品同学大家一块去达成共识，这点需要特别注意。另外，研发同学是不是真的理解需求，这点也非常重要。

Q6：研发经理觉得拆分任务费时间，不愿意在系统上拆分任务，也不愿意用Excel维护怎么办？

A: 第一：我们要多跟研发经理沟通。对于研发经理来讲，做好任务拆分能够给他的团队带来哪些价值。

第二：我们需要深入了解研发经理不愿意拆分任务的根本原因，再针对这些原因去制定具体的解决方案。比如我们通过让项目经理去帮助研发经理共同去做需求拆分，尝试先帮他做，再让他自己做。

Q7：兼职如何平衡开发角色和敏捷角色的工作时间呢？

A: 首先，我在团队里遇到一种情况是：研发Leader和产品Leader会充当Scrum Master的角色。

找Scrum Master的时候，也通常会找那些开发能力比较强的，比如开发leader这种身份，他们其实是有余力去做这些事情的。

Scrum Master的职能是分阶段进行的。项目初期，可能会把主要的时间放到Scrum Master角色里边去；项目中后期遇到一些疑难问题的时候，也会花一定时间去帮助一线开发同学解决问题；项目后期，Scrum Master的角色又会多一点，因为要组织团队去做复盘，找到团队当中有哪些可以再去做提升的部分。不同的项目阶段，Scrum Master所投入的时间是不一样的，这样去分配会更合适一些。

Q8：国企敏捷能动得了绩效考核吗？

A: 这个需要我们先去了解国企的考核体系和绩效考核内容；领导是否重视并支持敏捷愿意将敏捷纳入到考核体系中去。由于不同国企的绩效考核体系算法复杂且各不相同，所以我们需要具体问题具体分析。

Q9：脚本是什么样子？

A: 脚本可以理解为一个简单的用户手册。首先是要分角色的，比如我作为一名招聘人员或者作为一名运营人员，我应该怎么做？能够看到什么东西？其次，脚本根据每一个企业的特性可以自定义。它的目的就是让不同产线的人能通过简单的脚本把系统使用起来。

Q10：敏捷对技术工程实践，如单元测试、自动化测试、重构是不是有强依赖或者高要求？

A: 这要根据团队的实际情况来定，重要的点是在于我们对敏捷的定义。敏捷的定义大家都清楚，可敏捷落到团队中就需要大家能达成共识的。

比如Scrum3355的角色划分，会引申出另外一个话题——敏捷的成熟度。当我们确定团队角色时，我们就认为敏捷的第一阶段的工作完成了。《敏捷宣言》联合创始人Dave Thomas讲过，敏捷最麻烦的事情就是想当然把敏捷当作名词了，但它应该是形容词。所以敏捷并不是一定要单元测试、自动化测试到什么程度，也许增加一个迭代，就已经比较敏捷了。

Q11：关于敏捷需求颗粒度，业内有没有最佳实践？

A: 敏捷需求的颗粒度，我们通常会按照两周一个迭代走，但是两周一个迭代，我们是定义为上线还是做到可供上线？这是要企业内部自己定义的。关于最佳实践，我理解敏捷需求的颗粒度两周可以完成，并且能够上线，交付到用户手中，我觉得这就算一个敏捷的最佳实践。

Q12：能否分享一个DoD的具体样例呀？

A: 举一个简单的例子：拿今天的直播来说，今天的直播成功与否要怎样定义呢？

可以有以下标准：

嘉宾准时到场；
直播间的网络顺畅；
小伙伴的每一道问题都能够回答且能得到大家的认可；
这次分享是否能给小伙伴解决问题和疑惑。

以上就是这次直播成功与否的DoD。同时，这些DoD并非始终不变，而是需要随着时间的推移不断地进行补充的。当然，DoD也是我们回顾会的一部分，可以在回顾会上来看DoD有没有需要修改的地方。

同时，当我们做产品的DoD时，这个产品是需要潜在可交付的。DoD说明了潜在可交付的产品增量需要满足什么样的要求，也是对最终产品的质量要求。

Q13：b端业务怎样做敏捷比较好？

A: 这要看敏捷实践帮助b端业务解决了哪些问题，只要是帮助b端业务解决实际问题的，就算敏捷落地。

敏捷它是一个形容词，并不是一个名词，我们应该更多地关注敏捷方法能不能帮我们有效地解决问题，一切从解决问题的角度去考虑比较好。

Q14：产品经理也是项目经理，怎么平衡两种角色？

A: 在很多公司中，并不会严格区分产品经理和项目经理，往往都是一个角色。根据以往的经验来看，通常是用项目管理的方式做产品经理，会让事情的推进能够事半功倍。

Q15：怎样确保研发成员对敏捷的拥护使用呢？

先想清楚，为什么要推进敏捷，然后思考敏捷了之后给研发团队带来的价值，或者给研发个人带来的价值。改变大家的工作习惯很难，需要潜移默化，找到敏捷给研发成员带来的好处，逐个队员突破，找到能帮你站台的那个研发成员，一点点在团队推进。

国企敏捷大冒险！ | 第7期