为什么要总结

行有不得，反求诸己。 —— 出自《孟子》

学会从自身寻找原因，可以帮助我们成为更好的人。

其实，无论是个人还是团队，在年底进行一些有针对性的总结（建议是数据化呈现），对于找到自身问题，提高和改进，还是有挺大帮助的。

切忌，不是为了总结而总结。应该学会从客观的事实（数据化是个不错的手段），寻找问题的发生原因，从而尝试做改变，去改善问题。

准备工作

💡 思考的框架 优于 思考的内容

避免流水账

作为研发Leader，在做总结时，我会首先避免流水账，不要先思考这1年来，我们做了什么，这样很容易陷入到细节中。

思考：我们需要什么样子的团队

小时候，经常被问到，你想成为什么样的人。其实，管理团队也是一样的逻辑，先思考「我们需要什么样的团队」。在2021年初，我们团队定下的指导思想是「成为专业的团队」，所以，在接下来的1年时间里，我们都在遵循这个指导思想。

建设团队的指导思想

抽象团队的工作分类

我的思路

做了什么

建议按照工作分类进行重点事项的陈述

做到了什么，没做到什么

从做的事情，客观的数据反馈，和年初的目标，进行综合对比，进行分析，找到问题原因，为来年提供改善思路

分享自己或团队其他人的做事心得（方法）

意在提高团队认知，授人以鱼不如授人以渔

我的2021总结（部分）

做了什么

• Iteration 迭代
  
  
  

• Arch 架构

  • Backend
    • 涉及内容较敏感
  • Frontend
    • 涉及内容较敏感

• Assets 技术资产

  • 工具
    
  • 服务器和环境
    
  • 代码规划&设计
    • 涉及内容较敏感

• 团队

  • 架构
    • 涉及内容较敏感
  • 激励
    • 涉及内容较敏感
  • 活动
    • 涉及内容较敏感

做到了什么，没做到什么

• 涉及内容较敏感

分享自己或团队其他人的做事心得（方法）

为什么要数据化

用事实说话

通过数据的客观事实反应团队的协同效果和成果的产出质量，是从另外一个客观视角去挖掘问题的一种方式。尽量不要用「我觉得」、「我认为」这些主观臆断方式，进行复杂问题的评价。

角色多样、配合复杂

一个迭代，往往涉及到很多角色。所以，这些角色的行为和成果，对于「迭代质量」都会产生各种变化，这些变化往往是复杂的。所以，也需要从数据的层面，收集各个维度的客观事实，综合地评价「迭代质量」。

迭代也要迭代

产品的优化、迭代，是不断持续完善的。企业和产品的不同阶段，针对质量的要求其实也是完全不一样的。著名的项目管理三角形，其实就是权衡的过程，时间、成本、范围，最终都会影响质量的高低，只不过看某些阶段，我们更看重什么。在企业、产品不断的发展过程中，我们需要从各个方面收集数据，从不同维度持续分析「迭代质量」，以便于帮助我们在当前环境下，进行取舍，从而达到我们的产品目标。

如何数据化

在我们团队内部，采用了一个标准来评价迭代的质量，即「迭代质量评价标准」，其组成如下

迭代质量评价标准组成

4个维度 + 1个分值

• 4个维度
  • PM改动需求（30%）
  • User Story交付延期情况（10%）
  • User Story冒烟测试情况（20%）
  • Bug（40%）
• 1个分值
  • 迭代质量分值

维度	占比	分值	计算规则	例子
PM改动需求（PRD定稿后）	30%	10		Delay 0.5天，减1分，该项得分为：(10 - 1) * 0.3 = 2.7
User Story交付测试延期	10%	10		Delay 1天，减2分，该项得分为：(10 - 2) * 0.1 = 0.8
User Story冒烟测试通过情况	20%	10	通过测试的故事数 / 故事总数 * 2	共5个User Story，通过了3个，3 / 5 = 0.6 * 2 = 1.2
Bug（n = Bug总数 / 总故事点）	40%	10		共30个Bug，6个User Story，30 / 6 = 5，在5<=n<6区间内，得5分，再乘以40%，5 * 0.4 = 2

举个栗子

上面是我的团队，近期的一组迭代数据，背景交代

• 故事点：1个故事点 = 1人天
• 迭代流程：按故事开发和测试 → 整体回顾测试 → PM&UI验收 → 发布 → 复盘

迭代数据化能带给团队什么

• 团队为迭代负责
  • 通过数据化呈现迭代质量，让团队以一种理性的方式，审视迭代问题，从而找到解决方案，伙伴的目标是一致的：让迭代更好
• 让「问题」透明化
• 为改进团队迭代效能提供了坚实的数据基础（任何改变都能从数据层面找到体现）

想做还没做的事情

通过打通我们使用的各个敏捷工具，自动化收集迭代数据，产生「迭代质量分值」，并可以针对历史数据进行各自维度对比，从而更好的提高效率。

敏捷迭代为什么升级

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

一切从需求开始

需求源分类

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

目前，我们团队开启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 人/天）

估算流程

参与者

• 推动：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