Toggle navigation
Bruce Wong Blog
Home
About
Tags
Tags
好奇心是通往学习者心态的捷径
Me
OKR
Agile
敏捷
Retrospective
回顾会
ProductOwner
Acceptance Criteria(AC)
验收标准
Microsoft
技术
State of Agile Report
随笔
译文
User Story
User Story Mapping
影响地图
Kanban
敏捷之旅
年终总结
Scrum Patterns
Scrum
Coach/Facilitate
DDD
TDD
系统思考
AI
Me
Welcome My Home
OKR
OKR实践——重要紧急矩阵
OKR实战系列(四)
《绩效领导力：使用OKR成就超出期望的未来组织》读后感
探密"一学就会，一用就废"的OKR
《敏捷绩效领导力》课程学后感
如何引导更多的人参与团队OKR
OKR实战系列(三)
什么样的目标是适合OKR的?
OKR实战系列(二)
OKR应用中的一些误区
OKR实战系列(一)
Agile
饮鸠止渴——团队的慢性毒药
系统思考实践(4)
为什么你的团队会抵制变化
系统思考实践(3)
为什么对标准的要求会越来越低
系统思考实践(2)
AI生成文档?代码有用，领域知识为王
基于业务规则拆分用户故事
避免工作局促
AI并非万能，有效沟通是关键
一个“敏捷”项目复盘的思考
如何应对复杂任务
TDD系列
AI是助力还是取代我们？
“离开”还是“拓展”你的舒适区
是什么增加了系统的复杂度
产品价值 vs Bug数量
2023长春敏捷之旅——线上活动总结
2023长春敏捷之旅——线下活动总结
用户思维 VS 技术思维
头脑风暴小工具-影响地图
领导和团队的自主权
《敏捷实战-破解敏捷落地的60个难题》读后感（二）
权衡矩阵
《敏捷实战-破解敏捷落地的60个难题》读后感（一）
关于验收标准，你需要知道的一切（译）
暴露阻碍还是让他“顺利”的流动
寻找工作中焦虑的源头
系统思考实践(1)
保持住你写代码的姿势，你就是黑带了
尹哲老师代码工作坊心得
为什么大家都喜欢“人天”作为估算单位？
再见二月，谢谢你带给我的思考
产品团队业务思维重要性
构建有参与感的干系人小组指南(译)
了解和干系人合作的力量和最佳实践
通过假设地图进行产品待办列表排序
假设驱动开发(HDD)
项目经理和Scrum Master之间的不同(译)
A scrum master coaches, teaches and mentors
Scrum Patterns(38):产品的自豪感(Product Pride)
A Scrum Book——The Spirit of the Game
ATDD的小妙用
一个可以提前结项的敏捷项目
做一个有职业操守的软件匠人
TDD系列
持续发酵的TDD
TDD系列
简约而不简单的Kanban方法
程序员如何保证自己开发的正确性——测试开发有感
TDD系列
对已有系统如何开展TDD
TDD系列
无处不在的TDD思维
TDD系列
Scrum Patterns之理解各种团队模式
游戏化与驱动力
《游戏化实战》读后感
配置Mountebank环境
mountebank系列(2)
一次TDD(Test Driven Development)尝试感受
TDD系列
一个简单的方法基于风险排列优先级
一句话回顾会
验收测试驱动开发后记
Scrum Master应该如何参与每日Scrum
隐喻回顾会
一次ATDD的团队实践
Thinking Agile 2021，Being Agile 2022
写在2021年末的一些感悟
从一个乙方视角聊聊敏捷项目
Scrum模式之估算点模式读后感
固定价格项目能否敏捷
第15份敏捷年度状态调查
站立会(Daily Scrum)我们说些什么
Scrum小技巧
如何进行用户故事估算
10月9日Ethan Huang分享感受
Scrum Patterns(36):Sprint回顾(译)
A Scrum Book——The Spirit of the Game
一次Product Owner的假设引发的思考
Scrum Patterns(66):昨日天气(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(71):冲刺目标(译)
A Scrum Book——The Spirit of the Game
在用户故事中应该包含多细的细节？(译)
来自Mike Cohn大师的方法
Scrum Patterns(87):持续改进脉冲(Kaizen Pulse)(译)
A Scrum Book——The Spirit of the Game
梳理会(Refinement Meeting)在Scrum中是活动还是事件？
《The Scrum Guide》重读有感(6)
一次基于业务规则的用户故事拆分
Scrum Master的职责
《The Scrum Guide》重读有感(5)
分享几个团队敏捷转型过程中的故事
你以为的你以为未必是你以为的
团队决策小技巧
Scrum Patterns(87):完成定义(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(37):MetaScrum(译)
A Scrum Book——The Spirit of the Game
《看板方法官方指南》中文版发布了！
Sprint Review != Demo
《The Scrum Guide》重读有感(4)
SM和PO如何参与Daily Scrum
《The Scrum Guide》重读有感(3)
Scrum Team不等于Development Team
《The Scrum Guide》重读有感(2)
重学Scrum三大支柱
《The Scrum Guide》重读有感(1)
<精益创业>读后感
一次用户故事拆分分享
用户故事拆分招数全景图(译)
The Story Splitting Flowchart
用户故事是垂直的切片(译)
User Stories Are Vertical Slices
Scrum Patterns(9):小团队(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(29):每日Scrum(译)
A Scrum Book——The Spirit of the Game
用户故事拆分速查手册(译)
Story Splitting Cheat Sheet
一次用户故事拆分实战的感想
Power Question带来的改变
人生如戏，戏如人生
敏捷剧本杀玩后感
为何要构建团队契约
Scrum Patterns(57):团队('Pigs')的估算(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(64):梳理产品待办列表(译)
A Scrum Book——The Spirit of the Game
尝试从用户的角度思考
PO的姿势系列
Scrum Patterns(65):准备就绪的标准 DoR(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(24):迭代计划会(译)
A Scrum Book——The Spirit of the Game
敏捷开发需要内外兼修
一次<欣赏式探询>的体验
2020长春敏捷之旅总结
Kanban != 看板
学习Kanban方法有感
一次产品路线图(Roadmap)的探索之旅
绘制一张影响地图
一次有效的产品需求头脑风暴
一个拆分用户故事的案例分享
SPIDR拆分法
多团队如何评估故事点(译)
“How to Estimate Story Points With Multiple Teams” by Mike Cohn
理解用户故事的本质
传统研发团队的思维转变过程
团队如何快速对齐需求认知
Cosplay原型游戏
用户故事信息过多或过少带来的问题
来自Mike Cohn大师的建议
五种简单高效的拆分用户故事的方法
来自Mike Cohn大师的方法
我们需要软件工艺
《软件工艺》读后感
重新理解“软件工程”
《软件工艺》读后感
打破Scrum的五个误区(译)
Busting Five Scrum Myths by Mike Cohn
多米诺游戏工作坊(scrum 版) 观后感
什么是打桩服务
mountebank系列(1)
10种让虚拟化合作更好的方式(译)
规模化敏捷选择地图
Stop Starting Start Finishing
越多真的越好吗？
第14份敏捷年度状态调查
问卷调查——敏捷落地过效果探测器
迭代流程梳理会
验收标准如何写？
PO的姿势系列
感恩回顾会
敏捷
饮鸠止渴——团队的慢性毒药
系统思考实践(4)
为什么你的团队会抵制变化
系统思考实践(3)
为什么对标准的要求会越来越低
系统思考实践(2)
OKR实践——重要紧急矩阵
OKR实战系列(四)
AI生成文档?代码有用，领域知识为王
基于业务规则拆分用户故事
避免工作局促
AI并非万能，有效沟通是关键
一个“敏捷”项目复盘的思考
如何应对复杂任务
TDD系列
AI是助力还是取代我们？
“离开”还是“拓展”你的舒适区
是什么增加了系统的复杂度
产品价值 vs Bug数量
2023长春敏捷之旅——线上活动总结
2023长春敏捷之旅——线下活动总结
用户思维 VS 技术思维
头脑风暴小工具-影响地图
领导和团队的自主权
《敏捷实战-破解敏捷落地的60个难题》读后感（二）
权衡矩阵
《敏捷实战-破解敏捷落地的60个难题》读后感（一）
关于验收标准，你需要知道的一切（译）
暴露阻碍还是让他“顺利”的流动
寻找工作中焦虑的源头
系统思考实践(1)
保持住你写代码的姿势，你就是黑带了
尹哲老师代码工作坊心得
为什么大家都喜欢“人天”作为估算单位？
再见二月，谢谢你带给我的思考
产品团队业务思维重要性
构建有参与感的干系人小组指南(译)
了解和干系人合作的力量和最佳实践
《绩效领导力：使用OKR成就超出期望的未来组织》读后感
通过假设地图进行产品待办列表排序
假设驱动开发(HDD)
项目经理和Scrum Master之间的不同(译)
A scrum master coaches, teaches and mentors
Scrum Patterns(38):产品的自豪感(Product Pride)
A Scrum Book——The Spirit of the Game
ATDD的小妙用
一个可以提前结项的敏捷项目
做一个有职业操守的软件匠人
TDD系列
持续发酵的TDD
TDD系列
简约而不简单的Kanban方法
探密"一学就会，一用就废"的OKR
《敏捷绩效领导力》课程学后感
程序员如何保证自己开发的正确性——测试开发有感
TDD系列
对已有系统如何开展TDD
TDD系列
无处不在的TDD思维
TDD系列
Scrum Patterns之理解各种团队模式
游戏化与驱动力
《游戏化实战》读后感
配置Mountebank环境
mountebank系列(2)
一次TDD(Test Driven Development)尝试感受
TDD系列
一个简单的方法基于风险排列优先级
一句话回顾会
验收测试驱动开发后记
Scrum Master应该如何参与每日Scrum
隐喻回顾会
一次ATDD的团队实践
Thinking Agile 2021，Being Agile 2022
写在2021年末的一些感悟
从一个乙方视角聊聊敏捷项目
Scrum模式之估算点模式读后感
固定价格项目能否敏捷
第15份敏捷年度状态调查
站立会(Daily Scrum)我们说些什么
Scrum小技巧
如何进行用户故事估算
10月9日Ethan Huang分享感受
Scrum Patterns(36):Sprint回顾(译)
A Scrum Book——The Spirit of the Game
一次Product Owner的假设引发的思考
Scrum Patterns(66):昨日天气(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(71):冲刺目标(译)
A Scrum Book——The Spirit of the Game
在用户故事中应该包含多细的细节？(译)
来自Mike Cohn大师的方法
Scrum Patterns(87):持续改进脉冲(Kaizen Pulse)(译)
A Scrum Book——The Spirit of the Game
梳理会(Refinement Meeting)在Scrum中是活动还是事件？
《The Scrum Guide》重读有感(6)
一次基于业务规则的用户故事拆分
Scrum Master的职责
《The Scrum Guide》重读有感(5)
分享几个团队敏捷转型过程中的故事
你以为的你以为未必是你以为的
团队决策小技巧
Scrum Patterns(87):完成定义(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(37):MetaScrum(译)
A Scrum Book——The Spirit of the Game
《看板方法官方指南》中文版发布了！
Sprint Review != Demo
《The Scrum Guide》重读有感(4)
SM和PO如何参与Daily Scrum
《The Scrum Guide》重读有感(3)
Scrum Team不等于Development Team
《The Scrum Guide》重读有感(2)
重学Scrum三大支柱
《The Scrum Guide》重读有感(1)
<精益创业>读后感
一次用户故事拆分分享
用户故事拆分招数全景图(译)
The Story Splitting Flowchart
用户故事是垂直的切片(译)
User Stories Are Vertical Slices
Scrum Patterns(9):小团队(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(29):每日Scrum(译)
A Scrum Book——The Spirit of the Game
用户故事拆分速查手册(译)
Story Splitting Cheat Sheet
一次用户故事拆分实战的感想
Power Question带来的改变
人生如戏，戏如人生
敏捷剧本杀玩后感
为何要构建团队契约
Scrum Patterns(57):团队('Pigs')的估算(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(64):梳理产品待办列表(译)
A Scrum Book——The Spirit of the Game
尝试从用户的角度思考
PO的姿势系列
Scrum Patterns(65):准备就绪的标准 DoR(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(24):迭代计划会(译)
A Scrum Book——The Spirit of the Game
敏捷开发需要内外兼修
一次<欣赏式探询>的体验
2020长春敏捷之旅总结
Kanban != 看板
学习Kanban方法有感
一次产品路线图(Roadmap)的探索之旅
绘制一张影响地图
一次有效的产品需求头脑风暴
一个拆分用户故事的案例分享
SPIDR拆分法
多团队如何评估故事点(译)
“How to Estimate Story Points With Multiple Teams” by Mike Cohn
理解用户故事的本质
传统研发团队的思维转变过程
团队如何快速对齐需求认知
Cosplay原型游戏
用户故事信息过多或过少带来的问题
来自Mike Cohn大师的建议
五种简单高效的拆分用户故事的方法
来自Mike Cohn大师的方法
我们需要软件工艺
《软件工艺》读后感
重新理解“软件工程”
《软件工艺》读后感
打破Scrum的五个误区(译)
Busting Five Scrum Myths by Mike Cohn
多米诺游戏工作坊(scrum 版) 观后感
什么是打桩服务
mountebank系列(1)
10种让虚拟化合作更好的方式(译)
规模化敏捷选择地图
Stop Starting Start Finishing
越多真的越好吗？
第14份敏捷年度状态调查
问卷调查——敏捷落地过效果探测器
迭代流程梳理会
验收标准如何写？
PO的姿势系列
感恩回顾会
Retrospective
一个“敏捷”项目复盘的思考
一句话回顾会
隐喻回顾会
感恩回顾会
回顾会
一个“敏捷”项目复盘的思考
一句话回顾会
隐喻回顾会
感恩回顾会
ProductOwner
基于业务规则拆分用户故事
避免工作局促
AI并非万能，有效沟通是关键
如何应对复杂任务
TDD系列
是什么增加了系统的复杂度
产品价值 vs Bug数量
用户思维 VS 技术思维
头脑风暴小工具-影响地图
通过假设地图进行产品待办列表排序
假设驱动开发(HDD)
用户故事地图——让迭代计划灵动起来
一次ATDD的团队实践
Scrum模式之估算点模式读后感
如何进行用户故事估算
10月9日Ethan Huang分享感受
一次Product Owner的假设引发的思考
在用户故事中应该包含多细的细节？(译)
来自Mike Cohn大师的方法
尝试从用户的角度思考
PO的姿势系列
一次产品路线图(Roadmap)的探索之旅
绘制一张影响地图
一次有效的产品需求头脑风暴
一个拆分用户故事的案例分享
SPIDR拆分法
理解用户故事的本质
传统研发团队的思维转变过程
团队如何快速对齐需求认知
Cosplay原型游戏
如何组织一场用户故事地图工作坊
增强团队协作，洞察真实需求，研磨优良产品
一次用户故事地图之旅
用户故事信息过多或过少带来的问题
来自Mike Cohn大师的建议
五种简单高效的拆分用户故事的方法
来自Mike Cohn大师的方法
验收标准如何写？
PO的姿势系列
Acceptance Criteria(AC)
验收标准如何写？
PO的姿势系列
验收标准
验收标准如何写？
PO的姿势系列
Microsoft
AI是助力还是取代我们？
让AI看见——Azure OpenAI GPT-4 Turbo with Vision体验
Azure AI Studio使用体验——企业级AI工厂
Copilot Studio使用初体验
Microsoft Power Platform 介绍
技术
DDD建模 vs 传统开发
领域驱动设计(DDD)系列
保持住你写代码的姿势，你就是黑带了
尹哲老师代码工作坊心得
做一个有职业操守的软件匠人
TDD系列
持续发酵的TDD
TDD系列
程序员如何保证自己开发的正确性——测试开发有感
TDD系列
对已有系统如何开展TDD
TDD系列
无处不在的TDD思维
TDD系列
配置Mountebank环境
mountebank系列(2)
一次TDD(Test Driven Development)尝试感受
TDD系列
DDD与CQRS的关系
领域驱动设计(DDD)系列
领域驱动设计是软件设计思维方式的转变
领域驱动设计(DDD)系列
什么是打桩服务
mountebank系列(1)
Microsoft Power Platform 介绍
State of Agile Report
第15份敏捷年度状态调查
第14份敏捷年度状态调查
随笔
饮鸠止渴——团队的慢性毒药
系统思考实践(4)
为什么你的团队会抵制变化
系统思考实践(3)
为什么对标准的要求会越来越低
系统思考实践(2)
AI生成文档?代码有用，领域知识为王
AI并非万能，有效沟通是关键
如何应对复杂任务
TDD系列
AI是助力还是取代我们？
“离开”还是“拓展”你的舒适区
是什么增加了系统的复杂度
产品价值 vs Bug数量
让AI看见——Azure OpenAI GPT-4 Turbo with Vision体验
Azure AI Studio使用体验——企业级AI工厂
Copilot Studio使用初体验
用户思维 VS 技术思维
程序员如何利用AI加持
领导和团队的自主权
《敏捷实战-破解敏捷落地的60个难题》读后感（二）
权衡矩阵
《敏捷实战-破解敏捷落地的60个难题》读后感（一）
与AI的相处之道
暴露阻碍还是让他“顺利”的流动
寻找工作中焦虑的源头
系统思考实践(1)
为什么大家都喜欢“人天”作为估算单位？
再见二月，谢谢你带给我的思考
产品团队业务思维重要性
构建有参与感的干系人小组指南(译)
了解和干系人合作的力量和最佳实践
Scrum Patterns(38):产品的自豪感(Product Pride)
A Scrum Book——The Spirit of the Game
ATDD的小妙用
一个可以提前结项的敏捷项目
信任、倾听、正念、感恩
游戏化与驱动力
《游戏化实战》读后感
Thinking Agile 2021，Being Agile 2022
写在2021年末的一些感悟
从一个乙方视角聊聊敏捷项目
Scrum模式之估算点模式读后感
固定价格项目能否敏捷
如何进行用户故事估算
10月9日Ethan Huang分享感受
一次Product Owner的假设引发的思考
梳理会(Refinement Meeting)在Scrum中是活动还是事件？
《The Scrum Guide》重读有感(6)
Scrum Master的职责
《The Scrum Guide》重读有感(5)
Sprint Review != Demo
《The Scrum Guide》重读有感(4)
SM和PO如何参与Daily Scrum
《The Scrum Guide》重读有感(3)
Scrum Team不等于Development Team
《The Scrum Guide》重读有感(2)
重学Scrum三大支柱
《The Scrum Guide》重读有感(1)
<精益创业>读后感
换个角度看问题,锻炼成长型思维
是需求还是我们自己的Bug？
整理了最近一些对我有感触的话
我们需要软件工艺
《软件工艺》读后感
重新理解“软件工程”
《软件工艺》读后感
多米诺游戏工作坊(scrum 版) 观后感
Stop Starting Start Finishing
越多真的越好吗？
我们生活中忽略的WHY的力量
<黄金圈法则>
游戏化工作靠谱吗?
译文
关于验收标准，你需要知道的一切（译）
构建有参与感的干系人小组指南(译)
了解和干系人合作的力量和最佳实践
项目经理和Scrum Master之间的不同(译)
A scrum master coaches, teaches and mentors
Scrum Patterns(36):Sprint回顾(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(66):昨日天气(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(71):冲刺目标(译)
A Scrum Book——The Spirit of the Game
在用户故事中应该包含多细的细节？(译)
来自Mike Cohn大师的方法
Scrum Patterns(87):持续改进脉冲(Kaizen Pulse)(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(87):完成定义(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(37):MetaScrum(译)
A Scrum Book——The Spirit of the Game
用户故事拆分招数全景图(译)
The Story Splitting Flowchart
用户故事是垂直的切片(译)
User Stories Are Vertical Slices
Scrum Patterns(9):小团队(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(29):每日Scrum(译)
A Scrum Book——The Spirit of the Game
用户故事拆分速查手册(译)
Story Splitting Cheat Sheet
Scrum Patterns(57):团队('Pigs')的估算(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(64):梳理产品待办列表(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(65):准备就绪的标准 DoR(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(24):迭代计划会(译)
A Scrum Book——The Spirit of the Game
多团队如何评估故事点(译)
“How to Estimate Story Points With Multiple Teams” by Mike Cohn
打破Scrum的五个误区(译)
Busting Five Scrum Myths by Mike Cohn
10种让虚拟化合作更好的方式(译)
规模化敏捷选择地图
User Story
基于业务规则拆分用户故事
避免工作局促
通过假设地图进行产品待办列表排序
假设驱动开发(HDD)
用户故事地图——让迭代计划灵动起来
验收测试驱动开发后记
一次ATDD的团队实践
Scrum模式之估算点模式读后感
如何进行用户故事估算
10月9日Ethan Huang分享感受
在用户故事中应该包含多细的细节？(译)
来自Mike Cohn大师的方法
一次基于业务规则的用户故事拆分
一次用户故事拆分分享
用户故事拆分招数全景图(译)
The Story Splitting Flowchart
用户故事是垂直的切片(译)
User Stories Are Vertical Slices
用户故事拆分速查手册(译)
Story Splitting Cheat Sheet
一次用户故事拆分实战的感想
Power Question带来的改变
一个拆分用户故事的案例分享
SPIDR拆分法
理解用户故事的本质
传统研发团队的思维转变过程
如何组织一场用户故事地图工作坊
增强团队协作，洞察真实需求，研磨优良产品
一次用户故事地图之旅
用户故事信息过多或过少带来的问题
来自Mike Cohn大师的建议
五种简单高效的拆分用户故事的方法
来自Mike Cohn大师的方法
User Story Mapping
用户故事地图——让迭代计划灵动起来
如何组织一场用户故事地图工作坊
增强团队协作，洞察真实需求，研磨优良产品
一次用户故事地图之旅
影响地图
头脑风暴小工具-影响地图
一次产品路线图(Roadmap)的探索之旅
绘制一张影响地图
Kanban
简约而不简单的Kanban方法
《看板方法官方指南》中文版发布了！
Kanban != 看板
学习Kanban方法有感
敏捷之旅
2023长春敏捷之旅——线上活动总结
2023长春敏捷之旅——线下活动总结
一次<欣赏式探询>的体验
2020长春敏捷之旅总结
年终总结
写在2023年最后一天
写在2022年最后一天
写在2021年最后一天
写在2020年最后一天
Scrum Patterns
Scrum Patterns(38):产品的自豪感(Product Pride)
A Scrum Book——The Spirit of the Game
Scrum Patterns之理解各种团队模式
Scrum模式之估算点模式读后感
Scrum Patterns(36):Sprint回顾(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(66):昨日天气(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(71):冲刺目标(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(87):持续改进脉冲(Kaizen Pulse)(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(87):完成定义(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(37):MetaScrum(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(9):小团队(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(29):每日Scrum(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(57):团队('Pigs')的估算(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(64):梳理产品待办列表(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(65):准备就绪的标准 DoR(译)
A Scrum Book——The Spirit of the Game
Scrum Patterns(24):迭代计划会(译)
A Scrum Book——The Spirit of the Game
Scrum
用户思维 VS 技术思维
关于验收标准，你需要知道的一切（译）
为什么大家都喜欢“人天”作为估算单位？
构建有参与感的干系人小组指南(译)
了解和干系人合作的力量和最佳实践
项目经理和Scrum Master之间的不同(译)
A scrum master coaches, teaches and mentors
Scrum Patterns(38):产品的自豪感(Product Pride)
A Scrum Book——The Spirit of the Game
Scrum Patterns之理解各种团队模式
Scrum Master应该如何参与每日Scrum
从一个乙方视角聊聊敏捷项目
站立会(Daily Scrum)我们说些什么
Scrum小技巧
梳理会(Refinement Meeting)在Scrum中是活动还是事件？
《The Scrum Guide》重读有感(6)
Scrum Master的职责
《The Scrum Guide》重读有感(5)
分享几个团队敏捷转型过程中的故事
Sprint Review != Demo
《The Scrum Guide》重读有感(4)
SM和PO如何参与Daily Scrum
《The Scrum Guide》重读有感(3)
Scrum Team不等于Development Team
《The Scrum Guide》重读有感(2)
重学Scrum三大支柱
《The Scrum Guide》重读有感(1)
Coach/Facilitate
一个简单的方法基于风险排列优先级
一句话回顾会
Scrum Master应该如何参与每日Scrum
隐喻回顾会
一次ATDD的团队实践
站立会(Daily Scrum)我们说些什么
Scrum小技巧
分享几个团队敏捷转型过程中的故事
你以为的你以为未必是你以为的
团队决策小技巧
DDD
DDD建模 vs 传统开发
领域驱动设计(DDD)系列
AI生成文档?代码有用，领域知识为王
DDD与CQRS的关系
领域驱动设计(DDD)系列
领域驱动设计是软件设计思维方式的转变
领域驱动设计(DDD)系列
TDD
如何应对复杂任务
TDD系列
保持住你写代码的姿势，你就是黑带了
尹哲老师代码工作坊心得
做一个有职业操守的软件匠人
TDD系列
持续发酵的TDD
TDD系列
程序员如何保证自己开发的正确性——测试开发有感
TDD系列
对已有系统如何开展TDD
TDD系列
无处不在的TDD思维
TDD系列
一次TDD(Test Driven Development)尝试感受
TDD系列
系统思考
饮鸠止渴——团队的慢性毒药
系统思考实践(4)
为什么你的团队会抵制变化
系统思考实践(3)
为什么对标准的要求会越来越低
系统思考实践(2)
寻找工作中焦虑的源头
系统思考实践(1)
AI
AI生成文档?代码有用，领域知识为王
AI并非万能，有效沟通是关键
AI是助力还是取代我们？
让AI看见——Azure OpenAI GPT-4 Turbo with Vision体验
Azure AI Studio使用体验——企业级AI工厂
Copilot Studio使用初体验
程序员如何利用AI加持
与AI的相处之道
