60、软件开发中的盲点发现与事件分析

软件开发中的盲点发现与事件分析

一、软件开发技术选择

在软件开发中，有多种技术可供选择，如结对编程、团队编程、无缺陷开发、测试驱动开发等。这些技术可以个人执行，也可以结对或团队协作完成，具体取决于团队的情况。

（一）技术执行方式

• 个人执行 ：个人执行这些技术是可行的，能让开发者专注于自身的工作节奏和思路。
• 结对与团队协作 ：结对编程和团队编程有利于集思广益、分享见解，还能打破测试人员与其他团队成员之间的隔阂。团队可以通过实验来确定哪种方式最适合自己，而且不同技术可能适用不同的执行方式。

（二）盲点发现的负担问题

有人担心随着软件规模的增大，盲点发现的负担会越来越重。但实际上，盲点发现与传统测试不同，它不是随着代码库的增长而增长，而是用于检查假设，而不是验证不断增加的代码库。随着团队解决盲点问题并对交付高质量结果的能力增强信心，对盲点发现的需求应该会下降，而不是上升。

（三）技术使用的前提条件

任何团队都可以使用这些技术，但要明确它们是用于发现盲点，而不是检查软件是否正常工作。不要让它们成为瓶颈，发布前不需要进行全面检查，也不需要检查所有内容，重点是寻找开发系统中的缺陷，而不是软件系统本身的缺陷。不过，如果团队还无法确保代码几乎无缺陷，或者还没准备好放弃额外检查，可以在检查完盲点后再发布，但不要将盲点发现作为依赖。要改进开发系统，以便在不进行手动测试的情况下也能发布。

（四）技术使用的指标

当团队很好地使用盲点发现技术时，会有以下表现：
- 团队信任其软件的质量。
- 团队不将盲点发现作为发布前测试的一种形式。
- 生产环境和通过盲点发现技术发现的缺陷数量随时间减少。
- 进行盲点发现所需的时间随时间减少。

（五）替代方案和实验

这种实践基于开发者可以构建几乎无缺陷系统的假设，即缺陷是可修复的盲点造成的，而不是缺乏手动测试。常见的替代方案是传统测试，即构建可重复的测试计划来全面验证系统。但这些测试计划本身也有盲点，而且很多测试与程序员使用测试驱动开发创建的测试重复，成本高且很少能发现其他技术揭示的问题。在实验方面，上述技术只是开始，关键是验证隐藏的假设，任何能识别和测试这些假设的方法都可以尝试，比如模糊测试，即生成大量输入并监控意外结果。

二、事件分析

（一）事件分析的重要性

尽管团队尽了最大努力，软件有时仍会出现故障。故障有轻微的，如网页上的拼写错误，也有严重的，如损坏客户数据的代码或导致客户无法访问的停机事件。无论故障大小，在问题解决后，都需要分析发生了什么以及如何改进，这就是事件分析。

（二）敏捷团队对失败的态度

敏捷团队明白失败是不可避免的，人们会犯错、沟通会出现误解、想法可能行不通。与其试图避免失败，不如接受它。重要的是尽快检测到失败，尽早失败以便有时间恢复，控制失败的影响，从失败中学习而不是指责。持续部署就是这种理念的一个例子，团队通过监控检测失败，频繁部署能尽早发现问题并降低影响，使用金丝雀服务器减少失败后果，并从每次失败中了解自身的局限并改进。

（三）失败的本质

失败不是简单的因果关系，而是整个开发系统的结果。开发系统包括从工具到组织结构等软件构建的各个方面，与正在构建的软件系统不同。每个失败，无论多小，都是开发系统本质和弱点的线索。失败是由许多相互作用的事件导致的，当多个问题同时出现时就会发生失败。而且系统会逐渐向失败漂移，对于有控制失败记录的团队来说，威胁不是错误，而是成功。随着时间推移，团队规范可能改变，安全边界缩小，最终失败条件结合导致失败。此外，大失败和小失败的原因是相同的系统问题，小失败是大失败的“预演”，所以要把每个失败都当作学习和改进的机会，成功也可以进行分析。

（四）小失败分析示例

分析小失败，即使是微不足道的失败，也能揭示导致大问题的系统问题。例如，团队被要求修复隐私政策中的一个拼写错误，分析发现团队中没人认为检查隐私政策是自己的责任。后来团队决定对软件中的所有内容负责，在六个月后添加营销文案时，团队进行了审查，避免了一个错误。

（五）事件分析的步骤

事件分析是一种回顾，有效的分析包括以下五个阶段：
1. 设定阶段
- 提醒参与者目标是通过事件更好地理解软件开发系统，而不是关注失败本身或指责他人，要学习如何使开发系统更具弹性。
- 让大家确认能遵守目标并对事件相关人员保持善意，可采用 Norm Kerth 的首要原则。
- 考虑建立“维加斯规则”，即分析会议中的内容不外传，不记录会议，要求参与者不重复个人细节。
- 如果会议有团队外人员或团队刚组建，可建立工作协议。
2. 收集数据
- 创建事件的可视化时间线，将其分为代表不同时间段的列，列的长度可不一致。
- 让参与者通过头脑风暴列出与事件相关的事实性、非评判性事件，包括进展顺利的事件，写在相同颜色的便签上并贴在白板上。
- 回顾大图景，补充缺失的事件，用箭头表示事件的先后关系。
- 包括与人相关的事件，尤其是涉及团队控制或使用的自动化事件，要追溯人们在其中的贡献，保持事件描述中立无责。
- 鼓励参与者分享当时的意见和情绪，用不同颜色的便签记录。
- 让参与者突出时间线中重要的事件，并确认是否记录了所有相关回忆。
3. 生成见解
- 提醒参与者事件不是失败的原因，而是开发系统运行的症状，要分析更深层次的系统。
- 对涉及人的重要事件分配以下类别：
- 知识和心理模型 ：涉及团队内部的信息和决策。
- 沟通和反馈 ：涉及团队外部的信息和决策。
- 注意力 ：涉及专注相关信息的能力。
- 固执和计划延续 ：面对新信息仍坚持原有评估或计划。
- 冲突目标 ：在多个目标中做出选择。
- 程序适应 ：既定程序不适合情况时的应对。
- 用户体验 ：与计算机界面的交互。
- 自定义类别 ：可根据事件创建。
- 将类别写在第三种颜色的便签上并贴在时间线旁。
- 分组讨论每个事件对开发系统的启示，关注系统而非个人。
- 汇总讨论结果，用第四种颜色的便签记录结论，只记录学到的内容，不做建议。
4. 决定行动
- 回顾整个时间线，思考如何使系统更具弹性，同时进行头脑风暴，提出各种想法，不考虑可行性。可考虑以下问题：
- 如何防止此类失败？
- 如何更早检测到此类失败？
- 如何更快失败？
- 如何减少影响？
- 如何更快响应？
- 安全网在哪里失效？
- 应调查哪些相关缺陷？
- 将想法分组为“控制”“影响”和“杂烩”圈，讨论其优缺点。
- 通过点投票和同意投票决定团队要采取的选项，可选择多个。
- 思考防止失败的方法，如改变代码或设计使错误不可能发生，若无法避免则自动捕获错误，同时考虑事件对开发系统的启示，进行进一步调查。
5. 结束回顾
- 让参与者放松，可建议他们站起来深呼吸。
- 决定保留哪些内容，如时间线和其他工件的截图或照片。先让参与者检查时间线，移除不想分享的便签，然后拍照。

下面是事件分析步骤的流程图：

graph LR
    A[设定阶段] --> B[收集数据]
    B --> C[生成见解]
    C --> D[决定行动]
    D --> E[结束回顾]

（六）事件分析的注意事项

• 参与分析的人员应包括整个团队和事件响应相关人员，避免经理和其他观察者，以确保参与者能坦诚发言。
• 分析所需时间取决于事件的复杂程度，复杂的停机事件可能需要数小时，简单的缺陷可能只需 30 - 60 分钟，经验越多速度越快。
• 开始时，对于敏感事件，应由中立的主持人引导，事件越敏感，主持人的经验要求越高。

综上所述，软件开发中的盲点发现和事件分析是提高软件质量和开发系统弹性的重要方法。团队应根据自身情况选择合适的技术执行方式，正确使用盲点发现技术，并在软件出现故障时进行有效的事件分析，不断改进开发系统。

（七）事件分析案例深入剖析

为了更清晰地理解事件分析的实际操作，我们再次以之前提到的例子展开详细剖析。假设团队在部署过程中，出现了“Deploy script stops all ServiceGamma instances”的事件。
1. 收集数据阶段
- 参与者通过头脑风暴，发现该事件之前可能有“Op misspells –target command - line parameter as –tagret”以及“Engineer inadvertently changes deploy script to stop all instances when no –target parameter found”，而这又可能源于“Team decides to clean up deploy script’s command - line processing”。
- 同时，团队成员分享了当时的情绪和想法，如工程师表示因为要赶截止日期，所以在修改脚本时比较仓促。这些信息都用不同颜色的便签记录在时间线上。
2. 生成见解阶段
- 对“Engineer inadvertently changes deploy script to stop all instances when no –target parameter found”这个事件进行分析，将其归类为“冲突目标”和“知识和心理模型”事件。
- 从“冲突目标”角度看，团队成员感受到来自销售和营销的压力，需要优先满足截止日期，从而牺牲了代码质量。从“知识和心理模型”角度看，工程师对团队命令行处理库的行为理解有误。
- 进一步分析发现，团队在脚本开发上没有采用像生产代码那样严格的标准，如测试驱动开发和结对编程，这导致脚本容易出现错误。
3. 决定行动阶段
- 团队进行头脑风暴，提出了一系列改进想法，如“stop committing to deadlines”“update forecast weekly and remove stories that don’t fit deadline”“apply production coding standards to scripts”“perform review of existing scripts for additional coding errors”“simplify deploy script’s command line”“perform UX review of command - line options across all of the team’s scripts”。
- 将这些想法分组到“控制”“影响”和“杂烩”圈中。例如，“apply production coding standards to scripts”属于团队可以直接控制的；“stop committing to deadlines”可能需要与其他部门协商，属于可以影响的；而一些涉及多个团队协作的想法可能就属于“杂烩”圈。
- 通过点投票和同意投票，团队决定优先实施“apply production coding standards to scripts”和“simplify deploy script’s command line”。

（八）不同类型故障的分析重点

不同类型的软件故障在分析时需要关注不同的重点，以下是一个简单的表格说明：
|故障类型|分析重点|
| ---- | ---- |
|拼写错误|团队的审核流程、责任划分是否明确|
|代码逻辑错误|代码编写规范、测试覆盖度、开发人员的知识和技能|
|系统停机|系统的容错能力、监控机制、应急响应流程|
|数据丢失|数据验证机制、备份和恢复策略|

（九）持续改进的循环

软件开发是一个持续的过程，盲点发现和事件分析也是一个不断循环、持续改进的过程。每次事件分析的结果都应该反馈到开发系统中，对开发流程、工具和人员培训等方面进行调整。

下面是持续改进循环的流程图：

graph LR
    A[软件故障] --> B[事件分析]
    B --> C[得出改进措施]
    C --> D[调整开发系统]
    D --> E[新的软件开发]
    E --> A

（十）与团队协作的结合

在整个盲点发现和事件分析过程中，团队协作至关重要。有效的团队协作可以提高分析的效率和质量，具体体现在以下几个方面：
1. 信息共享 ：在收集数据和生成见解阶段，团队成员需要共享各自的信息和经验。例如，不同岗位的成员对事件的看法和了解可能不同，通过充分的沟通和共享，可以更全面地了解事件的全貌。
2. 共同决策 ：在决定行动阶段，团队成员需要共同参与决策，通过投票等方式选择最适合团队的改进措施。这可以确保决策的科学性和民主性，提高团队成员对决策的认同感和执行的积极性。
3. 互相学习 ：事件分析是一个学习的过程，团队成员可以从彼此身上学到不同的知识和技能。例如，开发人员可以从测试人员那里了解到更多的测试技巧，测试人员可以从开发人员那里了解到代码的实现细节。

（十一）培养团队的质量意识

除了具体的技术和方法，培养团队的质量意识也是提高软件质量的关键。团队成员应该将质量意识融入到日常工作中，具体可以从以下几个方面入手：
1. 树立正确的价值观 ：团队成员应该认识到软件质量的重要性，将质量作为工作的首要目标。不要只追求速度和数量，而忽视了质量。
2. 持续学习和提升 ：软件行业发展迅速，新技术和新方法不断涌现。团队成员应该保持学习的热情，不断提升自己的专业技能和知识水平，以适应不断变化的市场需求。
3. 主动发现问题 ：团队成员应该养成主动发现问题的习惯，而不是等到问题出现后再去解决。在软件开发的各个阶段，都要保持警惕，及时发现潜在的问题，并采取措施加以解决。

总之，软件开发中的盲点发现和事件分析是一个系统工程，需要团队成员的共同努力和持续改进。通过合理选择技术执行方式、正确使用盲点发现技术、有效的事件分析以及培养团队的质量意识，可以不断提高软件质量，使开发系统更加稳定和可靠。