大家好，我是陈哥。产品经理为什么不能一次性确定好需求？这个问题在知乎一直有着很高的讨论度和关注度。相信做研发的小伙伴或多或少都遇到过这种情况：大家或多或少都遇到过这种情况：明明跟产品经理都对接好需求了，一旦开始写代码，对方就突然说需求要调整。在实际工作中，一次性确定需求这件事，本身就不符合产品研发的逻辑，更违背了我们实际工作的常态。就像我们平时做一件没做过的事，不可能一开始就把每一步
大家好，我是陈哥。我前几天收到了一个读者的留言：我们团队正面临需求部分明确但市场反馈多变的项目。之前参加禅道中国行的时候看了融合管理框架的白皮书，我就想着试试。但实操时，还是只走了敏捷，完全没达到我想要的效果。其实这类看似用了融合模式，实则仍是单一模式的问题，很多团队都曾遇到。我们都知道，瀑布模式的优势在于其结构化、流程化，在需求明确、范围稳定的项目中能展现出强大的可控性。而敏捷模式强
大家好，我是陈哥。 我发现一个很普遍的现象，包括刚开始带项目的自己也是一样，我们很容易只盯着项目的时间。 但实际上，有效管控进度是一套涵盖规划、执行、监控、调整的系统性工作，每个阶段环环相扣，任何一个步骤有疏漏都可能导致整体进度失控。 接下来，我将会以禅道软件为实操工具，以开发一个APP开发项目为例，按项目启动、项目执行、项目收尾这三个阶段，来拆解一下有效管理进度的核心逻辑与实操方法，帮助大家搭建
大家好，我是陈哥。前几天参加大会和老朋友碰上了，就一起吃了个饭。他说他们团队这大半年就没踏实过，每个项目都做得特别赶。上次一个定制开发项目，本来留了充足工期，结果做着做着又开始加班。虽然聊了几句就揭过去了，我这几天还是忍不住想：为什么有些项目干着干着就成紧急项目了？一、紧急的根源到底在哪？我们总是喜欢给自己找各种各样的借口，怪客户要求严、怪市场变化快。实际上，不少项目在启动阶段就已经埋下
大家好，我是陈哥。我最近看了一系列关于LLM改变自动化测试的文章，说实话，真的打开了我新世界的大门。从最早的QTP、Slenium，到后来的Appium、Postman，尽管我们禅道也在做自动化测试，但我以为自动化测试的天花板也就这样了。无非是效率提升了一点，但LLM的出现，让我感觉像是有人在我面前开了一块全新的天花板。一、传统自动化测试有哪些局限性？众所周知，传统的自动化测试是先预设脚
大家好，我是陈哥。我看到有不少读者给我留言吐槽代码覆盖率很像自欺欺人的数字游戏，低了怕影响质量，高了又怕陷入“为了覆盖而覆盖”的无效内卷。明明功能测得差不多了，为啥非要揪着这个百分比不放？今天，我们就一起谈谈为什么那么看重代码覆盖率。一、测试人员的经验和责任没法量化很多人觉得，测试用例写得够不够，全靠测试人员的经验和责任心。这话没错，但经验和责任心是主观的，没办法量化。你说你测得全，怎么证
大家好，我是陈哥。从11月开始，我们陆续北京、深圳、上海、济南开展了禅道产品研发流程实战训练营。我们在后续活动复盘时谈到，有些参会者对需求实例化很感兴趣。今天想借着这篇文章展开讲讲。一、主动前置参与，从源头把控实例完整性很多测试人员做需求实例化，都是等产品经理把需求文档发过来才开始动手，这样很容易陷入被动。毕竟产品经理可能不懂技术实现细节，也未必能考虑到所有测试边界场景，很容易在需求文档
大家好，我是陈哥。不知道大家看没看过这个问题：既然测试也要求写代码，那干脆让开发兼任测试不就好了吗？这句话听上去像是测试人员被要求写代码的气话，但我之前在《做软件测试需要懂代码吗？》一文中讨论过为什么现在各个公司都开始要求测试写代码，大家感兴趣的话可以去看看。借着这个问题，我想和大家继续聊聊：为什么不直接让开发兼任测试？说句实在话，对于大部分企业来说，这想法太理想化，真落地准出乱
大家好，我是陈哥。我所在的禅道一直在做开源，所以我朋友经常会跟我聊开源相关的内容。他说，最近他用的一个开源工具从今年年初更新频率就变慢，现在Issue里的问题没人回答。其实，这种虎头蛇尾的情况不是个例，说难听点，已经成了国内开源圈的通病。咱们做技术的都知道，好项目是靠人堆出来的，可国内很多开源项目，从一开始就没解决“人从哪来、钱从哪出”的问题。很多项目发起者是大厂的技术骨干，凭着一腔热血把
从智能家居到工业互联网，从车联网到城市级感知网络，物联网正让万物“对话”重塑生活。每天有数亿台设备和应用程序正在通过物联网系统发送和接收数据。面对海量设备及其产生的高速数据流，如何做好以MQTT为代表的物联网协议性能测试显得尤为重要。今天，我们来聊聊科学开展大规模MQTT性能测试的实践与方法。01MQTT的工作原理MQTT是一种基于TCP/IP协议的即时通讯协议，采用发布-订
