• 七星海棠
    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