已有 281 人访问
许祥 ID.17128
阅读(225)
博客(0)
许祥的阅读

如何避免产品Backlog的这七个常见错误
产品Backlog是一个简单而强大的工具,用来捕获产品创意和调整产品决策,并且为开发工作的方向提供指引。不幸的是,想要用好产品Backlog这个工具并不容易。本文讨论了七个常见的产品Backlog错误,以帮助您识别和规避这些错误。产品Backlog太大几年前,一家医疗保健公司期望我能够在敏捷转型上提供一些帮助,特别是敏捷转型后对产品管理的影响。这个公司的敏捷转型团队所关心的一个关键挑战是如何选择正
259°/ 2021-11-21/2582 人阅读 / 0 人点赞 / 1 条评论

听过什么叫刷题式编程?有用吗?
图片来源:GeeksforGeeks这篇文章的观点可能并不适用于每个公司或每个工科学生。但这个观点已经非常广泛地存在我的经验中,以至于我觉得有必要宣扬一番。观点编程竞技是锻炼编程能力的一个好工具。但对竞争性编程的极端追求与其说毫无用处,不如说比毫无用处还要糟糕。事实上,不仅学生在朝这个方向努力,公司也在朝着这个方向努力而不是去寻找兴趣广泛的工程师。迷失—从起初的能力训练到不顾一切地痴狂编程竞技开始
234°/ 2021-11-19/2340 人阅读 / 3 人点赞 / 0 条评论

团队对质量负责,“我”可以不负责?
“敏捷测试强调团队为质量负责,那质量变成是团队的事情,可能有团队人员认为个人不那么负责问题不大,毕竟天塌下来有团队在。”一位转型中的测试经理表达了这样的担忧。这跟传统职责分明的做法有关,“我”管“我的”,“你”管“你的”,各自做好自己的本分就可以了。现在,既然说要团队来负责,那么“你”就可以多帮“我”负责一点,“我”少负责一点也没问题。听起来似乎还挺合情合理的。显然,这种想法是有问题的,把个人跟团
233°/ 2021-11-16/2338 人阅读 / 2 人点赞 / 0 条评论

互联网企业ToB转型质量保证四个基本点|ToB和ToC差异四个差异
刚加入互联网企业时,有两个事情让我印象深刻,并给我很深的思考,1.互联网企业做性能测试时,一般10分钟左右就完成测试,而传统企业性能测试时间大多在几个小时,有什么甚至要做到7*24小时,为什么会这样呢?到底是什么原因导致有这么大的差异?2.另外一个事情是刚到金融不久,开发金条项目,第一个版本上线的是借款,第二个版本上线的是还钱(大概2周后),后续的版本逐渐上线的合规风控等。这个事情当时给我一个很大
311°/ 2021-11-12/3114 人阅读 / 9 人点赞 / 0 条评论

将 Unix 哲学带入 21 世纪
做好一件事Unix的哲学是使用每一个简洁又专业的工具来做好每一件事,然后将它们像流水线一样连接起来操作数据。这是一个很棒的主意,并且在过去的几十年里一直运作良好。这一理念在1978年BellSystemTechnicalJournal前言中有所概述,描述了UNIX分时系统:列出的第一项和第二项实际上已经被我们反复实践。但现在是时候通过进一步定义非交互式的标准输出格式将这一理念带入21世纪。具体来说
228°/ 2021-11-07/2275 人阅读 / 10 人点赞 / 1 条评论

功能测试都做不好,还搞什么自动化?测试开发?
不论你是什么时候开始接触测试这个行业的,你首先听说的应该是功能测试。通过一些测试手段来验证开发做出的代码是否符合产品的需求?当然你也有自己对功能测试的理解,但是最近两年感觉功能测试好像不太受欢迎,同时不少同学真的是功能测试都没有做好,就去尝试自动化测试,测试开发什么的,结果是越学越迷茫,这是为什么呢?究其原因是,你功能测试还没有学好呢!我们通常认为的功能测试是根据需求,采取如下测试流程:需求分析,
267°/ 2021-11-02/2675 人阅读 / 78 人点赞 / 0 条评论

困在系统里的“研发效能度量” 该如何自救?
前段时间读了一篇文章:“外卖骑手,困在系统里”,引发了我很多的思考,后来有幸和作者有过一次交流更是让我印象深刻。上两周我写了一篇文章“如何用研发效能搞垮一个团队”引起了业界同行大量的讨论与关注,今天想借此继续来聊聊研发效能提升过程中另一个无法回避的的话题:“度量”。历史上度量失败的案例这其实是“窗户税”所引发的不良后果。1696年之前,英国政府对于个人房屋的税收采用的是“壁炉税”,也就是根据屋内的
300°/ 2021-10-31/3003 人阅读 / 2 人点赞 / 0 条评论

质量工程优秀实践中的六大原则
敏捷开发模式和DevOps的实践促进了开发、运维和质量团队更多的合作和更好的沟通,同时也模糊了这些团队之间的界限,强调每个人都对质量负责。敏捷实践让研发团队在交付速度上变快了,但不知不觉中质量却因此受到影响。本文总结了在质量工程实践中应该遵循的六大原则。原则1-团队应从第0天开始考虑质量问题,将质量工程彻底融入软件开发的生命周期。质量工程需要组织内管理层的支持和所有团队的参与。质量工程的建设将改变
244°/ 2021-10-31/2446 人阅读 / 1 人点赞 / 0 条评论

敏捷开发模式下测试经理没有了话语权?
“转敏捷后,测试经理的话语权没有了,团队更加关注交付速度而不重视质量怎么办?”在跟某转型中的团队进行交流时,一位测试经理表达了这样的担忧。我理解这里的困惑在于两个方面:●传统模式下测试是一个独立的部门,测试经理可以在测试这个阶段严格把关质量,有很强的话语权;在敏捷模式下,测试需要融入开发团队,都由开发团队PM来统一管理,很有可能会更关注交付速度,这种情况下,测试经理的话语权似乎减弱了,该如何发挥价
238°/ 2021-10-27/2386 人阅读 / 6 人点赞 / 0 条评论

谷歌软件工程:文化、实践与工具
摘要我们努力不说:"谷歌的软件工程”是唯一真正的方法,因为我们认识到,我们的规模和资源与其他组织完全不同。软件工程不是(单纯的)编程,而是长期的编程。我们主要关注的是如何让事情随着时间的推移持续发展,以及如何与其他人协调和合作。书中的代码很少,但其主要的内容依旧是关于软件的讨论。谷歌在技术上和组织上都是不完美的。你可以从我们对外部软件包的维护等技术问题的处理中看到,也可以从我们围绕公平和多样性的文
283°/ 2021-10-22/2838 人阅读 / 7 人点赞 / 0 条评论