把系统思考带给更多人-2018年3月杭州聚会

把系统思考带给更多人-2018年3月杭州聚会

历史 差不多在一年前有了“把系统思考带给更多人”的想法,到2017年7月才付诸行动。当时倡议共创系统思考工作坊,得到了很多朋友的响应,在2017年9月的杭州钱塘江畔通过两天的共创有了系统思考工作坊的第一个版本。过去的半年里大家在不同城市不同公司将它带给了更多人,同时工作坊本身也得到了演进。在去年12月我邀请有兴趣把系统思考带给更多人的朋友今年3月在杭州聚会,也就是刚发生的事,给大家做个更新。 2017年7月,把系统思考带给更多人 2017年9月,系统思考工作坊共创 2017年12月,系统思考工作坊进展和后续 2018年3月,“把系统思考带给更多人”聚会 “把系统思考带给更多人”有一个目标是到2019年底让3000人通过我们的工作坊学习了系统思考,到目前为止我们已经带给了~750人,算是完成了四分之一。从这个角度来说,我们在扎实地进展:) 聚会 这次聚会的第一天在保俶塔边的纯真年代书吧,其实是最初就想去的地方,也算了却一桩心愿。总共有16人参加,其中11人参加了去年9月系统思考工作坊第一版的共创,另外5人则是新加入。   两天聚会每天各有一个主题,第一天围绕现有工作坊,第二天围绕未来的扩展。具体日程是大家共同创建的,我对其中的一些内容简单做个更新。 在第一天里,Tony、晓云、长虹、Philip和王磊各自分享了他们现有工作坊的内容和交付方式,这部分对新加入的朋友尤其有帮助。对工作坊之后跟进和落地的讨论让大家对以后发展演进有了更清晰的思路,我会在后续部分分享。系统思考和某个话题(比如研发管理)结合的讨论让大家对如何定位工作坊有了更深入的理解。如何引导复杂动态建模的讨论则让大家得到了互相学习的机会。最后福润还分享了他长期以来总结的轻量思考。 在第二天里,一些朋友对在今年TiD大会上的系统思考时段(有三天)共同做了设计。大家讨论了如何使我们的工作坊能面向社区持续组织,如何把它带到目前还没有涉及的城市。我们对如何分享信息形成了共识,对外的分享会通过github生成的内容网页来做,而内部的共享则使用云盘。第一版的工作坊着重于分析问题,如何找到杠杆点是自然的下一步,我们讨论了如何自己实践,如何引导帮助其他人实践。下午还对系统思考和U型理论,如何提升自身的系统思考能力等话题做了交流。 后续 这次聚会对我来说一个重要的收获是大家对如何继续有了更清晰的思路和共识。 “把系统思考带给更多人”有两个层面,一是更多人对系统思考产生兴趣;二是更多人成为系统思考实践者。很难期望一个一天的工作坊能够让人持续实践系统思考,而在自己公司内部就有更多跟进落实的可能性。事实上,现有的共创成员在各自公司内部确实产生了更为持续的影响,比如华为、东软、中兴、诺基亚等。如果能有多位成员来自同一公司,又能产生更强的合力。所以我们希望通过社区工作坊让更多来自不同公司的朋友对系统思考产生兴趣,其中一些或许会有兴趣把系统思考带回他们所在的公司。简而言之,社区唤起兴趣,公司推动实践。 我们整理了“把系统思考带给更多人”的群组,决定保留两个。 1、“把系统思考带给更多人-兴趣组”,这是一个开放的群组,只要你对系统思考感兴趣就可以加入。除了系统思考相关的讨论交流外,我们也会把各地的社区课程通知到群里,方便有兴趣的人参加。社区课程在大连、杭州、上海、北京至少会保持每季度一次的频率,如果你不在以上城市,但是希望在自己的城市安排工作坊,只要在群里提出来,相信会有人响应的:) 2、“把系统思考带给更多人-共创组”,这个群组只包含参与过共创的朋友。目前为止就是参加了去年9月和/或今年3月活动的朋友。至少在2019年底之前,我们会每半年组织一次聚会,进一步共创和推动“把系统思考带给更多人”,所以你至少还有三次机会加入其中。聚会的具体安排和报名会在“把系统思考带给更多人-兴趣组”提前发布。 吕毅,2018.3...
Read More
用 Cucumber 实现微信小程序的验收测试

用 Cucumber 实现微信小程序的验收测试

最近微信小程序的开发如火如荼,现代互联网开发这个课程自然不能落伍哈。我连夜搞出了 bbuddy 的小程序版,同时实现了自动化测试。特此献上小视频(时长1分18秒)一个,大家可以先睹为快 你和你的团队是不是也在搞小程序呢?是不是也想对小程序做自动化测试呢?欲知详情,欢迎来报名参加下个月的 CSD 课程(暨现代互联网开发课程)...
Read More
认识组织选项背后的系统动态:需求还是任务

认识组织选项背后的系统动态:需求还是任务

  在辅导敏捷团队时一个重要的杠杆是增加对需求而非任务的聚焦。这篇文章描述其背后的动态。 传统的项目在两个层次跟踪进度。一个是里程碑,经常跟诸如需求分析完、集成准备就绪、测试完成这样的阶段相关联。另一个是任务状态,经常通过每周汇报会议来跟踪。相比之下,敏捷开发却跟踪需求的进度(注:更好的是跟踪那些需求的价值,但这不在本文范围内讨论)。我们将看到不同选择背后的动态,希望由此带来的理解能对成功的改变有所帮助。 为什么聚焦任务?  聚焦任务有它的原因。   任务焦点本质上代表了资源焦点。当面临成本压力时,我们尝试增加资源焦点,以提高资源效率,从而减轻成本压力。 我们如何增加资源焦点呢?一种方式是通过任务。事实上当跟踪任务时,次序经常是按人,问每个人在做什么任务。这样就能确保每个人都忙着。如果没有匹配他们技能的任务呢?我们创造任务来适应他们的技能。我们会在后面看到这将带来有趣的影响。 为什么聚焦需求? 聚焦需求也有它的原因。 需求焦点代表了客户焦点。当面临市场压力时,我们尝试增加客户焦点,以提高流动效率,从而减轻市场压力。 我们如何增加流动效率呢?一种方式是通过需求。我们不是跟踪任务和人,而是跟踪需求确保它们流动。我们较少关注谁闲着,更多关注如何让需求流动得顺畅。 两者之间的矛盾 如果两个平衡回路相互独立,成本和市场的目标能同时得到满足。然而,在资源效率和流动效率之间存在矛盾。 我们讨论资源效率时曾经提及,当一个需求对某些人来说没有他合适的任务时,我们就开启另一个需求以使他有合适的任务做,从而提高了资源效率。注意如果需要学习,他就不是资源有效的。并行需求的增多意味着客户焦点的降低。因此,资源焦点对客户焦点有负面的影响。 反过来也是一样。当我们聚焦客户,通过限制并行工作的需求个数以追求流动效率时,它不可避免会产生某些人没有合适的任务做的情况,这就不是资源有效的。因此,客户焦点对资源焦点也有负面的影响。 现在两个平衡回路就相互作用了。当市场压力变大时,加强客户焦点以提高流动效率。同时,这减弱了资源焦点,降低了资源效率。这时候是B2回路主导。当成本压力变大时,加强资源焦点以提高资源效率。同时,这减弱了客户焦点,降低了流动效率。这时候是B1回路主导。 理解这个矛盾帮助我们以不同的方式看待变革中的抵制力。虽然聚焦客户令人难以反驳,根本性的系统结构却产生反向的力量。 这个矛盾也提出了关于系统目标的重要问题。对特定的组织来说,你更想优化哪个目标 - 资源效率还是流动效率? 产生影响的杠杆 有可能两者兼得吗?或者至少在以某一项为主的同时能兼顾另一项? 来看一下我们是如何实现资源效率的。我们开始更多并行的工作以适应技能,但牺牲了客户焦点。我们可以让B3回路而非B1回路工作,也就是通过学习扩展技能,最终提高资源效率。B3回路对客户焦点并没有负面的影响,但学习也需要更长时间才见效。不令人意外的是,真正的杠杆在于我们如何能有效地学习和扩展技能。 上图是来自于《This is Lean》书中的效率矩阵。图中的蓝线表示通往“完美状态”的演进路径,首先实现B1回路(提高流动效率),然后再是B3回路(提高资源效率)。然而很多组织自认为它们的现状是“高效岛屿”,也就是B2回路主导,这样一来演进路径变成了图中的红线。从变革管理的角度来看,沿红线演进是困难的,因为它意味着资源效率会先降低。你可以改变认知以从更为真实的“浪费之地”出发,或者确保资源效率的降低是可以掌控的。 聚焦于需求还是任务本质上是在客户焦点和资源焦点之间的选择。 英文版:https://blog.odd-e.com/yilv/2018/02/seeing-the-system-dynamic-requirement-vs-task.html...
Read More
常见研发团队结构碰到的问题

常见研发团队结构碰到的问题

一般软件研发团队组成方式无非几种:按职能划分的职能团队,按系统结构划分的组件团队,以客户为中心的特性团队。这些团队结构各有各的问题和挑战。 职能团队 业务分析团队,设计团队,架构师团队,开发团队,测试团队,按照职能来划分。完成价值交付的过程会出现明显的阶段和交接传递。理想状况是一个需求流畅的从一个团队流畅的流动到下一个团队,直到价值交付到客户手中。 往返传递 现实情况是通常下一个职能团队为上一个团队提供反馈,需求可能会回到上一个职能团队进行调整,需求会在职能团队间来回传递。比如,开发团队完成开发后交给测试团队,测试团队发现bug又交还给开发团队修复,这个过程会反复多次。这样的反复通常无法预期,会经常影响两个团队的原计划,这又加剧了职能团队的下一个问题。 等待队列 工作性质和团队工作能力的不同,导致一些团队会有不能及时处理的任务堆积,形成队列。这些等待中的任务是半成品,不能直接产生价值,是一种浪费,还会使事情变复杂,比如需要有人来维护这个队列。队列会降低工作的流动性,从而降低价值交付的速度。 组件团队 组件团队是按照架构模块或系统组件来划分团队。比如GUI团队,API团队等。 限制设计 按照康威定律,“任何设计系统的组织……都不可避免地产生出与其组织沟通结构一致的系统设计”,团队的组成结构会限制设计。然而大多数情况下,一开始产生的设计都不是最完美的,组织的灵活性对有效的设计有着举足轻重的作用。而组件团队恰恰限制了设计的有效性。 强化瀑布,增加协调复杂度 组件团队还会加强瀑布的开发过程。通常组件团队的存在会导致工作安排按照组件来分配给各个团队,这意味着所有组件团队完成各自的工作后还需要集成并完成最后的测试,反馈被延迟了。当然我们可以用持续集成等方法来加快反馈频率,但这中间的协调工作也确实变多了,你的Team Leader或者Scrum Master是不是经常为这样的事情疲于奔命?想想如果每个团队的工作是完成相对完整的功能,协调工作是不是会减少许多?组件团队有自己的计划安排,但往往需要和其他组件团队协调(比如联调),导致计划总在被打乱? 系统问题 同时,组件团队和职能团队都会导致:团队往往只关注于完成手头上的工作而非价值;团队与团队间形成职责壁垒,各自只为各自工作负责,也不愿其他人碰自己的工作(典型的如开发人员不愿意其他人碰自己的代码),这也意味着各个团队会更倾向于局部优化,比如在团队工作内容不多的时候,团队会制造些活来干,或者基于专业性来挑选工作而非客户价值。 特性团队 特性团队是由长期合作、跨职能、以学习为导向、多技能的人员组成,能完成端到端客户特性的团队。通常团队的职责包括需求分析、交互设计、计划、设计、编程、测试等,这样团队就能全神贯注地完成端到端的客户特性。 大多数组件团队的缺陷也得以弥补了,比如计划、协调等工作被大大简化了,交接与等待的浪费也减少了,整体的生产周期也被缩短了。同时,团队的技能约束少了,计划和安排工作的灵活性就提升了,可以更多的专注于真正高优先级或更有价值的功能开发上。当然特性团队的好处虽多,但也有不少的挑战和问题: 团队及其成员需要扩展技能和相应的产品知识,以便尽可能的修改系统的任意部分 同时修改同一个代码的机率变高了,冲突的可能性也提高了,这就意味着需要频繁提交代码等一系列持续集成的实践来减小工作批量,缩短集成周期。 各个组件的设计责任被分散到了各个团队,除了持续集成外,还需要其他的实践来保持设计的合理性和持续改善,比如测试驱动开发,重构,演进式设计,组件守护者等。 有些特定的技能比较难以掌握,比如视觉艺术,或者稀有专家掌握的知识和能力(比如图像渲染中的光线追踪算法) 可能需要组织结构的调整,一般组织是以组件或者职能线的汇报关系,最终需要转变成多个团队向共同的上级经理汇报。 如果你正纠结于团队结构或者其它团队在研发过程中碰到的问题,可以考虑参加我的培训: Certified Scrum Developer认证Scrum开发者课程 —— 敏捷团队工程实践 时间:2018年4月8日~10日 地点:上海 ScrumMaster领导力课程 —— ScrumMaster进阶技巧课 时间:2018年4月16日~17日 地点:上海 或者也可以找我聊聊,可以通过zbcjackson@odd-e.com 或者微信 ...
Read More
一个快速有效提升团队效率和质量的方法

一个快速有效提升团队效率和质量的方法

在为客户提供教练服务过程中,我尝试过各种方法,发现其中有个方法提升团队的效率和质量最快速有效。简单概括就是实例化需求,但其实只用做一部分就可以有不错的效果。 为什么说这个方法快速有效?说快速是因为只需改变需求讨论会议或者Scrum中Product Backlog Refinement(PBR)的方式,通常就会在当前迭代看出效果来。有效是因为通常改善了团队的工作效率,减少了迭代内的bug,从而减少了开发和测试间的来来回回,提升了工作质量。过往的客户有做过Bug的根源分析,发现有一半是因为需求沟通的问题导致的。 具体做法是: 在开始开发前举行需求讨论会议。也就是Scrum中的PBR,通常在迭代的中间发生,用于讨论并澄清后续迭代的需求。 会议需要三个角色,产品经理或者Product Owner(PO),开发人员和测试人员。Scrum中就是PO和开发团队(包括了开发和测试等) 会议中产品经理简短介绍一下要讨论的需求,开发和测试用测试用例的方式描述需求,即验收条件。以5个需求和8人团队为例: PO花10分钟左右简单介绍5个需求 团队分成3个2~3人的小组,每个小组选一个需求进行讨论,写出需求的验收条件。20分钟一个时间段。此时,PO应随时帮助团队澄清疑问。 再10分钟每个小组分享一下各自的验收条件,其他人给出反馈 再做一轮20+10分钟的讨论,可以根据反馈来调整验收条件。如没有调整,可以拿下一个需求讨论。 如果需要,可以再做一轮。但通常2个星期的迭代,2个小时足够完成整个会议。 用具体的例子来描述验收条件来减少产生误解的空间。比如,买3本书包邮的例子 买一本《实例化需求》和一本《用户故事与敏捷方法》,快递费是12元 买一本《实例化需求》,一本《用户故事与敏捷方法》和一本《单元测试的艺术》,快递费是0元 用业务的语言描述。验收条件应当是业务人员都能看懂的,因此描述的语言应该是业务语言,不应包含技术或操作细节。这样更容易沟通,同时避免过多的讨论实现细节,关注于“需求是什么”而不是“如何实现” 通常来说帮助团队实现1到3比较容易,团队多练习几次就能习惯4和5的表达方式。至于是否一定要用“假如……当……那么……”的格式,如果只是帮助大家澄清需求,那重要的是大家理解这样的结构化表述,对需求规则理解的表述包含了“条件-行为-结果”。当然,我更倾向于使用这样的格式来帮助大家习惯结构化的表述,同时也能方便以后自动化。 经过这样的需求讨论会议后,团队将带着这些验收条件来进行开发,开发一开始写代码的时候就知道测试将怎么测,测试不用来来回回重复测之前已经讨论的情况,可以花更多的时间来发现之前没法预测到的问题。 如果想要有更进一步的效果,那就需要将验收条件自动化,并且不会为了自动化改变原本验收条件的描述,最终形成活文档。当然这需要的投入就比仅改变讨论方式要多很多了,也比较难完全掌握。用实例化需求来实现从外向内的开发——从PBR到Acceptance Test Driven Development(ATDD),再到Unit TDD。这将极大改善产品开发。这些将在以后的文章中讲解,或者来参加我们的培训。:D...
Read More
12