敏捷开发应用不当带来的碎片化问题

我是一名软件从业人员，写了很多年的代码

公司是职能型组织架构，一个产品线有测试组、项目管理组、架构管理组、产品管理组等，我们采用敏捷开发方式，但应用上存在一些问题，让我们从两个故事讲起

两个故事

故事1. 监控告警一次生产环境扩容过程

如上图所示，随着集群和集群内宿主机数量逐渐增加，监控数据采集压力变大，监控团队新采购了一批高性能服务器，对prometheus进行扩容，每台服务器都有公网IP，需要将新采购服务器IP添加到集群白名单内允许其访问采集监控数据

第一次升级

1. 经过研发团队评估，需要在图中3（ingress）的位置修改白名单；
2. 运维人员准备部署脚本
3. 全网升级
4. 升级验证，发现很多targets down

第二次升级

反馈研发团队分析，原因是2（宿主机）的白名单未修改，由运维人员手动调整宿主机白名单，target down数量在减少，但仍然存在部分target down

第三次升级

经运维人员分析，是1（交换机）白名单未放通，整理了有问题的集群列表，邮件知会交换机管理员放通，很久没有回复，又一次例行巡检时发现上述target down未修复，再微信联系收到回复并响应处理，处理完成后验证发现，仍然有部分target down情况，两相对比，发现通过升级前的target down数量多余升级后的，判定升级完成

故事2. xx能力评估

为了完善产品能力和提升产品在业界的影响力，我们报名参加了由中国信息通信研究院组织一年几度的xx能力评估。对标准进行初步评估后，包括我在内，初始投入人力3人，预计一个月完成

本次报名参加三项评估，我把它们分成两类：

• 边缘信任能力评估（总计1项评估）
• 容器类能力评估（性能、全栈两项评估）

分别由另外两名同事负责，工作量原因，除了与中国信息通信研究院对接、资源协调和整体进度推进外，我加入容器类能力评估

两位同事的做事方法截然不同：

• 同事A（负责边缘信任能力评估）：忙于其他事情，一周后投入，根据标准文档将任务进行拆分，因为对产品不熟悉，所以需要将任务分配给另外的8个人，占用2~3天时间，总计投入10人
• 同事B（负责容器类能力评估）：需要有人提供环境进行测试，环境提供后，没有引入其他人力。在环境准备方面，也遇到了一些问题：
  • 需要大量的服务器：总计需要近300台服务器，经过多次协调资源到位
  • 环境部署被切割为多个步骤，每个步骤负责人不同，部署一套环境需要4个人逐步执行动作才能完成，而该能力评估会对环境造成破坏性，需要反复多次部署环境，整个评估过程不下20次重装环境
  • 环境部署脚本性能差，部署耗时长，100节点时耗时已经超过10分钟

一些问题

简单的两个故事，将问题暴露无遗，我的总结如下：

1. 交付不完整，产品不可用，用户体验极差，无端耗费人力和时间；我们看看故事1：
   1. 很简单的一次扩容，升级前后时间跨度一个月之久，至少5个人参与其中；
   2. 完整数据路径包括：ingress、宿主机、交换机，任何一点白名单未放通都会导致无法访问，研发和运维人员没有完整的数据路径视野，不能在方案设计阶段识别所有需要修改的点，等到升级到生产环境才发现问题；
   3. 升级完成后，功能不可用，用户体验极差；
2. 造轮子，不用轮子，开发人员只负责开发分到手里的特性，不管用户是如何使用我们的产品；我们看看故事2中的同事A：
   1. 将边缘信任能力按照产品能力划分为多个部分（裸金属、虚拟机、容器、函数、镜像等），只熟悉其中很少的产品，之前未使用过其他产品，现在也没有使用其他产品的“冲动”，这是从个人层面讲的；
   2. 从团队的层面，一件不到1人月的事情需要10来个人配合才能完成，战斗力可想而知；
3. 会很多东西，却一件事也做不成，这个可以看看故事2里环境部署的例子：
   1. 一套环境被拆成了系统初始化、基础组件部署、应用部署、高可用改造，我赞成在生产环境中的权限分割，每人负责一部分，但这只是权限上的分隔，不应该是能力上的分隔；你可以让ABCD四个人分别负责前述四项工作，但A不应该只会系统初始化、B不应该只会基础组件部署，而应该是ABCD都熟悉系统初始化、基础组件部署、应用部署、HA四项工作。如果一个团队4个人，一人擅长100米短跑，一人擅长110米跨栏，一人擅长4000米中长跑，一人擅长马拉松，你一定会觉得这很OK；但如果一个团队四个人，一人擅长起跑，一人擅长跨栏，一人擅长加速，一人擅长冲线，这是怎样的一种场景呢？需要将这个四个人整合起来才能完成一个跑步项目，拆开来每个人都没用；
   2. 从个人层面来说，一件事绝不只是系统初始化这么简单，一定是多个步骤组合的，需要都掌握了才能做成这件事；
   3. 从团队层面来说，团队战斗力弱，稳定性不够。

怎么解决这些问题

上面说了这么多问题，我们应该怎么解决呢？

对个人而言：

1. 交付的完整性。从本文谈到的白名单变更，到开发中的其他特性，再到其他行业工作的其他任务，人生的种种，我们一定要思考事情的完整性，完整性不等于什么都自己做，只需要清楚的知道来龙去脉并做好自己负责的部分，这让我想到几个词：
   1. 一专多能：某方面的能力特别强，其他方面至少也是熟练程度，如果需要，可以随时替补完成相关工作；
   2. 端到端：从开始端到结束端，对于软件行业，开始端是客户需求，结束端是使用产品的用户，我们应该了解客户为什么会提出这样的需求、我们如何分析需求、如何设计方案、如何实现并最终交付到用户；
   3. 事情可大可小，务必有始有终：当我们上不具备独立完成一件很大的事情时，可以从小事着手，完整的做下来，不断挑战，去了解和尝试更大的事情；
2. 追求卓越，让优秀成为习惯。环境部署一事上面没有细说，里面有两个问题：高可用改造作为独立于基础组件部署的步骤甚为不妥、部署脚本平铺直叙的执行动作效率低下，我们要对自己有更高的要求，设计出优美的架构、编写出高效漂亮的代码、打造易用的产品；
3. 低头走路，抬头看天。这句话有两层意思：
   1. 一方面是不局限于当下的工作，不断钻研，把技术做的更深、更广，然后回馈到工作中，提升工作能力，为更有挑战的工作打好基础；
   2. 另一方面是生产工具也使用工具，站在用户的角度思考，为什么需要某个工具，什么样的工具可以帮助用户更好的完成工作，创造更大的价值，有助于给用户提供更有用的产品。

对团队而言：

1. 把团队建设作为很重要的工作来做，打造一个高效、稳定的团队，团队成员的能力能够很好的覆盖团队所需，能够专业、快速的完成相关工作，可以按照产品架构调整团队组织架构，纵向分层、横向分模块，每个位置都有主备，要求主具备解决当下所有可能遇到的问题和未来应该怎么走的能力，当主不在时，被应该具备解决当下所有问题的能力，并可在可接受的时间内培养出探索未来的能力；
2. 专业的人做专业的事，专业的人合作做造福人类的大事，产品有敏感的嗅觉和精准的判断能力，能够在纷繁复杂的需求世界中找到用户真正需要的产品规划，架构师根据需求设计出安全、可靠、易扩展、可移植的架构，测试代表用户验收产品，提出宝贵意见，各种角色各司其职，共襄大举。