项目进度按照规划时间走的四个步骤

Posted 2023-05-15

参考技术A 　　大家知道，控制好了项目时间就等于管理好了项目进度，因此在做 项目进度管理 的过程中，基本很多操作流程都是与任务时间的划分分不开关系。不论是估算工期、设验收阶段时间点，还是规划子任务周期等，都是为了让任务在规定时间内完成，即保障项目进度。

　　接下来，将简单描述项目进度关于时间管理的四个步骤。

　　一、分解项目工作任务，罗列清单文档

　　将项目工作分解为更小、更易管理的工作包也叫任务或活动，这些小的任务应该是能够保障完成交付产品的可实施的详细任务。

　　在项目实施中，要将所有任务列成一个明确的任务清单，并且让项目团队的每一个成员能够清楚有多少工作需要处理。任务清单应该采取文档形式，以便于项目其他过程的使用和管理。当然，随着项目活动分解的深入和细化，工作分解结构(WBS)可能会需要修改，这也会影响项目的其他部分。例如成本估算，在更详尽地考虑了任务后，成本可能会有所增加，因此完成任务定义后，要更新项目工作分解结构上的内容。

　　二、理顺项目依赖关系，设立里程碑

　　在产品描述、任务清单的基础上，要找出项目任务之间的依赖关系和特殊领域的依赖关系、工作顺序。在这里，既要考虑团队内部希望的特殊顺序和优先逻辑关系，也要考虑内部与外部、外部与外部的各种依赖关系以及为完成项目所要做的一些相关工作，例如在最终的硬件环境中进行软件测试等工作。

　　设立项目里程碑是排序工作中很重要的一部分。里程碑是项目中关键的事件及关键的目标时间，是项目成功的重要因素。里程碑事件是确保完成项目需求的任务序列中不可或缺的一部分。比如在开发项目中可以将需求的最终确认、产品移交等关键任务作为项目的里程碑。

　　在进行项目任务关系的定义时一般采用优先图示法、箭线图示法、条件图示法、网络模板这4种方法，最终形成一些列项目网络图。

　　三、分析范围、资源计划，估算项目工期

　　项目工期估算是根据项目范围、资源状况计划列出项目任务所需要的工期。估算的工期应该现实、有效并能保证质量。所以在估算工期时要充分考虑任务清单、合理的资源需求、人员的能力因素以及环境因素对项目工期的影响。项目时间管理在对每项任务的工期估算中应充分考虑风险因素对工期的影响。项目工期估算完成后，可以得到量化的工期估算数据，将其文档化，同时完善并更新任务清单。

　　其中，工期估算可采取以下几种方式：

　　1、专家评审形式。由有经验、有能力的人员进行分析和评估。

　　2、模拟估算。使用以前类似的活动作为未来活动工期的估算基础，计算评估工期。

　　3、定量型的基础工期。当产品可以用定量标准计算工期时，则采用计量单位为基础数据整体估算。

　　4、保留时间。工期估算中预留一定比例作为冗余时间以应付项目风险。随着项目进展，冗余时间可以逐步减少。

　　四、制定项目进度计划，运用科学方法

　　项目的进度计划意味着明确定义项目活动的开始和结束日期，这是一个反复确认的过程。进度表的确定应根据项目网络图、估算的活动工期、资源需求、资源共享情况、项目执行的工作日历、进度限制、最早和最晚时间、风险管理计划、活动特征等统一考虑。

　　进度限制即根据任务排序考虑如何定义任务之间的进度关系。一般有两种形式：一种是加强日期形式，以任务之间前后关系限制任务的进度，如一项任务不早于某任务的开始或不晚于某任务的结束;另一种是关键事件或主要里程碑形式，以定义为里程碑的事件作为要求的时间进度的决定性因素，制定相应时间计划。

　　在制定项目进度表时，先以数学分析的方法计算每个任务最早开始和结束时间与最迟开始和结束日期得出时间进度网络图，再通过资源因素、任务时间和可冗余因素调整任务时间，最终形成最佳任务进度表。

　　关键路径法(CPM)是时间管理中很实用的一种方法，其工作原理是：为每个最小任务单位计算工期、定义最早开始和结束日期、最迟开始和结束日期、按照任务的关系形成顺序的网络逻辑图，找出必须的最长的路径，即为关键路径。

　　时间压缩是指针对关键路径进行优化，结合成本因素、资源因素、工作时间因素、活动的可行进度因素对整个计划进行调整，直到关键路径所用的时间不能再压缩为止，得到最佳时间进度计划。

　　很多项目的时间经常处于争分夺秒的状态，任一环节的时间耗损都可能连带对其他项目任务产生影响，进而让整个项目有延期风险。因此，做好项目的时间管控，是项目进度的最佳最佳落实手段。

代码质量管控的四个阶段

前言： 

       质量、功能和进度，是一个软件项目的三根支柱，但在现实项目中，当质量和其它两项产生冲突时，往往是作为被牺牲的对象。团队对于质量的态度主要停留在口头重视上，似乎还没有上升到团队意识的高度，也缺乏必要的保障手段。但没有质量的功能，从它面世第一天就开始永无止境的修补，并最终走向被重写的命运；没有质量的进度，只能是一个虚伪的承诺，因为接踵而至的，是一轮又一轮的附加开销，有效进度被大大拖延。要想提升代码质量，首先需要确立质量意识

        本文讨论的代码质量指的是代码本身的质量，包括复杂度、重复率、代码风格等要素。代码是团队的共同财产，代码质量是团队技术水平和管理水平的直接体现。代码质量下降通常会自成因果，导致恶性循环：

• 破窗效应：在烂代码上继续生产烂代码的心理负担小很多
• 传染性：烂代码传递着一种不在意质量，只看业务成果的负面信息，会伤害团队的技术热情和工作氛围，导致更多烂代码出现

本文会分析代码质量下降的内在机制，并分享在代码质量管控方面的一些实践经验。

一、熵增定律与代码质量

熵增定律告诉我们，一个封闭系统总是趋向于熵增，也就是系统的无序程度只会不断增加。

         对于软件项目来说，代码质量代表着系统的有序程度，烂代码增加就是系统无序性上升的体现，在无外力影响的情况下，烂代码只会原来越多。

        为了维持系统有序，需要外界向系统不断输入能量。对于代码质量，我们需要主动投入资源，来有意识地抑制烂代码越来越多的自然趋势。

二、经典循环

        烂代码产生的常见原因是业务压力大，导致没有时间或意愿讲究代码质量。但是向业务压力妥协而生产烂代码之后，开发效率会随之下降，导致业务压力更大，形成一种典型的恶性循环。

        为了应对业务压力，常见的做法就是向项目中增加人力，但是单纯地增加人力的话，会因为风格不一致、沟通成本上升等原因导致烂代码更多。

        要遏制这种恶性循环，需要多管齐下，主动对代码质量进行管控，并且持续进行技术升级，系统性地解决问题。

        不过质量管控和技术升级需要长期投入才能产生效果。通常情况下人们还是倾向于通过增加人力快速地解决业务压力的问题，而忽略了对于代码质量的负面影响，导致代码质量越来越差。

三、四个阶段

我把代码质量管控通常需要经历的四个阶段，称之为“四个现代化”：

• 规范化 - 建立代码规范与Code Review制度
• 自动化 - 使用工具自动检查代码质量
• 流程化 - 将代码质量检查与代码流动过程绑定
• 中心化 - 以团队整体为视角，集中管理代码规范，并实现质量状况透明化

阶段一：规范化

        保障代码质量的基础是建立团队的代码规范，通常包括：

• 风格规范 - 缩进、换行、大小写等风格问题
• 实践规范 - 规避一些常见的隐患，或者针对特定问题的最佳实践
• 业务规范 - 与业务有关的特殊要求，比如文案中的关键词

        团队的代码规范通常以文档的形式存在，供新人们学习。但文档这种形式常见的情况就是新人看过之后就不再回顾了，也很难对实际写代码形成真正的约束。

        在规范的基础上，要通过 code review 将规范落地。code review 中大家可以对代码质量问题进行交流，并且相互监督，形成团队重视代码的习惯。

阶段二：自动化

自动化是指在代码规范的基础上，使用自动化工具进行质量检查，通常包括：

• 代码规范检查 - 包括风格规范、实践规范、业务规范
• 重复率 - 重复出现的代码区块占比，通常要求在5%以下
• 复杂度 - 总行数，模块大小，循环复杂度等
• 检查覆盖度 - 经过检查的行数占代码库总行数的比例

自动化质量检查可以覆盖多数常见问题，能够提升开发效率，也可以降低人工 code review 的成本。

         自动化检查工具的规则集与代码规范直接对应。通过编辑器插件，在写代码的时候直接给出检查结果。到这个阶段，团队的代码规范文档已经不再需要陈述各种细节，开发者可以直接通过查看自动化工具的规则集来了解代码规范。

阶段三：流程化

        流程化的意思是将自动化代码质量检查和 code review 与代码流动的过程绑定，从而保证所有上线的代码都经过机器与人工多个环节的检查。代码流动过程：

执行自动化代码质量检查的时机：

• 编辑时 - 使用编辑器插件，实时运行质量检查
• 构建时 - 在本地或者开发机的构建脚本中运行质量检查
• 提交时 - 利用Git Hooks，提交代码或者生成Pull Request时运行质量检查
• 发布时 - 在发布脚本中再做一次质量检查，通常与自动化测试放在一起

质量检查与代码流动绑定后的效果：

阶段四：中心化

当团队规模越来越大，项目越来越多时，代码质量管控就会面临以下问题：

• 不同项目使用的代码规范不一样
• 部分项目由于放松要求，没有接入质量检查，或者存在大量未修复的缺陷
• 无法从团队整体层面上体现各个项目的质量状况对比

为了应对以上问题，需要建设中心化的代码质量管控体系，要点包括：

• 代码规范统一管理。使用Git或者NPM包管理自动化代码质量检查的规则集，自动安装，不在本地写规则。一个团队、一类项目、一套规则。
• 使用统一的持续集成服务。质量检查不通过的项目不能上线。
• 建立代码质量评分制度。让项目与项目之间能够横向对比，项目自身能够纵向对比，并且进行汇总反馈。

 

总结

        在面临业务压力时，人们通常会倾向于通过增加人力来缓解业务压力。但从系统整体的角度来看，人力增加会造成代码质量变差，开发效率下降，从而再度增大业务压力。这种代码质量越来越差的循环，是熵增定律在软件工程领域的生动体现。

        为了抑制这种循环，我们需要有意识地投入资源来建设代码质量的管控体系。这个过程分为四个阶段：规范化，自动化，流程化，中心化。每个阶段都有不同关注的要点。