距离写作《软件开发模式：瀑布与敏捷》已经1年了，在新公司又带了1年新团队，中间陆续有看了一些软件工程的文章，是时候写点总结性的东西了。
我们知道要构建高质量软件，就要解决软件过程中的混乱，将软件开发过程中的沟通、计划、建模、构建和部署等活动有效地组织起来。
而软件过程，就是在软件项目的生命周期内，也就是软件从诞生到结束这期间，在开发与构建系统时要遵循的步骤。
本文内容纯属漫谈，希望对你有所启发。
实用的每日站会和看板
觉得最实用的还是每日站会和任务看板。
每日站会控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报三个问题：
- 你昨天完成了什么任务
- 今天要完成什么目标
- 有什么问题不能解决
每日站会的重要性在于，软件开发细枝末节很多，如果不进行每天盘点，很容易失控。
下面是开发团队里经常发生的问题：
- 代码缺少严苛的审核环节，导致规范失效，给后续的运维带来巨大的成本。
- 某个开发人员所谓的完成在交付测试的时候问题一大堆。
- 前后端开发人员没有按约定开发，沟通也不及时，出现互相等待的无效浪费。
- 产品经理和开发人员互相扯皮，推脱责任，最后不知道听谁的。
- 第一责任人缺失，等验收的时候才发现大家都不知道有这档事，最后延误工期等等。
必须要有严苛的代码审查机制
为什么是严苛而不是严格呢？代码的质量反应了我们的产品质量，产品不稳定、老是出现BUG，直接影响客户满意度和口碑。
同时，代码的好坏决定了未来运维的成本，如果因为一时疏忽和妥协，回头又没有及时修改，中间又出现人员变动，那么这份代码的后患是无穷的。
因为不规范，可读性差，对交接人来说从心态上是本能反抗的，但是又不得不改，于是就一通乱改，能贴膏药就贴膏药，能运行就可以，管他规范不规范。这样导致的后果是，代码从不规范走向更加不规范，很难想象经过5-10年持之以恒的不规范，这个产品还能活着。
技术债务的危害怎么形容都不为过，轻则系统局部异常，中等的会导致修改困难，严重的需要推翻重来。
从物理学上看，熵让我们理解了一件事，如果不施加外力影响，事物永远向着更混乱的状态发展，所以规范就显得弥足珍贵了（代码规范值钱吗？）
从软件设计看，软件设计要关注长期变化，需要应对需求规模的膨胀。如果腐烂的代码日积月累，这些在不断流变的东西可能还没你的软件生命周期长，又怎能支撑起长期的变化呢！
做产品，不严苛不足以长久。
开发人员要有产品经理的思维
开发人员习惯性陷入实现的细枝末节和局部思维，建议开发人员在开发之前，先不要去想如何实现。应该先问自己：
- 这个功能对用户有什么价值？
- 能为公司创造价值吗？
如果以上问题都是否定的，开发人员可以和产品经理理直气壮的辩论甚至说NO。然而，现实当中，很多新手程序员接收到指令后，不管三七二十一，埋头就敲代码，这是很普遍的，因为有个很好的说辞是：又不是我去调研的，我怎么知道客户想要什么，再说了需求不对那是产品经理的锅，反正和我没关系。
这种意识非常危险，因为产品经理也会有遗漏，一旦缺少合理质疑，等到开发完成，交付使用的时候被客户否定了，那么，失去的不仅仅是时间和金钱的成本，还有团队的战斗力和凝聚力，信任感，开发人员应该要有主人翁意识。
线上事故回溯讨论会
为了解决配合不积极和甩锅的问题，可以考虑引入了线上事故回溯讨论会，每两周一次，对发生的事故进行讨论，重在根因分析和以后如何避免，并事前强调目的不是追责。
因为，每个故障分析都能暴露出藏在深处的问题，对提高产品质量和团队间的信任效果都很好。
强调开发人员的主人翁意识
在团队中，不同的角色对主人翁的理解从上往下，是逐级弱化的。
我觉得主人翁意识是一个被低估的褒义词，这个词浑身上下充满了正能量，需要在团队里不断的宣讲，甚至写成口号挂在墙上。
- 有主人翁意识的人通常做事一丝不苟，不轻易妥协，有工匠精神。
- 有主人翁意识的人，自我驱动能力都相对比较好，有事主动承担，不叫苦，也不喊累，因为对自己负责，所以能力一般也不会太差。
- 有主人翁意识的人，做事相对努力上进，人品也容易获得肯定。
- 有主人翁意识的人，团队的漏洞和危机更容易避免，团队成员配合默契，无需繁重的章程和规定，效率杠杆。
- 有主人翁意识的人，通常会更愿意帮助别人，见到别人文档写不完，一声不吭就给你无私的支援。
- 有主人翁意识的人，公司的事就是自家的事，甚至要比自己的事更加负责任，因为自己出错大不了一个人承担，公司的事影响的是一群客户。
- 有主人翁意识的人，更容易受到同事的尊重。因为和这种同事搭档，实在太轻松了。
- 有主人翁意识的人，集体意识好，愿意承担责任，凡事主动汇报，不用每次过问：“你任务完成得怎样了云云”。
- 有主人翁意识的人，因为对自己负责，所以更多意愿自省，更多意愿自驱，执行力不差，更容易拿到结果。
当负责人是有这种意识，整个团队自热而然会慢慢养成这种意识。
不要把重心放在研发流程本身
市面上讲开发模式和流程的文章很多，不管研发流程多先进，是否出自大厂，我觉得都应该问自己团队几个问题：
- 这个开发模式适合当前的团队规模吗？
- 为什么我们要采用这个开发模式？
- 我们当前流程出了哪些问题？
- 哪些流程影响开发和交付效率？
- 当前的流程最致命的问题是什么？
- 我们真的有必要修改当前的流程吗？
只有找到当前团队的症状和问题，才能有的放矢，对症下药，否则很容易陷入教条主义，为了流程而流程。比如某某大厂都这么搞，我们也要这么做；某个专家这么说，我们也要这么做。如果只是简单照搬业界研发实践的话，效果往往不好，有时甚至会造成负面效果。
流程规范过多，其实并不见得是好事，增加一条规范可能要考虑删除一条，否则规范会变成枷锁和负担。
不仅仅是每日站会
站会虽然重要，但由于时间有限，并不能深刻的挖掘出那些深沉次的问题。所以不仅仅是每日站会的盘点，每个月应该都要有一份系统性的反思，从软件工程的系统层面来反思，比如需求调研，产品设计，软件设计，开发测试，实施运维等环节来深入剖析和总结。可参考愚文《关于盘点和总结的那点事儿》
不能仅仅是模式和流程
行文最后，我想泼一盆冷水：有了完美的开发模式和流程，你可能依然无法真正做好软件开发。
因为我们知道软件工程从大的方面包括过程、方法、工具。瀑布和敏捷只不过是过程里的两个重要的模式，如果没有方法和工具，整个软件工程建设还是有问题的。
- 比如需求分析人员经验欠缺，或者调研有偏差，那么就会把团队往坑里带；
- 如果系统架构和设计有缺陷，那么后期可能无法能力复用，扩展困难，性能和稳定性会打折扣；
- 如果测试不专业，那么产品质量就无法保证；
- 不善于使用工具，沟通和效率可能会打折扣；
- 如果不采用自动化，代码人工合并、编译和发布，那就回到传统低效的开发模式了。
未完待续
如何破解研发效率之道，要聊的内容实在太多了，除了软件工程，可能还要研发效能、OKR、中国式管理等等，接下来会从系统的角度，结合平时踩过的坑，在学中记录，在记录中实践再总结的方式，写一个专栏，敬请期待……