改善软件开发团队的效率的个人经验

合集 - 朝花夕拾(24)

1.改善软件开发团队的效率的个人经验2023-11-18

2.C++程序员的成长路径2023-11-183.Java程序员的成长路径2023-11-184.我的大数据之路 - 转岗半年的记录2023-12-275.我的大数据之路 - 生产变更方案的注意事项2023-12-276.我的大数据之路 - 基于HANA构建实时方案的历程2023-12-277.我的大数据之路 - 维表变了怎么办2023-12-278.IPTV SQM的项目总结2023-12-309.2016年全年回顾2023-12-3010.2015年全年回顾2023-12-3111.关于大数据平台上任务管理的思考2024-01-0812.听其言，观其行2024-01-0913.2019年全年回顾2024-02-1514.重案组第一季的观后感2024-02-1415.重案组第一季第一集的观后感2024-02-1416.重案组第一季第二集的观后感2024-02-1417.天空之眼的观后感2024-02-1518.2023年全年回顾2024-02-1619.2020年全年回顾2024-02-1620.2021年全年回顾2024-02-1621.2022年全年回顾2024-02-1622.2018年全年回顾2024-02-2223.为什么选择入行分布式存储2024-04-2424.承接新业务时的常见困难和对策2024-04-27

收起

梳理交付流程，包括：

• 定义各环节的责任人，交付件，交付件的质量标准。
• 明确流程的参与角色和报告关系。
• 定义各角色在流程中的分工和职责。
• 梳理各角色的标准动作。

执行上述流程，同时收集意见，识别问题，并制订改进措施，然后定期刷新前述流程。

提升效率的思路：

• 识别耗时活动，比如冗余活动要裁撤，必要的活动要思考改进措施。
• 识别阻塞点，比如调整分工或者交付顺序。
• 定义标准化模板，方法。
• 使用工具替代人。

下面介绍一个例子。曾经参与过的项目，按周出版本上线。

优化前的协作模式，如下：

• 周一上午，产品经理和SE，确定本周交付的需求。
• 周一下午，SE整理需求的方案，给开发和测试团队讲解方案。
• 周二上午，开发团队分解开发任务，明确责任人。测试团队分解任务，明确各自的分工。
• 周二下午，开发责任人撰写实现方案，拉对应的测试责任人讲解实现方案，启动开发，同时和SE确认遗留问题。
• 周三，开发责任人开发代码。测试团队撰写测试分析，输出门槛用例，在测试团队内部组织评审，评审通过即提供门槛用例。
• 周四上午，开发责任人评审门槛用例。
• 周四下午，开发团队执行门槛用例，按需求组织showcase开发，需求转测试。
• 周五上午，开发完成必改问题的修复，测试团队回归问题单。
• 周五下午，测试团队执行全功能验证。
• 周五晚上，测试团队在镜像环境验证基本功能，如果没有问题则执行生产环境的变更和验证。

上述交付流程运作一段时间后，整个团队包括产品经理，SE，开发和测试都觉得压力很大，交付进度很赶，交付效果很差，即事不成人不爽。

各角色抱怨很对，挑一些典型的意见，如下：

• 产品经理的意见
  • 需求交付进度不及预期。
  • 用户体验不满足要求或者功能不符合预期时，验证时间太足。
  • 版本经常带病上线，总要救火。
• SE的意见
  • 没时间分析需求。
  • 直接面对开发团队的不同人，沟通效率低，太花时间。
• 开发团队的意见
  • 留给编码的时间太短。
  • 方案不稳定，经常变。
• 测试团队的意见
  • 开发团队交付需求的时间集中在周五上午。
  • 测试时间短，全面覆盖的压力很大。
  • 手工准备验证环境，比较麻烦，经常定位环境问题。
• 运维团队的意见
  • 生产环境变更需要人工操作，操作时间长，且不可靠。
  • 执行变更操作的人，需要经常待命，压力大。

收集各方面的意见，依据团队的现状，采取了一些措施，如下：

• 已有的特性划分责任田，定义田主和后备，参与方案的分析和评审，支撑SE，开发责任人和测试责任人。
• 产品经理识别交付范围内的关键需求和一般需求，开发团队优先保证关键需求的交付。
• 调整协作流程，管理类动作迁移，保护SE、开发人员、测试人员的核心工作时间。
• 改进安装、部署流程，使用流水线执行自动化任务，实现部署和升级，消除人工操作引入的问题，缩短部署时间。
• 申请机器，开发团队和测试团队使用的机器分开，避免争抢机器引发的冲突。
• 测试PM引入自动化测试方案，逐步提高自动化测试用例的占比，降低全功能覆盖的耗时，降低测试团队的工作压力。

对协作流程做了一定的调整，如下：

• 第一周
  • 周四上午，评估下一周的交付需求的范围。
  • 周四下午至周五，SE整理需求方案，给田主和测试团队讲解方案。
  • 周五下午，开发团队分解开发任务，明确责任人。测试团队分解任务，明确各自的分工。
• 第二周
  • 周一上午，田主给开发责任人讲解方案，开发责任人撰写实现方案。
  • 周一下午，开发责任人拉对应的测试责任人讲解实现方案，启动开发，同时和SE确认遗留问题。
  • 周二，开发责任人开发代码。测试团队撰写测试分析，输出门槛用例，在测试团队内部组织评审，评审通过即提供门槛用例。
  • 周三，开发责任人开发代码，同时评审门槛用例。
  • 周三下午，部分需求开始showcase，转测试。
  • 周四下午，需求基本完成转测试，测试团队启动功能验证。
  • 周五上午，开发完成必改问题的修复，测试团队回归问题单。
  • 周五下午，测试团队执行全功能验证。
  • 周五晚上，测试团队在镜像环境验证基本功能，如果没有问题则执行生产环境的变更和验证。

上述措施实施一段时间后，逐步改善了产品的交付形势，来自周边客户的评价有明显改善，交付团队虽然依然很忙，但交付效率有提升，得到了更多的认可，团队整体的工作积极性有比较大的改善。

来自团队内各角色的反馈：

• 产品经理觉得特性上线的速度加快，得到了领导、周边同事更多的信任，同时在更多的项目得到应用。
• SE觉得现在有更多的时间和客户交流，识别需求，梳理思路，准备方案文档。
• 开发团队觉得成就感比较强。
  • 编码、自验证的时间相对比较充分。
  • 交付的节奏感更强。
  • 前期有问题的设计、实现，现在有机会规划修复计划，并在项目中实施并得到反馈。
  • 有机会尝试一些新技术。
  • 有机会直面客户，特性交付后可以快速得到反馈。
• 测试团队工作更加聚焦。
  • 不需要费心准备、修复部署引入的问题。
  • 环境独立，不需要抢环境。
  • 工作前移，用例的质量更有保障。
  • 预留主动思考的时间，有利于个人成长。
• 运维团队的幸福感有明显的提升。
  • 压力下降很明显，变更操作自动化执行，无需人工投入。
  • 有机会和客户、SE交流。
  • 有机会参与特性交付、功能验证工作。
  • 个人成长的空间得到拓展。

上述总结来自于个人对如何提高软件开发团队的效率？的回答，对内容做了一定的编辑，调整了格式。