研发管理方法论之任务拆解

随着互联网的普及,在国家“十四五”规划中提出“加快数字化发展建设数字中国”的战略远景,数字化成为企业发展的必经之路,数字化建设的落地一定是由技术团队来实现的。

 

现阶段的软件开发已经跟十几年前不一样了,我记得大学刚毕业那几年,一个人可以干完整个系统,现在软件开发过程中的职责细分、前后端开发分离等等,都明确表示软件开发是一个多角色、多岗位的流程性活动,要确保软件开发顺利进行,并且按时按质按量交付,那么完整的管理理念是必不可少的。

 

我们找CTO团队在过去20多年的研发管理工作经验中,提炼了一整套的研发管理方法论,可以用来指导研发团队的整体管理工作,我将会在随后的文章中跟大家详细探讨我们的经验和心得。

 

任务拆解

 

这一篇跟大家探讨的是任务拆解,软件开发是一个非常复杂的系统工程,参与的人员动辄几十人上百人,大家熟悉的Windows、Office等软件系统,都是成千上万人参与的。虽然我们日常见到的软件系统没有Windows这样复杂,但麻雀虽小五脏俱全,所有的软件开发都有差不多相同的流程和阶段。面对这么复杂的工程,只有能理解并将系统拆解开,才能按照计划进行推进。我们上学时都学过一篇课文叫《庖丁解牛》,面对一头牛,如何拆解呢?普通人估计真的无法下刀,而对于庖丁来说,就是非常简单容易的事情,原因就是他非常理解牛的身体构造,也知道应该怎样的顺序进行拆解,甚至能在下刀之前就告诉你,第36刀下去能帮你把后腿肉拆解下来。面对复杂的软件工程,我们如果也能像庖丁对牛那样熟悉,那何来延期无法交付之说呢。

研发管理方法论之任务拆解

如上图所示,我从三个维度来跟大家探讨一下关于拆解的逻辑。

 

架构设计的演进和规则

 

首先我们来看一下软件的架构设计,最早的软件都是单体架构,业务逻辑都写在一起,部署也是在一台服务器上。

研发管理方法论之任务拆解

 

随着互联网的发展,一台服务器的性能无法支撑业务的访问,这时候软件架构慢慢变成了分布式应用。分布式应用将相同的业务逻辑部署在多台服务器上,或者将系统划分为多个业务模块,业务模块分别部署在不同的服务器上,如下图所示。

研发管理方法论之任务拆解

再继续发展,业务也越来越复杂,各个拆分的业务中都会有很多相同的模块,例如都有用户体系、都需要通知体系,而这些可能相对独立的功能在不同业务模块都需要使用,在服务治理的需求下慢慢产生了微服务的架构。还记得当年加入阿里巴巴的时候正赶上服务治理的时期,有幸也参与见证了微服务框架Dubbo的早期设计。

研发管理方法论之任务拆解

 

对于微服务来说,也有它的一定规则和要求,不是拆的越细越多越好,简单来说就是每一个微服务都应该是解决一个领域的问题,建议采用单一职责的设计原则,相对独立的功能模块设计为一个微服务。相对应用内交互来说,微服务的调用成本、后期维护成本都是呈几何级数上升的,特别是多个微服务之间的相互调用,更会加大系统的复杂性。

 

举个我曾经参与过的案例,那个项目相对比较大,整体系统由多个ISV来承接的,各个ISV都有架构师参与,大家对整体系统进行拆分后,采用微服务的架构,总共设计了27个微服务。项目经理在对整体做规划的时候发现项目复杂度太高,而且每个微服务之间也有不少耦合的地方。我到项目组后跟几个架构师进行整体Review后,根据设计原则对已有的微服务进行分拆合并,最终仅留了11个微服务,多方多次Review之后,都一致认为拆分为11个微服务更合理,减少了过渡设计带来的复杂度和繁琐,整体系统架构清爽简洁。

 

项目拆解

之前的文章我们探讨过迭代开发方式,这里就不详细展开讲,强调两个关键点:

 

1、项目拆解的原则也是每个迭代都是一个完整的研发周期,必须能独立设计、独立开发、独立测试、独立部署交付的内容,不能因为后续还有没做的内容,导致本次迭代无法交付;

 

2、项目拆解后的每个迭代,建议2-4周之内能完成,太短了节奏太快团队会没有喘息时间,太长了无法享受小步快跑带来的喜悦。

 

个人任务拆解

 

软件项目的开发最终都是由参与的每个人都完成自己的任务,才能完成整体项目的交付,只要有一个人承担的模块没完成,那么整体项目就不可能交付,因此从管理的角度出发,必须让每个人都按计划按质量要求完成任务。



关于项目模块的开发时间估算,这是个经典的业界难题,任何系统工具都无法帮团队解决这个问题,只能根据开发人员和管理者共同协商得到一个估算时间,根据这些估算时间再跟业务人员、老板进行沟通协商,最终得到一个项目交付时间,只要能在这个大家认可的时间节点,交付符合质量的软件产品,那么技术团队基本就能做到符合预期的状态,后续如何做得更优秀,我们以后再探讨。

 

那么对于每一个开发人员,得到一个大家认可的估算时间后,是不是就可以放手让大家去干就好了呢?从管理的角度出发,这样放羊的方式,最终一定是要出问题的,没有过程管理很难得到理想的结果



假如说张三评估了这个模块5天能干完,那我们的规则就是要求张三将5天的工作量拆分成每天干什么,至少拆分成5个子任务,因为就算不拆分,他也是每天每天去干活,没有规划脚踩西瓜皮的方式,是无法按规划得到结果的。



这时候可能会有两种情况,一种是张三能按要求拆出来,每天的任务从逻辑上判断是合理的,大小粗细也差不太多,那么从逻辑上来说,张三5天能完成任务是相对靠谱的,只需要张三每天按规划完成任务,最终第5天就能得到整体任务的交付。

 

另一种情况是评估时间是大家一起评的,张三说我拆不出来5个子任务,原因很简单,就是对任务里面的一些细节没有经验,这时候团队中更有经验的同学来协助任务拆解,也拆成了5个子任务,每天一个,张三也认为相对合理,对于任务123能有把握当天做完,但对于任务45不确定,这也是他无法拆解任务的原因。这时候我们就会要求张三,在没有前置条件限制的时候,将任务45提前做,而不是放到最后来做。试想一下,如果团队20人参与项目,整体项目开发周期就是周一到周五,张三在周五快下班了告知任务干不完了,是不是所有人都得陪着协助干完了张三的最后一个任务,才能做整体交付,而如果张三将可能有风险的任务提前到周二、周三来干,周三就知道可能干不完,这时候管理者有很多种办法进行协调和处理,可以确保团队整体的任务在周五及时完成并交付。

 

可以再举个生活中的例子,假如说我们要安排下周一到周日去北京旅游,我们可以很清楚地规划周一早上高铁去、周日下午飞机回,周三去颐和园、周四去八达岭长城等等,每一天干什么都可以规划的清清楚楚,只要没什么意外情况,整体的旅游我们可以完全掌控,心里也会很踏实。换个目的地,如果让你规划一周去南极旅行一趟,估计你就很难将每天干什么安排好,是不是心里就感觉非常不踏实,但这时候有个专门做南极旅行的导游,帮你拆分好每天在哪里做什么,是不是就完全不一样了呢。

 

关于个人任务拆解,我们会形成一个规范,所有任务都必须拆解到每天做什么,每个子任务最多不能超过2天(JONE系统中按8小时/天来计算),就是单个执行的任务工时不能超过16小时,每天按照规划去完成自己承诺的任务,每个人的任务列表中都清晰地展示着自己的任务,在这种情况下,所有人都是有序地干活,每天交付自己承诺的工作内容,团队也就能交付整体项目的规划内容。你想,任务分配到每个人头上,每个人又能按规划每天完成任务,项目进度就完全可控了。

 

JONE系统中会根据规范每天将需要完成的任务在工作台展现出来,团队所有人都可以看到,每个人只要完成跟自己相关的任务就可以,任何没有完成的任务都会有相关的提醒。完全体现我们的管理原则:任何问题风险,必须在第一时间暴露出来,越早补救成本越低,越往后成本风险越高。

 

研发管理方法论之任务拆解

上一篇:javaweb学习总结(二十四)——jsp传统标签开发


下一篇:p41 打印九九乘法表