- 博客(103)
- 收藏
- 关注
RSS订阅原创 聊聊对神经网络的基础理解
热门的AI技术应用不断引起轰动。我们要针对AI新技术进一步学习，可以先从其爆发原点——人工神经网络（Artificial Neural Network，ANN）知识开始理解
2024-08-19 16:23:42
768
原创 聊聊《思考，快与慢》
丹尼尔·卡尼曼，是常年热门书籍《思考，快与慢》的作者，在近期的2024年3月27日去世，鼎叔翻出当年做《思考，快与慢》品读会分享的PPT，做一个小小的回顾和纪念。
2024-08-01 12:47:28
220
原创 聊聊AI学习入门-数学和信息论
先从数学和信息论开始，从经典理论和概念进行消化，简单介绍下自己是如何学习和思考其本质的。受限于本人在该领域的知识浅薄，如有错漏，敬请谅解
2024-07-19 10:43:03
748
原创 聊聊大模型如何为敏捷研发提效
随着大模型技术的风起云涌，各家大厂和研究机构纷纷开始了大模型在效能提升方面的尝试。复盘一下鼎叔基于前期团队实践的心得，也和不少同行交流过，思路还是很被认同的。大模型在研发效能领域的实践，有喜有忧。喜的是，自然语言表达能力的革新，值得把所有依赖教练推动的敏捷方案都重做一遍；忧的是，如果不掌握敏捷研发的本质理论，不懂敏捷，各种大模型提效实践的成功概率会非常低
2024-07-11 16:59:31
1255
原创 聊聊测试的左移和右看（合辑共13篇）
测试左移的本质是，既然越早进行质量内建活动，得到的收益越多，为什么不把技术人员的一部分精力放在更早期的环节进行质量推动和把关，总的质量保障收益是更高的。测试右看的本质是，既然验证发布效果是持续改进的动力，为什么不在系统测试结束后，持续投入一定的精力，观察用户对质量的期待是否与认知相符，从而在未来的研发周期采取果断改进行动
2024-06-24 14:48:33
781
原创 聊聊研发效能的可视化
效能可视化建设，首先要明确核心用户是谁，他的需求是什么，其次再明确唯一的北极星指标是什么，围绕它来建设质效可视化大盘，切忌不让其他指标喧宾夺主
2024-06-12 18:15:50
741
原创 聊聊测试的右移
完成端到端测试（也可以称为系统测试）阶段后，进入灰度发布或正式发布阶段，测试人员除了采集和分析缺陷外，也需要抽出一定精力，持续进行高价值的质量保障活动
2024-06-04 17:11:37
870
原创 聊聊ChatGPT的本质
阶段性总结下我对ChatGPT的基础理解，算是一篇学习思考笔记吧。其中难免有很多不准确的，或过于简略的地方，将来再迭代学习
2024-05-22 14:13:38
1334
1
原创 聊聊持续测试的进阶
如果在测试部门只能推行一个技术建设项目，那鼎叔就会选择“持续测试”。这篇继续聊聊持续测试建设的ROI分析，思考未来的成熟度进阶，以及其他要注意的
2024-05-11 15:47:45
493
原创 聊聊精益需求管理（合辑共九篇）
鼎叔感觉大家对于如何敏捷地创建和管理需求是非常感兴趣的，这第六个文章合辑整合了“精益产品需求管理”相关的九篇原创文章，内容非常丰富，欢迎分享给身边受苦受难的产研团队，放下争端，一起搞钱
2024-04-16 12:09:17
277
原创 聊聊产品的重新定位
移动互联网时代把“选择”的暴力推进到极致，就是俗称的“卷”，如果不能占据用户的心智空间，再大规模的现有产品都会被“选择的暴力”摧毁。产品的定位总是客观存在的，正确的产品定位会引领正确的公司运营，没有正确的定位就一定是错误的定位
2024-04-02 17:54:02
926
原创 聊聊让用户成功的产品
最体现用户对产品的满意程度的指标，是NPS。用户使用自己钟爱的产品会出现WOW时刻，其背后的本质，就是好产品能帮助用户获得成功，从而极大提升NPS。我们不止关注用户使用产品时的体验，还要关心用户使用之后会发生什么
2024-03-18 11:33:13
733
原创 聊聊测试左移到开发阶段
测试人员除了要学习开发人员提供的设计技术文档（用作测试设计的参考）以外，还可以积极参与开发相关的如下重要活动，更早地暴露问题，减轻而非加重开发人员的负担
2024-03-13 16:38:41
890
原创 聊聊大模型的幻觉问题
聊聊大模型的幻觉问题。这也是各大公司做大模型实践分享的高频词汇。这个主题也很有趣，它不只是服务品质问题，更可以上升到哲学探讨
2024-02-20 15:26:19
832
原创 聊聊需求的工作量估算
度量交付需求的数量和时间相对容易，但度量每个需求的大小则比较难落地，我们需要统一的方法来度量各个团队的需求交付规模，它有利于精细化的组织改进，推动团队以比较舒服的节奏完成承诺，还能稳妥处理紧急需求插入，潜在收益远大于成本
2024-02-13 19:37:51
1025
原创 聊聊需求评审与验收测试
验收测试是质量左移的利器，也是团队各角色对需求形成共识的“语言”。遗憾的是大多数团队没有好好利用这个武器，仅仅把验收测试当成P0用例，在流程最后才使用
2024-02-06 20:54:26
840
原创 聊聊刻意练习-天才并不存在
我们继续聊聊刻意练习的实践方法和标准，杰出人物保持动机的技巧，最重要的是解释为什么“天生才华”其实并不存在，唯有刻意练习才能达到自我成就的彼岸
2023-12-18 10:06:37
846
原创 聊聊刻意练习-构建心理表征
社会上经常出现的两类观念，一个是天才和大师有着常人没有的巨大天赋（这也是自媒体最爱的爽文），一个是只要“刻意练习”一万个小时以上就能成为大师（这是老师和家长最爱的教条），这两种说法都容易误导人。天才并不存在，盲目训练也可能适得其反，但是高效且正确的长期训练可以让普通人在任何方面成为大师
2023-12-04 11:42:55
923
原创 聊聊测试左移到需求阶段
测试左移是多年来测试行业的热门话题，在实际的践行中容易停留在“意识流”层面，仅仅是鼓励测试人员应该“主动做什么”，然而在业务压力大的常态下，被鼓励的尝试往往无疾而终。只有基于敏捷理念的理解，对研发生命周期各个环节进行质量内建实践，才能把测试左移落实成好习惯，形成好流程，最终内化为敏捷团队的本能
2023-11-11 00:06:29
192
原创 聊聊精益需求的产生过程
对产品研发而言，最大的风险在于用户需求没有挖掘清楚，而且产品的需求描述和传递过程失真，最终导致生产出来的产品不是用户真正想要的。精益需求生产过程，就是希望尽可能地降低这种极大的生产浪费。这套互联网行业的生产过程，也适用于任何行业的产品精益生产
2023-10-21 14:23:17
144
原创 聊聊团队如何开始敏捷转型（合辑共15篇）
专辑《团队如何开始敏捷转型》共有15篇文章，涵盖知识领域非常丰富,先从敏捷理念的知识开始介绍，阐述了敏捷宣言和原则对于测试活动的启发，引出敏捷测试的定义。接下来，本合辑针对主流的敏捷实践框架及其价值观做了核心知识回顾，包括Scrum、XP、用户故事、精益看板和大规模敏捷框架SAFe等，然后分别从测试视角详细分享了值得关注和尝试的敏捷措施
2023-09-24 09:14:51
144
原创 聊聊“心流”的修炼
“心流”Flow，就是在工作/学习/生活中的一种高效忘我状态，这个过程能带来显著的幸福感和成就感。本文先介绍积极心理学的“心流”理论，来自Mihaly Csikszentmihali，再谈谈教练或leader如何在团队中修炼成员的心流
2023-09-08 10:30:32
111
原创 聊聊每日站会
每日站会是一线敏捷团队自己的会议，快速同步成员为达成迭代目标所做出的贡献，并对有风险的阻碍采取行动，有利于提升每个成员对项目的认知程度。如果测试人员所在的项目团队没有组织每日站会，一线测试团队也可以自行组织，用很少的时间高效沟通，受益良多
2023-09-03 15:49:04
201
原创 聊聊大规模敏捷框架和测试启发
知名公司敏捷转型往往涉及大部门的所有员工，甚至跨多个部门一起进行敏捷开发，相关全职人力动辄50人以上，甚至高达数百人。因此我们有必要引入大规模敏捷实践框架，对于多个特性团队（8个以上，甚至数十个团队）联合研发，该如何协调，交付更高层次的价值呢？
2023-08-30 11:09:49
114
原创 聊聊敏捷实践的“个体与交互”
敏捷宣言有重要的一句话：个体和交互胜过过程和工具。作为工程师，我们眼里往往只有后者-过程和工具，因为通过它们能实现看得见的价值。可能因为我们大部分是计算机科学或软件相关专业，而“个体和交互”更多关注于心理学和行为学，导致这块是敏捷实践上最难以改进的“软”地方
2023-08-25 16:57:42
105
原创 聊聊代码的整洁（上）
《代码整洁之道》这本书最有影响力的一个观点，就是代码的好名字本身就解释了最重要的信息，如无必要，不要增加代码注释。这个观点和传统软件质量观点是不同的
2023-08-08 15:29:08
69
原创 聊聊单元测试的整洁
敏捷及TDD鼓舞了很多程序员编写自动化的单元测试，但是他们经常会遗漏编写好测试时很重要的细节。测试代码也需要遵守一定的质量标准，“脏测试”等同于（甚至还不如）“没测试”
2023-08-01 12:05:06
118
原创 聊聊精益看板和测试启发
精益理论的核心是造物先造人，消除浪费和持续改善。每个员工都有机会发现自己工作方式的问题、解决问题和进行改进。我们通过减少不增值的浪费缩短交货时间（比如，从客户下订单到公司收到现金为止）。而缺陷其实是一种不必要的浪费，从精益理论中我们可获得不少测试启发
2023-07-21 17:45:37
118
原创 聊聊用户故事的估算和拆解
对于Scrum和用户故事实践的最大难点，我相信是如何估算用户故事的大小，如何拆解它？过大的用户故事会带来一系列的沟通复杂度和潜在质量风险，最好的用户故事是不超过2-3开发人日就能够完成的。本文重温行业经典的估算和拆解方法，并从测试人员的角度思考它
2023-07-18 14:42:38
240
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人