华山论剑线下会

本次线下会主题

很多企业在敏捷转型的开始或者转型过程中遇到了很多困境和难点，本次线下活动就先解决三家公司面临的实际问题。由五位敏捷大咖针对企业问题进行现场问诊。

到场企业敏捷大咖（图片从左到右）：

华为云资深产品经理 刘恒

曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师  王立杰

IBM敏捷教练  管婷婷

资深过程改善顾问、资深项目管理顾问、华为云DevCloud敏捷专家  黄俊

管理3.0认证引导师 侯伯薇

全部参会人员：

合一网络企业现状和面临问题

2014年成立的初创公司，企业规模11-50人，从事领域：软件开发

敏捷转型的痛点：

内部：

1.      团队一开始使用传统开发模式，总会遇到交付产品和需求不一致的情况；

2.      采用scrum流程后开会时间变多，开发变慢，不被团队人员接受

3.      由于敏捷开发前期没有编写系统概要设计/详细设计一类的技术文档，交付时客户要求提供，只能临时补充。

外部：

4.    开发过程中客户不能看到完整产品，项目上线后客户提了很多意见，浪费人力物力，后期交付出现问题；

5.      受到客户需求制约，不能合理进行迭代计划的分配，也不能按自己的规划来上线升级；

6.      和客户的需求沟通通过微信和电话，需求的确认通过邮件和传真，导致需求滞后，不适合敏捷开发的要求。

现场会诊：

问题：在内部如何和开发人员沟通？使用敏捷开发方式时在外部如何和客户沟通？

王立杰：针对你外部痛点里的“开发过程中客户不能看到完整产品”，你可能走的还是大瀑布不是敏捷，敏捷我们希望的是小步快跑迅速迭代，每次迭代的东西客户应该可以看到。你相当于是在大瀑布里玩小迭代，整个还是瀑布流程。这是我看到的比较大的问题，你应该尽早的让客户看到迭代结果。

管婷婷：我说一下开会时间变多这个问题，为什么很多团队会觉得使用敏捷之后会议很多，其实我们是想用敏捷的这些会议结合看板取代传统的大部分会议。

侯伯薇：你提了很多痛点，其实如果说持续沟通的话交付问题就可以解决，如果沟通效率高的话开会时间就不会很长。我经常会遇到很多企业带着敏捷的帽子做着传统的事，敏捷更关注的是人，以人为本才能真正做敏捷，而不仅是遵循某种制式。

黄俊：我提两点，第一是沟通，平时的看板可能的话可以透明化，当客户能看到你们的分工和进展的时候就会对你们更放心。第二，变我们经常去客户公司为邀请客户到公司参观。

刘恒：团队人员觉得开会时间长可能是大家没有在会议中获得收益，所以在开会时要注意让大家能获得收益。另外开会时间一定要短，比如早会控制在15-30分钟，每个人只讲关键的——昨天做了什么、需要求助什么，具体求助在线下解决。再比如在planning会议前开一个预planning会议，这个会议参加的人很少，我们的话只有产品经理和VC，在这个会议中把下一步的迭代大概定下来。这样正式的全员planning会议就会进展比较快；我们华为云的话还把planning会议和验收的会议合在一起，大概用时1小时。另外你提到客户不认可你的敏捷，其实不是客户不认可而是它看不到敏捷的价值所在。你给客户交付的迭代应该是他最想看到的东西，这样他就会对你越来越有信心。

星汉网络企业现状和面临问题

小规模公司，从事领域：互联网应用

敏捷转型的遇到的问题：

1.      需求变更频繁给企业带来的困惑：给客户看的次数越多，客户需求变更越多

2.      人力不足如何用好敏捷：公司规模小，一个人可能负责不止一个项目，项目周期也普遍很短。开发人员会先写代码后补文档，文档是带有应付感觉的而不能起到敏捷开发中真正的作用。

现场会诊：

王立杰：与客户做好约定，需求确定了再开始，如果迭代出来出入实在太大，可以考虑终止项目而不要硬做下去。我个人觉得两三个人就不要搞敏捷了，如果本身就可以合作的很好就不用为了敏捷而敏捷，这些流程也是有开销的。

刘恒：确实市场存在很多这种团队很小周期很短并且是合同制的方式。我们内部也在想，我们想到的一些办法是，第一要看客户，如果客户比较强硬而企业又必须接这个单来生存，那这时合同一定要完完整整理清所有需求再来开发，并在合同中说好，如果变更过多需要延期或加钱。如果客户可以沟通且经常变化，可以采用原型图的方式将需求具象化下来，要做好预判，如果觉得这个客户就是容易变化的主，我们要加强沟通而不是防守型以减少后期变更。对于几个人开发，如果开发人员觉得文档价值不高而客户又需要，是允许后期补的。

管婷婷：越是变更大的其实越适合敏捷，关键是你如何巧妙设计好MVP。我们要用最小成本的MVP拿到客户最有价值的反馈，如果我们遵循这个原则，那我们就会在早期的迭代确定用户想要的需求。如何设计好MVP其实是一门需要经验的艺术，在你学会它之前应该尽量选择能够配合你的客户。

黄俊：对第一个问题还是多花时间做好沟通，如果真的和客户需求出入很大就及时止损停掉这个迭代，因为就算你做下去也不是客户想要的。

侯伯薇：考虑目标，看具体情况，选择最合适的方式。

溪蔓国际企业现状和面临问题

企业规模51-100人，从事领域：国际贸易

敏捷转型的遇到的问题：

1.      敏捷开发的要点是什么？对需求分析阶段是否有改变？

2.      使用敏捷开发形式开发过2个项目，基本都会导致需求蔓延，如何避免？

3.      敏捷开发的优势是什么，节约开发成本？减少沟通成本？提高软件质量？

现场会诊：

侯伯薇：需求分析其实不是源头，再往前推还有业务知识。我们的思维要有一个高度，每个人思考的角度不一样，目标也不一样，我们和客户应该是朋友是一条船上的而不应该是对立谈判关系。研发人员不要只做研发，这样会做很多无用功，也不利于以后的发展。

黄俊：敏捷开发真的会节约成本吗，这是分情况的，当需求不怎么变动时传统的方法是可以做好的，当需求变动很大时更适合敏捷。而且我的一个小经验是全栈工程师可以减少沟通成本。另外需求分析时，在沟通时要抓住关键人，将业务人员说的向他的上级汇报确认。

管婷婷：敏捷的需求是有限的，只对近期的需求做细化，而对几个月后的需求保持大的颗粒度。针对不同的客户采取不同的敏捷的方式。敏捷里采取先沟通后文档，这是可以减少文档修改这些成本的，但是敏捷的精华在细节里，文档如何写也有很多讲究。

王立杰：传统方法的思想是需求是完全确定的，敏捷开发的思想就是允许需求的变化。外包的话也可以参考FTD流程，FTD划分需求也讲究莫斯科准则，有些是必须做的，有些是应该做的，有些是可以做的，还有些是不应该做的，提前约定好一些东西呢，需求蔓延就会小很多。

刘恒：敏捷开发的优势是为了降低变更带来的巨大风险的成本，所以我们认为敏捷降低的不是开发成本而是风险成本。第二，它会增加你的收入，降低风险能提高你交付的概率和时间，这样你就可以接别的项目，所以敏捷更多的是帮你开源而非节流。关于需求分析呢是这样的，需求分析和敏捷开发或者别的方法论没有直接关系，需求分析永远是软件开发中最重要的一环。需求分析不是技术活，而是需要走出去，走到业务或者市场，了解到利益相关人是谁，这就是如何改善需求分析。关于需求蔓延，你提到这个说明你正在敏捷转型的正途中，是因为敏捷让整个团队认为需求是可以变的，这是一个很痛苦的过程是一个过程的适应。但是无论是什么方法论，需求的变更永远是应该受到管控的，拥抱变化不代表需求可以随意的变化。只不过你是要用敏捷的方式去适应需求变更。很多时候你需要对这个变更签一定的约束，让团队形成“需求变更是一件很严肃的事情”这一认识，如果产品经理经常变更需求，那他的需求变更优先级就会降级，得不到研发团队的信任。也应该让客户认识到，虽然采用敏捷开发是拥抱变化的，但他们依然需要谨慎的考虑好他们的需求。

敏捷转型是一个过程，没有终点，希望各位企业都能在大咖的指引下、敏捷灯塔的照耀下，一步步探索，早日走向真正的敏捷。

视频链接：https://pan.baidu.com/s/1_h21s_SLSXG7faJ16k2oSQ

视频提取码：fxdk

以上文字内容由【内容众创兴趣小组-孔皮皮】整理。