EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
对于人数较多的研发团队，下面介绍下整个研发管理流程，瀑布式开发模式，虽然比较慢，不过很稳，适合传统企业。
( [8 Z" D, ~( ]! v2 |6 }) U- R
c1 V) f' n1 ^2 u1、立项阶段9 r. l/ w' ~- k- Z, E3 t
, t. V0 K' s: p' j/ U发起人提出需求（公司领导/客户等）、产品自身需求，产品部收到发起人通知或自身规划需求后，做相应的竞品分析、市场分析等评估工作，经过评估后，如需要以项目的形式继续往下实施，则安排填写《项目立项申请表》，并走流程进行确认，项目发起人一般是公司领导或来自客户。
* B% G7 h; E8 q9 C" H+ [% ]' h& K' G; q+ _1 k
2、需求阶段
2 \7 [. J7 L; k% p; T5 x' A. j6 v3 N8 u+ r- G$ l
MRD
: ^! D4 m! T# n: j3 z. k项目立项后，产品部进入需求收集、分析、筛选、整理等工作，产品部输出需求范围或其它产品规划文档，需求范围需同项目干系人进行讨论、确定，并最终由sponsor确认，需求范围需体现是否会涉及到第三方或公司内部其他部门（如财务、运营、客服等）的业务，需求范围得到明确后，将进入后续的产品设计阶段。- ^2 A# e! C/ E' J0 X* [/ f
. d* ?, `; a6 K2 v5 J/ V0 B8 |/ w
PRD( h6 `4 T5 m! G: k1 D
根据需求范围，原型设计编写产品需求文档及其它附属文档等，产品需求文档产生后，召集相关部门对产品需求进行评审，产品需求文档内容需包含（但不限于）如下部分：- Z, T( w' A) r
★ 功能需求是否覆盖$ `* V& I8 j: G* j6 H8 e; J
★ 性能需求是否覆盖( E: h- j9 u) {: g3 n* q1 L6 K
★ 数据需求是否覆盖
' p4 |( M& \' T0 K★ 监控需求是否覆盖
5 ^6 x: Y- K2 y* `3 j7 B★ 适配范围需求# u% h) i9 {: ^) A4 K: J7 [
★ 新老平台/系统的兼容性要求
O, y1 K$ C4 U: B8 c" _% p★ 周边系统的影响评估$ v$ b% Q( {$ h Y( f, _/ j
★ 安全需求! l5 Z" Y5 Z I8 e4 x
★ 系统容量/并发需求: K, o ]* v4 l5 l# ?# j% e1 _
+ `0 m* J$ Y$ ]5 e8 \原型设计
+ M$ ^5 V' t, F7 l8 y1 F) A根据需求范围，对产品进行设计，并输出产品原型，产品原型设计产生后，须召集相关部门进行评审，可与产品需求文档PRD一起进行评审，评审过程需形成会议纪要，评审通过后，将正式原型归档。
! l3 S5 \7 N6 r4 ^! D5 G4 R$ X$ a% v0 f/ J
3、规划阶段2 [5 r e: ~3 P6 G5 N! a
1 W8 |! R2 s+ @ r2 E E- c/ _在项目正式启动前，项目经理需要做一些项目前期规划工作，规划的内容和范围主要包含：
; Z2 S3 y* l( [2 [' bØ资源评估及规划+ f) t% O* u0 g- M. C
Ø项目风险评估和管理计划
4 U4 B$ N# d8 B4 z6 T8 s2 z" {Ø项目估时及时间计划表+ Y0 w3 j: s/ ]4 X
* P3 B( r9 _ l- h5 f: Z! B( b
Ø项目Check List生成) h: J3 Z! K5 g0 K& |
. k4 u9 `+ k, t+ L! V5 u( g @* _2 o, V资源评估及规划
6 T3 l* ~. j/ x! [. M' |0 d* d项目经理组织对项目的资源进行评估和规划，项目资源主要包含内容如下：. D0 F; Y; P- A1 J. x% Q8 n
★ 开发资源/工具规划确认
9 L3 l3 |, \( F& `3 ~& t( U★ 测试资源/工具规划确认; M$ d( ]) ~3 h! t
★ 生产环境资源规划确认
1 k; `9 J; ]7 v, y% y/ a- [$ k% o. s/ N; M$ j6 R
项目风险评估及管理计划: U. x& z' x, f9 u! |$ }
项目经理组织项目组成员对项目的风险进行识别和评估，项目风险主要包含技术风险、资源风险、沟通风险、环境风险等，引导项目组采用头脑风暴等方式，对风险进行识别，并对其严重程度及影响面进行评估，以综合评估风险指数，针对识别出来的风险，需要给出相应的预防措施，以防变成问题，将风险降到最低点，最终生成风险评估及管理计划，由项目经理实时跟进，并定期更新和维护风险管理计划表。9 O2 N# W8 w- u5 B6 c
6 t* E2 s( k/ c0 B项目估时及时间计划表
# H& ^, F4 ~( Z0 e' q项目经理召集相关研发经理、团队成员进行计划估时及制定，研发人员需要配合项目经理进行任务的分解和评估，同时对开发时间进行评估（估算的时间要尽量确保合理），评估的时间粒度原则上能让项目经理可有效的进行任务跟踪，具体的粒度由项目经理根据项目实际情况进行把握（按照国内的项目管理惯例，一般情况下，最小粒度希望能细到1天，最长不能超过3天。）项目计划所包含的维度需包含（但不限于）：
, D7 E' m9 J: ^4 Z★ MRD
0 D7 v7 u4 w) N e★ PRD4 X# _5 X1 J- G
★ 研发设计
% M9 q! s6 y* w9 f2 U/ a★ 编码" i, Z1 C& Z4 c: ~
★ 自测. y _0 n3 |$ {
★ 联调' Z4 Z ?& I9 s+ ` |$ f( \1 A
★ 测试
; C, g% N1 E5 M★ 验收% b+ g" v+ W7 K9 f* ]
★ 上线
4 r7 }+ F# I S+ b, ?★ 结项
/ i7 d d8 J% a t. z0 U2 p C项目经理根据开发、测试等部门评估的计划，整理出整个项目计划，作为项目正式启动的重要输入之一。 I# Y6 A# @: J" a* m
, \/ r3 ?! G5 f) A) W+ B
项目正式启动2 Z) u9 [9 G* {5 Y8 w" E
项目规划阶段工作就绪后，项目经理发起会议并召集项目组所有人员进行正式启动会议，会议主要明确内容如下：; Y o1 ~' K a) @. B; |, i
① 项目计划同步和确定
: ^7 p' s0 g- U! y② 资源及人员职责的明确和确定 Y) b1 N w$ G' m, O
③ 当前风险评估及管理表的宣讲& S1 r5 s/ s9 _% |* ]
④ 对项目目标的同步和明确
6 V; Q w; b g会议结束后，项目经理将以上4项明确后的结论做最终整理，并将其相关文档提交到SVN上进行统一管理。
/ Z9 Y/ K5 V) q
1 Y( G" f& a# g: t4、设计阶段. p! u+ b+ r, v$ U4 H
" Y$ v, m3 R+ {5 |* o, I
技术调研 f+ P( L8 w- R" D1 N& C
针对产品规划过程中所提出的技术风险、难题进行前期技术调研，技术调研要有一定的深度，评测结果要真实可信，其他来源的数据仅能作为参考，要以自己的测试结果为主，调研工作结束后，需编写《技术调研报告》，报告中要给出调研技术的分析和建议结论，调研过程中涉及到相关的代码和demo，需要在《技术调研报告》中体现，并说明具体放置的路径，研报告输出后，安排项目组相关人员对调研结果进行评审。2 j$ { ]7 W% b" R8 @
C+ _. y9 d# P* a
技术方案设计" P/ n! s$ Z \& L
开发人员根据产品需求文档进行系统模块的划分和分解，分模块进行系统分析，各个模块的系统分析完成后，需要编写《详细设计文档》、《数据库设计文档》等，各子系统间的交互需要编写《系统内部接口文档》，如本系统与其他系统有交互，需要编写《系统接口文档》，针对《详细设计文档》、《系统接口文档》及《数据库设计文档》需召集项目经理、产品经理、开发人员、测试人员等进行评审，详细设计文档包含（但不限于）以下内容：
1 b$ D& m. i4 a* x* x, k5 F+ B★ 系统架构% ]( u3 U% J+ J9 E
★ 系统各模块分解及功能说明' c6 S- }8 N% X( I! y2 m
★ 各系统之间的关系及如何调用
/ U% _7 z% {1 ~★ 其他部门的合作对接方案/ P' V* [' @4 h: O0 \% ^
★ 数据平滑迁移方案设计, m; T8 I/ k$ e+ R3 D1 `
★ 安全方案等4 r3 w! p) {2 E& i$ k) Q, d. q
详细设计文档需以部门或系统为单位，整合成一份文档输出，避免一个项目N份设计文档。8 W5 a9 N+ X- J, R! e
+ Q: I& [* n, v C测试用例设计及评审
) Q4 F' S2 S! j X7 w3 F5 X$ C9 d! t测试人员根据产品需求文档、详细设计文档进行测试用例的编写和分解， 测试用例编写完成后，需要组织相关人员进行评审，并输出评审报告，测试用例的设计在实际项目操作过程中，可能也会在产品设计阶段确认之后就开始。
0 F/ l) L, O% Q1 F6 d2 }! L" ~, F' s
UI设计及评审
4 b/ H1 V. ?( o% R3 cUI设计师根据产品原型、产品需求文档对UI进行设计，UI设计稿，需同业务方、产品、开发等相关干系人进行评审，原则上产品经理对设计稿上功能、流程是否满足进行负责，设计师对设计稿上的外观、审美进行负责，评审通过后，进行定稿并正式提交。
& u& h( z7 ~! V. |8 p# l3 m7 W1 Y, {
/ Q D- Q/ @8 W$ X4 \5、研发阶段
8 ?6 o0 r5 k) s# g6 `
1 H. w: V" T' _1 d1 d0 V编码
2 G u9 n1 W+ u% \代码格式须遵照《Java代码编写规范》等规范书写，代码需确保编译通过，并每天入库一次，代码入库前必须完成Code Review，在代码编写阶段，需要严格按照项目计划执行，并确保代码质量。
5 w' a. X9 G$ m g
/ Y5 V1 b B9 f! t( c8 n1 {' s {+ _单元测试" L: W3 E z2 B8 m: B
在代码实现过程中，需保证在一个迭代周期内完成单元测试（迭代周期视项目具体情况而定），在一个迭代周期结束前，入库的代码需包含相应的单元测试代码，单元测试代码入库前原则上也必须进行Code Reviewer，单元测试的最终结果是保证迭代周期内的代码测试通过，以确保入库代码的质量。
- O# M( a% Y6 }$ @8 J: S
/ g/ H. b2 Z7 Q% C7 s9 m4 Y x联调6 |* T' K+ G* R M* H
在编码及单元测试完成后，项目进入联调阶段工作，联调工作主要包含：9 v9 P0 b( T% w( m6 }8 L! I
★ 子系统间接口、功能联调; c9 r9 O* I8 D5 `- x, m3 V
★ 本系统与其它系统间的接口、功能联调# K) b4 r& ?& g( a
联调需确保各子系统间或相互调用的系统之间接口调通，正常流程的功能实现正常，为后续测试奠定良好的基础。6 q" L5 A$ U1 Z* u2 w# f ^% N
' ?# W4 `5 N# m$ j+ @3 D提测/ V# i s1 d( a: T. g
联调通过后，开发人员将代码提交到指定的服务器地址，开发人员需填写《xxx项目提测申请单》， 邮件提交给测试相关人员，版本提交申请单需包含以下内容：
8 |- L7 V$ g2 Y7 k) A★ 项目名及版本号7 ]& r* U( }" K! o2 r& Z+ t9 `6 q
★ 联调结果
$ w3 T b1 |6 X; m★ 代码的具体地址（包含SVN地址及SVN版本号）
) g, l! w+ x$ J! _0 I★ 新增/修改的功能/bugs 清单及功能自测结果7 y; R' j* m/ ?
# Y8 \& m2 d+ o$ P6 y) g
6、测试阶段
* J0 o# |2 q- \5 }, ~6 }* Q$ F" u% X
冒烟测试
3 `# t y* ^* }6 r/ @0 R: m4 I# `测试部接收到版本后，安排进行冒烟测试，冒烟测试在测试环境上进行，冒烟测试过程中，如果发现重大问题，致使测试无法进行下去的，需要及时将问题highlight给项目经理及开发部，开发部需第一时间安排优先处理问题，直到冒烟测试通过。
& h1 E, I# t! | {# I5 l. U* b- h9 _1 _6 ? F2 d
系统测试
9 T1 [. h7 Q9 B4 K, I W测试负责人对任务进行分解到每位测试人员，并确保每条用例到具体负责人，测试人员收到测试版本及测试任务后，进行测试工作，测试人员的工作需按照项目计划进行，如出现与项目计划不符的，需及时提出，并与测试负责人及项目经理进行沟通，测试过程中发现的bug提交及具体操作，请按照JIRA系统操作流程执行，测试过程中，如果碰到严重问题而造成正常测试无法进行的，需第一时间highlight出来给开发和项目经理，开发接到问题后需第一时间安排分析解决。测试负责人需要每天反馈测试进展情况，并输出项目测试日报。
! N9 {8 T" Y- Q' d- J3 \2 h& b8 R+ J
测试报告评审
: b( D1 P2 e) S' `3 Z1 ^# e项目经理收到测试部发出的系统测试总结报告后，结合实际情况，发起测试报告评审的会议，会议评审内容主要包含测试报告的内容及JIRA中的bug list。
4 i9 o7 q8 C E% y! R测试报告评审的原则：7 }) m8 B6 e* Q9 ^% i3 p2 G l. ~5 c
★ 针对N/A的部分需要说明具体原因，并确认当前是否确实无法测试；
& \# r. m5 F' V" Y; s& L' L★ Fail项是否都已提交到JIRA系统中进行管理。- ~- C6 c/ a0 b3 i& ~0 L% n
Bug List评审原则：
4 ^3 i# A3 ~% d f: C7 _★ 需要对每个bug的最新状态作确认；: e% o* X1 U# @, C* R/ H* G. T" ]
★ 逐一讨论bug，对每个bug需要分析其严重程度、解决的优先级；$ A' `) W N4 U- a4 c
★ 每个bug需要明确具体的负责人和解决时间点；
) H+ R' R* a) U% p9 x: r★ 对一些bug暂时不需要解决的（如需求不明确或严重程度低的），可做“挂起”处理。但事后需要特别对“挂起”问题，重新进行分析、讨论，作为后期完善、优化的一部分内容；2 A3 i2 R8 Y, ?( i" O
★ 针对“争议”类的bug需要项目组做特别讨论，并给出处理的结论。6 d+ v$ n: u4 v# s3 S
根据评审完的报告和bug list，需要进一步明确下阶段版本更新、系统测试的时间点以及测试范围，根据评审的结果，项目组确定版本是否可达到上线标准。
2 |! g- @8 O! Q7 q/ |9 ]0 s( E
: P* r" w& Y# s1 N; Z开发debug( b9 m3 }) \; {, }+ [6 E
开发人员需要主动查看分配给自己的Bug，并及时更新Bug状态，开发在解决完bug后，要及时更新bug状态，并对已解决bug注释原因及解决方案，针对Bug修改的代码提交时，原则上不允许以下情况：
- h0 E* h4 ?3 v, l1 q0 b★ 一次提交代码中包含多个Bug修改；, o6 l1 e6 _4 {1 q4 F7 A& N
★ 一次提交代码中即包含Bug修改，又包含其他功能的开发代码。0 V* R' i( b& `, u1 \
' n! H6 `( i* p) t% N6 \7、验收阶段 c6 I! N$ E) ?$ J/ H4 c G9 _
+ {- L0 ]% `; }. Q2 p* \0 b1 S
产品验收5 t5 B5 W' [1 `" v0 h6 l" V
当测试通过后，在提交上线申请前，产品经理需对产品进行验收工作，验收工作结束后，需输出验收报告，并在验收报告中给出是否通过等结论，将产品验收报告同步给项目组相关干系人。8 m9 |* c7 ]4 z, B, q- E
. Y* G, m) H+ j1 k) s, A, @6 s$ ]
8、上线阶段
# R- b) Q. {. @9 }! y) ^0 ^2 ^# T. ?- v4 t( N2 _
上线准备会8 j$ V* o. h. ?, c, s+ T: @4 L' U
项目经理召集开发、产品、测试、运维等相关部门进行上线前准备会议，会议内容主要包含（但不限于）以下内容：
5 d2 h t! v# s★上线前的上线方案是否准备完备# N6 R; a( ^2 u& N0 a
★上线的具体时间确定% A5 P. v z3 H
★上线的相关事项准备
7 d+ x! L! Q- j$ q1 w2 ~/ M2 k/ }★上线check list核对
2 M& k, d2 i( F+ j$ v/ H# E★上线人员确定/ X8 M F k- X( r
★风险评估等
" k6 M C% ^& ], u3 C; W& A0 v) ]6 T5 |/ H
上线部署申请" ~* L/ K6 q. T3 U1 f; }/ _
指定的研发负责人在工单系统上发布上线申请；审批通过后方可进行项目上线工作。
' B1 u: y$ ~/ f5 n+ b
( X+ y$ _. R+ n. j6 x" j部署上线
; _# h- p6 y4 X( R) e5 `5 l上线申请单审批通过后，进行上线工作，上线结束后，运维人员需要验证系统是否能正常运行，确保上线成功，上线结束后，上线人员需要将上线结果通知相关人员。- F! W1 @9 f9 f$ l: \
/ g: ^4 ]' B5 \
线上验证. h, t& J1 ?, C, g9 m3 E/ n# y
测试部门需要提前准备验证测试的测试方案和测试用例，测试部门收到上线成功通知后，启动线上验证，线上验证过程中如果发现问题，需要及时将问题通知给项目经理、开发人员及运维人员等，项目经理得到通知后需第一时间召集项目组相关人员进行讨论，以确定后面工作的安排，线上验证通过后，测试部门需输出线上验证是否通过的邮件，周知项目组相关人员。
+ t# f3 z' J. P" o
* l- t; ?" q5 n+ P1 x0 `: O3 X% u% R+ p9 o. O `
" u5 b# y3 F4 ^; G6 ?' r9 v$ s$ c/ G6 N6 Z9 r- i
- J3 H2 O7 U$ y3 M2 }
! E: E8 }6 S% ^2 \
, j% t( X& ]% N, H0 Q* t% e/ o9、收尾阶段* }1 l2 Q' ^- q d0 Y
( l$ x9 |- S# Y1 h# B6 p4 l结项 L) `/ c5 L: i0 \ N) _2 y& `* d
当上线成功及系统稳定后，项目经理须安排项目组所有成员进行项目总结会，项目总结会，每个项目组成员都须参与并积极发言，会议主要内容包含三大部分：6 s" Y5 @1 p) P
★ 从项目中得到哪些收获
; O3 k8 y6 N) G0 u* f7 A★ 项目运行过程中碰到问题及改进意见3 A; _" V6 y( k( [$ a: w
★ 对后期项目期望是什么
# h% r) S; ]* ^项目经理需要对会议内容进行总结，作为项目的组织过程资产，以作为后续项目的借鉴和经验教训，针对暴露问题的措施或解决方案，将其落实并完善项目管理体系，并更新项目管理流程及相应的模板，以PDCA闭合管理，需检查项目在运行过程中所有过程文档及产出物是否已正式入库。
% S; q+ i' |7 h
+ i5 E! y/ v6 b, v0 ^1 o6 D) A
' Y5 ~; ?7 j$ S+ ~3 z( P9 X |
/1 
发表于 2021-9-2 10:37
收藏
淘帖
支持！
反对！