项目开发周期和项目管理

  • 本文主要总结阐述目前经历的的开发周期和项目管理,
  • 阅读大概12分钟
  • 适合新手+项目管理新手+有经验进行自我总结

身为前端开发,目前在三家公司做过开发
不想看之前经历可以直接跳到总结并给出自己点方案

两家上市公司+一家200人的小公司,这三家公司以下就简单简称A/B/C吧

A公司的开发流程

一个项目的生命周期

  • 1、开发组长产品商量开发人员(需要哪些人,大概工期)
  • 2、产品建群发需求文档
  • 3、开始需求会议(此时UI基本完成,再次确定难度和事件)
  • 4、根据接口时间开始开发(一般前端在后端完成60%之后才开始)
  • 5、到测试时间开始发布测试环境开始测试

主要问题

  • 改需求比较随意,经常遇到测试好等待发布,产品要改样式啥的
  • 测试阶段也比较随意,比如要求周一测试,我可能找找借口给你推到周二测

B时期的开发流程

一个项目的生命周期

  • 0、产品经理有需求想法去找项目经理讨论可行性和紧迫性
  • 1、项目经理开始分任务
  • 2、产品建群发需求文档 答疑解惑
  • 3、前后端把产品叫过来答疑解惑准备开发发送答疑解惑邮件
  • 4、前端或者后端选择一位作为项目负责人对项目工时分解,沟通开发时间和测试时间,最终开发测试产品约定统一时间
  • 5、建立开发任务立项邮件附带上一步的分解文档,让主管在任务平台创建任务和分解任务,在文档中约定时间开始开发
  • 6、测试前一天确定是否延期,如果延期,需要产品测试过来重新评估工期
  • 到提测最后一天时,需要产品测试和主管过来验收项目
  • 7、根据验收,第二天中午前修复bug发测试发布提测邮件
  • 8、bug集中在邮件中发送,典型bug需要在任务平台建立
  • 9、完成测试时会发生确认邮件

主要问题

  • 开发往往在产品需求会时对项目并不清楚,导致没有多少疑惑
  • 需求会时,产品只会瞎搞,很多技术细节,开发并没完全理解,导致后面各种问题
  • 开发阶段改需求导致很多问题

C的开发流程

一个项目的生命周期

  • 产品在自身或者用户反馈接到需求建立issue
  • 第一周最后一天开一个需求细化会,与所有开发测试过下一步要做的需求和安排,在细化会将issue 按照等级分类,
  • 第二周开始一次迭代会,将细化会没确定的需求确定,评审每个需求需要的时间(投票决定)然后分配任务(平均每个人5-7个工作日)。两周一次迭代(一个0.1版本)开发,按照分在不同版本issue进行开发
    • 因为开发工作日不算熟悉需求和代码审核+测试bug+开发的时间的,所以两周虽然就开发5-7工作日时期很满的
  • 领取issue后,开发熟读需求,并理解,然后找测试和产品进行开卡让开发描述这个项目需求
  • 开发在主干上拉去分支根据issue建立相应的分支名称
  • 完成开发后,进行桌面检查
  • 提交代码,申请合并(先向同组申请代码审核=再向测试提交申请) 测试收到申请则进行测试验收,发现bug太多,则直接驳回,否则继续进行测试,每个bug 再申请合并页进行消息记录,开发改完bug则进行回复,测试完无bug,进行合并操作。合适时机 测试将改主干发布线上,
  • 测试正式测试之前需要看到当前代码已被review的记录,
  • 一轮测试之后,将所有bug记在issue中,开发将所有bug改好,提交riview则可以继续下一轮测试(一般<=3轮)

主要问题

  • 没有提测文档环节,开发文档在哪里,测试注意点不够重视,主要靠口头

总结并给出自己点方案

总结下来最小的那个公司C公司相对完善和人性,但也有不少问题

  • A公司太随意,可能和我当时所在项目组有关(主要是轻应用)
  • B公司没有开卡环节,测试bug没有轮次之分,开发可能在开发前两天并不知道开发需求,邮件和工作平台效果很好,可以记录项目和个人工作量
  • C公司如测试开发文档都写在issue里面,没有自己的文档

总结下来大概分为以下流程

  • 每次开发分为开发周期,一般2周,当周未做完的顺延到下周
  • 安排专人处理线上bug
  • 一个迭代周期 10个工作日 -1个工作日会议,平均每人6-8个工作日工作量
  • 每日早上站会
    • 昨日自己干了什么
    • 今日打算搞什么
    • 有什么困难需要协助
产品确定并细化成功能
利用两天调研和确定需求
项目1
项目2
项目3
利用两天调研和确定需求
开始开发
开发中进行测试用例评审
代码审核
第一轮测试
完成修复继续下一轮
新需求
迭代会前2天需求细化会
迭代会
...
开发向产品确定确定细节
...
开卡=向产品测试讲述需求
桌面检查=开发是否符合需求
评审并再次确认需求
审核通过申请合并到测试分支=转给测试
所有问题记录并转给开发
测试无问题则合并分支开始下一次开发

关于细化会

功能优化|新需求|新项目 以下统称为开发任务

  • 产品主持
  • 讲解下一期可能要做的开发任务,了解可行性
  • 确定开发任务需求等级,
  • 不确定的开发任务需求分配给开发进行调研

关于迭代会

  • 对细化会的开发任务进行评审
    • 投票决定每个开发任务的开发工时
    • 工时最小单位是半天,超过8天则定义为跨迭代周期的开发任务,对任务再次拆分
    • 分配给每个开发开发任务
    • 保证每个人分配的所有开发任务加在一起在5-8个工作日
    • 确定一个人主要负责线上项目(其分配的任务在3-5个工作日)

关于白板管理

  • 最好是真实点白板+web页面
  • 分类为本次迭代周期待开发,正在开发,正在测试,准备上线
  • 每天晨会也是围绕白板进行产出
  • 建议白板方便每日抬头就看到进度
  • 建议也使用web方便任务统计和每个员工kpi核算,方便年度和季度总结

一个开发任务的开发

1、开卡会议

  • 1、开卡准备:熟悉需求并向产品询问细节
  • 2、找到UI+产品+测试 向他们阐述所有需求
  • 3、提出疑问+同时测试也提出疑问
  • 4、产品经解答疑问,并判断开发和测试对需求是否理解透彻
  • 完成后邮件发送参会人和抄送必要主管
    • 邮件需要写需求点+项目各方人员+开发周期等

2、测试评审

  • 一般在开发开始后1-2天,测试主持向产品经理和开发阐述测试需要测到所有点
  • 产品开发注意是否有遗漏或错误地方
  • 完成后邮件发送参会人和抄送必要主管

3、桌面检查

  • 开发完毕,邀请测试和产品经理到开发处检查程序是否符合基本功能需求
  • 不符合打回
  • 符合但有部分问题,半天时间改完
  • 完成后邮件发送参会人和抄送必要主管
    • 邮件需要写测试建议+注意事项+host配置+需求变更+影响页面等等

4、代码审核

  • 通过桌面检查后,开发申请同组进行代码审核,并向同时说明每一段代码设计思路。审核提出改进处,
  • 改进完毕,对代码进行rebase 然后提交测试
  • 完成后邮件发送参会人和抄送必要主管

5、测试与debugger

  • 测试完成第一轮测试指出所有bug
  • 开发在第一轮完成后修复所有bug进入代码审核同4
  • 测试开始第二轮测试
  • 测试人员反复测试无bug则本次开发封板
  • 本次开发上线前需要再次进行回归测试
    • 完成后邮件发送参会人和抄送必要主管

你可能感兴趣的:(杂技术/杂知识点)