敏捷团队绩效评估原则
663
2022-05-29
本次线下会主题
很多企业在敏捷转型的开始或者转型过程中遇到了很多困境和难点,本次线下活动就先解决三家公司面临的实际问题。由五位敏捷大咖针对企业问题进行现场问诊。
到场企业敏捷大咖(图片从左到右):
华为云资深产品经理 刘恒
曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰
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
以上文字内容由【内容众创兴趣小组-孔皮皮】整理。
云市场 软件开发云
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。