未找到页面 – 敏捷开发咨询顾问,Scrum认证,敏捷项目管理培训,敏捷教练 https://www.uperform.cn Tue, 26 Mar 2024 08:06:51 +0000 zh-CN hourly 1 https://wordpress.org/?v=6.4.3 https://www.uperform.cn/wp-content/uploads/2018/07/cropped-cropped-UPerform-ico-1-32x32.png 未找到页面 – 敏捷开发咨询顾问,Scrum认证,敏捷项目管理培训,敏捷教练 https://www.uperform.cn 32 32 身为Scrum Master,为什么你组织的持续改进没有效果? https://www.uperform.cn/continuous-improvement/ Tue, 26 Mar 2024 08:06:04 +0000 https://www.uperform.cn/?p=8066 […]]]> 在Scrum团队或敏捷团队中培养持续改进的文化对个人幸福、提高效率、建立与利益相关者的信任以及提供真正改善客户生活的产品至关重要。本文深入探讨了从《Scrum反模式指南》书籍中提炼出的十项可行策略,为渴望拥抱改善实践的团队提供了一份路线图。从拥抱Scrum价值观和培育心理安全到优先考虑客户反馈和持续学习,这些策略提供了一个全面的方法,促进创新、合作和持续改进。

团队持续改进的十大行动

为了培养持续改进的文化并拥抱改善实践,对于希望提高效率、建立与利益相关者的信任以及交付能够显著影响客户生活的产品的Scrum或敏捷团队的改进建议:

定期反思与回顾

重要性:定期进行回顾能够让团队停下脚步,反思过去的行动、实践和工作流程,找出优点和改进的空间。这种持续的反馈循环对于调整流程、提升团队动力并确保团队保持敏捷、应变能力强至关重要。

步骤:确保在每个迭代结束时都能保持回顾的一致性。在这些会议之前,共同制定一个促进开放和包容性的议程。组织者应该采用匿名反馈机制和引人入胜的游戏等实践,以确保诚实和建设性的讨论,为有意义的进步和团队发展奠定基础。

执行改进行动

重要性:实施已确定的改进措施表明团队致力于持续改进,并确保从回顾和反馈中获得的见解得以付诸实践,从而产生实实在在的收益和进展。

步骤:在每次回顾结束时,共同努力确定改进行动的优先级并确定明确的责任归属。将这些行动整合到团队的工作流程中,在看板或任务列表中像处理其他任务一样跟踪它们。定期在后续的回顾中审查它们的进展,确认它们是否在完成的轨道上,并评估它们的影响,确保这些努力能够为您的流程和结果带来有意义的改进。在负责人遇到困难时提供支持。

拥抱Scrum价值观

重要性:将Scrum价值观深入融入团队的理念中,促进了一个有利于持续改进的工作环境。这些价值观指导着行为和决策过程,确保每个团队成员都与Scrum原则保持一致和承诺,从而增强了合作和效率。

步骤:举办一次专门的会议,团队共同讨论每个Scrum价值观,并确定在日常工作中体现这些价值观的具体行动或行为。创建一个团队章则或工作协议,将这些价值观纳入其中,并承诺互相对彼此负责——就像专业人士一样。

建立心理安全

重要性:心理安全是团队创新、冒险和开放沟通的基础,让团队成员能够毫无顾忌地分享想法、挑战和反馈,而不必担心负面后果。对于营造一个持续改进蓬勃发展的环境至关重要。

步骤:通过匿名调查启动团队当前心理安全状况的评估。之后,进行一次专注于积极倾听、建立共鸣和解决冲突技巧的研讨会。定期跟进进展,并将心理安全设定为回顾中的一个经常议程项目。此外,当团队的安全在组织层面受到威胁时,与领导层联系,启动关于如何改善情况的讨论。

促进利益相关者合作

重要性:有效的利益相关者合作确保团队的努力与更广泛的业务目标和客户需求保持一致。在整个开发过程中吸引利益相关者参与,可以引入多元化的观点和反馈,这些反馈可以突显出改进的未预见领域,并确保产品开发走在正确的轨道上。

步骤:将利益相关者作为一个团队进行参与,从Sprint评审开始。此外,建立清晰的沟通渠道和反馈机制,以促进持续的对话;你希望在Sprint评审之外也能获得来自利益相关者的反馈。记住要根据利益相关者的需求量身定制沟通方式;有时,这可能需要一份书面报告。

赋予团队决策权

重要性:允许团队就他们的工作做出决策,增强了他们对结果的拥有感和责任感。这种自我管理的程度对于营造一个由最接近工作的人推动持续改进的环境至关重要,从而实现更加有效和及时的改进。

步骤:首先制定一个决策框架,鼓励协作,并力求达成一致,而不是采用基于同意或多数决策的模式。直接采用同意或多数决策可能会妨碍团队的统一性,并导致派别的形成。在回顾中确定决策时应用这种包容性方法。这为团队提供了一个平台,让他们练习和完善集体决策能力,确保每个团队成员的观点都得到认可和重视。

利用视觉管理工具

重要性:像看板板这样的视觉管理工具提供了关于工作进展、优先事项和瓶颈的透明度。这种可见性有助于团队更有效地管理其工作流程,识别改进机会,并做出明智的决策。

步骤:共同建立或完善看板板,确保它真正代表团队的工作流程。它应该用于工作进行中的限制、阻塞任务和质量控制检查点。养成在回顾中评估和更新看板板的习惯,根据不断发展的团队需求和流程进行调整。在每日Scrum会议期间考虑使用“遍览看板”的技巧。

专注于客户反馈

重要性:优先考虑客户反馈可以使团队的努力立足于真实的用户需求和体验,直接推动与客户满意度和产品成功相关的改进。这确保了团队始终专注于提供价值并解决正确的问题。

步骤:建立一个系统的反馈收集流程,这可能涉及组织用户访谈、部署调查或进行Beta测试会议。将定期的反馈审查周期纳入到回顾、冲刺规划和冲刺评审会议,或产品待办事项完善会议中,以确保客户见解持续地融入到开发周期中。

培养成长型思维

重要性:在团队内部鼓励成长型思维,促进学习和适应能力的态度。它帮助团队成员将挑战和挫折视为成长的机会,推动个人和团队的发展和创新。

步骤:组织一个关于理解和接受成长型思维的研讨会,包括拆除固定思维信念的练习。激励团队成员确定并追求个人发展目标,并经常交流见解和成就,可能通过像“学习日志”或在Sprint回顾的情境中进行。

持续学习和技能发展

重要性:投资于持续学习和技能发展,确保团队保持适应能力,能够克服新挑战。它支持团队能力的发展和创新解决方案的引入,使团队和产品始终处于行业趋势的前沿。

步骤:每个迭代为团队成员安排特定时间参与学习活动,如在线课程、研讨会和午餐袋、配对或集体编程会议。通过“学习展示”或内部迷你研讨会传播新获得的知识和能力,促进共享增长和专业知识文化。

]]>
Scrum团队如何定义“有价值”? https://www.uperform.cn/team-values/ Fri, 15 Mar 2024 08:45:23 +0000 https://www.uperform.cn/?p=8054 […]]]> 前言

Scrum框架的存在是为了尽快向利益相关者交付价值。听起来不错,对吧?但什么是“有价值的”?对于Scrum似乎如此核心的东西,却很少有关于“价值”含义的指导。我们担心,如果没有对其进行有意义的定义,它将仅仅是一个词而已。

在这篇文章中,我们提供了一个更细致的方法来理解“价值”对于你的产品和产品待办事项的意义。

在Scrum中最大化价值

在Scrum框架中,对于Scrum团队尽可能频繁地交付有价值的增量是很重要的——至少每个冲刺一次。每个增量都使团队及其利益相关者离有价值的产品目标更近一步。没有这一点,就很难了解还需要什么,以及降低复杂工作的风险。产品负责人负责最大化开发人员完成的工作的价值。

虽然这听起来是个好主意,但在现实世界中这到底意味着什么呢?

你如何确切地说出你的Scrum团队交付了价值?你需要观察或看到发生了什么?

你的团队交付的所有工作是否都应立即对利益相关者有价值?或者可以有一些延迟吗?

“最大化价值”在Scrum团队做出的行为和决策方面意味着什么?

产品目标如何指导什么是有价值的?

Scrum团队如何决定产品待办事项中哪些项目比其他项目更有价值?他们基于什么做出这些决定?

在决定什么具有“价值”时,你采取的是哪个角度?

这些问题很难回答。Scrum指南巧妙地避免了对“价值”进行定义,并认为它取决于为其完成工作的上下文和利益相关者。但是,当一个Scrum团队缺乏对价值的工作定义时,它如何能够有效呢?我们很容易想象到一个Scrum团队通过完美地完成他们的冲刺,每个冲刺向利益相关者交付高质量的增量,但实际上却没有交付任何有价值的东西。

事实上,在僵尸Scrum的情况下,我们经常看到这种情况;尽管每个人都在按部就班地工作,但最终却没有任何有价值的东西。仅仅“做Scrum”并不能神奇地产生价值。

让我们从两个角度来理解价值:价值与利益相关者。

每当Scrum框架谈到“价值”时,它指的是Scrum团队与其利益相关者之间的交易。换句话说,只有当交付并得到利益相关者的验证时,某物才有价值——在此之前,任何价值都是纯粹假设的。

利益相关者是对产品有实际利益的人——而不是仅仅转达或代理他们个人没有的需求的人。当Scrum团队交付的工作对利益相关者有价值时,他们将获益;当团队没有交付有价值的工作时,他们将损失。

因此,尽管积极使用你的产品或用他们的资金投资于其发展的人可能是你的利益相关者,但你的市场部门同事可能不是。虽然你的同事可能对你的产品或如何营销它有有用的意见,但他或她可能并不使用它,也没有投资于其发展。

这给了我们一个重要的见解:我们需要从实际利益相关者(而不是代理人)与Scrum团队之间发生的交易的角度来看待价值。这也突显了大型组织中的Scrum团队经常面临的挑战之一。他们的实际利益相关者通常隐藏在组织的后面,有价值的问题经常被完全忽视,因此重点转向尽可能完成更多的工作(而不考虑这些工作有多有价值)。

价值与长期性

通过利益相关者和Scrum团队之间的交易的这种视角也引起了对未来交易的可持续性的关注。毕竟,如果一个Scrum团队把所有工作都免费提供,他们或他们的产品将不会长久存在。

同样,预算可能不允许团队满足利益相关者的任何潜在需求。这显然更多地关系到投资于产品开发的利益相关者(例如投资者或支付Scrum团队工资的组织)而不是主要使用它的人。但最终,这两个群体都会从可持续发展中受益。

这种长期性和可持续性的方面是为什么“商业价值”可能比“价值”更准确,尽管Scrum指南只谈到后者。商业价值的一个常见定义是:“决定公司长期健康和福祉的各种价值形式”。

这种长期性的视角也解释了为什么2020年的Scrum指南正式规定了一个单一的产品目标,以便在大量冲刺的开发中集中注意力。很可能会有比可以或应该解决的更多需求,产品目标为团队提供了一个基准,以便根据什么是有价值的和什么不是(至少目前不是)做出决策。

一个特定的利益相关者需求可能非常有用,但如果它与产品目标不符,那么它就不足以花时间处理,而这些时间本可以用在更有价值的项目上。

现在所有这些考虑仍然是抽象的。当我们开始详细设置产品待办事项并确定每个项目的商业价值时,这将无济于事。你如何确定产品待办事项中的某些项目是“正确的东西”还是“错误的东西”呢?

五种价值类型

考虑到这一点(利益相关者和长期性),我们继续分析了我们与Scrum团队开发的(商业)产品的产品待办事项。我们将这些项目分类为不同类型的价值,并最终得出了五种似乎相当好地描述大多数情况的类型。我们将在下面无特定顺序地讨论这些。

注:由于我们的个人经验主要与商业组织有关,我们的大多数示例也来自这方面。并非所有类型对非商业组织同样相关,尤其是“商业价值”。但即使对于非商业组织,从经济角度看项目仍然是有意义的。

1.商业价值

商业价值是最直接的价值类型,包括产品待办事项中直接为开发产品的组织带来收入的所有项目。在其他所有条件相同的情况下,这项工作将产生净利润。

例如,当一个项目交付后,客户支付以获取它时,这个项目就产生了商业价值。这可能是你产品的新版本、一个新功能或可解锁的附加组件。

也可能是一段新的付费可下载内容、网店中的新产品,或者其他客户直接支付的项目。尽管交付和付款之间可能存在一些层次,但我们喜欢将这些项目看作是发送给客户的发票上的项目。

在这里要问的关键问题是:“(考虑产品目标)这个项目如何增加我们的收入或利润?”回答这个问题越容易,它就越清晰地提供商业价值。如果很难确定,你可能在处理另一种价值(见下文),或者该项目实际上可能根本没有价值,你需要将其移除。

2.效率价值

产品待办事项中并非所有项目都会产生收入。但项目也可以通过直接降低生产、维护和交付成本来直接影响利润。这些项目代表着简化、自动化、减少或平滑产品所需的其他工作的工作;它使其他工作更高效。

从经济角度来看,这些项目通过花费更少的资金为交付给利益相关者的相同价值提高了你的成本效率。或者,如果你不是商业企业,它节省了你多少时间。这就是效率价值。

例如,如果对代码库的更改使您能够用更少的服务器运行相同的产品,那么您就产生了效率价值。但它也可能涉及自动化或简化必要的开发、运营或交付过程中繁琐和重复的任务。

对于我们帮助开发的产品之一,我们在产品待办事项中有减少在客户现场设置产品所需时间的项目。尽管这个项目本身并没有产生收入,但它确实为我们(和客户)节省了金钱。

更间接地,项目也可以减少其他地方的工作,从而降低成本。例如,当一个项目增加了应用程序的稳定性,从而减少了每周帮助台的大量来电。

对于每个项目,关键问题是:“(考虑产品目标)这个项目如何为我们节省金钱或时间?”如果情况不明显,你可能在处理其他类型的价值。或者该项目根本没有价值,你需要将其移除。

3.市场价值

一个产品的成功程度取决于知晓它的潜在用户和客户的数量。通常情况下,产品开发涉及大量工作来增加这种认知度,进入新市场,或与竞争产品区分开来。这项工作代表了市场价值。

市场活动是这种工作的一个很好的例子。例如,这可能是为推广你的产品而设置和撰写简单网站的工作。或在LinkedIn上启动一项营销活动。甚至写一篇博客文章、录制一期播客或视频也可以从这个角度被视为“市场价值”——只要它主要关注于为你的产品创造认知。

从软件开发的角度来看,这可能是将应用程序移植到其他平台(例如从iOS到Android,或从Steam到Xbox Live)。或者添加功能以吸引新的客户群。

对于每个项目,关键问题是:“(考虑产品目标)这个项目如何让我们吸引更多用户或客户?”如果很难证明这个项目如何吸引新用户,你可能在处理其他类型的价值。

4.客户价值

即使你的产品正在产生收入,具有高效率,并且为用户所熟知,但如果客户不继续使用你的产品,或者一有机会就转向竞争对手,要成功仍然很困难。因此,使你的产品对其客户更有用和有价值的工作是有价值的。这实际上增加了你的产品的“粘性”,正如埃里克·里斯在《精益创业》中所说的那样。这就是客户价值。

对于每个项目,关键问题是:“(考虑产品目标)这个项目如何增加客户继续使用我们产品的可能性?”如果你无法清楚回答这个问题,你可能在处理其他类型的价值。

5.未来价值

最后,你的产品必然会有一些工作在完成后并没有产生任何明确的价值,但在(近)未来如果不完成可能会导致巨大问题或显著成本。这就是未来价值。

研究和创新是这一类工作的例子。有时候你需要研究与当前技术堆栈面临的问题的替代技术解决方案。或者你想要改进团队的实践和流程,这需要你花一些时间学习。

减少技术债务似乎也是这一类别的一个例子。技术债务包括在产品之前应用的所有捷径和快速修复——可能在紧要关头——这些可能当时效果很好,但现在却带来了问题。例如,一些重要部分的代码可能缺少自动化测试。或者文档没有更新。或者代码块已经变得像意大利面条一样纠结,开发人员不敢触碰它,担心它可能像代码的竞技塔一样全部崩塌。

未来价值的一个风险是所有时间都花在了可能在未来有价值的事情上,而没有考虑到现在什么是有价值的。虽然将这类工作从产品待办事项中移除可能很诱人,但这些项目可能代表着对未来灾难的防范。即使未来仍然大部分未知,但其中一些防范措施可能是明智的保留——即使它们不会立即产生价值。

对于每个项目,关键问题是:“(考虑产品目标)这个项目如何在未来为我们节省金钱或时间?”如果你无法清晰回答这个问题,你可能在处理其他类型的价值。一个良好的产品待办事项应该只有少数这样的项目,而且不要太多。

合规性呢?

当我们首次分享这个分类时,最常见的问题之一是如何处理现有法规、协议和认证的合规性。有人建议“合规性价值”是否应该成为其自己的类型?

我们当时对这个问题感到困惑,现在仍然如此。我们在这里的担忧是合规性本身并不真正有价值。相反,它是一种手段,希望是有价值的。例如,当客户要求遵守某个协议并为此付费时,这显然是商业价值。

如果客户不为此付费,但他们仍然要求这样做以保持他们的支持,那么这就是客户价值或市场价值。如果合规性涉及安全或加固,那么是为了防止潜在的安全漏洞造成的损害。这就是未来价值的例子。

我们看到太多的例子,即为了合规性而遵循合规性,结果导致了巨大的成本、效率降低,并使发布变得更加困难。虽然在某些发生这种情况的情况下是合理的,但在其他情况下却并非如此。因此,为了避免这种情况,我们鼓励你深入挖掘合规性,确定为什么合规性有价值。

此外,我们认为合规性更适合于“完成定义”。除非你谈论特定的功能或功能,否则大多数合规性通常包括质量指南。这难道不正是“完成定义”所用之处吗?

开始关于价值展开对话

我们在这里提出的分类法当然不是完整的。各种类型在几个方面有重叠,有些项目可能并不明确地属于任何一种类型,但仍然具有价值。

但这并不是重点。重点是你应该与你的团队和利益相关者就产品待办事项中每个项目的价值展开对话。对于那些你可以轻松分类到这些类型中的一个或多个的项目,你可能正在处理有价值的东西。

如果你不能,你的团队,尤其是你的产品负责人,需要有一个异常有说服力的理由,解释为什么它仍然在产品待办事项中。毕竟,产品负责人如何通过保留看似没有价值的项目来最大化Scrum团队完成的工作的价值呢?

我们希望这篇文章激发了你与利益相关者就价值展开对话,并对在产品待办事项中保留什么和丢弃什么做出有意义的决定。

]]>
老生常谈的敏捷价值观,你的理解和应用真的正确吗? https://www.uperform.cn/the-agile-manifesto/ Thu, 29 Feb 2024 16:23:23 +0000 https://www.uperform.cn/?p=8038 […]]]> 敏捷宣言概要

“我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由 此我们建立了如下价值观:

  个体和互动 高于 流程和工具
  可用的软件 高于 详尽的文档
  客户合作 高于 合同谈判
  响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

(https://agilemanifesto.org/iso/zhchs/manifesto.html)

个体与互动高于流程与工具

无论你的流程有多么深入和巧妙的设计,你的工具有多么高科技,最终决定成功与否的是你与团队已经团队本身的协作方式。你的团队以及他们有效高效沟通的能力比他们遵循的流程或所使用的工具更有价值。

这并不是说敏捷哲学不鼓励形式化的流程或工具。它们都可以为你的团队提供结 构和促进互动。但归根结底,它们排在次要位置。

毕竟,如果你的团队不能有效沟通,流程和工具就毫无价值。但如果让一个聪明、有动力的团队去完成任务,有时虽然没有任何流程或工具来管理项目,他们很可 能会找到一种合适的方式来达致成果。

可用的软件高于详尽的文档

传统的产品开发流程通常在编写一行代码之前需要大量的文档。在敏捷哲学下,让软件(或者任何产品成果)尽快进入客户手中是最重要的。毕竟,如果你不让产品投放市场并从真实用户那里收集反馈,你怎么能改进你的产品呢?

虽然这个价值观强调了在让文档成为瓶颈之前尽快推出软件(或者任何产品)的重要性,但需要注意的是,文档本身并不是一件坏事……只要你不过度去做,并且能持续去更聪明的使用文档及改进你做文档的方式来带来最优产品成果的交付。你的最终成败在于是否给客户/用户提供价值,而且最好是早一点能做到。

客户合作高于合同谈判

敏捷哲学强调以客户为中心的产品开发实践,而不只是以交付物为中心的方法。虽然合同及法务条款在业务中始终有其存在的位置和必要性,但若只是列出你会向客户提供的东西,其并不能替代与他们实际沟通,了解他们的真正需要和面临 的挑战及要解决的问题本身。

传统的以交付物为中心的流程允许合同决定最终交付什么,这为双方期望的一致性留下了很大的缝隙和潜在偏差。敏捷哲学(以及由此产生的许多形式化流程)鼓励在开发周期中建立一个持续的客户/用户反馈循环。

在敏捷哲学下,与客户的协作在开发过程的早期就开始,并在整个过程中频繁发生。与真实客户/用户密切协作及互动的这种文化帮助产品团队确保他们向客户提供有效、有用的解决方案。当你经常与客户交流并将反馈纳入你的开发过程中时,你减少了风险,消除了猜测,最终一起实现共赢。

响应变化 高于 遵循原计划

复杂事物及工作中,唯一不变的是变化本身,以及各种在行动前无法完全把握及预测的偏差和不如意。敏捷方法的一个重要好处是它鼓励团队根据持续收集和分析的新信息频繁地审查和调整当前的计划。因此,产品或者项目路线图不再是一份静态文档,而是一项动态的战略,而且更有潜在最终成效。

在敏捷环境中,产品经理或者任何负责人(通常也鼓励和团队一起)需要学会以充分透明的方式向利益相关者展示他们的目前的真正进展(当前交付物增量及动态路线图),以反 映基于最新所学习和掌握到的变更可能性。

换句话说,敏捷方法允许产品或者项目团队根据战略需要随时调整其优先事项和计划。这些团队不会因为承诺要完成原计划而陷入已经过时的计划中。

总结

通过遵循敏捷宣言的价值观,我们相信可以更好地应对软件开发的挑战,提供更有价值的产品和解决方案。无论是个体和互动、可用的软件、客户合作还是响应变化,我们都将以这些价值观为指导,不断改进和创新。

]]>
首次揭示!传统管理是如何在数字化IT时代延续混乱的? https://www.uperform.cn/traditional-management-that-creates-chaos/ Thu, 29 Feb 2024 16:18:57 +0000 https://www.uperform.cn/?p=8035 […]]]> 现状

尽管敏捷工作方式、持续交付和产品导向已经得到广泛应用,但仍有许多公司仍然采用项目管理的方式进行工作。实际上,项目管理永远不会完全消失。

在很多大型企业中,跨团队的协调工作始终是必要的。项目的进展与RAG(红、黄、绿)状态保持一致,就像繁忙路口的交通随着红绿灯的节奏运行一样。绿灯表示一切顺利。黄灯表示需要关注,也许可以要求团队提供额外的每周状态报告(就像额外的官僚手续能够帮助团队一样)。红灯表示情况不妙,内部审计要求采取行动,管理层派人介入协调危机。

困境

大多数企业组织只在出现问题时才关注IT交付,而数字化领导力则强调持续改进。这种模式反复出现。管理层太忙,无法关注绿灯时的状态问题。团队找到了改进方向,但因为没有专注于交付更多功能而备受指责。团队也发现了系统性挑战的微弱信号,但被忽视,直到错过了里程碑。一旦状态变为红色,才全员动员起来解决危机。

我多次站出来,因为我知道系统性问题不会得到关注。最近,我与一位正在进行敏捷转型的高级项目经理讨论了这个问题。他告诉我,最近他们经历了一些意外事件,危机模式下的协作非常有效。我感叹道:“良好的敏捷领导力应该让这种协作在日常工作中解决混乱的问题,而不需要费太多力气”。

混乱中的领导与敏捷组织的挑战

尽管全世界都喜欢英雄,但敏捷组织并不需要他们!

通常,领导者在混乱中扮演前线指挥官的角色,强调命令与控制的风格。带领团队从混乱中恢复是令人满足的,但这种模式不可持续。组织喜欢英雄,但那些能够保持项目状态为绿色的人往往被认为缺乏战斗经验。这种情况会持续下去,并深入到企业文化中。

业务部门在数字化转型中必须认真对待这种情况,否则会加剧混乱。在混乱的循环中前进是不可持续的,这样的企业面临风险,会经历一个又一个的危机,耗尽人才。

我们如何扭转这种文化?

我们可以很容易批评一些人的行为和对问题的贡献,但责备并没有任何建设性。

那么,我们来思考:应该如何解决?如果真运作一个绿色RAG状态的更高效的IT团队会带来什么回报呢?

开始向改变并拥有以上这种状态,实际上是成功的数字化变革的起点:

1.系统性管理

2.持续改进的文化

3.追求卓越

团队的系统性管理

敏捷思维强调良好协作的必要性,这是非常正确的。数字化组织也努力复制互联网独角兽公司的组织模式,采用更扁平化的结构和自主的团队,以加快决策速度。然而,许多人仍然将团队视为个人的集合,并专注于任务。我们难道看不出其中的矛盾吗?

如果我们从个人层面进行管理,我们就需要微观管理者来组织和协调任务。领导者为自己的价值辩护,坚持站在每个决策的十字路口,并成为前进的瓶颈。团队成员在一朝被蛇咬,十年怕井绳的基础上,放弃了自主性和协作性,倾向于盲从领导者的指示。如果没有系统性管理的方法,团队就无法达到期望的自主和协作水平。

系统性管理始于管理者与团队在工作现场的连接(例如,在团队所在的空间,而不是在管理者的玻璃办公室)。这个概念从丰田生产系统中的“Gemba”开始已经存在了几十年。“Gemba”的意思是去到工作发生的地方。

在制造业中,由于生产流水线的物质性,这一点非常明显,但在数字化团队中就不那么明显了,因为数字化团队中的一切都是虚拟的。在IT团队中使用“Gemba”,强调了在可视化管理的支持下进行信息辐射的需求。过程流程和质量进展可以张贴在墙上(或在线可视化板上),团队可以基于此展开改进的讨论。

管理者还需要具备与整个团队合作的技能和技巧。倾听系统的声音(VoS)可以产生透明性,并能够及早发现系统性挑战。此外,对问题的预期可以促进更好的工作流程。通过采用这些实践,团队变得更加自治,领导者与团队融为一体,从而大大减少了对中间过程微观管理的需求。

持续改进

为了避免自满并推动持续的绩效,丰田生产系统采用了Kaizen,这是一个持续改进的流程。每个人的工作不仅仅是完成自己的任务,还要思考如何改进工作方式,提高工作成果。这种持续努力是一种非常好的刺激大脑的方法,尤其是在生产流水线上的工作可能非常枯燥。

新技术Kaizen的创始人中尾千寻(Chihiro Nakao)坚持推动不需要投资的简单改进。他的目标之一就是激励人们,以防止自满。好的Kaizen还可以在领导层和团队之间创造出一种不同的动态。团队不断发展自主、自立和协作的能力,而管理层变得更注重引导和教练,以及激发创造性思维。我们今天在IT行业中追求的目标,难道不正是40年前丰田公司发明的吗?

许多人很快指出,制造业的生产和IT行业不同。这是事实。然而,在IT的虚拟环境中进行持续改进实际上更容易。与生产流水线上的工人相比,IT人员更自然地扮演知识工作者的角色。真的没有什么可以找的借口。

问题在于,公司的IT部门一直忙于跟踪处于红色RAG状态的问题,而我们忘记了对绿色RAG状态进行持续改进的锻炼。现在是时候重新启动了。让我们重新关注持续改进,为IT行业带来更大的进步。

追求卓越

有组织会反对追求卓越,但很少有组织真正在IT领域做到这一点。DevOps运动在推动这个主题上做出了贡献,但这种努力仍然局限在IT范围内。质量是每个人的责任,从业务需求的启动开始。

在实体商品上,缺乏质量很容易被发现,但在虚拟软件上却很难被发现。你可以从前端的可用性或测试一些边缘情况中得到一些关于质量的想法,但这只是冰山一角。隐藏在表面之下的代码质量是什么?它什么时候会回来咬你一口?RAG状态并不能解决这个问题,事实上,它通常会使问题恶化。

我曾经参与过一个项目,在黄色和红色之间徘徊。业务部门和管理部门不断向团队施压,要求按时完成项目。他们唯一能牺牲的就是质量。有人在意吗?团队在意,但没有人听得进去。

因此,对于任何不符合团队期望的工作标准的东西,我们让团队开始捕获产生浪费的实践,并记录技术债。团队感觉好多了,信息得到了传播,它变得不容易被忽视。然而,我们不应该走到这一步。

IT领导者和产品经理应该高度关注质量。通过项目的方式组织工作并不会促进这种行为。项目本质上是短暂的,交付项目的人很少会成为维护项目的人。质量、可持续性和可维护性在日常决策中很少被高度优先考虑。

关注项目所带来的只关注短期结果的态度,并不支持为公司的数字化打下坚实的IT基础。有效的Kaizen也不太可能发生,除非团队和领导层有长期的承诺。

除了更好地与客户保持一致外,基于产品/服务的一致性还可以维持长期存在的团队和领导力。这促使对人员进行投资,让他们理解工程,并在决策中考虑质量的优先级。然而,这种一致性与传统组织的建立方式在很大程度上是相违背的(这是由规模经济而非流动经济继承而来),这构成了在数字化绩效方面取得进展的重大系统性挑战。

许多公司的IT功能障碍是由基于项目的工作和错误的激励所导致的。这促使了与建立成功的数字化业务基础不相容的行为。为了解决这种情况,需要领导者迈出一小步,领导力才能迈出一大步(借用了这句话…:-))。

数字化变革始于与团队合作,以理解如何让明天比昨天更好:更智能的流程、更大的自主权、更好的产品/服务、更强的技术能力。这是一个根本性的转变,转变为促进产品和工程性能的IT领导力,其中包括系统性管理、产品/服务和流程的持续改进、卓越的工程能力以及解决阻碍我们的系统性障碍。

]]>
案例分享 | 如何突破转型困局?——药厂数字化转型的敏捷之道:从思维到文化的全面转变 https://www.uperform.cn/pharmaceutical-factory-case-study/ Sun, 25 Feb 2024 12:45:58 +0000 https://www.uperform.cn/?p=8020 […]]]> 科技不断进步的时代,企业数字化转型成为许多公司面临的重要挑战。如何利用新科技和新工具,创造新的竞争优势,成为企业迈向成功的关键。本文将通过优普丰首席敏捷教练申健Jacky实操的药厂案例,探讨敏捷教练在企业数字化转型中的作用,并介绍数字化转型所面临的挑战以及如何克服这些难题。

前言

科技的进步日新月异,如何利用新科技和新工具进行企业的数字化转型,创造新的竞争优势,已经成为许多企业面临的重要挑战。然而,在企业数字化转型的道路上,敏捷教练扮演着非常重要的角色,这一点很多人并不了解。

2019年,一家知名欧洲药厂的中国分公司在全球企业500强中,寻求UPerform优普丰敏捷咨询教练申健Jacky(江湖人称申导)的帮助,目标正是数字化转型。对于这样的大型企业来说,推动数字化转型就像是要让一艘大船急转弯,非常困难。然而,这家药厂却在短短一年内取得了令人瞩目的成绩。

从最初连人才招募都遇到困难的阶段,到后来不仅培养了上百名敏捷人员,还将交付周期缩短了30%。隔年,他们在全球药厂排名中跻身前8强,取得了令整个行业惊叹的成绩。

国际药厂数字化转型,多头马车难整合

在国际知名药厂中,为何急于进行数字化转型?原因在于集中采购等政策对药厂利润造成了压力,高层迫切希望通过数字工具更精准地了解客户拜访效果和市场反馈。他们希望将过去口耳相传的市场消息和销售战绩转化为实际的数据和资料,通过分析、评估和控制费用,让业务运作流程在合规的前提下更加自动化和透明。

然而,面对如此庞大的组织结构,仅仅建立网络医院系统、营销整合系统、在线会议和支付系统就涉及到医学、市场、销售、法律、人力等多个部门。在数字化转型过程中,谁来决策、谁来主导整体规划,以及各部门之间如何有效沟通,成为这家药厂面临的最大难题。尽管花费了整整一年的时间,公司高层仍然感到头疼,因为整个过程仍然像一盘散沙,缺乏整体协调。

敏捷教练剥洋葱

在对这家药厂进行深入剖析后,申导和他的团队发现了该企业在数字化转型过程中面临的五大痛点。这些痛点包括人才缺失、缺乏建章立制、技术与业绩难以融合、员工欠缺能力培养以及文化宣导不足。

首先,人才缺失是一个重要问题。由于药厂是传统产业,尽管他们提供高薪吸引科技人才,但外界仍担心转型失败可能导致裁员。因此,许多人持观望态度,导致招募人才方面遇到困难。此外,药厂内部员工大多是传统医药人才,缺乏数字相关能力和经验,甚至高层也认为员工能够熟练使用Excel已经是幸运了,更别提数字化转型了。

其次,缺乏建章立制也是一个问题。办公室的格局和环境对于工作氛围至关重要。传统办公室通常是封闭、安静、各部门独立的状态。相比之下,明亮、开放的办公空间更有利于沟通。针对这个问题,教练团队与装修部门进行了沟通,根据敏捷需求,在办公室内增设了看板等基本工具,使工作项目和进度一目了然,并潜移默化地融入敏捷文化。

第三,技术与业绩难以融合。无论数字化转型多么成功,最终目的都是提升公司业绩。然而,该企业过去常常将业务和科技分开处理,忽视了将新科技与业务结合的重要性。业务单位向IT部门提出要求后就离开,导致数字化转型停滞不前。

第四,员工欠缺能力培养。过去,药厂各部门分工明确,缺乏敏捷思维意识,并且很少进行专业职能的进修和培训。为了解决这个问题,教练团队对内部员工进行了需求分析和产品体验等培训,并为未来的敏捷团队培训了不同角色,如Scrum Master和Product Owner,以便每个人都能根据个人业务需求进行专业技能的再造和再培训。

最后,文化宣导不足也是一个问题。人们的观念转变需要时间的洗礼。面对新的观念或工作方式,大多数员工的第一反应是抗拒。因此,教练团队鼓励高层经常分享成功的故事或案例,以便这些观念逐渐渗透到每个员工的思想中,并通过敏捷日等活动加深信念。

不只拟定策略 “陪跑”才是敏捷落地关键

为了推动数字化转型,企业高层首先需要理解敏捷的概念。因此,申导制定了”统一思想”的策略,邀请了该公司的首席PO、人资部长、采购主管、敏捷转型负责人、HR和OD负责人等参与培训,让Scrum的基本架构在高层的思想中扎根,共同学习敏捷的基本概念,如33355和看板等。

其次,教练团队从药厂的关键业务入手,通过分析大数据和产品资料来评估可能的绩效指标和工作内容方案。第三步是加强外部人才招募,同时加强内部人才培训,陆续组建了15个敏捷团队,分别负责不同的任务目标。接下来,教练团队与这些敏捷团队签订辅导合约,通过定期测评来推动改进,明确游戏规则并进行解释。最后,将方案实施,并由教练团队在旁边提供支持,定期进行成效评估。

在这家药厂中,敏捷团队的PO多数来自营销部门,开发人员则由不同部门的成员组成任务型小组。每个Sprint结束后,教练团队会介入进行成效评估,并提供专业反馈。这种循环的方式体现了迭代的思想,并落实了二八法则,力求在最短的时间内解决最大的痛点,并交付最大的价值。

交付周期减3成,业务满意增3成

经过近一年的努力,药厂的数字化转型终于步入正轨。到目前为止,已经成立了5至6个小型数字产品团队和4到5个非数字的工作团队。通过敏捷实践培训,成功培养了上百名专业的敏捷人才。相比传统工作模式,药厂在引入敏捷后,交付周期缩短了整整30%,业务单位通过频繁的交互和修正,对交付成果的满意度提高了3成。

申导说:”敏捷转型是一条永无止境的学习和优化之路。”教练团队最初介入辅导已经超过3年,药厂从最初团队组建困难的阶段一步步克服难关,通过数字化提升业绩、解决产品反馈问题,目前转型工作仍在持续进行。

许多人可能会好奇,既然企业的数字化转型已经进展顺利,为什么教练团队仍然没有退出?申导说:”教练团队无法在短短一年内解决企业长期积累的问题,他们只能从当下最关键、影响最大的问题入手,然后逐步处理次要但重要的问题,以此循环迭代优化。”

敏捷转型大不易?最常卡关的3大难题

申导总结了他在过去10年中辅导超过30家国内外大型企业的经验,指出了敏捷转型中最难克服的三个难题,分别是”思想认知”、”能力建设”和”基础设施打造”。

首先,人们习惯于接受确定性,待在舒适区,并按照过去熟悉的工作模式进行工作。因此,突然要求他们从事新的工作内容,适应新的组织方式,这种不确定性必然会对许多人造成冲击,他们担心自己做不好,害怕失去职位,因此产生各种反弹。在这种情况下,可以通过心理建设和教练的方式启发团队成员,帮助他们打开眼界,提出一些可行的方案,让他们感受到一些踏实和确定性,让他们知道”别人都是怎么做的,你也可以做到”。

在能力建设方面,无论是数字转型还是营销能力,在像药厂这样的传统产业中,都是全新的事物。大多数员工没有经验,也不知道该如何做。只有通过学习来补充硬技能和软实力,才能在数字转型的浪潮中保持竞争优势。

最后,系统和工具等基础设施是推动敏捷转型不可或缺的重要基础。特别是在当今大型企业团队经常分布在世界各地的情况下,敏捷方法也应与时俱进。采用电子看板进行随时更新,有利于各地工作团队的对齐和协作。这样的基础设施能够支持团队的敏捷工作方式。

AI时代,企业不只要敏捷更要拥抱AI

随着人工智能(AI)时代的到来,申导呼吁企业在敏捷转型的过程中敞开心胸迎接AI,因为AI将成为未来企业不可或缺的重要思维。他指出:”如果说,数字化是先进生产力和生产关系的综合,那么敏捷是生产关系,AI就是下一波先进生产力,也是’数字’的进阶版”。

随着AI的发展,未来只需说一句话,AI就能帮助企业创建一个网站。这将导致许多人力资源被淘汰,人与人之间的协作也可能减少。因此,企业必须在AI的基础上建立各种系统,如AI客服和AI营销机器人。申导认为,如果企业不赶紧跟上这股AI浪潮,垄断性行业或许还能维持一段时间,但被淘汰的风险是可以预见的事实。

在面对AI时代的挑战时,企业需要灵活应对,将AI作为一种工具和资源,与敏捷转型相结合,以提高效率和创造更大的价值。同时,企业也需要关注人力资源的培养和转型,使员工具备适应AI时代的技能和思维。只有这样,企业才能在激烈的竞争中保持竞争优势,并实现可持续发展。

总结

科技的进步推动了企业数字化转型的需求,而敏捷教练在这一过程中扮演着重要的角色。通过深入剖析一家药厂的案例,我们看到了数字化转型所面临的挑战和敏捷教练的作用。人才缺失、缺乏建章立制、技术与业绩融合困难、员工能力培养和文化宣导不足是数字化转型中的痛点,而敏捷教练通过培训、建立合作团队和提供支持等方式,帮助企业克服这些难题。

在数字化转型的过程中,敏捷教练不仅制定了策略,还与企业高层和团队密切合作,通过分析数据、评估绩效和持续改进来推动转型。经过一年的努力,药厂取得了显著的成果,交付周期缩短了30%,业务满意度提高了3成。然而,敏捷转型并非一蹴而就,企业需要持续学习和优化,解决思想认知、能力建设和基础设施打造等难题。

随着人工智能时代的到来,敏捷转型不仅需要关注数字化,还需要拥抱AI。AI将成为未来企业不可或缺的重要思维,企业应将其作为工具和资源与敏捷转型相结合,以提高效率和创造更大的价值。同时,企业也需要关注人力资源的培养和转型,使员工具备适应AI时代的技能和思维。只有这样,企业才能在激烈的竞争中保持竞争优势,并实现可持续发展。

因此,敏捷转型不仅是一项技术和工具的应用,更是一种思维和文化的转变。企业需要不断学习和适应新的挑战,与时俱进,才能在快速变化的市场中立于不败之地。敏捷教练的角色将继续发挥重要作用,帮助企业实现数字化转型,并在未来的AI时代中保持竞争优势。

]]>
Scrum Master 中文CSM认证课程-2023年12月-线上-敏捷项目管理培训 https://www.uperform.cn/certified-scrum-master-csm-online-20231223-2/ Thu, 01 Feb 2024 08:21:22 +0000 https://www.uperform.cn/?p=7864

时间:2023年12月23-24日

讲师:Bill Li 李国彪

地点:线上

价格:RMB 7000元每位,提早报名或团队报名有优惠

联系方式: 021-34753688

Email: Service@uperform.cn

课程优势:

Scrum联盟 ScrumMaster CSM认证 及 PMI PMP PDU & ACP Contact Hours
知名敏捷先行者李国彪(Bill Li)先生讲授
互动性和实操性强,千锤百炼的口碑课程,获广泛推荐

授课顾问:

Bill Li - CST
Bill Li 李国彪 先生CST, CSP, CSPO, CSM & MBA. Scrum联盟CST-认证Scrum培训师,UPerform优普丰创始人,中国地区推广敏捷的先行者之一,自2008年,作为Scrum培训师、敏捷教练和组织顾问,Bill感兴趣于如何能更有效地帮助客户的产品和研发组织及团队变得更有效果,更多的乐趣,更少的无谓的障碍和浪费,更少的压力,但能产出更好更精的产品和服务,获得更多的客户、员工、投资人、甚至于社区的尊重和认可…
Bill在敏捷领域服务过多家知名企业,对价值交付、敏捷思维和方式、团队氛围和激励、产品策略等有独特见解。他有超过18年的海内外跨职能IT行业管理及技术经验,自2004开始接触Scrum。李先生曾在美国师从软件界泰斗Ken Schwaber(Scrum的创立者之一)及Mike Cohn(敏捷估算及计划的鼻祖)。他近几年翻译或合作翻译了Ken的两本著作《Scrum敏捷项目管理》及《Scrum敏捷项目管理实战》,以及Mike的《用户故事与敏捷方法》。Bill也熟知PMI PMBOK项目管理方法。除了工科学位,李先生也是加拿大约克大学毕业的MBA。

课程主要内容概要:

究竟什么是敏捷?;
敏捷究竟想应对什么问题和机会?;
敏捷思维、原则和文化;
Scrum和敏捷的关系;
Scrum的特点、亮点及框架要素;
迭代化增量式的价值创造及交付;
Scrum中的角色与责任聚焦;
共创式的团队合作与加速成长;
有效实施敏捷与Scrum的主要考虑;
产品价值思维对比项目管理思维;
对敏捷需求/用户故事和内建质量的探讨;
对于规模评估、承诺与规划的探讨;
团队的特征及自组织的培养;
绩效跟踪及敏捷的扩展的概要;
敏捷领导力的特征和期望;
ScrumMaster作为教练式领导者领入门;
许多的实战案例分享和有问必答;

证书及其他:

课程结束后完成注册手续时,每位学员获得Scrum Alliance颁发的Certified Scrum Master证书及2年的联盟会员资格,同时获得PMI的PDU学分及ACP Contact Hours。课程结束后学员将获得课程电子版材料。

报名咨询及获取详细课程大纲:

Tel: 021-34753688

Email: Service@UPerform.CN

]]>
2024我们官宣了—Jacky申导成为国内首位认证敏捷技能导师! https://www.uperform.cn/official-announcement/ Tue, 30 Jan 2024 10:29:37 +0000 https://www.uperform.cn/?p=7854 […]]]> 优普丰成为国内首家敏捷规模化认证培训咨询机构!

同时让我们热烈祝贺优普丰首席教练Jacky申导成为国内首位认证敏捷技能导师!

2024年,我们将隆重推出认证敏捷规模化CAS-S1认证培训,帮助您从零开始搭建规模化敏捷结构方案。

如果您对CAS-S1认证敏捷规模化培训感兴趣,现在就可以扫描添加我们的客服,提前了解认证资讯。

我们期待与您一起探索敏捷的精髓,共同打造高效灵活的组织!

]]>
破幻求真,unFIX解决组织系统设计的原则和底层逻辑 | 系列4 https://www.uperform.cn/unfix-4/ Tue, 30 Jan 2024 10:26:38 +0000 https://www.uperform.cn/?p=7852 […]]]> 尝试:低成本、安全、快速的方式,避免失败

Author: Jurgen Appelo

Link: https://unfix.com/blog/try-cheap-safe-fast

注:这篇文章感觉就说了一个观点/一句话:Fail这个词不好;应该强调Try,不要过多渲染fail。

“让我们庆祝失败”

“创造一个可以接受失败的环境”

“尽快地失败,尽早地失败,经常地失败”

“只有当你放弃时,才是真正的失败”

“让我们且败且战!”

我参与敏捷社区已经超过十四年了,我想我已经听过所有大家能想到的关于“失败有多么重要”的谚语,比如上面那些。实际上,在我早期的文章当中中我也多次提及到。

然而我却感觉到自己越来越不喜欢“失败”这个词。

当我依据一个好的习惯却出乎意料的出现错误时,是否意味着我失败了?

当我从某件坏成果事件的错误当中学习经验时,意味我真的失败了吗?

当本次实验只是一百多次测试中的第十次时,是否又意味着它失败了?

现在想来,我在生活中曾多次失败,但往往并不以我原来所预期的方式进行的。

我在一家创业公司中投资了过多的钱,而这家公司并没有如我想象当中所那样成功,所以我失败了。我当然从这次经历中学到很多经验,而且也很珍惜这些经验成果,因为我为它们付出过很多。但也许我也可以用更少的钱学到同样的经验。所以我的失败在于,这个实验过于昂贵了

当我试图只靠肉眼在夜里跑步时,我失败了。因为在同一周里,我曾两次在黑暗中被物体所绊倒,导致我两边的膝盖都严重地受损,并永远留下疤痕。事实上,我确实享受在黑暗中跑步的过程,但自从发生过这两次事故后,我夜跑就戴上头灯。我的失败在于,这个实验过于冒险了

许多年前,我曾尝试花两年时间开发一个软件程序,这过程中没有向任何用户或客户展示过,这导致了我的失败。我太享受写软件的这个过程,以为自己独立完成所有的事情。不幸的是,市场似乎对我的产品没有兴趣。我的失败在于,这个实验花了过长的时间

然后,我还尝试做过一些毫无所获的事情。比如有很多次,同意一个我不喜欢的要求,然后发现我陷入了使我讨厌的承诺当中。我早就知道自己不喜欢这份工作。即使勉强尝试,又有什么意义呢?我是否盼望着这次事情会有所不同?我的失败在于并没有学到任何东西

换句话说,现在的我对失败的意义逐渐有些不同的看法。

实验的结果总是有好有坏,有积极有消极的。它们既不是成功和也不是失败。当一个实验的成本低,安全、快速、当我们学到有价值的东西时,我们就是成功的

于是在这里,我改进了这些口号:

“庆祝尝试与学习,而非庆祝失败。”

“建立安全地进行尝试的环境,而非安全地失败”。

“尽快地尝试,尽早地尝试,经常地尝试,安全地尝试”。

“只有当你浪费了金钱、健康或时间时,你才是失败。”

“当你停止努力,什么也没学到时,你才是失败。”

附:在使用Celebration Grid(https://management30.com/practice/celebration-grids/)这个方法时,将 成功 和 失败 这两个词,替换为 积极 和 消极,效果更好。

看情况,都是可选的

Author: Jurgen Appelo

Link: https://unfix.com/blog/it-depends

注:“看情况(It Depends)” 可能是咨询师面对客户问出的任何的问题时,可以提供的一个标准答案 😀。框架这个词会暗示一些不可改动的硬性结构,Jurgen认为unFIX和敏捷方法更应该被描述为可选择性使用的模式语言。

最好用勺子喝汤;除非你想吃面条,那么我建议使用筷子。

一般而言认为,并不存在放之四海而皆准的所谓“最佳实践”。实践只能是“在当前上下文环境中最被认可的已知方法”。它们可能是在某个特定情况下最好的做法,直到有人找到更好的方式取代它,或者情况发生变化为止。

正是出于这个原因,我不是那些框架方法论的死忠。下面是关于“框架”的一些定义:

1.可以围绕其构建某些东西的一种支撑结构

2.用于计划或决定某些事情的规则、想法或信念的一套系统

3.一个基础的思维概念结构

4.一种用来支撑或包装某物的骨架结构

5.一种由组合和连接在一起的部件所构成的结构

大多数”框架”的定义,都暗示了一个基本的、最小的结构。楼房是围绕金属和混凝土的框架上建造的;离开宪法或法律的框架,就无法从事法律的工作;没有自然语言的框架我也就没办法写书和博客文章。在每种情况下,框架都是必不可少的、最小的结构。框架就像是个启动器。没有框架,就无法开始构建。

正因为如此,unFIX模型不是一个框架。设计组织的方法有很多,而unFIX并不强制要求任何特定的结构。所有的做法都是可选的,没有必须的、最小的结构,这意味着unFIX与SAFe、合弄制以及其他方法/模型是非常不同的(最小规格版本的“SAFe”被称为最小化SAFe。对于合弄制而言,则要求必须遵守合弄制的章程)。

可能更应该将unFIX模型描述为一种模式语言,有点类似于著名的建筑师Christopher Alexander提出的架构模式。你不使用其中任何一个模式,也能够创建建筑物和城镇。那些模式都是可选的。然而,当你意识到“在当前环境下已知的最佳方法”的相关模式,并开始考虑和应用其中一些好的做法时,事情通常会变得更好。

一切都是可选的,看具体情况而选择。

当然,优秀的顾问和教练早已经知道这一点。他们明白,当人们教条地将敏捷框架解释为,必不可少且不可调整的最小结构时,就会出问题了(这恰恰是框架这个词本身的定义所暗示的!)。如果将敏捷框架理解为类似于unFIX的模式库,可能会更好。一切都取决于实际情境,一切都是可选的。

注意:我们为各种模式提供了规则/约束说明,因此,如果你打算使用某个模式,先考虑这个模式正确的使用方式应该是什么。

你可以不用任何工具,直接捧着碗吸面条。你也可以使用吸管、茶匙甚至叉子。但是,你多半得多花点时间才能吃完这碗热汤面。我的话,我会推荐你用勺子和筷子。

]]>
敏捷人要小心了!团队出现这9种迹象,注定要失败 https://www.uperform.cn/n-methods-of-agile-failure/ Tue, 30 Jan 2024 10:21:30 +0000 https://www.uperform.cn/?p=7847 […]]]>

敏捷仅仅发生在开发团队

敏捷实践仅仅在开发团队发生。业务团队还是把需求写好后,扔到开发团队来,并命令开发团队必须在某个Deadline之前完成。在这种情况下,开发团队不直接对业务目标负责,变成了工具人。

这样的开发团队和业务之间很少会有交流,更别说谈判。他们只是按照业务团队命令行事,至于业务团队丢过来的需求是否合理,同样的业务目标下有无更好的解决方案,就不是开发团队考虑的事儿了。

这样的软件,实际上大部分成了并不懂开发技术的“产品经理”设计出来的产物,开发人员只是负责填上代码让机器能够工作。

开发团队脱离业务,也无法建立更适合业务的模型。最后产品变为一个畸形怪,缺乏合理的抽象、设计。最后越来越僵化。

没有或很少自动化测试

自动化测试,特别是TDD(测试驱动开发)的作用,被IT行业严重低估了。自动化测试是可维护、高质量软件的基石,甚至可以说比生产代码还要重要。

目前我们行业整体上对于自动化测试极其缺乏,大多数团队都不具备自动化测试能力,或者有一定能力但以时间紧为借口拒绝自动化测试。

失去了自动化测试的保护,我们就缺乏勇气对烂代码进行持续重构,因为谁也无法预料改几行代码会不会带来新的Bug。没有了持续重构,我们就会欠下越来越多的技术债,这会不断降低我们对业务的响应能力。

没有自动化测试,我们人肉回归测试速度变得让人难以忍受,我们要不舍弃部分外在质量,仅仅测试“改动”部分(这实际上很难);要不就拉长回归测试时间。

过长的回归测试时间又会让我们倾向于批量进行测试,以减少回归测试次数。这样就降低了我们的敏捷性,把持续交付变成了批量交付,敏捷变成了瀑布。

实现自动化测试的关键在于开发者测试,而不是雇佣更多测试人员编写脚本。因为测试人员编写的测试运行速度慢、对程序员反馈慢。

而提高代码质量我们需要的是对程序的快速反馈,自动化测试写的越早、运行速度越快,越有利于程序员及时获得反馈。最早编写自动化测试的方式就是TDD:在写生产代码之前编写。最快运行自动化测试的方式是单元测试。

不注重代码质量

经常有人会说:我们现在时间很紧,先做出来再说,先不管质量。很多人认为质量是可以牺牲的,但其实不是。你写出来低质量的代码是因为你只会写出这种质量的,给你多的时间你也无法提高。

要提高代码质量只能是提高人的技能。而绝大多数人(别看别人,说的就是你,也包括我)都无法一次性写出高质量的代码。因此我们要不断重构,而要支持重构,又必须有足够快的自动化测试。

另外,低质量的代码并不会带来高效能。除非你程序简单到只有几行代码,否则随着代码复杂度提升,低质量代码迟早就会拖你的后腿。我们行业中很多人称呼别人的烂代码是“屎山”,但其实大多数人自己也是这个屎山的贡献者。

软件之所以称为“软”件,是因为我们期望它容易改变。对于不大会改变的,我们会把它做成“硬”件。对于低质量的代码,我们会越来越难以对其进行改变。一个小小的改动可能导致大量Bug产生,找到需要改变的地方就颇为耗费人力,更别提改变后还需要大量人肉回归测试了。

在这种软件质量下,我们还能敏捷起来吗?

不注重需求质量

俗话说“Garbage in Garbage out”。软件需求是软件的输入,没有良好的需求,必然产生不了良好的软件。

而我们这个行业,优秀的产品经理比优秀的程序员更加稀缺。毕竟,程序员编写的东西再烂,它也有个基本原则:可以跑。

而大多产品经理,编写的垃圾还没有个标准去衡量。有些产品经理醉心于设计方案,而忽略用户价值,导致设计一堆白象功能(耗费巨大却没有用);有些产品经理对需求分析不完整,考虑场景不全面,导致产品Bug层出不穷;有些产品经理不分轻重缓急,导致团队浪费大量时间在价值不高的事项上。

有些产品经理只会讲大故事,无法把需求拆分到足够小,这样交付批量就大,降低敏捷性。

以事儿来定人

以事儿来定人的典型就是项目制。人都是从属于某个技术团队,比如Android组、iOS组、后台组之类的。等有了项目,你张三、李四、王五过来,你们做。到了中间觉得赶不上了,再加赵六什么的。项目团队里,人员变化频繁,磨合成本高。而敏捷里面的很多实践,都是基于团队的。比如团队速率、回顾改进、人员流动。对于频繁变化的团队,很多实践就很难持续下去,即使做出了一些成绩,也很快面临项目结束,团队解散,导致知识丢失。以事儿来定人的好处是节约了人力成本,所以外包团队都倾向于使用,特别是人头外包的。这样可以最大化企业收益。但对于企业IT或者互联网,一般来说对业务的响应才是第一优先级要考虑的。不能对业务进行响应,再低的成本也没有意义。敏捷的实践基本上都围绕团队、围绕人进行。以事儿为目标设人,就违背了敏捷的原则,最后必然是导致不敏捷。

不注重提高人的能力

很多IT企业不注重对人的培养。不少人会说,我辛辛苦苦培养好了,转头就让别的企业挖走了。果出现这种情况,企业应该反思:为何优秀的人才我都留不住?难道你只配使用劣质人力?其实就像程序员抱怨写不出高质量代码是因为时间紧,企业抱怨培养人会被挖走本质是自己不知道如何培养人。企业把员工看作是随时可替换的螺丝钉,表面上说员工是最大财富。可实际上却对人进行工具化。软件开发是一个设计过程,面临的是不确定的、易变的。不是搬砖头。开发者不是生产者,而是设计者。对于设计者,替换成本比较高。我们行业996让员工没有时间学习,35岁退休实际上就是压榨了员工10来年的本能。大家全凭本能干活,缺乏优秀的实践。实际上就是在低水平不断重复。缺乏人的能力的提高,敏捷不过是空中楼阁。

敏捷就是工具

有些企业把敏捷转型简单定义为工具平台的使用。用了看板、开了站会就是敏捷了。使用了CI/CD工具就是DevOps了。买了个自动化测试平台就是自动化测试了。敏捷宣言第一条:“个体和互动胜于流程和工具”。流程和工具可以帮助我们更快更好完成任务,但更重要的是个体和互动。仅仅购买一堆工具就宣称自己敏捷了,这是舍本逐末。

人员复用

IT人员不好找这是行业难题,当然这个难题也是行业自己整出来的(不注重培养)。在这种情况下,不少企业就搞矩阵式结构。横向是产品或者项目,纵向是职能团队。很多人员在不同的产品和项目里共用。这样的结果是看起来员工工作很饱和。但由于员工在多个产品中复用,必然导致他有多个代办事项列表,而每个待办事项列表的优先级并不一致。这样他就必须在多个事项之间不断切换,从而导致了他效率的损失。还有因为他有多个事项要处理,实际上又会造成其他人员对他的等待。

团队内严格职能划分

团队内分成若干职能:Android开发、iOS开发、测试、后端开发、数据库、运维、架构设计、BA、安全。恨不得一个萝卜一个坑。导致的结果就是在从需求到交付的流程中,产生多次工作交接。我们知道,交接就会导致等待,等待就是浪费。因此,为保持团队敏捷性,应该减少交接。另外,职能的严格划分会导致工作量严重不均衡,相互之间不能补位。当某个环节产生堆积的时候,其他人也只能干看,甚至不断生产让其堆积更加严重。

]]>