Categories
management|管理 technology|技术 中文

代码的分支管理、CICD以及版本定义

分支用途详解

  1. dev 分支是开发用的
  2. qa分支是测试用的
  3. uat是的在发布之前给内部人员(运营人员,或者老板们)使用的
  4. staging是用于压测的环境,上线前的最后验证
  5. master是用于生产环境部署的,是稳定的版本;部署的时候可以打tag,如:V0.1
  6. 还有两个目录: feature, bugfix。 feature是用于新功能开发,bugfix是修复bug的分支。

开发的流程描述

  1. 从dev拉取代码分支进行开发,开发完以后要merge request到dev,这个时候,会进行代码的code view
  2. dev是开发的前后端联调用的,开发者自己测试没问题了之后,就可以由前后端的lead merge到qa,qa人员就可以基于qa分支测试(转测)
  3. qa测试如果发现问题了,提交bug单给开发人员,开发人员在自己的feature分支开发修改(或者是创建bugfix分支修改),最后还是要回到第1步的流程;如果qa测试没问题,就继续
  4. 把qa测试成功的代码merge到uat供内部体验(可以省略本步骤)。如uat测试有问题,则反馈到产品,产品完善需求再从头开始开发流程。
  5. 把uat验证过的代码merge到staging,可以进行压力测试,也可以作为production环境上线的预演。
  6. 如果staging环境预演成功,就可以把代码merge到master进行上线了。这时候可以基于master分支打tag,如:V0.1.2

CICD

CICD的意思是:持续集成,持续部署。 一般来最好做到自动部署:dev代码有更新,自动部署到dev环境;qa有更新,自动部署到qa;uat和stagingg都是如此;prodcution环境需要devops手动部署。

版本定义的规则

可以在开发之前加一下产品需求的定义和版本的规划,在打tag的时候,就是对应的版本号了

产品版本号的管理建议:

1.一个完整的版本定义为V1.0,前面阶段性的版本用V0.1, V0.2这样的;

2. 线上版本的bug修复版本定义为: V0..1, V0..2 这样的。

3.版本号跟jira上的版本定义一致,跟发布版本的tag一致

Categories
management|管理 中文

开发流程及4W1H标准:让项目进度可控

开发流程图

如图所示的流程,是比较通用的,这篇文章主要想说说执行上的细节。

开发流程细节解读

1.蓝色部分主要是产品团队负责细化,但在技术评估环节,需要开发团队的lead参与。产品团队需要定义好版本计划、开发细节、时间点,负责人,这是整个流程中最重要的环节。

2.对于功能需求的细化,产品团队最好能提供完整的需求文档以及线框图。有了线框图之后,开发团队就可以进行开发了,等到UI完成了再进行替换即可。

3. 按照4W1H标准进行需求安排。

4.工作安排要用统一的方式,例如:可以邮件为准,或者jira为准,明确一个就行。假设以jira为标准,就可以用jira的版本控制来安排工作,每个版本里的tickets都明确好具体的需求,负责人,时间点等。用jira也很容易做好开发部分(图中绿色部分)的整个流程,让版本的开发标准化。

5.如果有的需求当前无法评估时间,那么就把评估时间当做一项任务拆分出来,按照4W1H进行安排;如果需求当前无法安排负责人,那么就把确定负责人这个事情当做一个单独的任务来进行安排。以此类推,让所有的任务都符合4W1H标准,做到每项开发的工作任务都可控。

6.每项任务,PM或者Team Lead最好是每天都跟进一下相关的进度,一方面及时跟进每项任务的进度;另一方面发现有遇到阻碍的情况,可以很快调整。

7.有效提高会议效率:以小团队为单位开需求小会,为了解决具体的问题,一天可以有很多小会;尽量少开大会,大会汇报大的进度,以及整体计划的跟进和调整,不讨论具体细节。会议请提前安排,明确会议主题,明确会议参与者,明确会议时间(尽可能不要超时),做好会议记录和总结,并落实会议决议。

4W1H标准

工作的安排需要明确why(为什么有这个需求?or 谁提出的需求?),what(需求及其验收标准),who(负责人)、when(完成的时间点)、how(执行方案)。why是需求的来源,如果在细化需求的时候遇到问题,可以追本溯源来重新分析;what让执行人知道具体的执行细节;who是确定了谁对需求的执行结果(质量和时间)负责;when是让每个需求都有时间节点,也能让团队的人明确每个需求的优先级;how是用来记录这个需求的执行策略。

总体来说,整个流程中,蓝色部分的需求定义和工作安排是最重要的,参考4W1H标准进行,可以让整个项目要做的事情,时间点,准确可控。另外,需求的定义者要学会对工作任务进行拆解,建议让每个最小的任务的工作时间控制在1周以内,这样即便某个任务出现特殊情况延期,也容易快速调整并进行修正,整体进度不会受到太大的影响。

Categories
management|管理 中文

开发团队人员组织结构、工作要求和职责

组织人员架构图

如图所示,开发团队主要分为两个部门:一是产品管理,而是研发管理。产品部负责产品功能、UI和体验的整理和设计,研发部负责对产品进行实现。

产品管理部门

一个产品的需求,除了产品人员本身对于产品目标的设计,还会收集到用户、市场、法务等各方的需求反馈。产品部把需求主要分为:新功能开发、已有功能的bug修复、 用户体验的优化,然后综合衡量,制定出研发的版本计划。所以,开发的版本计划主要是产品部来指定,当然开发部的负责人会一起参与讨论,让计划更加合理。

产品部门的人员包括:商业分析人员,负责产品市场分析、竞争对手分析等,并提出产品需求;需求设计人员,输出产品需求文档和线框图;UI设计人员,根据设计文档输出漂亮的UI设计图并进行切图;QA人员,负责对研发实现的产品进行验收,让产品部门的人验收研发结果,会更加准确高效。在团队小的时候,商业分析、需求设计和QA可以同一批人。

开发管理部门

开发部主要对产品的需求进行实现,常见的划分为:前端开发和后端开发。在团队不同的阶段,devops可以独立,也可以放到后端开发。前端开发现在一般包含web和app,通常两个端由同一个人来领导会比较好,因为有大量的工作是可以重用的。

两个部门的工作,有一些模糊的地方,可以根据具体的情况协商来解决。例如:对数据结构的设计,可以是产品部门来设计,也可以是开发部门来设计。这个要看团队负责人的能力和经验了。很多产品部门的lead是有研发背景的,研发的lead也可能参与过多个成功的产品设计。

两个部门的人相互合作,相互促进,共同决定着产品研发的速度、质量和用户体验度。

补充一点:把产品部和研发部分开,还可以适用于使用外包开发团队的场景。公司内部做好产品需求、UI的设计以及最终产品的验收,是可以把工作外包给专业的外包公司的。这种情况下,把devops人员放到公司内部即可。

各个岗位lead的职责和要求

  • 要求:

1.能够在相关的专业领域有足够的项目经验,以及快速学习的能力

2.能够识别下属的能力,合理的安排工作需求

  • 职责:

1.对职责范围内的事情进行全面负责

2.安排、验收需求(why, what, who, when, how)

3.定期评估组内人员表现(做了哪些事情,是否按时完成,质量是否满足要求,有哪些突出的贡献),提交给Hr部门进行评估,给升值、加薪,或者淘汰做参考。

BA Lead

管理BA团队,把市场、商务、法务等方面的需求,转化为产品需求

Design Lead

管理产品设计团队,把需求细化,转化为详细的产品需求文档,以及线框图

QA Lead

管理测试团队,负责对研发开发完的功能进行验收

Backend Lead

管理后端研发团队,负责后端功能的实现,数据储存、安全性以及高并发性能问题

Frontend Lead

管理前端开发团队,负责用户端的产品实现

Devops Lead

管理Devops团队,负责开发环境、测试环境,以及生成环境的搭建,环境的安全性,代码的部署。