闭环设计

最近整理了一段工作内容,往事不断的浮现在脑海里,感觉一直忙忙碌碌的吃老本，经验能力却没什么提升；

什么是经验，应该将过去的经历总结成方法，经过1,2,3次的验证且符合预定的期望的这才是经验；

越是碎片化的越是获取不到太多的积累，回过头来仔细想想为什么会这样，其实就是关键的闭环设计与执行的偏差；

因为手里的事情较多，很多经历都在做方向性的东西，最近关注的产品研发变得少；导致现在的产品研发只做了4个环节，甚至有的只做了2，3个环节，问题开始暴露，研发效能，人员成长，团队稳定，产品质量都在走低。

4个常做环节

以产品研发为例子，一般只会做1，4，5，7这4个环节。开个需求会，研发，测试，上线之后完事；造成这种原因有很多：项目紧，任务重，来不及，流程多了研发慢了，理由是客观的，事实也是如此。

3个问题

只做4个环节，这种现象象有持续下去会导致3个很严重的问题产生：

1团队问题：人员不稳定，心态崩溃得不到成长，看不到发展前景；

2产品的问题：迭代速度越来越慢，bug越来越多；

3代码问题：代码质量越来越差，无效的，鸡肋的code一大堆，谁也不愿意接别人的代码，动不动就提重构；

客观环境

土匪有土匪的打法，国军有国军的打法，我党有我当的打法；很多团队会觉得迫于客观环境必须做减法。我觉得这是非常正常的。项目初期就预估了只存活1年左右的无所谓，干就完了，先满足用户搞到钱再说；但是我经历的项目里面90%项目都是打算活2,3年的或者已经活了2,3年的。

接下来讲讲缺失的4个环节的作用和如何做

1、复盘

大部分的复盘是在这个版本上线后，组个会拉上相关人员，一起讲讲总结总结优点，缺点，待改进的，需要避免的，表扬表扬某某某，完了发个会议纪要，散会；然后接着下一个版本研发，有意义吗？有，但是过几天就忘了,流于形式。

复盘的目的是什么，是要继承好的方法，形成方法论利用制度流程来传承下去；好的方法必然是会对团队的效能是有帮助的，这才是要达到的目的。

那应该怎么做呢？

1、会议纪要要连贯：连贯的意思是，上一次版本的复盘总结必须通过一个地方能连贯的阅读，用于看多少做到了，那些没做到；

2、总结1,2个方法：总结1,2个方法，不要多了，多了执行不会短期出成果；

3、验证方法：一定要验证但是要快速验证，有时候理想是很美好的，但是执行起来效果并不一定如预期；

4、完善制度流程：将验证过的方法制度加入现有的制度流程中；

2、代码review

代码review在技术氛围不浓烈的团队里面做的其实是非常少的，除非有个带头大哥，这个带头大哥要有比较强的上技术实力且获得大家的认可，然后他去组织，否则review的人员不会有太多的收获，最终对研发质量和人员提升没有帮助。

其实任何技术经验的人都能组个团队进行代码的review，但是我们要的是代码review要有实际的价值，而不是为了做而做。

做的目的？

做代码review目的是人员技术的提升，质量问题发现前置，增加团队容错性（例如有人请假了还有人能顶上去）。

怎么做？

1、技术说明

找现成的插件扫描；还有设计模式，编码习惯，语法特性使用；坏味道代码的捕捉；设计原则的遵循如ocp,lsp,dip,srp,isp等;

有个现实的问题，团队中可能没有人有上面的那些能力怎么办？

边学边招聘，但招聘是远水解不了近渴；只有学，让某一个人专攻某一个块去学，代码review的时候他负责捕捉他熟悉的领域，发挥团队的力量；

2、业务说明

还有一部分我们经常忽略业务的说明。比如有些评审我们会无感评审，也就是脱离业务只评审代码，我们经常说我们是一个团队的在做一个项目，他懂我做的东西，我的代码即业务说明，但是有些同学理解真做不到！但是如果有业务讲解环节，将会对评审效果带来大大的帮助。

uml，接口设计，表设计，类结构图，用户故事图；只要能说明业务的一切都行，这个时候你需要拿出下面第4点说的“技术设计与评审相关文件”。建议不要口述，口述复杂业务的时候对人的理解程度是个挑战。

3、用例设计与评审

有一种现象值得警惕，测试人员发起用例评审，参加的人有研发同学，产品同学；由大家评估一起评估用例，但是在会议中大家对用例都提不出问题或者都不关心用例是否已经有效覆盖到版本中的大部分产品内容。

用例设计与评审我相信团队都会做，但是用例发挥了多少作用，评估的比较少。按照只开会不总结的方式做下去最后他只会变成流程的某一个环节而已，象征性意义更大。

那应该怎么做呢？

1、用户故事地图

利用用户故事地图来描述整体的产品业务逻辑，在会议中阐释此次版本的内容涉及到故事点和背景要交代清楚；

2、单元用例和关联用例要分开

单元用例：研发的内容都是分模块按功能按接口来实现的，每一个方法都会对应上对应的研发的单元测试；那么测试用例应该也是要覆盖到研发同学写的测试用例，这部分要单独来说，并且征求研发同学的意见是否已经全部覆盖到了；

关联用例：单元测试通过并不代表整个流程通畅，因此需要关联用例来阐述；这个如果能利用到用户故事地图，讲解要测试的功能和流程，那是相当有效的；这个着重征求产品同学的意见，询问是否覆盖到了产品功能；

3、用例bug和非用例bug要分开

写的用例应该要记录到管理工具中，然后发现的bug应该要跟用例关联；例如：总共发现10个bug，能跟用例关联的bug是2个，不能关联的bug是8个；我们可以设计一个标准公式：4：1 也就是4个用例bug可以出现一个1个非用例bug；

上面例子中我们现在能跟用例关联的bug是2个和不能关联的bug是8个，那么比率是1:4跟我们的标准4:1完全不符合；说明用例质量很差，无法提高产品质量。

2、评估分

我们都知道线上出了问题，最先想到的人是运维，问运维为什么有bug还有上线，然后运维说我看到测试报告写的通过我才上的；然后找到测试，这个时候一般都会有些理由，有的合理，有的不合理，继续追溯效果也不太好，大不了各打三十大板；其实追溯的目的不应该是为了找人背锅，而应该聚焦如何防止再次发生。那测试怎么办？

1、测试要做的是加强团队成员的贡献度和责任心：

研发评估用例并给出分数：研发人员评估用例是否已经覆盖到他所写的代码的功能点，并给出具体的分数，比如说80分，就代表基本覆盖，60分就代表用例不完善；

产品评估用例并给出分数： 产品同学评估此次用例是否覆盖到了整体的产品功能和产品流程，并给出具体的分数；

4、技术设计与评审

技术设计的种类比较多，概要设计，数据库设计，uml设计，类结构图设计，逻辑设计，接口设计等等

有一种现象就是技术的设计文件只对编撰人有帮助，对团队其他人员起不到什么大用；因为在落地的时候，大部分人会根据自己的思维逻辑来完成；会议中作者更多的是在讲解整个文档，少了沟通询问环节比如：他人明白这个需求的复杂度在哪里么？我设计的缺陷性在哪？他人有没有更好的办法？我们更多的应该是沟通比这个更有效的方案，这样才有火花；

设计和评审的环节更多的是思维逻辑,技术和经验的碰撞，还有一个很重要的点我们没做过就是设计回顾。

比如我项目上线之后或者在review阶段环节，有没有把文档来拿出来比对看看，看具体的落地代码是不是跟之前的一致；偏差率是多少，为什么会偏差？把这件事持续做了后是非常非常有效果的，对整个团队技术能力和整体把控能力都会有质的提升。

产品的质量和效能取决于研发，产品，测试，研发，项目，是一个整体的事情；我们努力一大步，效果可能只是一小步；不要担心这是正常现象。

持续去做闭环设计与执行是能在短期内看到效果的，同时对个人成长更是巨大。