上士闻道,勤而行之;中士闻道,若存若亡;下士闻道,大笑之。不笑不足以为道。 --《道德经》
软件工程从原始的作坊式工作方式,经过了哪些思考、哪些方案的试探,才在不断地尝试与改善后,走到现代化的工程过程?在升级的道路上,经历了哪些挑战,以及针对这些挑战做了哪些方案,这些对于真正践行敏捷工作方式具有重大的指导意义。本文将对比作坊式开发过程与敏捷开发过程的区别,以实例的方式来总结这两个过程管理中的提升点。
对于大多数公司来说都有一套完整的研发流程,以支撑公司的研发体系。这样做最大的优势是可以保证各个团队的行为规范的一致性,继而保障质量、速度、规范性的一致性。而作坊式的过程管理一个很大的特点就是各个团队之间没有统一的研发流程,导致更多细节性问题暴露。
阐述过程分先后,但作坊式的过程管理的问题并不是先后出现的。而是并发发生的,所以这里的陈述顺序不影响问题的优先级和问题发生事件。下面讨论一下作坊式的过程管理中会遇到的问题。下文中以抽象总结出的结论作为章节标题,再以实例来说明标题。
边界模糊说明两件事:业务边界模糊,时间边界模糊。这两个模糊边界会导致投入的人力未知、质量问题收敛速度未知。所以,项目管理铁三角缺一项就会影响质量,作坊式过程中会缺三项可以说是没有做过程管理。
业务边界模糊可以从几个方向说明:
时间边界模糊可以从几个方向说明:
在作坊式过程的团队形式比较恰当的比喻是团队是一个职能型组织。职能型组织最大的特点是相互独立,专业化团队。在作坊式过程中这样做其实会发生更多的问题,例如:某部分工作再一直堆积而又没有办法加快进度、信息不足导致开发过程的验证不足从而导致质量飘忽不定、同时开启的工作事项越来越多失去重点。
团队关系以单个成员独立完成为主,不评审,不检查,不回顾。在这个过程中就会发生信息同步不通畅,无法说明的工作内容与进度,单个成员负责特定业务的问题。
在开发过程中不设置阶段(里程碑)、不设置目标,从而把团队工作作为一个任何内容都可以插入的,都有必要插入的。在这样的情况下一个团队不管是 two pizza 团队还是更大的团队,只要是根据这样的规则就会一直开启新的工作项。作者在工作过程中见过一个团队同时开启十几项事务。例如:线上问题修正,KA 客户支撑,代码安全扫描问题修正,性能优化,客户小需求几个等等都同时开启。
在这样的情况下,主要特征是规划与执行有问题。规划过程与执行过程无法对齐导致了只做了紧急不重要的事,而做不了规划中的事项。
丢失焦点便是为什么叫冲刺的根因。前面说到时间边界模糊,再加上上一节说到同时开启多想工作项。再加一个无周期的环境中又开启多个事项,而不是团队专注于一件事在固定周期内解决这一件事来保持阶段的专注性。这样导致团队成员都很忙,但是又没有完成更多的事情。从而降低成员成就感,并对职位晋升有较大的阻碍。因为职位晋升需要阐明在一个周期内为团队、为公司做了哪些贡献,在作坊式过程中做事既琐碎有误目标总结为贡献就会很难。
团队目标缺失导致团队成员没有行为规范。没有行为规范各个成员就会按照个人理解对代码,开发规范进行实施。在开发过程中就会发现A想这样,B想那样最终就看谁更强硬。而不是看团队整体的目标输出价值,还是稳固质量就开始做自己的事情。导致各做各的,由此任性的成员就从这里出来。
事情堆积如山,再来新的事情必须排队进行。因为事项同时开启过多,导致每个成员要做的事情都是不一样的。每个人头上都是一堆事要做,而每个事情都有不同的头需要去牵扯出来再做,所以,没有办法去做。
因为没有里程碑的制定,就没有办法 check 计划执行情况。无法跟进进度的情况下很容易造成相互职责,相互不信任的过程。进入负反馈循环之后就会造成团队在泥沼中越陷越深,再加上作坊式过程无法完成自我改善。
初步总结一下作坊式过程,其实还有很多事情无法深入讨论。例如:这样的团队中的成员对于过程管理的认知是什么样的?这样的团队中文化是什么样的?
永远在响应变化,那就是没有响应变化。因为永远响应变化那就没有时间去做自己应该做的事情,例如 OKR,KPI 事项。而在根据 OKR 引申到要支撑的业务方向的变化就更难进行支撑。
因为无视质量,所以新开发的内容上线,线上什么时间出问题都保持迷惘状态。从而需要时时刻刻都要保持警惕,然后以人力的方式老保证系统上线故障的解决。
进度对齐包括团队内部对齐,团队间对齐。一方面因为信息沟通不畅,另一方面因为不进行规划,再加上每项事都是单个成员独立完成。几乎各个点都有可能影响进度,而这些点又没有对齐所以风险更高。
从上面的现象描述过程中可以看到,软件开发的团队合作几乎没有。为了不守规矩想怎么干就怎么干。
在这样的团队中既无输出有无成果还每时每刻都要提心吊胆的盯着线上是不是有问题。而且不会有张弛有度,只会一直的在做紧急的事情。看完上面的内容是不是感觉很无力,很不理解怎么做成这样。从软件开发领域的基本规则作者推导出一个更一般性的规则:理清事物之间的关系,描述清楚事物的边界,剔除不必要的内容,添加必要内容;遵循这个规则才能更好的做成事。
将大的无法评估的工作,拆分成小的工作。并以明确小工作的目标,以小工作来组成项目。这样即设置了里程碑,又可以进行 check 。这就是完成冲刺的第一个概念周期。
由 Sprint Backlog 来明确迭代目标,以 Product Backlog 来明确产品目标。这样就有了冲刺的另一个概念目标。
敏捷过程中可以用各种各样的形式的工具去管理整个流程。而在过程管理中以统一,完善的方式去做一个敏捷过程。CODING 提供了一整完整可用的方式对敏捷过程管理。
在 CODING 中可以使用史诗级任务看板来管理需求。可以有效的管理需求的优先级,并可以根据优先级在迭代中选择 Sprint 任务。这样迭代的边界可以在选择 Sprint 任务的过程中变的清晰,并在迭代启动会中澄清时间边界。
在敏捷迭代过程中,可以对 Sprint 任务进行拆分,并对拆分的工作进行工作量评估。这样可以很好的控制进度风险。保证迭代工作可以低延时的交付。并评估工作量的过程是开发团队公认的,在团队内形成共识的。相当于团队中每一个成员对外的承诺。提升团队成员的参与感。
团队过程改进在作坊式的过程中都是运动式的。没有固定的时间点,没有固定的会议在 CODING 度量中可以看到有效的了解团队中的开发速度,交付速度。对于影响开发速度,交付速度的内容一眼就可以看到,以过程数据量化展示的方式给团队提供过程改进的依据。
最简单的事才是最难做的。就像以敏捷方式来解决作坊式的问题看似简单,但只有在真正理解和实践敏捷开发的核心价值观和实践方法的基础上,才能够在解决作坊式问题时发挥出敏捷的真正价值。
软件工程是以工程化方法规范软件开发,按步骤和流程进行软件开发,保证软件项目成功交付。上世纪 60 年代,IBM 开发 OS/360 操作系统,这是第一个超大型软件项目,非常复杂。当时,共有 1000 名左右的程序员参与其中,该项目总投入工作量高达 5000 个人年,但最终却无法运行,以失败告终。而项目负责人 Brooks 博士总结经验撰写了《人月神话》一书,使得该书成为软件工程领域的经典之作。
尽管发展多年,软件工程仍然是一个充满挑战和机遇的领域。相信随着技术的革新和应用场景的拓展,软件工程将迎来更为广阔的发展空间。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。