开发项目管理

uelophim · 发表于 2020-5-29 10:58

EDA365欢迎您登录！

您需要登录才可以下载或查看，没有帐号？注册

x

本帖最后由 uelophim 于 2020-6-2 11:32 编辑

开发项目管理是研发体系中不可或缺的一部分。项目经理是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对开发项目涉及的全部工作进行有效地管理。即从项目的需求开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。

开发项目管理中主要管理的项目主要归纳为两大类，项目开发、bug修复，这两类分紧急和非紧急的情况，在项目管理中对项目开发、bug修复、紧急、非紧急的安排和处理都是不一样的，而且这四种涵盖了整个开发项目的管理。紧急的情况，项目经理判断可以开发后就要立马安排成员给处理。而不是紧急的需求就统一进行任务安排。

开发项目管理的生命周期包括了从项目分析阶段、项目开发阶段、项目测试阶段、项目上线阶段、项目使用阶段，项目使用阶段会产生bug以及优化迭代的需求针对这些任务就要重新进行开发项目的管理。如下为开发项目管理的生命周期图：

项目分析阶段：就是产品经理给到需求后，项目经理对项目进行分析以及将任务安排给各个成员的过程。
项目开发阶段：这个阶段最主要是保证任务的按期进行。
项目测试阶段：这个阶段是保障项目质量的最关键阶段，测试测的越详细上线后出现的问题越少。
项目上线阶段：这个阶段先要做好上线前的准备工作和上线的风险评估，保障上线过程中没有问题。
项目使用阶段：这个阶段要跟进上线后的功能有没有出现问题以及对用户的使用情况进行分析，看后续是否对改项目进行迭代和优化。
6 j0 w* d) J$ I) d# u" m

具体该怎么做好开发项目管理呢？我们观点主要是下面这些维度：

技术评审$ W& }% I( K: @, ^3 i" _

技术评审也是项目分析阶段非常重要的一个环节，目的是对逻辑实现以及技术的可行性进行分析，保证了需求的合理性，也让对应参与成员有个整体的认识，为后续开发和排期做好铺垫，但是按项目的复杂程度流程也是不一样的。

复杂项目需求：整体需求大于3天工作量的项目
{; y/ L- K! D% d5 K1 t1 m

对于这种项目比较复杂我们应该有更规范化的流程来对其进行评审，因为这种项目是影响最大的，也是最消耗人力和成本。对于这种项目我们的主要流程如下：

提前发送资料; W1 r/ W4 ?) `! [3 H# J
- 产品经理准备相关资料，并提前将相关资料放到共享盘，发送给涉及到评审的所有人。
  & ^& w# m; p" H

确定评审时间
$ J/ I6 X b+ A- C& K
- 项目经理和产品经理确定评审时间，并通知相关参与成员评审时间。
  5 k' A4 k: A5 ?5 |* D/ s3 b) U. g

开始评审# t7 L3 E/ k! E3 Q* c4 E& \
- 产品经理讲解评审内容。
- 参与成员提出问题与建议。0 W/ J7 K! B# x2 q( Y2 a

评审后
1 e$ o4 G9 ?; K" p6 W/ b$ v7 h
- 项目经理和相关参与组长总结评审会议，并讨论评审结果。随后项目经理将评审结果通知产品经理，产品经理发送邮件同步评审结果。
- 若评审结果为通过，项目经理将对项目进行排期。
- 若评审结果为不通过，产品经理需要对需求进行调整，调整后发起再次评审会议或产品经理需要向产品负责人反馈，产品负责人和需求负责人需要对此结果进行二次讨论。
  % R. [7 Z7 d9 v% s6 R- s8 s4 O

可以参考下面技术评审的流程图：

简单项目需求：整体工作量小于3天的项目需求，也可叫其为零碎需求。7 e0 }" b; C3 _0 v& U9 [

这种项目可能是小的bug修复比较小的优化需求，可能本来一句话就可以说完的还搞个会议就有点杀鸡用牛刀的感觉。那对于这种需求我们又应该怎么做呢？而且对于这种需求产品经理每周进行汇总而后与项目经理进行核实为零碎需求并且给与开发后，如果是来一个穿插一个，会打乱原有的开发计划除非是紧急需求，然后通过邮件发送给相关的成员，如有需要产品经理在小范围进行需求的讲解。

技术评审维度
4 h" A# u- p) n; E% W
- 需求背景：概述需求从哪来，为何要做这块。
- 用户与需求概述：描述需求应该要做成什么样。
- 功能模块：需求涉及相关的重点大的功能点。
- 简要优先级：描述下当前的最重点内容。
- 流程讲解：讲解本次需求涉及主要流程。
- 数据指标：讲解本次需要哪些关键性的指标。
- 原型与交互：讲解原型内容和交互。
  o# [9 i" y) J" e* W) {! d0 T

开发计划
. v, S, U4 W- o0 `5 R+ q

“凡是预则立，不预则废”，项目计划的制定对于整个项目运行来说无疑十分重要。一个整体的计划可以让公司层面了解整个开发周期，也让各自负责的小伙伴都明确自己要做什么。

计划来源
; ? u/ f/ ^; M' o9 |) Z7 l
- 项目需求：项目需求主要从产品经理手上直接获取，还是就是研发自身发起的优化迭代需求和工具性开发，这个也是最主要的来源。
- 系统基础建设：包括框架开发和迭代、系统优化、第三方系统或扩展引入等工作。
- 服务器基础建设：包括服务器硬件监控和维护、系统软件监控和维护、第三方系统搭建和监控等基础运维工作。
- 回归测试：主要是测试对线上项目进行回归测试。% I) n) B) l3 Y* ` \

模板参考
( X. y8 ?+ O7 k; T* i/ E4 r

项目计划既要让公司层面了解也要让负责的小伙伴也明确自己要接下来要做什么，故有一个好的模板是很关键的，那么对于计划模板我们应该怎么做才好呢？如下图为excel项目计划模板参考图表，可以看到项目整体的时间和人力安排，也可以看到主要负责的成员的计划和完成任务情况，以及整体的提测时间。

计划安排) Y: I& R$ ~; q- e1 p+ ^+ _+ o
- 项目进行技术评审后，项目经理需要确认是否有明确的上线时间，如果有要将具体上线时间知会给参与成员。
- 涉及到的各个端的组长根据项目情况对任务进行拆分和评估所需耗时，拆分后的任务和开发成员进行沟通。
- 将沟通后的任务拆分情况给到项目经理这边，项目经理先检验任务安排是否合理而后将任务结合实际情况进行具体时间排期，若排期超过上线时间应该要和组长和成员进行沟通讨论任务的调整，直到将计划调整到合理的时间范围内。
  ' [2 p6 M, x; v: K7 ^: d

进度管理" t# K( |: ~' w1 n# j

进度管理是保障项目按期完成最重要的关键点。好的进度管控方式能让项目进行的更顺利，那我们该如何做：

每日晨会制度
3 V( w. R* n2 O+ T0 g5 b' j0 z
- 每天早上花5分钟左右。
- 参与成员按小组分别进行。
- 每人讲自己昨天做了什么，有什么问题，今天的计划是什么。
- 其他人了解别人的工作情况，并发现指出可能存在的问题。" Z/ \3 k/ n) q$ r) l5 M5 c

每日日报6 }2 X* `, i* n! i4 R( x1 q
- 当天晚上成员发下当天的工作情况。
- 可微信部门群进行发送确保其他成员也知道你做了什么。
- 参与成员为所有成员。
- 发现问题进行回复。
  ' R" ?1 g. B5 E, [' @& r, b

定时跟进, l0 J7 ^% F- I4 O

项目经理要定时跟进，在即将项目完成的前一天以及每隔几天，了解成员是否有需要协助的地方，任务完成是否顺利。

进度反馈$ N m6 r# B- T4 S* C( z7 M& @
- 每周邮件
  5 ^8 r7 u) N7 N

通过每周发送开发计划邮件，让其他部门和公司层面了解项目的进展情况。

周例会" [# m1 N3 f- }9 r. C

通过每周例会的进度汇报，让部门上级知道项目的详细进展，以便及时作出大的层面项目调整。

进度异常处理
6 B& _8 d" z# B1 c
- 若是技术问题需要安排其他成员给予技术上的答疑。
- 在不影响整体项目情况下的进度延期，需要调整下其个人的排期。
- 若影响当前项目的进度延期，需要及时安排其他成员进行协助处理。
- 若影响到其后续项目的进度需要安排其他成员处理后续项目。
- 安排其他成员协助的原则是优先安排熟悉当前项目的人进行协助处理。
- 当所有成员都有项目在处理的情况下，原则是将优先级最低的项目成员调配出来。3 E, P" Q. b: \$ N

通过以上5种方式项目经理可以了解到成员的项目进度以及让公司层面知道具体项目进度，如果前期是用excel记录的话，还要及时的将了解到的情况进行excel更新。如果有成员进度落后了就要及时进行项目的调整或者安排成员进行协助。

代码review' ?& W# ^9 B/ U) r: u/ M. X) m

代码review是保障代码质量的重要一个环节，目的是提升代码质量，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助成员成长。

代码review方式8 W, K( G5 B' K3 H. a
- 交叉review法:每日花30分钟左右，让成员之间相互交换进行review 。
- 共享review法:间隔一段时间举行现场review，让成员自己讲解自己的代码 。
- 审核review法:代码将要上线阶段导师或项目经理进行代码review 。6 V2 o4 I; l7 K. ^+ X2 F

代码review是相对枯燥的一项工作，不要让review轮为一场形式，失去代码review的意义，那如何进行有效的代码review呢？ ) ~" e" f7 [0 l; |# W, m' v

控制每次审查的代码量和时间。, T7 l+ T* b1 z" n* e

每次试图审查的代码过多和时间过长，发现问题的能力就会下降。故代码review时间不能太长，把握在两个小时以内，应该进行缓慢的review，半个小时大概review 200到300行代码左右。 

 谨慎的使用审查中问题的发现率作为考评标准。1 l P( r1 N3 ^, Q: w% N+ H0 |4 Y

在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。如果是参与者自己发现的问题就更不应该给于惩罚了。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。当然如果在问题屡次发生的情况下，应该要给于参与者适当的提醒。

所有的问题和修改，必须由原作者进行确认 。) |5 w1 K3 P D) C% S5 E

这样可以确认问题确实存在，保证问题被解决； 而且也能让原作者了解问题和不足，帮助其成长，避免后续犯同样的错误。 

使用好的工具进行轻量级的代码审查 。
' O% H* b9 } {6 }1 S5 L/ L; I

“工欲善其事，必先利其器”。如果是PHP可以使用RIPS，RIPS可以发现SQL注入、XSS跨站、文件包含、代码执行、文件读取等多种漏洞。使用好的代码审查工具可以节省大量的人力，而且效率更高，代码审查工具可以规范化我们的代码，统一代码风格，我们只需要关注逻辑方面的review。

版本控制' o# G8 c+ z6 O8 Z0 g

版本控制作用是帮助我们记录和跟踪项目中各文件内容的修改变化。它就像是代码的快照，故我们可以很容易对产品的版本进行任意的回滚。

对创业公司来说，除了要有远见之外，产品的快速化迭代也是非常重要的。进入互联网时代开发已经从个人时代进阶到团队协助时代了，可以说版本管理的重要性同于人的双手，已经成为团队中沟通的桥梁。

项目风险控制。
+ ]- T8 q: C6 H
- 备份与恢复。
  9 X& ~$ ?) o& t8 l

版本控制不仅是起到了备份的作用，也起到了恢复的作用，这在项目风险起到非常重要的作用。举个例子你写今天有个需求要上线你写了1000行代码，其分散在10个文件中。这个功能上线后发现对原来的功能有影响，现在要删除原来写的代码，假设之前没有使用版本控制，要删除这个功能就要对之前10个文件都找出来然后逐步删除，在这个过程中还要非常仔细，而且要重新对功能测试一遍以免删错了。这种事情在项目开发中是显而易见的，所以版本控制存在意义非常的重要。当然这只是版本控制存在的最核心一点。

要有规范化使用版本控制。5 q9 w3 y- ?+ H; @. C; \0 |7 W

版本控制作用确实很大，但是合理使用版本控制才能减低项目风险，不然还是会造成很大的灾难。举个例子我们测试是专门有测试分支的，测试分支上合了多个项目需求的代码，如何因为开发人员误把测试分支的代码合到他自己的分支代码中来，从而导致上线的时候开发人员将自己的测试分支的代码也一起合并到线上分支中去了，结果导致了其他不应该上线的需求也一起上线了，所以整个系统访问出现了问题。因为只发布了后端的代码，前端代码还没发布。因为处理这个事故回滚都花了一个多小时，时间是小事对线上的造成的影响才是大事。就因为合错了分支导致了这场悲剧，类似的问题还不止是发生了一次，后面总结出来要做好规划好的操作。

如何做好版本管理。
9 o( ~2 F4 a$ d \! g
- 项目涉及到1人开发：由开发者自己从master上建立新的分支进行开发，而不要在已有的分支上进行，除非很清楚这个分支是和master代码是一致的。
- 项目涉及到多人开发：由主开发从master上建立新的分支，保证代码是和master一致，其他人在此分支上进行开发。
- 开发过程中要定期合并master代码，如每天合一次，保证开发中的分支不会落后master分支太长时间，而导致重复开发问题。
- 对于代码每次提交要检查每行代码的变更是否是本次要提交的代码，务必不能将非本次提交的代码进行提交。
- 对上线时代码的合并操作，合并的时候是经常看不到改动的文件，可采用gitlab上的Merge Requests进行合并操作，这样可进行多人对代码review审核，防止将不是本次需要上线的代码也发布上线了。
  6 d: X' u0 }! Y7 R0 u% C3 Y

上线发布6 h% ~* ?9 {$ w4 V: r0 Q

是项目上线阶段重要的一个环节。这个也是最后一道关口，是我们可以做防范处理的最后一道匝道，所以在这一环节我们更要准备充分。

发布风险/ @0 s. }5 E3 C6 H% l; E

从历史经验来看，曾经我们没有注重发布风险的控制，出现了各种问题。常见的问题总结如下：

成员分支合并错误：这种情况一般都影响比较严重，很可能导致系统访问出现问题，而且还要进行代码的回滚。
代码脚本没有执行：一般情况下只需要重新执行下脚本就可以解决问题了，但是有时候忘记执行导致问题定位所花费的时间也是很长的。
数据库脚本没有执行：这种一般比较容易定位，只需要查看对应错误日志即可发现问题，但是往往因为这种情况导致线上访问出现大面积异常。
, H% r; h1 `/ I2 S( F

故因为发布产生的各种问题将导致上线时间被大大延长，也影响到线上正常的使用。所以我们应当有更规范化的流程来保障上线的发布，尽可能的降低发布风险。