Java微服务-项目管理-任务分解与项目质量总结

一、为什么要任务分解

　　1、情景

　　在做项目过程中，经常出现下面几种情况：

　　（1）研发说：“由于我当初写开发方案时没想到这个地方这么复杂（或者这里隐藏了很多需要开发的需求），所以想要延长开发时间”。

　　（2）项目上线后或者提测后发现，研发有些功能或逻辑没有实现，研发会说：“我开发的时候没有注意到”。

　　2、根本原因

　　上述这些研发的说辞看似解释了这些情况的原因，其实这只是借口，并不是问题的根本原因。

　　对于上述两种情况，研发没有想到某些地方存在复杂逻辑以及没有注意到隐藏需求。其根本原因是：

　　（1）在需求评审和分析时，没有仔细分析和拆解各个需求任务的逻辑和功能；

　　（2）在写开发方案时，比较粗糙和偷懒，没有把所有需求任务分解到最小粒度。

　　总结上述两个根本原因，就是在需求分析和编写开发方案时没有做好任务分解。

　　3、任务分解的重要性

　　要想避免由于没有做好任务分解，而导致项目进度或者项目质量的问题。首先研发需要重视任务分解的重要性。虽然产品经理已经把整个项目的目标和需求描写清楚了，但是距离研发立马上手编写代码还需要两个重要的关键步骤，就是需求分析和编写开发方案。

　　研发的需求分析，主要是以下工作：

　　（1）了解和掌握项目中的业务逻辑和业务流程，检查逻辑是否自洽；

　　（2）研究项目的开发可行性；

　　（3）将项目拆解模块（这个阶段不分解到最小粒度），主要是对项目的业务框架有基本的了解，以及对项目的体量和复杂度有大概的了解；

　　（4）将本次项目的重点和难点部分标记出来，可能时复杂逻辑、或性能要求、或公共组件和方法等（在编写开发方案和开发时需要重点考虑）。

　　编写开发方案应该要有以下几个步骤：

　　（1）根据需求文档，分解项目任务。

　　分解任务是一个综合步骤，具体怎么分解，下面会讲到。

　　分解任务时，一定要将任务一层一层分解，直到分解不下去。最终的最小粒度任务是可以交给任何一个开发人员，简单解释就可与让该开发人员明白具体要做什么。

　　这一步，需要产出一个任务列表（树状结构）。

　　（2）根据第一步产出的任务列表，对项目进行框架设计。比如，某个业务逻辑的实现可以参考哪个设计模式、哪些方法可以抽象成公共方法、哪个业务方法需要使用分布式事务或者消息队列。

　　 这一步主要是开发人员对整个项目的代码框架进行设计，设计后会得到一个新的任务列表（同样是最小粒度）。这里可以对重点部分和难点部分进行着重设计。

　　（3）根据任务列表，进行排期和分配任务。

　　通过分解任务和得到的任务列表，对我们有什么作用：

　　（1）可以准确且清晰地定义项目的范围；

　　（2）方便给开发人员分配任务，以及后续寻找负责人；

　　（3）可以提高估算开发时长的准确度；

　　（4）方便排出各个任务的优先级；

　　（5）有利于明确项目的影响范围，最大程度地降低风险。

二、怎么任务分解

　　每个研发都有自己分解任务的方法，但是都需要遵循以下分解原则：

　　（1）分解任务一定要以结果为导向，切不可为了分解而分解。我们分解任务是为了高效地做项目，使项目的最终交付结果符合预期。如果一个小项目，它已经很明确清晰地显示了各个子任务，那大可不必花时间和精力去做分解。

　　（2）分解任务要像剥洋葱那样，一层一层地往下分解。切不可跳过中间层级，像切洋葱那样一步就分解到最小单元。

　　（3）分解任务一定要分解到最小粒度，分解到不能再细分为止。

　　（4）从上向下分解，一般是分解某个任务或者功能的组成元素，这样也符合面向对象的编程范式-组合原则。在最下层可以描述最小任务的具体。

　　（5）要遵循 MECE 原则。

　　　　a、相互独立，在同一层级上的任务有明确区分、不可重叠；

　　　　 b、完全穷尽，不遗漏，尽可能穷尽所有的小任务。

　　分解完成后会得到一个项目任务的树状图，然后根据这个树状图进行代码框架设计。设计后根据树状图就可以产出一个项目任务列表，这个列表只是表格形式的任务分解树状图，只是它会有更详细的信息，比如每个任务的开发时长、负责人等。

项目质量总结：

　一个项目最终是否成功，有很多因素综合决定。作为项目的研发以及一个项目的主要研发，到底需要完成哪些工作才能尽可能影响项目的成功。大多数研发并没有这样的思考，更别提提炼总结项目管理的方法论了。结果就是大多数开发，拿到项目就是做，根本没有思考的过程。然后最后项目上线甚至提测后是什么样，就听天由命了。出现问题然后就匆匆忙忙地修复BUG，从来没有停下来想过为什么。

　　首先是一个研发的思维和态度，提升一个人的思维还是比较困难的，需要一个长期、系统的过程。但是端正态度还是相对容易。研发对待一个项目不能仅仅只是当做一个活来干，首先他要有足够的责任心。做的好不好是能力问题，有没有做好的决心是态度问题。

　　对于如何尽可能提高组员对待项目的责任心。第一步，需要自己以身作则。自己需要表现出强烈的责任心和主人翁意识，尽可能让自己的态度影响周围的人。第二步，要高标准严要求。在项目开始时，就需要奠定这样一个基调。开发过程中发现任何问题及时提出、及时改掉，不允许懈怠。与此同时要注意方式。不仅要让大家知道标准是什么样的，更重要的是先强制大家按照标准执行。做的好的需要及时赞赏。

　　其次是研发的一个思维，思考的深度决定了一个研发项目成功的概率。我们经常说研发不仅要有技术思维，还要有产品思维、商业思维。同时，做项目要有工程思维。为什么有些开发是程序员，有些是软件工程师？为什么我们所从事的学科是软件工程而不是编程？

　　我们开发一个项目，最终上线的这个过程，就是软件工程实施的过程。工程思维最大的特点是“要把事情做成”，也就是可交付、可使用、并做到开源节流。软件工程实施需要工程方法，有目的、有计划、有步骤地解决问题的方法就是工程方法。这里不对工程思维展开赘述，只是强调这种思维的重要性。

　　最后才是一个研发将项目流程中各个步骤落地实施的能力。这个执行过程考验研发的执行力以及自律性，不能懈怠，严格按照标准执行。一个人的执行力是他的基本职业素养的基础体现，但其实大部分人的执行力还是较差的。怎么在项目中保证组员的执行力不能太差？一个办法就是靠流程，研发组长把任务拆解之后分配给组员。剩下的开发过程只要严格按照设计的框架和制定的开发计划进行，基本可以保质保量的开发完成。最难的就是监督组员有没有按计划执行，这就考验研发组长项目过程把控的能力了