0%

敏捷迭代为什么升级


团队在敏捷迭代实施的过程中,遇到了各种问题,在这个过程中,也发现了很多很好的方法论。所以,近期根据团队迭代的实际情况,做了2.0的迭代流程升级。
团队使用的工具,在很早的文章里面有介绍,请查看小团队如何落地敏捷开发

一切从需求开始


需求源分类

由于提出需求渠道比较多,为了便于管理,我们对需求源进行了分类,具体分类如下:

需求类型 描述 对应迭代版本号
feature 基于产品价值的自主产品迭代 feature/sprintXX,如:feature/sprint40
cs 客户成功经理反馈的用户侧需求 cs/yyyyMMdd,如:cs/20210713
tech 研发内部发起的技术改进或重构类需求 tech/模块或重构名,如:tech/mtms、tech/res
hotfix 故障流程触发的线上问题修复需求 hotfix/yyyyMMdd,如:hotfix/20210713

目前,我们团队开启Sprint的需求类型为:feature,其余类型不触发Sprint。

迭代流程


整体迭代分为6个阶段,分别是

  1. PRD Review:产品需求评审、用户故事评审
  2. Estimate:概要设计、工作量估算(扑克牌)
  3. Sprint Start:Jira创建Sprint、版本号、登记用户故事、创建甘特图
  4. Sprint In Progress:迭代进行中,每天10点站会同步进度
  5. Deploy:PM、UI验收、版本发布
  6. Sprint Review:迭代复盘

1.PRD Review

PRD Review流程

参与者

  • 推动:PM
  • 参与:RD FE QA UI

输入信息

  • Confluence中的本次迭代的PRD

输出信息

  • 蓝湖中本次迭代原型讨论终稿
  • 用户故事讨论终稿

Confluence中的PRD

钉钉中的用户故事

2.Estimate

估算方式采用的是「规划扑克估算法」。一种基于共识的估算方式(游戏),主要用于估算Scrum迭代中的开发任务的工作量问题,通过团队的共同的评估方式,使得偏差变得相对较小。

什么是规划扑克

规划扑克使用Fibonacci序列作为Story Point。Fibonacci序列是13世纪引入的数学系列数字,用于解释自然的某些形成方面,例如树的分支。通过将前两个数字相加来生成序列,以获得序列中的下一个值:0,1/2,1,2,3,5,8,13,20等。出于敏捷估计的目的,一些数字已经改变,导致以下系列:1,2,3,5,8,13,20,40,100

扑克说明(点数约定:1 Story Point = 1 人/天)

解释
0 不需要工作量
无穷 任务巨大
? 无法估计
一杯咖啡 不足0.5,分分钟搞定
其他 按照字面意思理解点数

估算流程

参与者

  • 推动:PM
  • 参与:RD FE QA

输入信息

  • 用户故事

输出信息

  • 用户故事的估算和优先级

操作步骤(一般2轮估算基本可以达成共识)

  • PM进行用户故事描述
  • RD / FE 的团队成员,通过面朝下的方式打出编号卡(斐波那契值:1,2,3,5,8,13,20,40)
  • 卡片同时亮出
  • 解释估算偏差,并讨论
  • 估算共识达成

估算记录表

估算完成后,我们把估算的结果填写到钉盘中的故事列表中,并确定故事优先级

3.Sprint Start

Sprint创建&开启流程

参与者

  • 推动:Scrum Master(QA)
  • 参与:RD FE QA

输入信息

  • 用户故事 & 估算结果

输出信息

  • Jira内的Sprint & Gantt

创建Epic

创建Story

Sprint面板

Gantt

4.Sprint In Progress

日常流程

参与者

  • 推动:Scrum Master(QA)
  • 参与:RD FE QA

输入信息

  • 站会同步

输出信息

  • 用户故事更新

5.Deploy

验收&发布流程

参与者

  • 推动:Scrum Master(QA)
  • 参与:PM UI RD FE

输入信息

  • UAT环境

输出信息

  • 迭代发布
  • Sprint Done

6.Sprint Review

Review流程

参与者

  • 推动:QA
  • 参与:PM UI RD FE

输入信息

  • 测试报告

输出信息

  • 复盘结果

测试报告



总结


以上就是目前研发团队的2.0版本的敏捷迭代流程,后面需要重点改进的还是,如何引入CI、自动化测试等等手段,进一步提升测试的效率,从而更快的反馈出问题。

微信关注我,及时接收最新技术文章

前言

早期阶段的ToB SaaS,从数据规模来讲,相对较小,所以从研发成本、服务器成本上,一切从简,采用「简单」的数据收集方案,进行用户行为数据的收集工作,从而指导业务和产品。

大数据计算一般的流程如下:

其中「数据收集」包含了「数据采集」「数据加工」「数据存储」三个步骤,通过这些步骤将用户的行为和环境信息转化为结构化数据,从而沉淀为数据资产,为产品设计、运营分析、业务决策提供重要的数据支持。

事件模型

记录用户行为,首先要考虑的就是如何结构化,即事件模型

  • WHO:用户ID、设备指纹、学校ID ……
  • WHEN:事件发生时间、时间上报时间
  • WHERE:设备信息、网络环境、业务环境 ……
  • WHAT:事件标识、场景标识、事件参数

埋点SDK

为了简化业务同学开发埋点时的工作量,并对埋点日志进行一些必要的限制,需要统一的埋点SDK,目前需要2个端的SDK:微信小程序SDK、JS SDK

SDK包含的功能如下:

  • 用户标识管理
  • 设备信息、网络环境、业务环境自动收集
  • 事件上报生命周期管理(上报机制)
  • 兼容性处理
  • ……

数据存储

日志经过「数据采集」「数据加工」「数据存储」这三个阶段,在每个阶段后,产生的数据,从类别、存储介质、保存时间上是有区别的。

数据收集架构设计

  1. 各种端的SDK监控用户行为,通过Http请求上报给日志收集服务
  2. 日志收集服务,把原始数据写到硬盘,并进行归档操作
  3. 通过Filebeat + Logstash转发到Kafka内(主要是为了在高并发下,利用队列模式降低IO)
  4. 日志ETL服务,针对原始数据进行分析和相关数据补全,存储到MySQL,形成中间层数据
  5. 日志分析服务,针对业务,进行数据分析,形成分析结果数据
  6. WEB UI针对分析结果数据进行相应的报表展现

未来阶段

数据量

由于目前SaaS平台的数据量不大,数据的ETL、存储等等,采取了经济、简单方案,在后面数据量升级后,ETL可以采用Hive、Spark、Flink等等大数据解决方案,存储可以采用分布式大数据存储方案,HDFS等等。

大数据测试

当埋点较多、端类型比较多时,为了便于QA进行埋点测试,需要针对QA的测试方案,进行自动化大数据测试流程的设计和实现,保证埋点数据的准确。

微信关注我,及时接收最新技术文章

第一次接触

在2019年年初的时候,第一次接触OKR,从一本叫做《OKR工作法》的书了解到的,非常认同OKR工作法带来的好处,也分析了实施OKR的难度。随后也曾在自己的团队尝试去使用OKR方式,当时公司整体业务并没有进行OKR的管理方式,所以也只是在研发内部形成的对某些目标尝试,但是由于某种原因,我「离开」了团队,OKR的后续实施也搁浅了,是一次不成功的尝试。

新的起点

时间来到了魔幻的2020,我有幸加入了「教育赛道」的创业团队,经过3个季度的努力,公司的SaaS平台经历了「重新建立」到「价值变现」的过程。2020年底的时候,针对业务和团队,进行全方面的复盘。

创业维艰

复盘的过程,也充分体会到了「不容易」,多变的市场环境、有限的资源、「善变」的客户,在各种环境和压力下,跳出事情本身,从更加理性的角度审视,变得无比艰难。想起了2年前读过的一本硅谷创业家们的书籍《创业维艰》,回想自己这几年作为创业公司中的一员,确实艰难,2020年更是如此。

过程中,一个值得注意的现象:研发兄弟们在开发的过程中,有时候「抱怨」,非常不认同这次迭代做的事情。这背后应该是「产品价值」的传达不一致,产品、研发「目标」的不一致导致的。这2种应该紧密配合的角色,产生了「不信任」的情绪,这对事情本身,是有百害而无一利的。

为什么需要OKR

「目标」的不一致和不聚焦,「价值」认同的不一致,是我们遇到的一个非常大的问题。复盘后,我又想到了OKR,「公司老大」在2020年底的时候,也打算在2021年采取全公司OKR的目标管理方法。这让我有机会,更加全面的理解和实施OKR。我又再一次的认真读了一遍《OKR工作法》,并更加认同这就是解决我们遇到问题的良药。

OKR解决的问题

  • 从一个创意到让客户认可产品,还能快速上手使用,并愿意付费,这个过程每个环节难度都在增加,每个环节都需要你组建合适的团队完成。聚焦到具体的事情上,确保他们一直记得所做的事情的意义。
  • 产品型公司的OKR关键在于,需要跨部门的产品团队层面上升到公司业务层面。
  • OKR不是唯一一件需要做的事情,而是必须做的事情。

OKR的实施

第一阶段:各自思考OKR

每个部门负责人,思考2021年的规划,并从规划中提取出自己认为的「核心目标」和相对应的「关键策略」,对应的OKR应该是「Core Objective」「KRs」。

第二阶段:O的讨论

这个阶段主要是各个部门的负责人和「公司老大」一起讨论新的一年的Objective和KRs的过程。我们基于下面的表格进行讨论,并最终汇总成公司级别的OKR。

PS:O是什么的出发点,还是需要回到「初心」。从公司的「愿景」「使命」层面,逻辑推演出「产品价值」,并从「产品价值」推演出「核心目标」和要做的事情。这点耗费无数脑细胞,非常难,但是也是必须这么思考,这是对于思想锐变的一个过程。

公司和产品存在的意义,在于可以为社会提供「价值」,没有「价值」的公司和产品,无法长期的存在下去。

未完待续

第三阶段:预算的确定

兵马未动,粮草先行。一个靠谱的预算,会给新的一年的规划保驾护航。所以,从预算的角度,对OKR的结果进行另外一个维度的校准。

第四阶段:季度OKR的确认

这个阶段主要从年度OKR的共识,抽取出每个季度的OKR。

微信关注我,及时接收最新技术文章

这支团队是从2020 Q1开始接触的,在这个过程中,团队在迭代质量和效率上面得到了很大的提升。但是作为团队的「舵手」,我迫切想知道,大家对于团队的看法和新的一年的预期是什么,为2021年进行团队调整收集大家的真实想法,所以才有下面的「总结」活动。

目的


  • 了解团队成员关注的价值,为塑造团队价值作为参考
  • 了解团队成员关注的团队的问题,并针对性解决
  • 促使团队成员可以思考2020自己的好的和不好的地方,进行个人复盘
  • 了解大家的目标,想成为什么样的人,从思考如何让「个人目标」和「团队目标」的重合度加大,使双方受益

形式


  • 线上调查
  • 线下面谈

线上调查


主要是调查表的方式,这种方式,大家会有思考的时间,和谈话不同,调查表会更加客观看出问题。

明确为什么做

设计调查表的选项前,需要非常明确知道,通过选项的数据,我们希望得到什么,得到的东西可以帮助我们做什么。
这里,再强调一个调查前提

切忌 通过数据去衡量团队某个人的好坏。
调查的目的是 通过团队反馈指导如何打造好团队,而不是做员工评价。就像是芬兰的学校的学生过程评价系统,评价的目的不是区分排名,而是从老师角度去看,如何调整教学策略,去帮助学生。

调查表工具

由于公司使用的钉钉,我就采取了钉钉收集表的方式进行了这个工作,从表单设计,到填表,再到收集汇总,钉钉的表现还是非常不错的。下面是钉钉如何设计表单的简单示意图。

设计的表单如下:

数据的汇总和总结

调查问卷的结果,我们应该认真总结和思考,从数据后面思考本质,下面的是针对问卷调查,我的总结的截图

线下面谈


明确谈话的Framework和思路

提前给大家准备时间,我这里是提前了3天通知大家。并且在通知时告诉大家是在什么时间,每个人,也发了一张纸,内容主要是帮助和建议大家思考的方向和思路。

给自己整理出面谈日历

通过日历提醒自己,面谈的时间安排,提前做好认真准备,包含会议室,想谈话的内容等等。

做好面谈记录

我的记录基本是在面谈结束后做的,因为在面谈时,为了保持「尊重」,不要一直埋头记录什么,给别人感觉不好。所以,在结束后,马上回忆,进行记录。

总结和思考

主要是通过了解大家的情况、预期、目标等等,汇总建议、思考建设的方向是否和大家预期有偏差。了解大家想要什么,如何使「个人目标」和「团队目标」重合度高。

写在最后


这类方式,我也是第一次在团队中使用,效果其实还算在预期内,希望可以给大家带来一些思考和启发。

微信关注我,及时接收最新技术文章

写在前面

什么是真正的程序员

2020年已经结束,回顾和思考了2020年我的团队的好与坏,并且在2021年应该如何更好地建设团队。在谈如何做团队建设之前,我们先来说说程序员这个个体。

在互联网的浪潮下,程序员这个职业从某种程度上来说,具备了改变世界的能力,随着各种培训机构越来越多,程序员也成了高薪的代名词。越来越多的人选择这个职业,是因为高薪。从本质思考,高薪是做的好的结果,而不是成因。所以,我们应该思考下,我们当初只是为了高薪而加入吗,那么现在呢,什么才能支撑一个程序员走的更远?

什么是真正的程序员

相信上面的问题,程序员们或多或少都思考过,相信每个人都有自己不同的见解和认知,曾经读过一篇文章:《什么是真正的程序员》,原文来自《A Little Printf Story》

文章较长,耐心读完,相信有很多启发。

初心

Stay Foolish, Stay Hungry

做什么事情之前,应该时时刻刻记住做事情的原因是什么,即WHY。从本质主义出发,才能找到做这件事情的价值。在明确价值的前提下,才有目标,就像小故事里面的printf一样,最后他明白了技术是为了解决现实问题而产生的,这样技术才能产生价值,脱离了这点,再好的技术也是苍白无用的。

所以,技术的价值在于解决实际问题,也就是实现其社会价值,而且应该用技术的力量持续改进现实问题。

团队是什么

下面我们思考下什么是团队,我Google了下团队的定义,维基百科的解释如下:

团队由若干独立成员共同组建,有临时与长期之分。团队要为某一共同目标而奋斗,这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理,是横向的交流与沟通而不是纵向的命令与服从。—— 来自维基百科(https://zh.wikipedia.org/wiki/团队

从这个解释,我们可以发现几个KEY WORDS

  • 共同目标
  • 交流与沟通
  • 贡献

其实说的白一点就是:一群人在为同一个目标去贡献自己的力量,在这个过程中保持平等和良好的沟通。

那么研发团队就是,一群保持初心且有共同目标的程序员们,通过贡献各自的力量,持续地用技术去解决现实问题(改变世界 😂 )。

从哪些方面建设

  • 团队文化
  • 团队成长
  • 团队激励
  • 团队效能

关于这4个方面,我近期会整理好,继续更新上来,每个技术团队的基因和所处的环境,以及产品情况,都不一样,所以在建设方面,还是需要因团队而异,欢迎大家一起交流。

References

什么是真正的程序员
团队

微信关注我,及时接收最新技术文章

2020年随着居家时间增多,对自己的思考的时间也多了起来,而随着年龄的增长,认知的提升,获取的知识也不知不觉从技术类侧重到了提高认知层次。下面的清单更多的也是索引的作用,看过了有个大概印象,当需要使用时,再去找。

社会类

  • 《生命摆渡人》
  • 《机械宇宙》
  • 《大学的终结》
  • 《未来简史》
  • 《人类简史》
  • 《硅谷钢铁侠》

认知类

  • 《赋能》
  • 《卓有成效的管理者》
  • 《反脆弱》
  • 《OKR工作法》
  • 《重新定义公司》
  • 《支付战争》

教育类

  • 《你就是孩子最好的玩具》
微信关注我,及时接收最新技术文章

高效会议

有时候一天会被大大小小的各种会议打扰到爆,而让人最沮丧的是,会议讨论过程往往很多时候偏离的主题,从而导致低效,没有会议结论,就更别提什么效率了。

最近,公司「老大」提出在2021年的会议需要高效,议而决,决而果。所以,认真回忆了我在2020年参加会议的情况,感觉确实糟糕无比,那么如何开一个「高效」的会议呢。我思考了下面几个问题。

  • 我们为什么开会
  • 如何提高会议效果

我们为什么要开会


会议价值

思考的起点:我们还应该从「价值」的基本面去思考。

会议本身是一个讨论和决策的过程,其本身并不产生实际的价值。而真正产生价值的事情有2个,一个是「有形」的,一个是「无形」的。

  • 有形价值:会议产生的决议或行动项被落实,对产品或业务产生了价值;
  • 无形价值:让团队有条理、高效地开会,节省宝贵时间;

会议的目的是为了产生价值,价值是公司存在的意义。

生产「产品」复杂

互联网公司大都以某种「服务」作为价值的交付,每天团队是在通过知识去生产「产品」。信息技术革命让我们从劳动力作为主要生产力,转为知识作为主要主要生产力。而交付的「产品」往往需要不同技术领域和业务领域的知识综合产生的,这就决定了,「产品」的复杂程度较高。

所处环境复杂

当今社会,企业的竞争压力巨大,外部的竞争环境会给企业带来特别强烈的危机感和生存压力。在高压下,如何做出好的产品决策,并执行到位,这需要较为合理的组织架构和管理理念。而对于生产复杂「产品」的企业来说,需要的知识领域越来越多,需要各个专业的知识工作者也越来越多,所以,需要把组织内的知识工作者召集到一起,进行协作和沟通,让大家目标一致。

如何高效开会


从会议的生命周期来看,会议可以分成:「会前」、「会中」、「会后」

会前

会议有几个要素,「主题」「时间」「地点」「参与者」「资料」。

我们应该提前通知与会人上面的这些要素,会前资料非常重要,它是「高效」会议的重点,大家提前阅读资料。在开会时,都已经知晓了会议内容,和要讨论的事情。

在会议开始前,主持人应该提前5分钟达到现场,准好投影等设备,并提醒与会者会议马上开始。

会中

会议开始:首先应该阐明,会议的目的,也就是为什么开,需要达成什么共识或者行动项。

会议持续时间:个人认为应该控制好节奏,人的注意力是有限的,会议的讨论周期不应该特别长,如果需要很长,应该合理安排中间休息。

会后

这个阶段是会议价值的体现特别重要的一步。会议形成的决议,争议项,应该记录好,维护到企业的TODO LIST里面去,形成任务,并且主持人或相关OWNER,应该跟踪任务的进展。如果存在争议项,需要确认争议项在什么条件下,双方在进行讨论解决。

总结


只要公司还在运作,会议就一定会存在,所以,请每个人认真组织会议、认真参加会议,让会议产生真正的价值。

微信关注我,及时接收最新技术文章

我们日常开发面临的问题


  • 紧急修复线上BUG,应该如何拉取代码进行改动,直接在develop或master改吗?
  • 现在团队有好几个并行开发任务,每个上线时间点不一样,而且是不同的小组负责开发,怎么管理并行任务,如何推送正确代码是一个大问题。
  • 每个人对于分支命名不一样,对于命名的理解也千差万别,上线前在发现,分支合并错了。

分支管理的目标


  • 代码提交在应该提交的分支
  • 随时可以切换到线上稳定版本代码
  • 多个版本的开发工作同时进行
  • 明确每个分支的功用,做到对应的分支执行对应的操作
  • 使用 Git 管理版本迭代、紧急线上 bug fix、功能开发等任务

有一份前辈的参考资料


A successful Git branching model
By Vincent Driessen on Tuesday, January 05, 2010

首先这个不是Git或Github的官方资料,只是这位前辈的个人总结,也仅仅是适用当时这位前辈所在的Team的工作模式,并不适用与目前团队的工作模式。所以,在参考Git Flow的资料后,我们制定了自己的团队规范。

我们的规范


feature/sprintXX

  • 作用:新功能迭代开发
  • 部署环境:开发环境 DEV
  • 创建:基于develop分支
  • 是否删除:功能发布后删除
  • 限制:无

test/sprintXX

  • 作用:新功能迭代测试
  • 部署环境:测试环境(FAT)
  • 创建:基于feature分支(每次提测前,feature merge develop代码,feature再合并到test)
  • 是否删除:功能发布后删除
  • 限制:No Push / 开发人员Merge

hotfix/yyyyMMdd

  • 作用:线上问题修复
  • 部署环境:测试环境(FAT)
  • 创建:master分支(修复上线后,合并回master和develop)
  • 是否删除:修复发布后删除
  • 限制:无

develop

  • 作用:包含最新的功能代码,新建feature/sprintXX 分支的基础
  • 限制:No Push / 开发人员Merge

master

  • 作用:稳定代码
  • 部署环境:生产环境(PROD)
  • 限制:No Push / 少部分有权限的可Merge

分支操作规范


feature/sprintXX分支下使用rebase

解决提交路线图清晰问题,git pull默认是merge操作,可以使用如下命令进行rebase

1
2
3
4
5
git pull --rebase

#也可以做全局配置
git config --global pull.rebase true
git config --global branch.autoSetupRebase always

分支合并使用 no-ff

解决fast-forward 合并的路线图问题,这种 merge 的结果就是一条直线,无法明确看到切出一个新的 feature 分支,但是使用 no-ff就可以明显看出新feature分支的合并路线图

1
2
# 合并sprint01 到 develop 分支
git merge --no-ff feature/sprint01
微信关注我,及时接收最新技术文章

为什么需要


  • 降低Review成本,可以明确知道本次提交的改变和影响
  • 规范整个Team的提交习惯,对技术素养的养成有益
  • 可以通过统一工具,抽取规范的message自动形成change log

GitHub Angular Demo


目前Github的Angular项目,就是完全采用规范的Git Message来进行日常的提交管理和发布管理的,下面是这个项目的Commit记录,和自动根据commit生成的change log

遵循什么规范


目前,使用较多的是AngularJS规范

1
2
3
4
5
6
7
# 包括三个部分:Header,Body 和 Footer

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

包括三个字段:type(必需)、scope(可选)和subject(必需)

任何一行都不能超过100个字符

type

用于说明 commit 的类别,类型包含如下几种

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
  • revert: Reverts a previous commit
  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

如果type为feat和fix,则该 commit 将肯定出现在 Change log 之中。其他情况由你决定,要不要放入 Change log。

scope

用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同

subject

subject是 commit 目的的简短描述

Body

Body 部分是对本次 commit 的详细描述,可以分成多行

Footer 部分只用于两种情况

不兼容变动

如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法

关闭问题

如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue。

如:Closes #123, #245, #992

工具约束


我们的目标还是要通过工具生成和约束

Commitizen

commitizen/cz-cli 代替git commit

我们需要借助它提供的 git cz 命令替代我们的 git commit 命令, 帮助我们生成符合规范的 commit message

1
2
3
# 如何安装,在安装之前请先安装npm
# 全局安装 commitizen
npm install commitizen -g

除此之外, 我们还需要为 commitizen 指定一个 Adapter 比如: cz-conventional-changelog (一个符合 Angular团队规范的 preset). 使得 commitizen 按照我们指定的规范帮助我们生成 commit message

1
2
3
4
5
6
7
# 进入到我们项目的根目录

cd your_repo_root_path
# 初始化package.json
npm init --yes
# 为commitizen指定适配器
commitizen init cz-conventional-changelog --save-dev --save-exact

现在我们就可以用git cz去进行提交了

但是问题来了,如果我们此时还用git commit -m “” 去提交,也是允许的,但是这肯定不是我们想要的,因为我们需要对message进行格式限制,所以,我们需要下面的检验插件commitlint + Husky

Commitlint + Husky

commitlint可以帮助我们检查校验提交的message

如果我们提交的不符合指向的规范, 直接拒绝提交

校验 commit message 的最佳方式是结合 git hook, 所以需要配合Husky

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 在我们的项目根目录
npm install --save-dev @commitlint/{config-conventional,cli}
npm install husky --save-dev

# 在package.json尾部加入如下结构
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
}


# 在项目根目录新增文件commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', [
"feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"
]],
'scope-empty': [2, 'never'],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};

现在,我们可以在试试git commit -m “test”看看是否可以正常提交,应该会得到下面的拦截记录

Standard Version

通过以上工具的帮助, 我们的工程 commit message 应该是符合Angular团队那套,这样也便于我们借助standard-version这样的工具, 自动生成 CHANGELOG, 甚至是语义化的版本号(Semantic Version)

1
2
3
4
5
6
7
8
9
10
11
12
13
# 在项目根目录
npm install --save-dev standard-version
# 在scripts结构体中加入执行脚本
{
"scripts": {
"release": "standard-version"
}
}
# 生成changelog
# 第一次生成
npm run release -- --first-release
# 后续生成
npm run release

会在我们项目根目录生成一个CHANGELOG.md文件,如下所示

项目中如何使用


如果我们已经完成了上述操作,会发现我们最终会得到一个package.json,我们只需要把package.json / commitlint.config.js提交版本库即可

把node_modules 和 package-lock.json都加入git忽略文件

下次再新clone项目后,直接在项目根目录运行npm install即可完成上述所有步骤

PS:NPM有时候国外镜像不稳定,可以切换淘宝镜像

1
npm config set registry https://registry.npm.taobao.org
微信关注我,及时接收最新技术文章

目的


首先,我们需要明确为什么要做这件事情。这件事情能给大家带来什么,预期结果又是什么,这里的“大家”主要有3个主体:公司、团队、个人,每个主体对于技术学习与分享这件事件,都有不同的预期结果,下面总结了几点目的:

  • 学习新技术,提升自我,形成技术知识体系
  • 提升专业知识领域的经验
  • 提升沟通和表达能力
  • 学习和分析内容,可以帮助产品技术框架、性能、工具的推进
  • 技术资料的沉淀,形成公司技术价值

如何开始


了解了目的,我们需要想想如何做,才能达成目的。成人的学习、培训是比较难顺利推进,繁重的开发任务和人的惰性,Leader和管理层是否真正关注和帮助大家,这些都是历来公司内部推进技术学习与分享的各种困难,最后很多公司和团队都是不了了之。那么我们怎么做才能避免一些坑呢:

  • 管理层统一思想,技术学习和分享是长期工作,其效果体现需要长期来看和评估
  • 内容的质量,内容不能过浅
  • 明确的分享周期和分享团队,明确分享人和听众的责任
  • 选择内容不能随意,需要针对“听众”的情况,选择感兴趣的内容

如何做


1.分享成员

降低责任分母,如果12人团队,责任分母是12,会因为各种原因,某个人觉得不是我一个人的事情,很难主动分享;把分享做成小组,责任分母变小,可能是2或者3,这样小组内推进,比每个人的自驱动力推进来的靠谱。

我们目前的研发团队组成有3类

  • RD:4人
  • FE:5人
  • QA:3人

以3个小组为单位,进行技术学习和分享活动,按照顺序轮流执行,小组内,可以一次多人分享,也可以一次一人分享。

2.周期确定

周期规则必须明确,这样分享人和听众,都有时间去准备。

分享时间规则

  • 频次:每2周1次(几组轮流)
  • 时间:周四晚上19点15分
  • 时长:60分钟内

分享人准备

  • 发出大纲:提前1周,即分享前一周的周四前发出

听众准备

  • 阅读资料:分享会前1周内,需要把分享资料进行阅读,有分析显示,如果不提前看开会内容,在会议上可能听懂的内容也就20%,为了不浪费自己的生命,也应该分享前去阅读资料

3.内容选择

学习和分享的目的,是为了提高大家的技术水平,扩展大家认知的领域,所以内容选择建议分成2类:技术专题分享、自由主题分享。

如何选择内容

内容的选择,应该因团队情况和产品技术架构情况而异,每个季度进行一次规划,从团队中了解管理、技术弱点、希望提高的方面、产品下一步的技术和框架的要求,针对规划出来的内容,进行内容的选择(也包含培训课程平台的选择,目前选择的是拉勾教育)。

技术专题分享

  • 有针对性提升团队在某一个技术领域的专业技能
  • 可以快速的,有针对性的使用在现有架构和产品中
  • 往往需要由浅入深,进行循序渐进的分享

自由主题分享

  • 拓展认知
  • 内容可以更广,甚至可以邀请相关非技术同学参加
  • 更加要求分享者的表达的逻辑思维,怎么把大家不熟悉的内容,讲明白

针对分享类型,可以有针对性的进行技术专题分享和自由主题分享的交替

Reject Simple

想要分享的内容和形式NB,你就得变的NB
在内容上,我们拒绝特别简单的技术内容,不要分享安装什么什么环境、什么什么入门之类的

4.团队氛围

通过技术学习和分享,提升团队的技术氛围,加强大家的了解,提高凝聚力。

分享会提供一些饮料、好吃的,在一个轻松的氛围下,免费学习知识,肯定有更多的人愿意来参与进来,主动性会增强很多。

总结


除了学习和分享,也希望大家学会感恩

感谢公司可以提供平台给大家进行分享的机会;
感谢分享人利用自己时间,准备PPT;
感谢听众认真聆听,踊跃提问;

怀着一颗感恩的心,你会看到更美好的东西,站在别人的角度思考,会让你走向另一个高度!

微信关注我,及时接收最新技术文章