研发模式和流程的再思考

  • A+

距离写作《软件开发模式:瀑布与敏捷》已经1年了,在新公司又带了1年新团队,中间陆续有看了一些软件工程的文章,是时候写点总结性的东西了。

我们知道要构建高质量软件,就要解决软件过程中的混乱,将软件开发过程中的沟通、计划、建模、构建和部署等活动有效地组织起来。

而软件过程,就是在软件项目的生命周期内,也就是软件从诞生到结束这期间,在开发与构建系统时要遵循的步骤。

本文内容纯属漫谈,希望对你有所启发。

实用的每日站会和看板

  觉得最实用的还是每日站会任务看板

  每日站会控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报三个问题:

  • 你昨天完成了什么任务
  • 今天要完成什么目标
  • 有什么问题不能解决

  每日站会的重要性在于,软件开发细枝末节很多,如果不进行每天盘点,很容易失控。

  下面是开发团队里经常发生的问题:

  • 代码缺少严苛的审核环节,导致规范失效,给后续的运维带来巨大的成本。
  • 某个开发人员所谓的完成在交付测试的时候问题一大堆。
  • 前后端开发人员没有按约定开发,沟通也不及时,出现互相等待的无效浪费。
  • 产品经理和开发人员互相扯皮,推脱责任,最后不知道听谁的。
  • 第一责任人缺失,等验收的时候才发现大家都不知道有这档事,最后延误工期等等。

必须要有严苛的代码审查机制

  为什么是严苛而不是严格呢?代码的质量反应了我们的产品质量,产品不稳定、老是出现BUG,直接影响客户满意度和口碑。

  同时,代码的好坏决定了未来运维的成本,如果因为一时疏忽和妥协,回头又没有及时修改,中间又出现人员变动,那么这份代码的后患是无穷的。

  因为不规范,可读性差,对交接人来说从心态上是本能反抗的,但是又不得不改,于是就一通乱改,能贴膏药就贴膏药,能运行就可以,管他规范不规范。这样导致的后果是,代码从不规范走向更加不规范,很难想象经过5-10年持之以恒的不规范,这个产品还能活着。

  技术债务的危害怎么形容都不为过,轻则系统局部异常,中等的会导致修改困难,严重的需要推翻重来。

  做产品,不严苛不足以长久。

开发人员要有产品经理的思维

  开发人员习惯性陷入实现的细枝末节和局部思维,建议开发人员在开发之前,先不要去想如何实现。应该先问自己:

  • 这个功能对用户有什么价值?
  • 能为公司创造价值吗?

  如果以上问题都是否定的,开发人员可以和产品经理理直气壮的辩论甚至说NO。然而,现实当中,很多新手程序员接收到指令后,不管三七二十一,埋头就敲代码,这是很普遍的,因为有个很好的说辞是:又不是我去调研的,我怎么知道客户想要什么,再说了需求不对那是产品经理的锅,反正和我没关系。

  这种意识非常危险,因为产品经理也会有遗漏,一旦缺少质疑,等到开发完成,交付使用的时候被客户否定了,那么,失的不仅仅是时间和金钱的成本,还有团队的战斗力和凝聚力,信任感,开发人员应该要有主人翁意识。

线上事故回溯讨论会

  为了解决配合不积极和甩锅的问题,可以考虑引入了线上事故回溯讨论会,每两周一次,对发生的事故进行讨论,重在根因分析和以后如何避免,并事前强调目的不是追责。

  因为,每个故障分析都能暴露出藏在深处的问题,对提高产品质量和团队间的信任效果都很好。

强调开发人员的主人翁意识

  在团队中,不同的角色对主人翁的理解从上往下,是逐级弱化的。

  我觉得主人翁意识是一个被低估的褒义词,这个词浑身上下充满了正能量,需要在团队里不断的宣讲,甚至写成口号挂在墙上。

  • 有主人翁意识的人通常做事一丝不苟,不轻易妥协,有工匠精神。
  • 有主人翁意识的人,自我驱动能力都相对比较好,有事主动承担,不叫苦,也不喊累,因为对自己负责,所以能力一般也不会太差。
  • 有主人翁意识的人,做事相对努力上进,人品也容易获得肯定。
  • 有主人翁意识的人,团队的漏洞和危机更容易避免,团队成员配合默契,无需繁重的章程和规定,效率杠杆。
  • 有主人翁意识的人,通常会更愿意帮助别人,见到别人文档写不完,一声不吭就给你无私的支援。
  • 有主人翁意识的人,公司的事就是自家的事,甚至要比自己的事更加负责任,因为自己出错大不了一个人承担,公司的事影响的是一群客户。
  • 有主人翁意识的人,更容易受到同事的尊重。因为和这种同事搭档,实在太轻松了。
  • 有主人翁意识的人,集体意识好,愿意承担责任,凡事主动汇报,不用每次过问:“你任务完成得怎样了云云”。
  • 有主人翁意识的人,因为对自己负责,所以更多意愿自省,更多意愿自驱,执行力不差,更容易拿到结果。

  当负责人是有这种意识,整个团队自热而然会慢慢养成这种意识。

不要把重心放在研发流程本身

  市面上讲开发模式和流程的文章很多,不管研发流程多先进,是否出自大厂,我觉得都应该问自己团队几个问题:

  • 这个开发模式适合当前的团队规模吗?
  • 为什么我们要采用这个开发模式?
  • 我们当前流程出了哪些问题?
  • 哪些流程影响开发和交付效率?
  • 当前的流程最致命的问题是什么?
  • 我们真的有必要修改当前的流程吗?

  只有找到当前团队的症状和问题,才能有的放矢,对症下药,否则很容易陷入教条主义,为了流程而流程。比如某某大厂都这么搞,我们也要这么做;某个专家这么说,我们也要这么做。如果只是简单照搬业界研发实践的话,效果往往不好,有时甚至会造成负面效果。

  流程规范过多,其实并不见得是好事,增加一条规范可能要考虑删除一条,否则规范会变成枷锁和负担。

不仅仅是每日站会

  站会虽然重要,但由于时间有限,并不能深刻的挖掘出那些深沉次的问题。所以不仅仅是每日站会的盘点,每个月应该都要有一份系统性的反思,从软件工程的系统层面来反思,比如需求调研,产品设计,软件设计,开发测试,实施运维等环节来深入剖析和总结。可参考愚文《关于盘点和总结的那点事儿

不能仅仅是模式和流程

  行文最后,我想泼一盆冷水:有了完美的开发模式和流程,你可能依然无法真正做好软件开发。

  因为我们知道软件工程从大的方面包括过程、方法、工具。瀑布和敏捷只不过是过程里的两个重要的模式,如果没有方法和工具,整个软件工程建设还是有问题的。

  • 比如需求分析人员经验欠缺,或者调研有偏差,那么就会把团队往坑里带;
  • 如果系统架构和设计有缺陷,那么后期可能无法能力复用,扩展困难,性能和稳定性会打折扣;
  • 如果测试不专业,那么产品质量就无法保证;
  • 不善于使用工具,沟通和效率可能会打折扣;
  • 如果不采用自动化,代码人工合并、编译和发布,那就回到传统低效的开发模式了。

未完待续

  如何破解研发效率之道,要聊的内容实在太多了,除了软件工程,可能还要研发效能、OKR、中国式管理等等,接下来会从系统的角度,结合平时踩过的坑,在学中记录,在记录中实践再总结的方式,写一个专栏,敬请期待……

90DIR-CMD