- 博客(214)
- 收藏
- 关注
RSS订阅原创 A2 最佳学习方法
那个时候就要开始找参考书，准备实例和联系，准备和教学的过程中，就让我更了解里面的概念，比如挣值分析(Earned Value)，可以不用对着教材，直接在白板写出来给大家讲的地步，也能很顺利自然地解答学生的问题。2017年开始教敏捷ACP课，也同样做很多授课前准备，同时间也开始写分享文章，把教材 PPT 里的 知识点编成分享文章，放朋友圈，优快云和公众号等，覆盖更多人众，过程中又进一步理清敏捷、精益管理的道理，比如平常给人家讲课比较随意，但成文章就必须精简内容。现在回看，以上每一点都是学习，帮我更了解。
2025-03-24 15:33:07
674
原创 A1 PPT 投影
2005年，我第一次做PMP项目管理培训，只是按PPT的点读，再补充解释，当天立马收到学生投诉。所以现场讲解，我都会选择用白板与水笔，或黑板与粉笔， （如果有学员远程听课，我会打开空白excel表，用电脑笔边画边讲）。如果有准备PPT的话，我在讲完后，才打开PPT，只用来总结重点，不会按PPT逐条读。著名的18分种TED Talk演讲，都是以讲故事为主，有些会投少数几张能辅助学员更好了解故事内容的幻灯片，我听过几次精彩的TED Talk，纯讲，一个幻灯片都没有。
2025-03-21 15:07:35
425
原创 《A++ 敏捷开发》- 19 协作改进整个系统
“专注用户，从顾客的角度生产产品。”某次现场培训，我分享了丰田汽车故事后，请学员分组讨论，写出对工作最有帮助的3条。以上是某组的第一条，我请他们解释说明。“我是做开发的，反思时发现其实不清楚我的工作对客户有什么作用。”一位年轻的编码人员说。因为编码工作大部分都是由产品经理或项目经理过滤后分配，所以如果你随便问身边的编码人员，70-80%的可能不知道用户为什么要这样做，要开发的功能有什么价值。这位年轻编码人员的分享让我想到2年前某公司要推行需求与研发分离的故事。质量部经理：以前需求是研发团队的一部分，
2025-03-14 15:58:25
754
原创 《A++ 敏捷开发》- 18 软件需求
需求没有按价值过滤与分析，分优先级；没有全面考虑各种场景没有全面识别利益相关者没有明确描述非功能需求，并可验证用户故事卡需求评审需求分析：RDM 3.5, 3.6, 3.2 ( 场景 )干系人：PLAN 2.4, MC 2.2 ( 沟通的策划与监控 )非功能需求：RDM 2.2 ( 客户需求，包括功能与非功能需求 )需求卡片：RDM 2.2 , 2.4 ( 客户需求与活动或工作产物之间双向可追溯 ）需求评审：RDM 2.3。
2025-03-07 16:11:48
1297
原创 《A++ 敏捷开发》- 17 持续集成
为了避免客户验收前或使用后才暴露大量棘手缺陷，可能要花很长时间才能发现并解决，便应依据精益和系统工程的原则，把系统拆分成子系统/模块，先开发并测试子系统/模块、集成、再测试，按部就班地完成整个软件开发。
2025-02-28 10:24:38
1136
原创 《A++ 敏捷开发》- 16 评审与结对编程
提高代码质量和可读性（编码规范）提高代码复用加强测试驱动开发一边写代码一边说提问，如：这方法是否归为这个类每人带纸和笔（最好铅笔）不断想复用客户：我猜你说的3步是：第一步，高层认同软件质量问题的严重性，为此交过学费，知道损失多大第二步，管理层不仅了解软件的质量问题和改善措施，更需要内部立项做培训和投入资源（人力），做过程改进第三步才是具体的培训课。因为缺乏第一步和第二步，所以之前做完了结对编程培训后，没有效果我：厉害，完全对。
2025-02-21 20:16:01
1009
原创 《A++ 敏捷开发》- 20 从 AI 到最佳设计
虽然本部分分章节讨论需求、设计、编码、集成、评审、测试各过程的最佳实践，但若想改进应先设定总体目标，用多种视角看整个系统，再定各过程如何配合，好比建筑师按你的新花园别墅要求（如2层4房2厅，预算在一千万内）一样，必先做总体别墅设计，而不是先分别房间、客厅。
2025-02-19 15:10:26
787
原创 《A++ 敏捷开发》- 15 TDD与重构
从50年代起，软件系统越来越普遍，规模越来越大，越复杂。但延迟甚至失败的项目也越来越多。如果我们沿用系统工程的严格思维，是否可以像造一架飞机一样，写好大型的复杂软件？1968年，Dijkstra提出要structured programming方式编程，所有的程序都应该跟设计飞机一样，要先总体设计，然后一层一层分解下去，程序里不能随便用 GOTO 语句。七八十年代的软件开发几乎都是用这种思路去设计，但发现复杂项目还是经常失败或者严重延误。
2025-02-12 16:13:01
1195
原创 《A++ 敏捷开发》- 14 精益与敏捷
看完某研发部总监的缺陷分析报告后，我问：“你们什么时候做分析？总监：“产品发版后。”他们最近一次发版是八月份，立项早在三月份已经开始。我：“如果你们分析的目的是之后做改进，发版后才分析的作用不大。要想有真正的效果，就必须让开发团队每次2-4周迭代后一起做回顾分析。虽然总监说很赞同，但估计他心里想：“我们这几个月一直天天都很忙，中间怎么能腾出时间做回顾复盘！一条原则应能改变他的思路，从2013年起，这原则一直驱动我每天每月做规划。
2025-01-16 13:44:54
646
1
原创 利用工作坊促进持续改善
如果领导关注质量改进并支持，首先要估计改进能带来多少收益，估计能减少多少返工成本，减除投入的成本，包括人力资源、培训、辅导等，然后申请立项，才可以把改进当成正式项目来策划和监控。把所有关键利益相关者都拉到一起，用2到3天的工作坊培训，促进部门尽快制定改进目标和行动计划，挑选项目做试点，并预估何时可以取得效果，再大规模推广。因为大家第一次都没有经验，不知道如何入手，工作坊可以让所有人一起讨论和制定改进目标与计划。本来可能需要几个月来回讨论修正，现在只能压缩到2、3天。
2024-12-10 08:42:10
949
原创 《A++ 敏捷开发》- 7 策划与监控
自己可以首先使用刚才的原型法制定公司总体的过程改进计划（要注意刚才我举的例子只是改进小组的计划，并不是公司总体计划），并要求项目组针对改进目标下制定自己的改进项目计划，他们后面可以再使用APF的方法，针对软件开发项目制定计划和监控，后面便应可以回应开会时胡总要实时监控项目偏差的要求。
2024-11-28 16:33:23
788
原创 《A++ 敏捷开发》- 26 根与翼
今年被质量经理邀请参加他们的质量沙龙，但只有30分钟，我就用了TED演讲思路，用了17分钟讲软件开发公司的常见质量问题和改进措施。你觉得下面4种工作，哪一类工种占的工作量最多？编码与代码设计。交付后的所有工作，包括维护、更新与缺陷修正。交付前的评审、静态扫描、测试与缺陷修正。项目管理与监控。从2012年Capers Jones对美国软件公司的统计中看到，编码只排第二（占开发工作量的25%），测试与评审和缺陷修改的总工作量才是排第一（占30%）。
2024-09-14 16:06:37
1266
1
原创 《A++ 敏捷开发》- 13 从团队实验 到持续改善
反观世界级企业如丰田汽车，从二战后一直到现在不断持续改善，超越了原本的美国汽车巨头。“90年代，丰田汽车共8万员工，每年共用4百万条过程改进建议，平均每员工每年有50条。”Dr Juran 用以上例子什么是企业持续改善文化。也正是这种改善动力让丰田超越竞争对手，成为全球最大汽车公司。
2024-08-12 10:10:08
820
原创 《A++ 敏捷开发》- 12 软硬兼施
某次量化根因分析培训里，我跟各现场同学说：“前面我们说可以用鱼骨图分析根本原因，但我不建议在迭代回顾时用它找根因。知道是什么原因吗？请问你是读那所高校？当时是否自己选的？”“XX大学。当时是我自己挑选的。”“现在回想，是否觉得XX大学挺不错？ ”“是的。”“如果是自己选择的，都会觉得比其他好。1956年，Brehm 决策影响实验 （详见附件）验证了这心理。 所以如果用鱼骨图分析根因，大家都会觉得这只是组长的分析，并非我自己的想法，后面便没有动力执行。”前面第二章里的粮食分配实验也验证了团队只有兴趣执行自己
2024-08-08 08:02:51
720
原创 《A++ 敏捷开发》- 11 团队协作 分析根因
公司主要为全国不同的医院开发医疗行业的软件产品。六年前，公司规模还不到五百人；四年前，公司办公地点扩大了一倍，占地3000平方米，总人数也增加到接近900人。尽管公司骨干比较稳定，但新人的流动性很大。公司制定了很多量化指标，如需求一次性通过率、开发速度、测试缺陷密度等，并不断监控，但并未取得明显改善。技术总监问：“请教一个一直困扰我的问题——如何激励团队，让他们更有积极性？“现在你们员工的收入底薪和奖金的比例大概是多少？总监：“大概七成底薪，其他的就按每人每年的表现分发。“主要依赖主管的打分吗？
2024-07-24 09:20:12
1274
4
原创 《A++ 敏捷开发》- 10 二八原则
团队成员协作，利用项目数据，分析根本原因，制定纠正措施，并立马尝试，判断是否有效，是改善的“基本功”。10-12章会探索里面的注意事项，13章会看两家公司的实施情况和常见问题。如果已经获得高层支持，她也赞同目前返工工作量太多并愿意投入资源进行过程改进，我们首先应该针对哪些方面进行改进呢？软件开发的特点是，超过95%的成本都是人力成本。因此，我建议利用二八(20/80)原则，继续识别哪类工作的占比最高（详见附件）。
2024-07-11 10:21:50
1121
原创 《A++ 敏捷开发》- 25 创新：从个人到公司
创新，顾名思义，是指创造新的事物或提出与常规不同的见解。丰田汽车公司精益生产(JIT)的案例展示了丰田通过一线员工的智慧不断改善，最终实现了许多人最初认为不可思议的目标，如“零”缺陷和“零”库存。这使得丰田成为现代汽车生产的标杆。但这些改善都只属于解决问题（Problem Solving），而并非创新（即使团队迭代回顾时针对缺陷排除率分析根因也不能算是创新）。为什么有些公司和个人能够通过创新取得成功呢？接下来将首先回顾个人创新的要素，然后探索团队创新的方式和成功的关键要素。
2024-05-19 09:42:49
634
1
原创 公司如何制定年度目标
要工作坊有效，须要注意以下4点原则（例如第一点是必须所有相关人参与）：注意：老师的主要作用是辅导，所有要抛开传统的“老师教、学生学”的思路，尽量让大家自己投入和沟通。
2024-04-03 16:33:52
1362
原创 EV 挣值分析案例
软件开发项目最大的成本就是人工成本，但如果项目监控不足，最终很容易导致项目整体延期，成本超支。因为每个人都习惯了尽量等到最后一刻才完成提交，所以必须把任务分解到几人天的颗粒度并监控，才可以控制任务不延误。但如果只是做了项目任务分解，没有对应的监控，也不会有任何作用。如果只靠项目经理自己人工去监控每个活动的延期，并在里程碑做汇报，会很困难。
2024-03-20 09:26:20
995
原创 《A++ 敏捷开发》- 9 寻找改进机会
发现培训反馈靠主观，只是靠老师主观打分，可以增加考试就可以满足不客观了发现有些课学生成绩及格率低，下一次同类外部培训要求学员备课，以提高学生的通过率只是采取这些行动，对公司级培训质量改进作用吗？几乎没有，因为只是对问题做correction,没有改变系统与习惯，类似问题还是会再出现。但如能深入探索根因，就发现原来新员工正式上课的培训不长，只有一天，大部分还是靠新员工在工作中，跟有经验“老”员工导师，老带新，边做边学。
2024-03-01 09:27:30
989
原创 《A++ 敏捷开发》- 8 获取高层支持
我：对过程改进来说，最重要的成功要素是什么？客户：最难的是如何得到高层的支持，这不仅仅是嘴巴说说而已，而是要切实地给人、给时间。高层往往不清楚什么是质量改进的重点，但他们对员工的人均收入、利润（比如员工可为公司盈利的时间占比。如果少，就表示这个员工对公司的盈利贡献不够。）等这些财务指标都非常清楚。我：非常赞同。我们可以利用评估机会来引起高层对质量改进的重视，但往往评估组只说软件开发的各种问题，难以引起他们注意。一般人，尤其是高层，一听到问题都会觉得比较烦，没有动力听下去，更不要说有对应的改进行动了。
2024-02-13 13:28:49
1350
原创 《A++ 敏捷开发》- 7 估算工作量
这几年大数据很火，很多高科技公司都推相关的工具或者方案，很多软件开发项目经理觉得应该也用数据分析，分析历史数据，准确预估项目工作量、工期。但实际上，虽然预测模型已经有超过50年的历史，过千份研究报告、教材、指南，但使用在项目中不多。更多研究发现如果用专家估算可能更准确。以上是2009年IEEE杂志中的文章，Jorgensen先生的结论。
2024-02-05 09:23:50
1594
1
原创 《A++ 敏捷开发》- 6 估算软件规模
虽然简化功能点(SiFP)比传统国际功能点（IFPUG）简单易学，但开发人员还是容易用工程师的视角来估算（本应用用户的视角），导致计算错误。所以要多看案例并做练习，才能把握（能参加培训会更好）。它是做什么的？功能性需求技术需求质量需求第二类和第三类归为非功能性需求。功能点主要是针对功能性需求，目的是提供对客户有意义的功能点数，来客观地衡量软件规模。该如何去做？数据功能——实体 (逻辑文件 Logical File)事务功能——行为（基本过程 Elementary Process)
2024-01-28 19:45:35
1533
1
原创 《A++ 敏捷开发》- 5 量化管理从个人开始
PSP 的简单介绍PSP0基础 - 工时：计划与实际对比；每阶段引入多少缺陷；排除了多少缺陷PSP0.1加入代码行统计 - 计划与实际对比；代码规范PSP1加入使用 PROBE 方法 做规模估算PSP2加入设计与代码评审的计划与统计PSP3Cyclic process 先做策划与总体设计，然后多轮开发 ， 有点类似迭代开发。PSP跟CMMI成熟度模型类似，也是按部就班一步步，帮助软件工程师利用度量改进自我的开发过程。
2024-01-21 21:37:31
1071
1
原创 《A++ 敏捷开发》- 4 三点估算
估算是一个范围，不是一个数唐工：你估计完成开发用户登录模块要多少天？小李：3天。唐工：能在3天完成的可能性有多高？小李：可能性很高。唐工：可否量化一点?小李：可能性为50%~60%。唐工：所以很有可能不止3天，要4天了。小李：对的，其实也有可能要56天，但我估计概率不大。唐工：你信心有多少？小李：难说，有95%的信心可以在6天之内完成。唐工：所以有可能要用上7天了？小李：这样说吧，如果所有可能出问题的都出了问题，甚至会10天或11。
2024-01-16 21:25:27
1087
原创 《A++ 敏捷开发》- 3 克服拖延症
技术总监问：现在我遇到最大的难题就是如何提升下面技术人员的能力，如果他们全都是高手，我就很轻松了，但实际上高手最多只有 1/3，其他都是中低水平。你接触过这么多软件开发团队，有什么好方案？我：你可以先听听以下故事。小李：你平常办公时间一直都很忙，还可以腾出晚上和周末时间，把客户遇到的问题，如何解决等，汇总成分享文章，每两周公众号发布，很厉害呀。我：其实你也可以做到。要成为专业软件工程师，除了要学习软件工程相关的知识与技能外，个人有没有高效率的习惯其实更重要。
2024-01-09 20:26:42
983
原创 《A++ 敏捷开发》-2 改进从团队开始
上一章介绍了丰田方式水面下的七个习惯，但公司应如何有效开展与推行？有哪些误区要注意？我们先看美国东岸某家小印刷公司的故事。
2023-12-30 09:42:42
978
原创 《A++ 敏捷开发》-1 如何改善
既然SCRUM方法有不足，XP方法能解决开发质量问题，是否团队学好XP便能帮助团队做好敏捷开发？ 怎样才能不断完善？
2023-12-21 09:46:11
1202
1
原创 A++ 敏捷开发-1 如何改善
A公司一直专门为某电信公司提供针对客服、线上播放等服务服务。张工是公司的中层管理者，管理好几个开发团队，有5位项目经理向他汇报。他听说老同学的团队都开始用敏捷开发，很感兴趣，便参加了几次敏捷交流会，觉得可以解决很多开发团队的问题，尤其是可以快速交付给客户。他便提建议给部门经理推动敏捷开发，找咨询公司做相关培训，例如SCRUM Master 内部培训，然后全面开展实施。开始时，部门经理有些怀疑，问：“听起来很吸引，但后面那些工程文档都不做，会不会影响质量和交付？
2023-12-01 14:16:43
1322
1
原创 如何做好迭代回顾4/4
两个月前，为北京Y企业做差距分析诊断，发现大量缺陷在系统测试才被发现，建议加强迭代回顾根因分析。质量经理便开始尝试内部推动，并在两周前做了一次团队回顾辅导。
2023-11-09 08:57:51
256
原创 如何做好迭代回顾 3/4
今天培训的对象是老客户，但与3年前不同，这次从公司前台处走到总监办公室足足花了2分钟。 沿途要经过他们的三个开发大厅：每个大厅坐着70到80人。规模与3年前相比，大了很多，新员工绝大部分是做项目开发测试等技术工作。总员工数量从不到200人到超过600，且还在陆续增加，所以虽然两年前才搬到这个3000平米的新办公室，现在也基本上坐满了。我：公司发展很快，跟三年前完全不一样了。总监：是的，CEO特别支持公司的发展，在这方面做了很多投资。以前我还能喊出每个员工的名字，现在新人太多，很多都脸生。例如，只见这几百人
2023-07-28 16:39:02
259
原创 如何做好迭代回顾 2/4
北京某软件开发公司，专门为电信供应商做定制软件开发，比如发短信做些推广活动等。公司希望做过程改进，我首次与公司老板访谈：我：过程改进主要帮助管理层更好达到公司业务目标。你们自己是最清楚有那些不足，请问你觉得哪里最有改进空间？总经理：我不太熟识技术细节，只能从客户视角看。
2023-07-07 16:24:33
19793
原创 如何做好迭代回顾 1/4
为了确保质量应该用精益的概念。每一小步确认限制级，确保达标。然后与客户确认，而不是先定一个总体的几个月计划。按总计划监控任务是否延误？因为后者会把团队的关注点都放到按时交付去，无法确保最终的产品达到高质量要求。迭代回顾让团队可以每走一小步，回顾有那些不足，分析根因，下一步做改善。如果要从“救火”的管理思路变成基于根本原因找出预防措施的思路，就需要管理者‘放手’，让团队自己收集数据，自己分析与制定纠正措施。
2023-06-26 10:31:50
604
原创 OD1 敏捷背后的思路
ACP(Agile Certified Practitioner)是美国项目管理协会（Project Management Institute）的敏捷证书，在大陆也流行，与其他认证不一样的地方是ACP并不针对某一种敏捷方法，它更注重的是敏捷背后的核心思路如何应用于项目管理中。ACP没有官方培训课，只有框架与最佳实践，并提供参考书单。我有幸在香港讲过6次，每次3天ACP课程，这让我更明白敏捷的重点并非大家都听过的技巧（如看板，每天站会等），而是背后的思路。这篇先讲两个故事来说明。== == ==
2022-09-09 16:24:54
493
原创 RDM1 软件需求与开发
客户：公司准备推行软件需求与研发分离。我：为什么要分开？客户：公司希望可以提高需求的独立性，也希望需求可以与研发相互制衡。以前需求是研发团队的一部分，很多时候就会倾向于从研发团队的角度来看需求。分开后可以更加独立，更多地从客户的视角看需求。我们严格要求做需求评审，可否用评审结果来评判需求的质量？我：我常常会问团队，需求评审找出的缺陷是越多越好，还是越少越好？如果有人说是越少越好，我就会继续问是否0缺陷就是质量最好，所以我们难以单纯地用评审发现的缺陷数去衡量需求的质量。
2022-09-09 16:23:09
601
原创 QAD1 持续交付 Continuous Delivery
很久以前,工程本科生都要在最后一年做个毕业项目。导师建议尝试参考一些常用的语言发声算法，在专门做信号处理的芯片上写程序，读出一些英文字或句子（与现在不同，当时这技术还未成熟，很多大学还在研究），虽然预计有不少技术难度，但觉得很先进，很感兴趣，便与另一位同学合作，开始制定项目计划。我们很努力，全情投入，一方面要研究语言发声的算法，也要并行设计电子线路和软件等。
2022-09-09 16:21:50
686
原创 MA2 统计分析案例
单靠统计分析是不会提高开发质量的，必须找到对应的方式，例如注重同行评审，不要等到系统测试才发现缺陷。做好需求以减少设计与编码对需求的误解。统计数据让开发人员可以“看到”到现在的状态与趋势，且分析新方法对提升有没有作用。
2022-09-09 16:08:34
1120
原创 高效1 克服拖延症
一北京技术总监问：最大的难题就是如何提升下面技术人员的能力，如果他们全都是高手，我就很轻松了，但实际上最多只有三分之一，其他都是中低水平。您接触过这么多软件开发团队，有什么好方案？我说：我没有解决提升技术人员能力的银弹，但你可以听听我最近这故事：= = = = = = = = = = = = = = = = = = = = =小李：你能够在一周内写完程序通过测试，并把整件事汇总成分享文章初稿发布很厉害呀。我：其实你也可以做到。《个人写程序并记录统计的一些经验分享》里，我只是写了与软件工程
2022-02-15 09:49:47
451
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人