如果您突然要管理一个虚拟团队-你们中的许多人-这些做法将帮助您进行过渡
远程人才计划负责人在所有人突然从家里工作之前，远程工作是一个热门话题。根据我们进行的内部调查，接受调查的Atlassian中有95％愿意改变工作方式以实现远程的工作。
但是，我们大多数人仍然对在家工作及其特征尚不陌生。这不仅是弹性工作时间，不是您的日程安排中的在家工作，或者是为住在农村州的队友提供住宿。现在，尤其是整个团队都在远程工作。这意味着新的实践（或对常规实践的修改），新的工具和新的交流方式。为了使所有这些工作顺利进行，团队负责人要承担更多责任。管理人员定下基调。无论您的团队是一起坐在一个房间里并挤在一起，还是在Zoom会议中实际上是分布并挤在一起，都是如此。
但是要振作起来。尽管管理虚拟团队可能对您（以及许多其他人）来说是新的，但其他人已经有一段时间了。以下是对这些远程领导者有所帮助的一些实践，列出了管理和支持远程团队的实用方法。这些轶事和故事，关于什么是行得通的，什么是行不通的，这些将有助于您作为新远程船的船长在这些奇特的水域中航行。
管理虚拟团队的5个基本技巧 1.过度沟通 大多数领导者心中的一个大问题：远程领导团队和亲自领导团队的*主要*区别是什么？好吧，不只是*一个*区别。但是，可以肯定地说，您首先应该关注的是沟通，以及每个人在远程工作时通信是如何改变的。
在”正常的工作”中，许多决定是通过走廊交谈或午餐时间做出的。当这种临时信息共享没有发生时，您必须以某种方式替换它。首先要做好过度沟通。对于团队中的某人而言，根据新的决定，任务的状态或最近的更新，不同步就太容易了。无论如何都会发生，对吧？试想一下，当您的整个团队都在远程工作时，事情会跌落的裂缝。不仅仅是这些偶然的联系机会减少了，而且熟悉的团队信息交换也被完全破坏了。
因此，过度沟通。练习一下。使用Slack消息，@提及和电子邮件可以使所有人保持联系，即使您认为自己在重复。询问他们是否了解某些事情，即使您确定他们确实知道。请记住，如果是在小组互动中，则可能是Zoom呼叫中的其他人因为您询问或重复信息而不知道并了解到了该信息。重复一些内容以保持清晰无害，并且可以立即解决一些问题。
小提示 默认情况下，尽可能通过1:1消息进行团队沟通，并创建共享页面（如Trello面板或Confluence页面）以记下这段时间内的交流做法，以便整个团队可以关注和修改。
2.透明地工作 当然，还有另一个大问题，尤其是对于经理来说：您如何知道您的团队在工作？他们有生产力吗？
“我对100％远程访问的最初反应是每天通过Zoom进行登录，并坦率地安排了更多会议，” Atlassian PMM组的Claire Drumond说。”我意识到，我的团队在证明他们的工作压力方面与在确保他们没有压力的压力一样大！我们仍在继续完善自己的礼节和学习，但是如果没有信任和诚实，您将无法改善事情。建立对技术的信任与在工作时间空闲的人无关，这是要设定明确的期望和沟通。”
从很多方面来说，如果您真的聘请了合适的人，则不必为此担心。您应该相信您的团队，相信他们是您雇用的成人专业人士。但这是一个公平的问题，帮助回答这一问题的一种方法是查看您的工具。在Atlassian，我们使用Trello，Confluence，Jira，Slack，Zoom和许多其他工具。但是，无论使用哪种工具，都与您如何使用它们以及对您在做什么和何时进行透明化以及与团队和利益相关者共享所有有关的信息。
如果您正在寻找确保这种基本信息共享发生的方法，并且正在讨论项目和里程碑，那么可以尝试以下方法：
考虑频繁地更新Slack状态。要针对自己和团队，养成具体且一致的习惯。”深入工作”，”下午1点的午饭时间”和”散步”确实很不错。 @提醒多人。如果您不特别针对某人，请不要以为别人会看到评论或更新。重复使用某人的名字以确保其知情并没有什么害处。 使用共享的Google日历，并保持更新。一致的日历非常适合了解每个人的工作（无论是工作还是非工作生活）。 尝试站立会议。这些简短的团队会议可能非常有效。您可以更改一天中的时间，频率和名称。一些团队从YTB开始他们的一天-他们昨天做了什么，今天他们正在做什么，以及任何阻碍者。团结一致是一种一致的做法，当每个人都处于远程状态时尤其有效。 简而言之，请开发实践以帮助您的团队保持联系并提供有关正在发生的事情以及在哪里可以找到信息以了解正在发生的事情的更新。您不必担心人们在做什么，但是这将使您和他们的头脑轻松，为每个人提供共享更新的方式。
3.建立团队的远程工作基本规则 当事情是新的和不同的时，很难知道如何设定期望。像以前一样？如果远程团队不一样，怎么办？
简单的答案是：确保团队中的每个人都在同一页面上（大家的理解是一致的）。分组讨论，并得到大家的投入。在家工作对许多人来说是新事物，在当今不确定的情况下，它尤其独特。家里有孩子和其他家庭成员，新的时间表和节奏，无数的压力和担忧。必须考虑所有因素。在就您的团队需要以及您作为经理的需要和需要进行的这些坦率的交谈之后，请考虑以下提示：
在页面上记录所有内容，以帮助确保每个人都在同一页面上。这意味着一切：方法，角色和责任，行动项目，期望，关键决策等。 花时间与团队讨论您的沟通渠道和工具以及如何使用它们，包括预期的响应时间。 讨论如何在共享工作上保持一致，以及如何在该工作上进行协作。换句话说，建立您的分享习惯。 使用不同类型的会议-1：1，小组会议，整个团队-提供反馈并养成熟悉的习惯。 您正在做的是创建剧本。您正在建立有关团队运作方式以及每个成员的期望的规则。
4.检查人们的个人情况 您的团队表现如何？问，然后再问。这不仅意味着项目，还意味着人们的行为*方式*。首先，要为您的团队创造一个安全的空间来分享思想和感受。在如此空前而艰难的时期，这至关重要。作为经理，请尝试找出每个人的*实际情况*。寻找并提供必要的时间和空间进行私人交谈。
偏远的人经常遭受过度劳累。工作与生活之间的界限模糊，并适应不同的时区，通常很难”拔出”插头。所有这些都会损害人们的福祉。更不用说与远程工作相关的孤独感，更难以”看到”职业倦怠或与远程团队成员识别孤独感。
您必须经常检查，并真正证明您对团队的承诺。如果他们在截止日期前需要一些额外的时间，则要灵活一些。如果最近几天团队成员似乎还没有出现，请检查一下。以下是一些开放式问题的想法，这些问题有助于建立安全的空间：
你有什么感觉？ 您的工作量如何？ 你的倦怠程度怎么样？ 什么是最重要的？ 你的世界怎么样？ 你的工作怎么样？ 5.建立有趣的远程团队礼仪 在完全远程的同时保持团队的社交联系与以往一样重要。但是，您如何远程进行呢？
为了使团队保持一致，Atlassian创意总监Leah Pincsak发现了这样一个瑰宝：”打包您的几周社交活动，使其成为可选项，并且如果没有人出现，请不要感到冒犯。”
无论情况如何，团队之间的社交联系都至关重要。远程团队可以从团队社交礼仪中受益匪浅，但是需要有意识地培养他们。换句话说，不要强制虚拟的欢乐时光，只能像喝酒那样像例会。正如Leah所了解的那样，要使社交活动正常运作并感觉正确，它们必须是可选的。没有这种义务的感觉，他们为非强迫联系保持了必要的随意性和自愿性。
要考虑的其他社会观念：
设置社交Slack渠道，以在各种主题上保持联系。通常被称为”虚拟水冷却器”，创建一个聊天或分享特定主题的地方。 设置虚拟咖啡，午餐或欢乐时光。指定的时间在一起很漫长。 尝试像破冰船一样通过快速的个人登记开始每个团队会议。 一起玩虚拟游戏，这可能是一个很棒的结合体验。同样，请确保这些活动始终是自愿的，并保持这种感觉。鉴于目前情况如此之多，要求父母在漫长的一天之后而不是与孩子们一起度过”玩乐时间”是一个很大的要求。 查看一些虚拟团队建设活动，以探索更多想法。 像任何东西一样，这需要一些习惯。但是，您已经建立了可以模仿的虚拟团队管理实践和习惯。是的，这与在更”传统”的环境中一起工作并不相同。但是，您只需付出一点点努力，就可以比以前更好（甚至在某些情况下甚至更好）一起工作。
作者： NIKKI BELLINGTON
译者： Bob Jiang
内容来源：敏捷+社区线上直播006期，《IPD下的敏捷实践》分享实录
分享者：京东单冰
关注本公众号回复”IPD”即可获取本次分享的视频回放、下载PPT
大家好，非常有幸能够和Bob相约一起，给大家做这一次的分享。我现在就开始了，在京东智联云变革的这种形势之下，我们从去年开始接触到了IPD。之前认识我的伙伴们都知道我在京东做敏捷转型这方面的事情。 先自我介绍一下，我在京东算时间比较长了，之前在京东零售现在在京东智联云，之前我们叫AI，今年AI和云合并叫智联云，我正在负责京东智联云产品研发BP的项目管理团队。我们团队会负责敏捷转型等管理工作，同样也会带团队做管理变革、做 IPD流程导入，并且计划把敏捷和IPD进行一个完美的融合，希望去拉动产品线做融合。
对于我自己来讲，参与全国敏捷社区的活动组织，做过敏捷之旅、Tid大会、和多次全球技术周的分享嘉宾。非常愿意跟大家去一起分享在敏捷落地中的一些感受。很多同学其实之前在问我说你们在做IPD，这个跟敏捷是不是有一些冲突啊？会不会是我们又回到大的瀑布了？所以今天这个分享也会跟大家去做一些探讨和解读。
今天我们大概会分三个部分去给大家做一个分享：
第一个部分，从整体业务企业敏捷生态圈去考虑怎么样使敏捷联动市场，直接引导市场价值。 第二个部分，讲讲如何和做IPD，这是今天跟大家探讨的一个重点部分，如何用敏捷+IPD拉动市场。 第三个部分，敏捷+IPD环境下，敏捷教练项目经理应该在什么位置？怎么样去自我变革？怎么样去引导团队？ 第一部分，启动篇
业务级敏捷系统生态圈，市场导向直击价值
为什么要做这件事情呢？在市场的引导下，一步一步的去验证敏捷，去引导团队。变革就是因为在不确定的这种环境下，会面临很多不确定的事情。在团队变革的过程中，它也会新陈代谢的。在市场环境里，公司会面对很多严峻的问题。 现状问题是什么？面对这么大一个成熟团队，面对两个成熟团队的融合，你会看到他们的问题到底在哪？首先从问题出发，方向就是解决这些问题。
查看原文获取更多材料
敏捷转型非常复杂。成功有巨大的好处，但不能保证成功。客户所钟爱的生产力，创新和更高品质的产品或服务的提升，可以使转型组织的挑战变得非常值得。
与任何工作一样，在开始之前进行正确的准备将大大改善结果。 作为Scrum的教练和培训师，多年来，我与各种各样的客户合作，从金融到农业，从媒体到制造业，并且不断发现6个关键要素可以使您的转型正确地开始。 1. 建立合适的团队 敏捷转型可能是组织上的，但它是建立在强大的Scrum团队的基础上的，这就是为什么您需要拥有”合适的团队”的原因，但是在当前的偏远地区，招聘比以往任何时候都更加困难。让您的团队参与招聘过程至关重要。文化适应对建立强大团队和技能组都同样重要。视频聊天是虚拟世界中重要的面试工具。这使团队有机会与候选人见面，并使候选人看到团队互动。 每个团队都应该具备从开始到交付工作的所有必要技能，但是团队也应该足够小以确保轻松协作（《 Scrum指南》本身建议三到九个人）。这消除了跨团队或跨部门的依赖性。最大的时间浪费是在等待其他团队或经理的”批准”或”答案”。这些延迟开始增加，使团队没有足够的时间来实现他们的目标，这正在缩小！ 团队需要明确的目标和方向，以供他们开发产品。这种共同的愿景有助于团队感觉相关并与更广泛的企业联系。一旦有了明确的指示，团队就必须拥有”方法”。他们必须有权组织自己，以构建自己认为合适的高质量作品。 领导力将使团队有责任按时，按预算完成这项工作，还将寻求使他们能够采取行动，而无需不断的检查和批准。达到这种平衡至关重要。而且，这将有助于塑造敏捷转型的组织文化。
2. 从第一天开始就有好的指标 您怎么知道您的转型是否有效？这是一个重要的问题，在敏捷转型已经开始之前，这常常被忽略。 通过尽早设置这些指标，您可以从第一天开始进行检查和调整，并极大地增加了成功的机会。 在开始新的冒险之旅之前，团队需要知道成功会是什么样。管理层和团队都需要就我们将要采取的措施达成共识，以确认我们的新工作方式确实有效。团队和经理都必须明确期望。 期望对于与团队合作的每个人必须透明。
“您为什么开始这一转型旅程？” 该问题的答案是什么定义了转型的目标，并最终定义了工作的成功。清晰的愿景提供了目标。目标是团队的主要动机（Dan Pink，*Drive*，2011年，中文版《驱动力》），并确保从领导者到产品负责人再到团队成员的每个人都为实现这一至关重要的共同愿景而努力。
团队幸福感是所有企业特别重要的一项指标，尤其是在我们正在一个偏僻的工作环境进行敏捷转型。随着社交选择变得越来越有限，我们必须密切关注幸福。幸福是主要指标；当团队的幸福感突然下降时，质量和速度往往随之而来。 3. 专注于产品而非项目 组织通常将精力集中在他们的”下一个大项目”上，但是，如果您退后一步，您会发现这种思想的潜在缺陷。项目是一项短暂的工作，将”紧急”放在优先位置。但是，优秀的团队实际上是长期存在的。 一个项目可能代表着全新的事物。或者它可能只是已经存在的新事物。但是产品是持续交付的服务或功能，是公司使命的核心。 了解这两者之间的区别是关键。敏捷组织特别了解他们的产品是什么，以及他们的项目适合企业的整体情况。他们对自己的价值流有清晰的了解，因此可以开始围绕传递价值和发展这些价值流来构建其转型。 稳定的团队会更成功，这是建立在团队协作并学习如何协作的基础上的。它随着时间的流逝而发生。
4. 选择合适的产品负责人 产品负责人（PO）是*至关重要的角色* ，是团队和敏捷转型的关键。产品负责人应该激励他们的团队。在寻找一个好的产品负责人时，要寻找一个即使使团队遥遥领先，也能使团队对其所做的工作以及他们的产品*可能*感到兴奋的人。产品负责人还必须对团队有强烈的信任，他们会弄清楚如何单独交付PO所要求的。最重要的是，在为您的团队寻找PO时，请找一个善于倾听的人。倾听是强大领导力的核心。
专门的产品负责人是鼓舞人心的领导者。她拥有团队目标的愿景；团队需要做什么以及为什么需要这样做。 他们必须对自己的市场及其当前趋势具有深刻的见解和认识。为了实现这一目标，她必须花大量的时间从客户和利益相关者那里获得重要的反馈，然后利用这一见解来塑造与团队共享的愿景。阐明愿景使团队成员具有目的感以及与企业目标和使命的联系。这就是为什么我们说PO拥有”什么”（指的是方向）。
最后，这是一项全职工作。 产品负责人不能只专注于该角色。他们不能再有”日常工作”。一个已经有另一份工作的PO对两者都不利，并降低了整个企业的价值。许多组织都迷失了这一步。开始转型时，请不要犯此错误。每个团队一个PO并不是成功的秘诀，但多个团队的一个PO无疑是灾难的秘诀。
译者注：这里Bob并不同意原文的观点。多个团队（前提是一个产品）一个PO是很合理的。具体细节回头再展开一篇文章。
5. 选择合适的Scrum Master Scrum Master必须是服务型领导。 那么到底是什么意思呢？
Scrum Master不仅可以促进Scrum活动的开展，而且还是值得信赖的团队成员，致力于为团队提供支持和”服务”。这包括在Scrum上指导团队和产品负责人，并消除可能会使团队减速的任何障碍或问题。 Scrum Master角色需要高水平的情商，才能了解团队的动态并保持进度。Scrum Master准备好并且愿意与那些”不舒服的”对话来帮助团队克服在学习成为团队中自然产生的挑战。一起感到不舒服，一起感到舒适。
Scrum Master需要衡量他们的团队是否满意。研究清楚地表明，快乐的团队可以更好、更快地完成工作，并能提供更高质量的工作。在2012年1月至2月的《哈佛商业评论》中，他们将整本杂志的重点放在幸福上。他们发现的是：
”……我们发现，使员工感到幸福的唯一途径也是使股东受益，这是因为出色完成一项重要工作所带来的成就感。我们不仅要使员工”快乐”，而且要通过帮助他们成就伟大的事情来实现。简而言之，我们应该通过帮助员工赢得客户的热情拥护，赢得员工对公司的使命和成功的热情拥护。” （HBR博客Rob Markey，2012年1月7日）
Scrum Mastery是我最爱的角色。在远程工作的世界中，Scrum Master的工作要困难得多。在远程工作的团队中，您的Scrum Master将是帮助指导团队如何共同工作和保持一致的人。她将通过制定团队工作协议，然后让团队负责达成他们达成的协议来做到这一点。在我们合作的世界仍然未知，建立、执行和重新评估该协议对于建立强大的团队动力至关重要。
Scrum Masters还可以帮助团队专注于工作与生活的平衡。众所周知，现在远比在办公室工作要困难得多。这需要有人让每个人都对自己的真实感受保持诚实，有时，认真研究我们的实际举动是我们自己做不到的。Scrum Master必须成为提醒我们的指南，以提醒我们如何在这个不确定的工作环境中照顾自己。
6. 指导与管理 甚至在为敏捷或数字化转型启动第一支团队之前，您都需要获得领导的支持。最重要的是，管理者需要成为指导者。 任何成功的转型都涉及思维方式的重大转变。没有这种转变，您的组织就有使用Scrum术语（”仅以名称命名敏捷”）的危险，而实际上并没有改变您的工作方式。
在一个转型的组织中，领导力的目的是定义和共享组织的愿景，消除使团队变慢的事情，并指导和授权他人。 管理工作；带领人。随着世界变得越来越疏远，这变得更加真实。事实是，许多人喜欢生活中的自治和授权感。通常，传统的”人事管理”会感到束手无策，尤其是对于像我这样的人而言，他们立即拒绝被告知天性该做什么。领导力是关于赋予人们权力，提供心理安全和服务型的领导力，但同时也意味着要使人们对自己做出的选择的结果负责。我们必须能够相信我们的团队不需要持续的监控。他们真正在乎产生卓越的结果。
我什么时候不使用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.
为什么初创公司通常是充满活力的网络结构，度过初创阶段则通常会成长为官僚化的层级结构？这里简单探讨两个驱动因素，如下图中左侧悬臂（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和预测计划共存！
在这个博客中，我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度，并确保持续解决和减轻障碍和依赖性。它还将预测变成对话（与被视为承诺的项目计划中捕获的固定估计相反）。
参与团队回答的核心问题是：
敲黑板 - 划重点（译者注）
“您是否有信心在本季度末之前完成关键结果？”
你可能还喜欢 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团队的成员都会问自己两个问题：
“我们对在接下来的四个冲刺中交付多少产品列表条目充满信心？”
“在接下来的四个冲刺中，我们还能提供多少呢？”
绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。
我常说我可能发明了故事点，如果真是这样，现在我会感到很抱歉。让我们一起来探索我现在对故事点的思考。至少有一个人对我所想的很感兴趣。 – 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试用它。我们想尽可能快的持续传递价值。
我们想把正在做的东西的价值明显化，让产品经理或者其他老板等不及想看到产品。这样…我们就在有或没有故事估算的情况下做了正确的事。
最近怎么样？
可怕。我的团队很担心，我们感到与世隔绝，并且我很难将我们重新团结在一起。
听起来很有挑战性。
它是。真的是这样。我只是不了解我所了解的其他团队之间的合作情况如何。
嗯，团队其他成员的感觉如何？
我认为我们每个人都感到同样，沮丧和孤独。
不需要这样，让我们扭转一下……
通过经验学习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意味着我们必须在身体上相距遥远，但我们不必在社会上相距遥远。使用以上方法可以使您与团队更紧密联系，并成功克服当今的挑战。保持。连接的。
我们必须使自己摆脱海洋将永远安息的希望。我们必须学会在狂风中航行。 〜亚里斯多德-奥纳西斯
