什么时候不用测试驱动开发(TDD)

Bob Jiang
我什么时候不使用TDD? Alex Bunardzic一直是有关TDD及其反对者的 Twitter 话题中的一员。他的担忧之一是TDD的支持者同意TDD并不总是合适的,但没有说什么时候不用TDD。让我们探索一下。 亚历克斯的担忧似乎在于他正试图让组织中的人员使用TDD,其中许多人提出了异议。这些异议之一是,甚至专家都说他们并不总是使用TDD,所以我们为什么要在这里使用TDD。 现在,如果您接受销售培训0^,那么您将要教的一件事是如何处理异议。第一项也是最强大的技术是忽略它们。在销售中,您可能会继续提出反对意见,这就是为什么我们很多人讨厌被出售的原因之一。 我没有卖任何东西,但似乎Alex负责在他的公司中销售TDD,所以我们可能有不同的担忧。我在写和讲授思想上的关注是可以理解的。我很乐意将决定权交给听众。如果我每月都有这么多TDD销售的配额,我可能会有所不同。 尽管如此,我确实知道有些情况下我通常不使用TDD,并且我或多或少乐于谈论它们。或多或少是因为TDD主题似乎不断地深入我的灵魂。无论如何,这里是: 我什么时候不用TDD? 让我数一数:我*有时*不用TDD的… 当手头没有合适的TDD工具时; 当我不知道如何测试某事时; 当输出本质上是可见时(可视化); 当程序是一个简单的,会扔掉的。 让我们通过示例进一步探讨其中的每一个情况。 当没有像样的测试工具可以立即使用时,我通常不用TDD。 一个例子是我iPad上的Codea Lua。它没有附带TDD工具,而且很长一段时间没有可用的工具。我很喜欢写一个玩玩,因为在Lua中反思很有趣,但从未真正得出我喜欢的东西。 然后出现了CodeaUnit,它工作得非常好,我最近在示例TDD会话中使用了它。但是请参阅以下部分。 另一个示例是Second Life的脚本语言LSL。该语言非常初级,不包含反射功能,这在您尝试生成一个体面的TDD框架时非常重要。如果没有可用的工具,则我用TDD的频率将比理想情况低。 但是请注意:缺少一个不错的工具并不是不使用TDD的很好理由。通常,我在Lua或LSL上的开发所花的时间要比遵循TDD学科所需的时间长。我怎么知道?我对使用TDD和不使用TDD时会发生的事情非常有经验,因此我很容易认识到缺少测试会伤害我的情况。 最好的迹象是调试会话需要更多的时间。这总是表明更多测试时我‘会做得更好。 如果工具不易使用,您是否应该考虑不使用TDD? 我认为这不是很好的理由。几乎可以肯定的是,无论您使用哪种语言,都可以使用一个很好的TDD工具。对我来说,如果是只写一些小小的一次性程序的人,寻找和学习该工具的投资*可能*不值得。您正在专业地工作。对于您来说,投资可能是值得的。 很可能,这对我来说是值得的。在没有TDD的情况下工作会使我更经常地进入调试模式。即使对于我的小型项目,TDD的价值也可能存在。我将自己不这样做的原因归咎于懒惰,说实话而不是出于智慧。 当输出本质上是可见(可视化)时,我通常不进行测试。 在Codea / Lua中,人们经常编写一些代码在屏幕上绘制运动对象。在《第二人生》中,我经常编写脚本来在虚拟世界中移动事物。尽管这些脚本中的某些部分可能会从TDD中受益,但总会有一些-其主要功能使我不知道如何有效地使用TDD。 让我们举两个例子。 想象一下,我想在iPad屏幕上绘制一个蒸汽引擎。该图片的一部分将是引擎驱动轮,该驱动轮会随着火车的移动而旋转。推杆安装在该轮的半径中间附近。该推杆的轮端绕转0^左右。该杆的另一端在连接到蒸汽活塞的另一根水平杆的推动下水平地前后移动,该水平杆只是来回运动。 我们的任务是在轮子旋转时针对每个角度计算推杆的位置。为了弄清楚该如何做,我绘制了一些草图并做了一些几何处理(通常使用直角三角形),直到我弄清楚了在每个方向盘上的远端在哪个位置。 显然,当车轮为零时,推杆完全远离车轮,其端点为l + r,其中r为推杆圆的半径,l为杆的长度,假设车轮位于零位置。 当车轮处于180度时,终点将在l-r处。当车轮位于90或270时,终点将为…sqrt(l ^ 2-r ^ 2)。同时,如果角度为θ,则起点为 rotBy(θ)。 大概。多一点的几何使我相信终点是sqrt(l*l - y*y) - x,其中x和y是起点的相对坐标。 也许,有一种更好的方法来计算终点。它一定是某种 sin或cos (正弦或余弦)功能或类似的东西。但是这种方法很好用,因为我们有能力在两点之间画一条线。 所以我只是编写了代码,看起来像这样,没有进行大量清理: -- Loco function setup() theta = 0 -- degrees deltaTheta = 1 origin = vec2(600,600) radius = 200 rodRadius = radius/2 rodLength = 500 end function draw() background(40, 40, 50) strokeWidth(5) drawWheel() drawRod() theta = theta + deltaTheta end function radians(angleInDegrees) return angleInDegrees*math.

驱动组织演进的心智模式

Bob Jiang
为什么初创公司通常是充满活力的网络结构,度过初创阶段则通常会成长为官僚化的层级结构?这里简单探讨两个驱动因素,如下图中左侧悬臂(1,5)所示。 图1: 组织复杂度为何增加 第一个驱动因素是领导者对专业化效率的期望。度过初创阶段之后的一个倾向是为效率而优化,以尽可能收割其成功产品收益。提高效率的传统做法是细化分工,从创业时期的人人都是全能战士,转向"专业的人做专业的事",如图中B1环路(2-3-4-9-2)所示:专业化效率提升压力(2)导致分工细化,分工细化使得专业化效率提升,专业化效率提升使得专业领域的产出提升,于是压力得以缓解。此动态背后的领导者心智模式是:细化分工有利于效率提升、产出增加。 然而分工细致程度同时也带来了整合成本的增加(包括分工产生的等待浪费和集成投入)。这至少部分抵消了专业区域产出导致的总产出增加。 (分工细致程度导致的专业化效率提升还受分工导致的依赖制约,为简化,图中不表达)。 第二个驱动因素是领导者对管控程度的期望。领导者的控制倾向带来增强管控程度的压力。这种压力会使分工细致程度增加,以增加角色职责清晰度,从而增强管控程度,缓解管控压力(环路6-3-7-8-6)。此动态背后的领导者心智模式是:明确的职责分工可以带来对组织和员工的有效掌控。 公司成长过程中,这两个驱动因素往往导致分工细致程度增加,然而分工细致程度的增加又带来一系列其他后果。分工细化会导致部门增加,进而导致组织层级增长,应变能力下降(3-15-16)。同时分工还会导致组织壁垒产生(3-12)。组织壁垒有促进人员增长的倾向(地盘意识以及流动性降低所致),而人员增长又容易进一步强化组织壁垒(软件开发为例,模块所有团队有使模块变复杂的倾向)。 组织壁垒的产生和应变能力的下降都导致组织更难把握市场上的机会,于是创新能力下降,这在更长的时间里导致总产出下降(13-10),组织走向下坡路。 由以上分析可知,组织复杂程度的增加有其内部原因,有些原因与领导者的心智模式相关而非价值驱动。而从精益观念来看,如果把组织的目标定位为为客户创造价值,那么组织的复杂性往往是超出必要的。所以,转型中常常有"简化组织"的呼声。 组织应变和创新能力的提升,有赖于领导者的心智模式升级。如果组织创新能力乃至总产出的下降不能触及领导者的心智模式,那么转型容易头痛医头脚痛医脚,难能成功。只有领导者理解了所面临问题的根源,才可能从管控型组织转向赋能型组织,并纠正对专业化效率的片面追求,使系统动态发生根本转变 – 如下图中上下两条红线。 图二:组织转型的心智基础 <感谢Paulino Kok老师的洞见对此文的贡献> 马林胜/20200420

敏捷与OKR实践(如何让OKR与敏捷计划共存)

Bob Jiang
僵化的详细长期计划(根据消耗的预算跟踪进度)正在敏捷组织中迅速成为对过去的褪色怀旧记忆,这由预测和非静态路线图代替。定期在这些可视化文件前聚会,您将能够学习、共享并触发重要的对话,解决依赖性并邀请服务型领导的行为。使您的OKR和预测计划共存! 在这个博客中,我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度,并确保持续解决和减轻障碍和依赖性。它还将预测变成对话(与被视为承诺的项目计划中捕获的固定估计相反)。 参与团队回答的核心问题是: 敲黑板 - 划重点(译者注) “您是否有信心在本季度末之前完成关键结果?” 你可能还喜欢 Google OKR小册子 如果您不熟悉OKR,目标和关键结果的概念,则可以将目标视为”让我们对这一领域/问题/需求加倍研究”,而关键结果则视为”让我们完成这一特定影响/结果/目标/交付成果”这将推动我们朝着目标迈进。” 对于每个季度,目标数量通常限制为3-5。每个目标依次具有3-5个关键结果。常见的指导原则是,平均而言,您应该以关键结果的70%成功,即以30%失败,这是正常的并且可以接受。该准则可确保我们设定大胆的目标,并避免安全起见。为什么?好吧,如果我们惩罚成功率不到100%的事情,我们最终将优化军阀制度。 OKR白板站立会议 当2017年重新引入OKR时,我曾在Spotify担任敏捷教练。我所工作的部落(认为半自治部门)不希望OKR成为PowerPoint中的静态幻灯片,而该幻灯片很快就被人们遗忘了,但是在生活我们可以随时”计划”,以找出如何互相帮助。 与其以数字演示形式总结部落的集体协作的OKR,我们将它们(OKR)写在一块大白板上,该白板在所有团队旁边的走廊上非常醒目。每两周一次,我们进行OKR白板的站立会议。希望加入的每个人都受到欢迎,但我们要求每个团队(八个团队)至少有两名代表参加。 会议的例行很简单。我们走上了白板,一次实现了一个目标。对于每个目标,我们都会大声读出关键结果的措辞。提供该关键成果的工作团队简短地分享了进展并宣布了他们的信心水平。会议持续了15至25分钟。 置信度 对于每个关键结果,相关团队都回答了以下问题: “您是否有信心在本季度末之前完成关键结果?” 绿色自信的笑脸 –完全自信这会发生。我们可以准备市场营销活动。 橙色担忧的笑脸 –我们可能做不到,应该提醒利益相关者。 红色悲伤的笑脸 –没办法。这不会在本季度内发生。不过,我们仍在努力。 检查 –完成。已交付。做完了。 停止 –我们已停止进行此工作(…由于优先级的改变或关键结果本身已变得无关紧要)。 每个关键结果下方都有6-7个框(取决于该季度中发生了多少个两周的周期),每个OKR白板站立会议都用掉一个框。当我们进行第三次站立时,我们填写了第三个方框,依此类推。这种方法使我们对我们的信心水平有了历史的认识。 如果有几个团队提供相同的关键结果,那么他们每个人都分享他们的进度和信心水平。但是,最悲观的置信度是框中显示的置信度。 提供关键结果的团队名称以方框下方的小文字表示。 实际上,我们有第六个符号-?问号表示”我们还不知道”。有时事实证明这是现实,他们真的不知道。但是对我来说那很奇怪。如果团队不确定自己是否有决心在OKR周期内实现目标,那么如何使团队”致力于”关键结果?但是事实证明它很有用,因此我们使用了它。 关键对话触发器 但是,重要的不是信心笑脸本身的更新-重要的事件是当笑脸的颜色从上次OKR白板站立起改变了颜色。 这些变化是重要对话的关键触发因素。绿色的笑脸变成橙色或红色的笑脸时,我们暂停下来,直到我们共同弄清楚如何采取行动后才继续进行讨论。房间里谁能帮忙?会议室中的谁可以将需要帮助的团队与可以帮助的人联系起来?我们需要提醒利益相关者吗?谁提醒利益相关者?要改变置信水平吗,需要做什么?等等。 仅在决定了至少一项有力措施(有可能推动我们前进)之后,我们才进行下一个关键结果。 即使每个团队每天都尽自己最大的努力来减轻障碍和解决依赖性,但OKR白板站立会议提供了一个反复出现的机会,可以将问题升级为需要扩大支持的朋友和领导者组织。 庆祝完成 当有人宣布他们完成”关键结果”并在框中打勾时,我们显然以雷鸣般的掌声庆祝。 服务型领导的机会 最初,一名敏捷教练协助OKR白板站起来。在前几次的站会中,三个部落首领都没有找到时间来参加。但是在第四次站会,其中一个部落首领加入了。 在几分钟之内,我相信他意识到这是一次千载难逢的良机,可以阅读所有团队的脉搏,对进度进行汇总并提供有益的服务型领导行为。他可以提供建议(在被问到时),为团队面临艰难的选择时提出前进的道路,并由于他或她的广泛网络而提供帮助,将需要的团队与利益相关者和组织的其他部门联系起来。 下一次OKR白板站立会议,所有部落首领都作为观察员参加了会议,准备在被要求时提供帮助和支持。很快他们甚至轮流为仪式本身提供帮助。 OKR白板审查会议 当季度结束后,我们聚集在一起参加OKR白板审查会议。我们回顾了已完成的关键结果,并讨论了未完成的结果。我们能学到什么?在下一个OKR周期中,我们可以带些什么?我们如何改善可视化和OKR板站立状态? 完成百分比 在第二季度,我们运行OKR白板站立会议,我们添加了一个方面来尝试使进度更新更加完整。对于每个关键结果,相关团队不仅回答他们的信心如何,而且还估计到目前为止他们已经完成了多少工作。(译者注:这个百分比慎重加) 我们为什么要这样做?好吧,我们觉得我们缺少故事的一部分。我们了解到,有时即使有些团队只是猜测自己已经完成了10%的工作,他们还是感到超级自信。有时,即使90%的工作都完成了,团队也感到非常悲观。在某些情况下,这是非常有用的信息。 组织内传播 当下一个OKR周期的时候,我们进行OKR白板后续行动的方式已在内部传播。令我们感到惊喜的是,几个部落抄袭了我们的方法。 当某种东西传播并在内部进行时,这是工具/技术/方法有用且有价值的最好”证明”。 可能的变化 如果这种方法对您有所启发,但您在团队或部门中未使用OKR,则此方法有许多变体,仍将静态预测转换为持续对话,从而触发重要对话。 预测扑克计划 如果假设我们正在处理解决一系列特定问题或完成功能之前无法交付产品,那么我们可以要求团队成员逐个猜测 “多少周/每次冲刺可以完成我们需要达到X?”通过在便利贴上写下他们的猜测。 删除最悲观和最乐观的投票,并在白板上写下剩余的范围。如果估计范围不会每周减少一周,那么您就有机会讨论可能采取的措施或缓解措施。 截止日期置信度 有时我们需要应付一个固定的期限。也许我们的机会窗口有限,或者也许我们必须在特定日期之前满足法律要求(例如GDRP)。然后我们可以问团队“我们在日期Z之前完成X的信心如何?” 可以用五个手指进行投票。一根手指代表超级悲观,五根手指超级乐观。三根手指可能意味着紧张。如果信心没有每周增加一次,我们将讨论需要做的事情或摆在我们面前的选择。 版本的猜测 一些团队会持续交付,但仍需要与利益相关者和客户沟通进度和期望。他们从产品待办列表中拉取工作加入到Sprint中。 可视化预测的方法是在Backlog中添加两行(例如,使用胶带)。 每个Sprint Review团队的成员都会问自己两个问题: “我们对在接下来的四个冲刺中交付多少产品列表条目充满信心?” “在接下来的四个冲刺中,我们还能提供多少呢?” 绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。

重新审视故事点

Bob Jiang
我常说我可能发明了故事点,如果真是这样,现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 – Ron Jeffries 当然,故事是极限编程的思想,不是Scrum的。不知何故,Scrum践行者接受了这个理念。尽管在Scrum官方指南中有关待办事项的内容,将待办事项作为用户故事是一种普遍的Scrum实践。 至少在某种程度上来说,他们是对的。我已经在其他地方写了关于故事的常规用法,正如它应该被写下来一样。在这里,我们将讨论的是”故事点”。 在极限编程中,故事最初是用来估算时间的:实现故事需要花费的时间。紧接着我们来谈谈”理想天数”,它是用来非正式地描述如果别人让你尽自己最大努力单独完成故事需花费的时长。我们用理想的天数乘于一个”负载因子”转换得到实际需要的时间。负载因子通常是3(3天才能完成一个理想天数的工作量)。 我们刚谈到用天数来估算,经常是把”理想”抛开。这将导致的结果是我们的老板很疑惑,怎么是要花费3天来完成本来1天就可以完成的任务,又或者说,为什么我们不能用3周来完成50”天”的工作。 我记得,我们开始称”理想天数”只是”点”。所以一个故事应该用3个点来估算,这就意味着这个故事需要花费大概9天来我完成。总之,我们确实也是只用点来决定多少工作进入一个迭代,所以如果我们说大概20个点,没人会反对。 我可能已提出改名字的建议。如果我真这样做了,现在会感到抱歉。从给我的同事西蒙的电子邮件中,有一些关于目前我对这个话题的想法,他问到: 你真的后悔发明了故事点,或者你只是简单谴责当他们做相关度量时,没有正确理解而导致滥用吗? 我答道: 我当然谴责他们滥用; 我认为使用故事点来预测”我们将什么时候完成”充其量是个无力的想法; 我觉得跟踪实际与估算的比较充其量是浪费; 我觉得比较团队的估算质量或速率是危险的。 让我们更深入一点。 实际上,一些用来做”敏捷”的方法,以更容易计划的名义,推荐给各团队规范化用户故事点。这表面上看起来非常合乎情理,却太容易掉进团队比较的陷阱,组织也是经常这样做的。 比较 首先,即使他们看起来很像,每个团队都有自己的技能和特定工作环境。所以如果他们看两个貌似一样的故事,一个团队说这是个2,另一个团队说这是个6,那就不是很有趣了,当然这样比较两个团队也不是个有效的方法。 现在我们怀着好奇心来了解这种状况,首先判断条件是否足够相似来比较,其次试问估算更高的团队,是否需要咱们能提供的帮助。这样就很好。隐式或显式地结束”更慢”团队的劣势或以某种方式搞砸——这将是非常糟糕的事,但不幸的却是很常见的。 我认为对很多管理者来说,比较两个产品团队是件极其诱人的事。在可能的情况下,抛开故事点的概念,甚至抛开评估点的概念,我认为也是足够不可抗拒的。我们回到如何用更少的估算来开展工作问题上,这里还有其他的文章也讲到这方面内容的。 跟踪 对于很多管理者,估算的存在意味着”实际”的存在,意味着你应该拿估算与实际比较,确保估算与实际相匹配。当估算与实际不匹配时,就意味着人们应该要学习如何更好的估算。 对我来说,真正的敏捷里最重要的是选择接下来要做的事,并且立即开展去做。最关键的问题是找出最有价值的事做,并且快速实施。快速开展去做,归结为去做小部分价值高的和快速迭代。如果不这样做,故事成本估算帮助不到什么。 因此,如果估算的存在让管理者把注意力从价值中移开,取而代之的是改善估算,把精力从快速交付真正有价值的东西转移。 这让我觉得估算,不管是点还是时间,都是浪费! 压力 有关估算/实际涉及的是老板们需要”更多”的自然压力。尽管很多团队已经完成了,这是不够的。更多,更多,更多。 交付有价值的东西,最好的方式不是更多、更多、更多,而是频繁的做有价值的东西。如果我们把故事分解到”足够小”替代估算故事,从而达到一直持续平稳地交付有价值的东西。 聚焦在更多的增值。让团队在越来越大的压力下做更多的需求,不可避免地会产生一个坏结果:团队试图更快速地去做,而忽略代码质量和测试。他们瞬间开始承载越来越多的缺陷,因为持续返工去修复缺陷,甚至由于代码质量迅速下滑而放慢速度。事情变得越来越糟糕,压力持续增长,这将演变成一场灾难的节奏。 由于估算至少被卷入过度压力的投入中,我宁愿避免。 我更深入点:我宁愿完全避免迭代或冲刺计划。在接下来几周,我们不会为去填补预算而工作,而会因为接下来有几项最重要的事情清单而做。 预测完成 一种常见的做法是做个基本特性列表,先想一会,然后决定定义我们产品的下一次发布。当然,接下来的问题是”这些什么时候能全部完成?” 没有人知道这个问题的答案。我们可以做很多工作来改善我们不知道的事,在某些领域和某些时候,这当中的一些事也是值得做的,譬如当一个大的合同等待投标的时候。但是当我们正忙于开发内部或外部客户的解决方案时,尽可能地频繁提供少量有价值的东西,而不是等到通常会无限期拖延的全功能一起发布。 选择临近下一次发布给客户的日期,尽可能地挑选好东西到发布中,这样更好。估算故事点或时间阻碍了交付。在我看来,如果可能的话,这最好要避免。 分解(拆分) 那么问题来了,如果你不喜欢故事估算,那你喜欢什么呢?好吧,我喜欢故事分解,它是将大的故事点分解成更小的故事点集合,每个小故事点尽可能高的价值,然而只需要很少的时间就可以完成,理想情况下,少于一天,也许只是几个小时。 现在,我不在乎与你争论分解(拆分)时是否必须进行某种估算。如果你或者你团队的估算只是在脑海里,没有告诉任何人,那么,不论是故事点或时间的估算问题,就不太可能提出来。当然,了解故事点”可能足够小”和”可能不够小”之间的差异并不等同于知道”三天”和”一天”的差别。 另外,这有个技巧。我在 Getting Small Stories 和Slicing, Estimating, Trimming有提到。我也是从Neil Killick学的:分解故事直到它只需要一个验收测试。一个好的故事点只需要很少的实践。 当然,还有关于估算主题的其他文章,点击链接会有超乎你想了解的。 预测将来 但是…难道我们不应该合理的知道一个产品发布需要多长时间和估算是否必要吗?然而也许这不是故事估算。你应该不会把你的需求归结到故事层面,若这么干,貌似是很大程度的浪费。 当然,如果你必须要这么做,那就这么做。无论我做什么或者我的关于你该做什么的理论,只是理念。最终你需要做的是在自己所处的环境下尽一切可能的成功。只是我觉得可以有些更好的东西。 第一,想想下一次发布的一个或多个重要功能。讲讲这些功能可以解决什么问题和什么样的软件可以帮助解决这些问题。谈谈可以解决一些问题的最简单功能。我们不必要解决所有的问题:通常我们提供一些解决方案足以推动事情的发展。 第二,想一个到那时你觉得可以构建出一些好的功能点的时间节点。设置最后的期限并开始着手工作。 第三,再分解重要的功能故事点并实现它。你应该能够在一天或更容易地实现。只做下一步最重要的:别试图老是先实现边边角角的功能。你应该尝试这样的思维框架”如果做了这个小东西,客户Jack就会在实际中使用它”。然后,就做这个小东西并且让客户Jack试用它。我们想尽可能快的持续传递价值。 我们想把正在做的东西的价值明显化,让产品经理或者其他老板等不及想看到产品。这样…我们就在有或没有故事估算的情况下做了正确的事。

如何打造优秀的远程敏捷团队(9步)

Bob Jiang
最近怎么样? 可怕。我的团队很担心,我们感到与世隔绝,并且我很难将我们重新团结在一起。 听起来很有挑战性。 它是。真的是这样。我只是不了解我所了解的其他团队之间的合作情况如何。 嗯,团队其他成员的感觉如何? 我认为我们每个人都感到同样,沮丧和孤独。 不需要这样,让我们​​扭转一下…… 通过经验学习Scrum的核心。 作为一名活跃的敏捷Scrum顾问和专业Scrum培训师,我一直在帮助众多敏捷团队。毫不奇怪,我所支持的所有团队都在尝试不同的方法来使远程工作正常工作! 我发现有些模式在表现非常出色的团队中很常见 1.创建一个团队WOW (Way of Working) 对于在线工作,团队”工作方式”方法一直是出色的在线Scrum团队执行的首要行动。 Team WOW是团队为自己创建的协议,概述了Covid19发生时我们作为团队将如何合作。一个优秀的团队WOW将回答以下一些问题; 我们将如何合作? 我们会喜欢Skype、zoom等实时通讯而不是电子邮件吗? 如果我们决定采用实时方法(好!),那么我们会鼓励打开摄像头还是关闭摄像头吗? 我们将使用哪些工具来共享我们的工作? 我们将使用哪些工具来可视化进度? 我们的主要工作时间是什么? 我们将如何互相帮助? 我们将如何保持联系? 随着事情的变化和我们了解更多,我们将如何更新WOW? 2.高带宽的沟通 对于日常协作,优秀的团队更喜欢在线的实时通信,而不是电子邮件。协作良好的团队通常会优先考虑 通过视频会议和可视化的网络电话,而不是拨打电话 通过拨打电话,而不是聊天工具 通过聊天工具,而不是电子邮件 通过发送电子邮件,而不是烟雾信号 与我合作的一些团队有主要的视频会议时间,因此他们的摄像头会打开一段时间,以在一天中的一段时间内营造一种联系感。就像和您的团队一起坐了一段时间。其他人仅将视频会议用于安排的会议,这对他们来说就足够了。让您的团队来决定什么工作方式的会议(请参见上文)是有用的,并对其使用进行纪律。 3.实时协作工具 这些工具是团队在分布式时间内保持生产力的重要组成部分。缺乏透明度是我们所有人都应该担心并不断改进的问题。如果我们不知道发生了什么,我们将如何相互支持和帮助?我们如何消除阻碍保持创新和不断创造价值的障碍呢? Trello,Microsoft Azure,Asana,Mural,Miro等协作工具为团队提供了跟踪进度,共同计划,共同回顾和不断保持我们的工作和思想对团队透明的方式,以便我们可以检查,适应克服摩擦并不断创造价值。尝试一些,采用一些。 4.迭代,使用追溯驱动的变更方法 永远不要低估团队不断学习的力量。在充满挑战的时代,我们永远无法确定会遇到什么。如果您是使用Scrum的敏捷团队,那么您已经在使用回顾来了解什么对团队有效,而哪些无效。您已经在适应新情况;您一直在评估自己的工具,并且对新的交付方式保持开放态度。回顾可以帮助我们检查对团队有用的东西,而不是无效的东西–这不仅仅是物理上的东西。良好的回顾有助于消除情绪上的摩擦,帮助我们检查团队的心理和社会健康;对于细心的团队而言,回顾可以帮助我们在出现灾难之前就对问题进行预警。回顾会通过改进问题来帮助我们变得更好。 5.安排调整后的核心工作时间 最好的团队认为,由于我们的孩子,宠物和家属现在与我们在一起,因此标准的9点到5点工作模式可能不适用。在我们的孩子休息或吃午饭,或者狗需要走路,或者年迈的父母需要检查的时候安排会议可能是不现实的。适应新常态的团队会更改其工作模式和核心工作时间,以消除日常挑战。Scrum提供了一种最小的事件模式,事实证明该事件可以在更改时起作用。最好的Scrum团队已经适应了这些事件,以应对团队特定的调度挑战。 6.测试灾难恢复 您的团队已经在使用回顾来适应吗?如果是这样,那么您可能已经在寻找保持连接的备份方式,并在发生意外情况时可视化工作。如果您的高速宽带停止工作,您的备选方案是什么?对备份技术和方法进行同步测试可帮助团队向前看,切换到备份并保持工作。最近,在进行专业Scrum Master培训时,我的互联网完蛋了。某个地方的某人认为这是切入某些电缆的绝佳时机。多么不方便。 幸运的是,我已经花了几天时间在我的移动互联网提供商之外进行培训,并且已经进行了测试备份。几分钟后,我又开始工作了,培训继续进行。您所依赖的关键技术是什么?这些技术失败的可能性有多大?您打算坚持不懈地进行哪些工作? 7.共同缓解技术摩擦 在家工作时,面对所有挑战,学习新技术似乎令人生畏。没必要。一旦您的团队选择了一些好的工具,一种快速学习它们的好方法就是安排学习课程,我们在彼此之间互相教如何在安全的支持环境中最好地使用这些工具。 当我过渡到画画时(上课不用ppt)-我有些沮丧,我只是想不出如何让壁画去表现我想要的样子。幸运的是,Ralph Joachim邀请我参加他的一项在线练习活动,我可以从他的经验以及其他15个专业Scrum培训师的经验中学到东西。拉尔夫(Ralph)创造了一个安全的空间来回答问题,无论是简单还是复杂。结果全面而快速的学习。当我的互联网失败并且我使用壁画通过移动设备进行了培训时,我没有错过任何拍子,为此我有拉尔夫表示感谢。 此外,学习的团队可以快速适应新工具,有意识地互相帮助,并使用协作安排的课程来一起实验,学习和回答问题。他们不希望它,他们计划并且有意识地互相支持。作为对此的扩展,如果您发现您的同事很挣扎,请提供支持并为他们提供支持。刻意帮助您的团队克服和掌握我们所有人面临的技术挑战,不要以为每个人都知道如何很好地使用所有工具。 8.接受学习,解决问题 动荡的时代意味着我们不会每次都正确。出现问题时,很容易对自己和同事感到沮丧。我们需要对我们的团队耐心等待。学会记住,鉴于他们的技能,能力和可用资源,每个人都在尽自己最大的努力来应对面临的挑战。 敏捷不是要怪罪责,而是要把湍流当作生活的一部分并刻意解决问题而不怪罪。 9.安排非工作事件 我认识的一个管理团队在星期四晚上向他们的团队发送信息,以进行星期五的hangout活动,您能猜到在那里工作的人的士气吗?其他团队在工作日结束时会进行30分钟的视频群聊,以讨论非工作玩笑和咯咯笑声。一些团队已经决定每周一次就足够了。尝试对您的团队有用的方法。 保持在线 请记住,Covid-19意味着我们必须在身体上相距遥远,但我们不必在社会上相距遥远。使用以上方法可以使您与团队更紧密联系,并成功克服当今的挑战。保持。连接的。 我们必须使自己摆脱海洋将永远安息的希望。我们必须学会在狂风中航行。 〜亚里斯多德-奥纳西斯

谷歌OKR指导手册 (译)

Bob Jiang
译者:乔梁 来源:《持续交付2.0》公众号 这是一本关于 OKR 迷你小册子,名为《google OKR playbook》,由 www.whatMatters.com 网站发布。 该网站由John Doerr 团队经营, 而John Doerr 正是 1999年将 OKR 引入 谷歌的那个人。 本文仅供大家学习参考,虽然文章较长,但值得一读,欢迎收藏。 文章的末尾有一些 8 道自我测试题,用来验证你的OKR是否在正确的实施。 如果你正实施OKR,可以用它们来验证一下吧~ 在实现OKRs方面 没有人比谷歌更有经验 随着公司规模的扩大,它定期发布 OKR 指南和模板。以下摘录主要来自内部资源,并经谷歌许可转载。 (注:这是谷歌对 OKRs 的做法。你的方法可能不同,也应该不同。) 在谷歌,我们喜欢大张旗鼓。我们使用一个称为目标和关键结果(OKRs)的过程来帮助我们沟通、衡量和实现这些崇高的目标。 我们的行动决定了谷歌的未来。正如我们在互联网搜索、Chrome 和 Android 中多次看到的那样,一个由少量员工组成的团队,朝着一个雄心勃勃的共同目标努力,就可以在不到两年的时间里改变整个成熟的行业。 因此,作为谷歌的员工和经理,我们必须有意识地、谨慎地、明智地选择如何分配我们个人与团队成员的时间和精力。OKR 是这种谨慎选择的体现,也是我们协调个人行动,以实现伟大集体目标的手段。 我们使用 OKR 来规划要生产的产品,跟踪它们的进度与计划,并协调人与团队之间的优先级和里程碑。 我们也用 OKRs 帮助大家专注于最重要的目标,并帮助他们避免被紧急但不太重要的目标分散注意力。 OKR是有野心的,它不是逐步增量式的,我们并没有希望一次性就完成所有这些野心。(如果我们真的这样做,那么,我们就不会具有足够的进取性)。 我们用色阶来衡量我们做得有多好: 0.0 – 0.3 是红色● 0.4 – 0.6 是黄色● 0.7 – 1.0 是绿色● 正确的OKR制定方法规则 没有认真实施和管理的OKR,是一种时间上的浪费,是管理上的假大空。与之相反,如果实施得好,OKR将是一种很好的动机激励工具,它能让团队明白什么是真正重要的,哪些地方需要优化,在日常工作中应当如何去进行利弊权衡。 要写出好的OKR可不是一件容易的事,但也不是不可能。请遵循如下这些简单的OKR制定规则: 规则1:O 要回答的是 “What” 的问题,它应当: 表达清楚目的和意图;

敏捷不是反管理,而是更加激进!

Bob Jiang
译者:Nikijv 审校:Bob Jiang 英文原文 一个Twitter的帖子问”敏捷”是否反管理,以及”敏捷”为什么经常看起来很像反管理。简单写一下,本文中我个人的观点是敏捷软件开发如敏捷宣言所设想的那样,并不是反管理。这比反管理更激进:这是一种完全不同的管理方法。 敏捷软件开发仍然比当今的认知更激进,相当的不幸,包括大部分品牌和方法,在我这个有点老的男人对云观点大喊大叫的时候,也被大多数较小的”敏捷”供应商所采用。 敏捷软件开发正如我们所定义的那样,对于业务与开发间的日常协作较为频繁,以维持增量的可工作软件。这样团队称为自组织团队,尤其要说明的是:最好的架构、需求、设计来自这些自组织团队。 原则上很清楚,软件、架构、设计等一切工作都源自于团队,从团队中涌现。 例如,需求不来自于一些业务单元,而是通过中央委员会进行传递,然后传递到一些传统部门或项目部门直到它落在一些程序员的办公桌上。 这不是”反”管理。这根本不涉及解决类似于预算工作、人员补偿、评估性能或者其他”管理”关心的主题。 当然,敏捷软件开发提出了一个新的、不同于软件产品制作的管理。尤其通过基于工作软件的可持续生产使用的自组织、增量、速度技术,是解决软件开发应该被管理的新方式。 敏捷是反管理的么?我不这么认为,敏捷明确反泰勒式的管理,而支持推动管理。 同样,像所有好人一样,我们更乐于好的富有成效的管理,强烈反对贫瘠、无效、有害的管理。 但是我想建议这个底线是: 如果一个组织试图通过任何传统的方式控制团队的选择,该做什么以及如何做的选择来管理敏捷软件开发,这样很可能他们做错了。 如果你是敏捷的支持者,你试图与传统管理达成某种中间状态或和解,有可能你也是没有真正理解敏捷软件开发的根本意图。 一、scrum在发光 考虑到Scrum的构想,最流行的敏捷方法如果不是最有效的,那什么是? Scrum称为自组织的团队,包括产品负责人,被授权于全部权利和责任,负责大型组织团队的投资回报率。Scrum团队中Scrum开发者的开发团队,必须包含交付产品增量的”全部必要技能”,一个被集成、测试过的、可工作软件包括团队迄今为止产生的所有价值元素。 Scrum承认Scrum团队是嵌入式的,以某种方式,在一个组织中,组织提供了资金(投资),干系人关心Scrum团队做了什么。敏捷团队通过每个冲刺向干系人展示他们已完成的工作,邀请并听取干系人的意见。Scrum团队与全权负责的产品负责人决定下一个冲刺做什么以及怎么做。 冲刺审查是Scrum团队及其嵌入组织之间的完整接口。 关于Scrum仍然有些问题没有解答,同样这些问题在上面Twitter的帖子中也涉及到了。Scrum不会告诉你如何预算,如何决定补偿,如何评估性能等等。 在Scrum课程中,人们经常询问各种管理职能。有个经典实践可以回应,课程上小组在便利贴上写下他们能想到的所有管理职能。他们可以把这些便利贴放到下面4个位置:开发团队,产品负责人,Scrum教练以及其他。 将会有两件事发生。首先,许多传统管理职能转移到一个或多个Scrum团队元素。由团队分配任务,由产品负责人决定要构建什么,由Scrum教练支撑和引导等等。有趣的一点是,总有些管理职能被贴到其他堆中。Scrum甚至不会建议如何做这些:这已经超出了Scrum的范围。 然而,很明显,Scrum打算不管这些超出范围的管理职能是什么,它们与团队的首要接口,可能只通过冲刺审查。尤其是除了产品负责人,没有人可以要求团队做任何事情,Scrum对”经理”在Scrum团队运行时可以做什么做了非常具体的限制。 二、敏捷软件开发是反管理么 敏捷软件开发需要一种新的管理方式,在团队规模上,团队内部拥有对产品的所有权利和责任,而且最主要的接口是检查实际演变的产品。 不一定是”反管理”,但一定与某些类型的管理背道而驰,尤其是源自于泰勒主义更具有侵入性的形式——福特主义,将工作视为机器,工人几乎没有权利或仲裁。尽管敏捷软件开发肯定要求从团队内部而不是外部应用这些概念,但与戴明和统计过程控制等概念的对立程度要小得多。 但我觉得主要的概念已经相当清楚:敏捷软件开发是一种完全不同的管理方法,尽可能的把权利和责任下放给团队。这种管理方法对于如何走得更远没有设置上限,但它设定了一个相当严格的下线,这个下线是嵌入在团队内部的产品做什么以及如何做。 三、这些想法的限制是什么 这很难说。我们通过敏捷团队的成长能力去决定谁在团队谁不在团队,这对薪酬和评估有很大影响。我们开始听到团队中的谁直接与客户合作,客户有时基于固定价格安排,或者更常见的基于运行速率为产品提供资金。 今天,更多的限制是被组织强加的——试图做”敏捷”,这些限制中有很多是明显错误的。有时组织没有从战略上很好地理解最好的管理是如何的。我通常认为,个人管理结构应在敏捷之前就位:不同的团队成员”属于”一个或另一个经理,而该经理则继续尝试对团队成员的行为进行控制。 坦白讲,自组织团队被授权,而这导致冲突、混乱以及很多时候应该做敏捷组织主要来源走向黑暗敏捷。这个观点是正确的。 底线,敏捷软件开发提倡不同的管理方式,很可能与一些过时的管理观念不相容,不幸的是,这些观念在今天仍然相当普遍。 反对的?不。完全不同?是的。 原文链接

知行合一的敏捷实践 来自道富银行 杨贵的分享实录

Bob Jiang
知行合一的敏捷实践 内容来源:敏捷+社区线上直播003期,《知行合一的敏捷实践》分享实录 分享者:道富银行敏捷教练杨贵  关注本公众号回复“知行合一”即可获取本次分享的视频回放、下载PPT。 一、原动力-你在为谁工作 在敏捷实施过程中,有几个问题很关键,包括组织的问题、人的问题、执行力的问题。其中组织的问题不在我们个体控制范围之内,今天主要聊聊人和执行力的问题。 点击阅读原文 查看回放 总结 总结来说,知行合一的敏捷实践要求做到: 价值观的认同,团队成员要有一致的价值观。 工作过程有章可循,定义好活动规则和检查规则。 团队成员积极参与。制定各项规则的owner。 反馈闭环,以数据驱动反馈闭环。 技控,用机器和工具来解决问题。