4、过程评估方法：评估类型（正式/非正式）、评估流程、评估工具选择
好，咱们接着聊过程评估。说实话，很多团队一听到「评估」两个字就紧张，觉得是来挑刺的。其实不然。评估的目的是帮你看清现状，找到改进的发力点。我自己做了十几年评估，从最初的懵懵懂懂，到后来能一眼看出问题根因，这个过程本身就是不断「被评估」和「评估别人」练出来的。
今天这一讲，我重点聊聊评估的类型、流程，以及工具怎么选。嗯，这些都是实战中绕不开的坎。
4.1 评估类型：正式 vs 非正式
评估不是只有一种玩法。根据目的不同，我习惯把它分成两大类：正式评估和非正式评估。你想想看，一个是「大考」，一个是「随堂测验」，性质完全不一样。
4.1.1 正式评估
正式评估，说白了就是有组织、有计划、有证据、有结论的全面体检。它通常用于：
- 客户审核：比如OEM要看你家ASPICE能力级，派审核组来现场。
- 内部年度评估：公司质量部组织的，对标CMMI或ASPICE。
- 认证评估：拿ASPICE等级证书，必须由认证的Principal Assessor主导。
正式评估有几个硬性要求：
- 必须有评估计划，提前2-4周通知。
- 必须有客观证据，不能光听口头汇报。
- 必须有评估报告，包含发现项、强项、改进建议。
- 评估员必须独立，不能评估自己参与的项目。
关键点：正式评估的结论具有「约束力」。如果评估结果是「未达标」，项目必须整改，甚至会影响交付节点。所以，正式评估前，我建议团队先做一轮自检。
4.1.2 非正式评估
非正式评估就灵活多了。它更像是一种「快速诊断」。我在项目中经常用这种方式：
- 同行评审：开发人员互相看代码、看设计文档。
- 走查：项目经理拉着几个关键角色，过一遍流程。
- 自评问卷：让每个工程师填一份检查表，快速摸底。
非正式评估的好处是：快、轻、无压力。你可以在迭代中随时做，发现问题立刻改。我曾经在一个项目里，每周五下午做一次30分钟的「快速评估」，就盯着一个过程域（比如SUP.1 质量保证）。连续做了4周，问题减少了70%。
我的建议：非正式评估不要追求「全面」，每次聚焦1-2个过程域。贪多嚼不烂，这是很多团队踩过的坑。
4.2 评估流程：从计划到报告
不管是正式还是非正式，评估的流程骨架是差不多的。我把它总结为四个阶段：计划 → 数据收集 → 分析判断 → 报告反馈。
4.2.1 计划阶段
这个阶段最容易被人忽略。很多人上来就翻文档、问问题，结果发现方向偏了。我个人的习惯是：
- 明确评估范围：是评估整个项目，还是只评估软件详细设计？是评估所有过程域，还是只评估工程过程？
- 确定评估准则：用ASPICE 3.1还是ISO 26262？能力级要求是1级还是2级？
- 组建评估团队：正式评估至少需要2名评估员，其中1名必须是主任评估师。
- 制定时间表：每天评估几个过程域？什么时候做访谈？什么时候看文档？
避坑指南：我曾经见过一个团队，评估计划里写「评估所有过程域」，结果只给了3天时间。最后评估员累得半死，结论也模棱两可。记住：评估不是越快越好，而是越准越好。
4.2.2 数据收集阶段
数据收集是评估的核心。常用的方法有：
- 文档审查：看过程描述、计划、报告、记录。
- 访谈：和项目经理、开发人员、测试人员、QA分别聊。
- 观察：看他们实际怎么工作，比如看一次每日站会。
- 工具日志：从Jira、Git、Jenkins里拉数据，看实际执行情况。
这里有个技巧：不要只看文档，要交叉验证。比如，文档里说「所有需求都追溯到了测试用例」，那你就随机抽5个需求，去工具里查一下，看是不是真的追溯上了。我在评估时，至少会做3次这样的交叉验证，否则我不下结论。
4.2.3 分析判断阶段
数据收集完了，接下来就是「断案」。评估员需要根据证据，对照ASPICE的评定指标（PA、GA等），给出每个过程域的等级评分。
评分不是拍脑袋。我一般遵循这个原则：
- 完全满足：所有证据都符合，没有发现任何不符合项。
- 大部分满足：主要证据符合，但有少量次要问题。
- 部分满足：关键证据缺失或不符合，需要整改。
- 不满足：基本没有证据，或者证据严重不符合。
注意：如果某个过程域被评为「部分满足」或「不满足」，必须给出具体的不符合项描述，并引用证据。不能只说「你们做得不好」，要说「在SWE.1中，需求规格说明书缺少非功能性需求，证据是文档第3.2节为空」。
4.2.4 报告反馈阶段
最后一步，把评估结果呈现给团队。报告里至少要包含：
- 评估范围、时间、人员
- 每个过程域的评分结果
- 不符合项清单（含证据引用）
- 强项和亮点
- 改进建议（优先级排序）
我习惯在报告最后加一页「快速赢」——就是那些花1-2天就能改好的问题。这样团队看到报告后，不会觉得压力山大，而是有动力立刻行动。
4.3 评估工具选择
工具选得好，评估效率翻倍。选得不好，那就是给自己添堵。我这些年用过不少工具，踩过坑，也捡过宝。下面是我的经验总结。
4.3.1 工具分类
| 工具类型 | 典型工具 | 适用场景 |
|---|---|---|
| 过程建模工具 | Enterprise Architect, SPARX | 定义和可视化评估流程 |
| 需求管理工具 | DOORS, Polarion, Jira | 追溯需求与测试用例 |
| 测试管理工具 | TestRail, qTest, HP ALM | 查看测试覆盖率和结果 |
| 配置管理工具 | Git, SVN, ClearCase | 检查版本控制和基线 |
| 评估专用工具 | Intacs Assessor Tool, 自研Excel模板 | 记录评估发现、生成报告 |
4.3.2 我的选型原则
选工具，我只看三点：
- 数据可导出：工具必须能导出CSV或Excel。为什么？因为评估报告需要汇总数据，如果工具是封闭的，你只能手动抄，累死人。
- 支持追溯：能快速从需求查到代码，再查到测试用例。没有追溯，评估就是盲人摸象。
- 团队熟悉度：别为了评估专门引入一个新工具。我曾经在一个项目里，为了评估买了套昂贵的工具，结果团队学了一个月还不会用，最后评估还是用Excel完成的。嗯，这个教训挺深刻的。
小技巧：如果团队预算有限，用Excel + Jira也能做正式评估。关键是模板要标准化。我有一套自用的Excel评估模板，包含过程域清单、评定指标、证据记录、评分计算，用了好多年，效果不输专业工具。
4.3.3 工具使用避坑
- 不要过度依赖工具：工具只是辅助，判断力才是核心。我见过有人用工具自动生成了评估报告，结果发现数据全是错的——因为工具里的数据没更新。
- 注意工具版本：ASPICE 3.1和4.0的评定指标有差异，工具如果没升级，评估结果会失效。
- 数据安全：评估数据往往涉及项目机密，工具必须支持权限控制。别把评估结果放在公共网盘上。
4.4 小结
这一讲的内容，说白了就是三件事：
- 评估类型：正式评估用于「大考」，非正式评估用于「日常体检」。两者结合，效果最好。
- 评估流程：计划→数据收集→分析判断→报告反馈。每一步都要有证据支撑，不能凭感觉。
- 工具选择：够用就好，别追求高大上。团队用得顺手，数据能追溯，就是好工具。
最后说一句：评估不是终点，而是起点。评估报告拿到手，真正的挑战才刚刚开始——怎么把发现的问题转化成改进行动。下一讲，我们就聊聊「改进计划的制定与跟踪」。到时候见。