七星海棠2022-05-25之前所在的一家公司用线上bug影响用户数（如2000）来定义故障的级别，但各业务团队的用户规模完全不在一个等级，内部系统的用户数总共也没到达2000，这样这个团队就一直不会出现P1级故障。而有的团队，每天在线用户数都几十万，随便一个问题影响的用户数都能上2000...跟上面领导提过，要按百分比来算比较合理，但上层不同意，觉得放开了这个口子，那以后我们团队可能就要松懈了...作者回复: 无法驱动团队改进的度量，就没必要保留。 针对你这样的情况，我也遇到过，各个产品线的背景，规模都不一样，暂时无法形成统一的企业层面上的度量。这个时候，为了推进度量驱动，可以让每个产品线自己定义度量，进行纵向对比，也就是说我们无法用一个度量来对比A团队和B团队”谁好谁坏“，但是可以用一个度量的趋势来判断A团队是“变好还是变坏”
2
羊羊2022-08-04 来自日本这个章节的内容大受启发，是工作经验的空白区。老师把PMP中项目的四要素引入到了自动化测试项目中，从范围，进度，成本，质量来考察项目的总体质量，让测试工作也能“多快好省”。 但是正对文中的度量指标，有下面这些疑问，希望老师解惑： 交付速度，用发布周期来度量，这个时间是包含了开发和测试的时间么？一般项目中，开发和测试的时间是交叠的，一个迭代周期的测试时间和第二个迭代周期的开发时间是交叠的；老师在实际项目中是如何计算这个发布周期的？ 交付范围中的新增代码行数，是指开发的代码行数，还是也包括了自动化测试开发的代码行数？同理，质量部分的bug，是单指针对软件质量的bug么？自动化测试的框架bug，脚本bug是否需要算入其中？作者回复: 这几个交付质量度量，是从客户角度来看到的质量。这么想就理顺了。 比如，发布周期，就是客户看到的系统版本更新周期。 代码应该是指的产品运行的代码 质量bug，应该是产品本身的bug 而我们所做的一切就是推动交付质量的提升。在内建质量里，再分为开发质量，测试质量，然后展开相应的内建度量体系
1
追风筝的人2022-06-01俄国文豪托尔斯泰曾经说过一句流传很广的话“幸福的家庭是相似的，不幸的家庭各有各的不幸 。 告别单身生活，不论有多么幸福，失去自由还是可惜的。 列文在追寻人生的意义过程中走向幸福，安娜在追求纯粹爱情的过程中走向不幸。作者回复: 说得深刻😂。熟读原著。人是社会关系中之人，心何处安放？智者忍受高冷的孤独，庸者遁离思考的痛苦。
1