敏捷基础之质量内建

质量内建：产品一旦被发布之后就有了好坏之分，通过某些检验方式已经无法提高或保证它的质量，所以质量检验必须内置在产品或服务构建的过程中，而不能在它发布之后。
总而言之，质量内建必须是在产品或服务构建的过程中的， 而不是发布之后的。

非质量内建的一些质量维护措施

监控报警

通过监控项目的日志， 数据库， 运行系统的运行情况，当发生错误（错误日志），cpu或内存 负载过高，发生了数据库慢查询 等等， 通过监控系统发出报警， 显示对应的报表。 开发再根据对应的时间点， 事后进行处理修复完善。

代码回顾，日常的优秀代码show

有些公司会在代码发布后， 或者是 固定一段时间，让开发人员把自己认为好的代码， 认为不好的代码， 进行回顾讨论，期望能通过讨论提高开发人员的代码能力， 间接提高项目质量。

测试人员测试

测试人员测试 不属于质量内建。 一般测试发生于产品构建之后， 测试人员再进行对应的功能的测试。测试出结果， 开发修复，修复完再测试， 可以说无限循环。

质量内建措施

上面这些居然都不是质量内建， 那么质量内建要怎么做呢？

单元测试

单元测试，单元测试是开发人员自我保证代码质量最好的方式， 假设你是一名开发人员， 开发了一个功能， 只是简单的进行调用测试，然后就丢给测试人员。测试完再修复bug， 有bug就继续修复，一直持续。 假设你现在是这个状态， 你应该想到为什么总是很多漏洞，怎样才能交付给测试人员一个质量比较有保证的版本，而不是依靠测试人员测试，返工修复。

做IT行业的都知道单元测试， 每个人都知道说有单元测试会保证质量，但是很多团队就是无法实施下去，“单元测试” 在他们看来就是一项耗时间，维护困难，没有太大意义的上级要求做的麻烦事情。 然而并不是， 在业界对单元测试已经发展了很久， 为了解决 单元测试 的一系列困难， 整个单元测试 框架 也不断的进化， 更加简单， 更加快速， 更加容易维护。睁眼看世界，多看看行业的变化。

后端单元测试可以看看这篇，
前端单元测试可以参考这个工具

代码扫描

使用代码扫描工具（Sonar， checkMark）进行代码扫描，在开发过程中， 分析有问题的代码， 并立即修复， 无须等到测试才发现。

Git Hook集成

通过对git hook(husky)集成单元测试， 代码扫描工具， 在push到远程代码仓库之前，进行对应的代码检测，单元测试，单元测试覆盖率到达标准， 确保提交到远程的代码质量， 不达标，不予提交。

Pull Request 代码Review

对每一个所做的修改， 都使用pull request进行管理， 可以参照Git工作流，每个pull request都全团队进行代码review， 建议在每日早会之后， 开发人员进行代码昨天提交的pr的代码review。

总结

以上就是 敏捷中质量内建的一些方式，也是业界比较常见的做法， 可以再发散一下， 是否有其他方式，可以在产品 开发或构建 过程中，提高产品质量。 希望大家可以能够更好的实施敏捷！

敏捷之自驱力

聊聊敏捷的自驱力， 很多团队使用了敏捷进行管理， 但是在跑了一段时间后， 很多管理人员反应， 敏捷就是个噱头，团队工作并没有得到改善，反而变得更加糟糕。 是的， 糟糕！！团队成员为了每个sprint的需求， 疲于奔命， 后面的需求又来了。团队自驱力也没有提高， 还是处于任务式的被动接受。 这个sprint有需求安排下来就开发。以上都是没有认识到敏捷到底是要达到什么样的目的。

敏捷的目的

“团队的自组织，团队成员的自驱动”。 敏捷的目的归根到底是这一句话， 所有敏捷所做的事， sprint，回顾会议，OKR， 都是为了上面的目的服务而做的。 要清晰的认识到这一点， 才能够较好的实施敏捷。 说一说看到的问题

没有让团队成员主动思考

很多管理人员说，
“我已经按照敏捷的流程，安排了整个项目的流程，团队成员没有自驱力，我也没办法，有些人就是这样”。
非常错误的想法。 执着于流程，但是没有认识到 管理也是对人的管理.

“对人管理， 有啊，我经常和他们说： 这是你的项目，你要对项目负责。让他们意识到要对项目负责， 要求他们进行分享，要求他们进行总结”。
可以看到这种说法的管理人员还是处于 “下发任务式， 主动要求式的管理” ， 这种管理方式不能说错，但是在敏捷中，不应该用“你要， 你去， 你做” 这种下发任务式，命令式的形式，让团队成员去做事。 那么应该怎么做呢？
是的， 让团队成员自己思考自己做什么。但是怎么让成员主动思考呢？

1. 在入职，one onne review 等沟通中， 和团队成员灌输， “我不会告诉你要做什么，你告诉我 你想做什么， 你能做什么， 展示你的工作成果给我看” ， “想一下 自己能做什么，怎么展示自己的工作成果” ， 让团队成员主动思考自己能做什么。
2. Sprint的制定， 让团队成员一起讨论， 这个Sprint他们想做什么，在保证项目进度基础上， 加上成员自身思考得出的任务：Devops相关， 学习相关，优化 等等。
3. OKR的制定，在团队OKR的基础上， 让团队成员自己确定自己的OKR要做什么，可以给一些建议，但是要让团队成员自己思考， 自己做什么。
4. 回顾会议，复盘。 是一个很好的团队思考的方式，在会议上，让整个团队一起思考， 团队现在缺少了什么东西， 什么做得好，什么做得不好，接下来要怎么做。团队的事要团队成员一起思考，不是由管理人员一个人决定。

总结

管理人员需要认识到敏捷的目的：“团队的自组织，团队成员的自驱动”。 所有的流程，方式都是为了达到这个目的而做的。行动起来就会游刃有余。

IT项目的工程化， 流水化

IT的工程化

标准化， 自动化，低代码，快速无缝衔接

哪些项目适合工程化生产

广告营销类（推广小游戏，推广页面）

标准化

项目的标准化

业务人员的标准化
统一的项目流程，话术，过程产出物，交付物，合同, 上线后相关跟踪（数据反馈）。

流程的标准化，简略化
部署，上线，下线，快速迭代

开发人员的标准化
统一的开发框架，复杂的内容交给第三方（动画交给UI人员），只做简单的应用开发

统一的开发框架

后端开发框架

基础功能

基础的web项目后端功能封装， 数据库事务

可靠性，稳定性

监控报警
单元测试
文档（前后端，客户）

快速开发

根据模板 自动生成新项目
自动生成文档
数据库表自动生成增删改查管理后台
单元测试框架自动生成

集成

CI/CD 部署集成

前端开发框架

api自动生成

根据后端接口文档 或后端提供一个接口(生成前端请求api文件) , 生成前端请求对应的api文件

测试

jmeter接口测试文件自动生成

后端提供对应接口,生成jmeter接口测试配置文件, 测试人员直接导入到jmeter就可以进行测试

集成，统一的部署流程

集成
项目集成docker, CICD pipline(github, gitlab), git hook关联，提交代码到仓库自动触发部署行为。无需人员进行配置。　生成对应的链接

What

By using docker , we can easy deploy the application. but how we control the deploy version and how can we rollback to last version if any error occur?

There is the solution we explore in development.

How

To control which version docker image need to deploy to prod. we need to defined the target ‘sign’ for our docker image, something like: “master”, “prod”.

To rollback to the image we want. all image need to have a ‘sign’ for rollback , something like: “2021-01-01 10:00:00 - asdffe”, “release date + commit id”.

so we need to push two image to docker repo: master image and release date + commit id image.

master image will overwrite old image all the time. the release date + commit id image will be saved in repo for rollback

Code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

TAG = date + commit id

REGISTRY=your registry

NAME=image name

PROD_TAG = master

UAT_TAG = uat


## build prod

# build image

docker build -t ${REGISTRY}/${NAME}:${TAG} .

# create image with PROD_TAG` `for`  `PROD RELEASE

docker tag ${REGISTRY}/${NAME}:${TAG} ${REGISTRY}/${NAME}:${PROD_TAG}

docker push ${REGISTRY}/${NAME}:${TAG} && docker push ${REGISTRY}/${NAME}:${PROD_TAG}

## build UAT

docker build -t ${REGISTRY}/${NAME}:${TAG} .

docker tag ${REGISTRY}/${NAME}:${TAG} ${REGISTRY}/${NAME}:${UAT_TAG}

docker push ${REGISTRY}/${NAME}:${TAG} && docker push ${REGISTRY}/${NAME}:${UAT_TAG}

Problem we meet

• teambuild效果不明显
• teambuild活动目的不清晰，teambuild活动到底是想达到什么效果？
• 团队成员参与度不足， 被动参加，置身事外
• teambuild形式单一，没有创新（一般都是吃饭）

For What

为了解决上面的问题， 通过轮流举办teambuild的形式，加强团队凝聚力，提高团队成员参与度， 构建积极参与的团队文化氛围。

Whom

团队所有成员，每次的团建活动按照姓名排序，轮流三个人进行teambuild活动组织安排。通过轮流的形式，提高团队成员对teambuild的参与度，引入更多思考变量。

举例：
Alex， Adam，Benjamin， Freddie，Remox，Sura

如上面的，第一季度由Alex， Adam，Benjamin进行teambuild活动组织安排。第二季度由Freddie，Remox，Sura组织安排

When

每个季度最后一个月进行teambuild活动
1-3 3月
4-6 6月
7-9 9月
10-12 12月

需要在每季度的第二个月发出活动计划，进行计划的投票，人员的安排。
1-3 2月
4-6 5月
7-9 8月
10-12 11月

How

计划

首先，不同的teambuild活动，要达到的目的可以是不一样的。
例如：

• 前一阵子团队全部人员加班加点帮忙赶计划， 所以想让大家能够比较好的休息，放松一下。 所以安排了放松的teambuild： 温泉， 按摩 等

• 发现大家之间除了日常工作，没有其他交流， 所以安排了团队交流，协作相关的活动：对抗赛，CS，王者荣耀线上比赛。

• 疫情期间，大家运动不足，交流也比较少，所以安排了能让大家进行运动，又可以促进大家交流的活动： 每日步数比赛。

所以针对不同时期，不同团队的teambuild，需要每个季度轮到的同学，首先考虑一下，这个teambuild要达到的目的。再根据目的进行计划。

计划落实

确定了大概的计划，需要去了解对应的信息，价格，人数限制，时间限制，天气。
建议是至少包含两个计划，
计划一是可以用公司teambuild基金覆盖的，基础的活动。 计划二是更上一层的，需要大家再加点钱的。

和团队其他成员沟通，投票，确认要进行哪个teambuild活动。 确认人数。 确定teambuild时间

活动进行时

1. 确保 提前和所有成员分享了活动注意事项： 时间，地点，安全事项 等等。
2. 携带对应的安全保障设备,如：药箱
3. 确保所有人员都平安归来
4. 其他…

绩效评估的作用

绩效是衡量一个人或团队的工作效果的指标，通过绩效可以清晰比较到公司各个人员的情况，再根据绩效进行相应的处理，奖励或者鼓励或者惩罚。如果没有绩效，公司将失去活力，没有发展。

评估绩效的几种方式

基于360度的综合考核

360度综合考核，多视角考核，考核者被上级，下级，同级，合作者，外部考核者（供应商和客户等）等 匿名 进行考核。
考核一般使用调查问卷形式，市面上有提供360度绩效考核问卷的公司。
考核者的多角化，有助于 考核 被考核者在不同的合作关系中的表现。 显示出隐藏的问题。
也对鼓励考核者进行多元化，全方位发展有所帮助。

建议：中高层绩效管理

缺点：

耗费人力，时间较多。

侧重综合考核，定量考核较少，定性考核较多。
例如考核 您觉得和被考核者一起合作，满意度多少？1-10分。 这种比较定性的，不是定量的考核，存在一定的主观判断。

因部门的岗位数量，岗位性质不同，会产生一定不公平。
如技术部门和商务部门，同样考核第三方对他的一个沟通流畅程度。可能技术部门或有所欠缺。需要再根据部门进行对比。

基于KPI，OKR的绩效考核

KPI：关键绩效指标
OKR：目标与关键成功法
通过KPI，OKR指标进行考核，考核内容明确，有利于被考核者与公司形成共识，容易被接受。

建议：低中高层绩效管理

缺点

有可能导致机械化的考核。
如 完成KPI指标就完成了绩效。其他不管了。没有考虑其他的人为因素，弹性因素（如家人生病，导致无法完成）。

基于BSC的绩效考核

BSC：Balanced Score Card， 平衡计分卡，通过对 财务（Financial）、客户（Customer）、内部运营（Internal Business Processes）、学习与成长（Learning and Growth）四个方面进行考核评估，得出绩效。

建议：中高层绩效管理

基于目标的绩效考核

通过制定目标，通过目标是否达成来衡量绩效。

缺点：目标的制订存在异议，怎样的目标才是符合考核的？
与基于KPI的绩效考核类似，容易忽略其他因素

建议：低中高层绩效管理

绩效积分奖励制

绩效积分奖励制, 对员工绩效实行积分，绩效积分形成“福利购买力”，在购买力达到一定水平后，员工可以凭借获得的购买力获取企业提供的弹性福利。

建议： 低层绩效管理

适合企业的就是最好的，没有完美的方式，需要在企业管理制度的基础上，进行评估使用哪种绩效制度