SAFe 6核心价值观
敏捷文化

SAFe 6核心价值观

SAFe(Scaled Agile Framework)是一种大规模的敏捷框架,帮助组织以敏捷的方式开发和交付复杂的产品和服务。SAFe的核心价值观是支持框架并指导其实施的基本原则。 一些敏捷社区对这个复杂而完备的框架是否真正实施这些价值观提出了质疑。 SAFe 6的四个核心价值观如下: 对齐 组织必须与愿景、使命、战略目标、流程和工具保持一致。这确保了每个人都朝着相同的方向工作,努力协调工作以确保高效。 对齐应该使整个组织以相同的方式理解客户,使用共同的语言并确保相互理解。 透明度 信息必须在所有利益相关方之间开放和透明地共享。这创造了信任和协作的氛围,使决策更明智、问题更快地解决。 容许错误的权利也必须成为一种建立和接受的文化;这使人们敢于“说”,并能够进行必要的更正,以使错误成为学习经验而不是未来的风险。 尊重个人 人是创新的动力。组织必须创造一个价值、尊重和鼓励人们冒险的环境。 通过指导和辅导推动个人的进步非常重要。事实上,项目的每个参与者都应该能够在没有风险的情况下表达自己的意见。 这个价值还强调了遵循原则:“您的客户是消费您工作的人”。 持续改进 组织必须不断努力改进其流程和产品。这使它们能够适应变化并满足客户的需求。 对于任何敏捷倡议的成功,对齐至关重要。当团队和个人在组织的目标和优先事项上达成一致时,它们可以更有效地协作并获得更快的结果。 透明度是信任和协作的关键要素。当信息及时公开共享时,团队可以做出更好的决策并更快地解决问题。 尊重个人是积极企业文化的关键元素。当人们感到受到重视和尊重时,他们更有可能积极参与和高效工作。 持续改进是学习和适应的过程。组织必须不断努力改进其流程和产品,以保持竞争力并满足客户需求。 SAFe的核心价值观对于任何大规模的敏捷倡议的成功至关重要。通过实施这些价值观,组织可以创造一个有利于创新、协作和持续改进的环境。 以下是一些SAFe核心价值观如何实施的示例: 对齐:组织可以创建战略文件,定义企业的目标和优先事项。他们还可以定期举行会议,讨论进展情况,确保每个人都在同一频道上。 透明度:组织可以使用协作工具实时共享信息。他们还可以定期组织活动,让人们互相见面并相互学习。 尊重个人:组织可以创建一个重视多样性和包容性的企业文化。他们还可以为员工提供发展和成长的机会。 持续改进:组织可以建立反馈过程,收集员工和客户的反馈。他们还可以投资于研发,开发新技术和新产品。 通过实施SAFe的核心价值观,组织可以创造一个有利于创新、协作和持续改进的环境。

敏捷心墙
敏捷文化

敏捷心墙

敏捷心墙是一个有用的小工具,用于了解研讨会或培训中参与者的情绪变化。这个工具在敏捷领域相对知名。 什么是敏捷心墙? 心墙是一幅大图片(可以是数字的),放在研讨会或培训的参与者面前。每个参与者都有一个小贴纸,可以放在他们选择的人物身上。 这是相关的图片: 参与者可以随时移动他们的小贴纸,如果他们在活动期间的情绪发生变化。一天中情绪发生变化并不罕见。 在关键时刻,比如活动开始、结束或休息时,检查每个人的情绪状态可能是很有趣的。这也可以作为一个有用的检查点。 我可以提供的最后建议是,这个工具不应该花费太多时间;只需用它来快速获取参与者的反馈。不需要用太多时间,否则可能会被受邀请的参与者视为浪费时间。

系统演示
敏捷文化

SAFe系统演示:重要概观

什么是SAFe系统演示?它是否是多个团队的审查?本文深入探讨了SAFe中这个关键和重要的事件。 什么是SAFe系统演示? SAFe系统演示是SAFe中的一个关键事件,旨在展示在敏捷发布列车(ART)的最新迭代期间实现的增量中集成的所有新功能。其目标是从利益相关者那里收集宝贵的反馈,以改进产品并指导未来的发展。在此事件中,展示所有成就,作为程序增量(PI)中进展的客观衡量标准。 这些反馈会引导出以下问题: 我们是否走在正确的道路上,还是需要改变方向? 我们可以在整个提出的系统中做出什么改进? 此事件需要前期工作,以确保其顺利进行。有效的事件管理将有助于预防未来的缺席。如果利益相关者认为他们正在浪费时间,那么他们可能不太愿意定期参加。 谁参与此事件? SAFe中的系统演示涉及: ART中的所有利益相关者 ART的产品所有者和产品经理 一个或多个系统团队成员 系统架构师/工程师、运营和一些开发人员 值得注意的是,在SAFe中,利益相关者被视为包括: 业务所有者 赞助商 其他敏捷团队(潜在客户) 管理层(与业务相关) 客户和/或其代表 此事件应何时举行? 理想情况下,系统演示应在冲刺结束后的第二天举行。不同迭代结束与此事件之间的时间间隔过长可能会导致反馈处理延迟。此事件应在每次迭代结束时举行。 通常,为此事件分配1到2小时,具体时间取决于您的ART的大小。但建议力争在一小时内完成此事件。 以下是SAFe提出的议程: 回顾业务背景和PI目标(5至10分钟之间)。 在演示之前简要描述每个新功能(5分钟)。 使用端到端方案演示每个新功能(20至30分钟之间)。 确定当前的风险和障碍。 进行讨论,以获取反馈。 总结进展、反馈和需要采取的行动。 作为提醒,此事件是“检查与适应”(Inspect And Adapt,I&A)过程的一部分,我们将很快在本博客上进行讨论。 系统演示是否取代了冲刺审查? 不,迭代审查(SAFe用于冲刺审查的术语)在每个团队内在迭代结束时进行,与标准的冲刺审查完全一样。系统演示是系统作为一个整体的展示,可能会产生非常不同的反馈。每个团队内的冲刺审查与团队的工作相比非常孤立。 这就是系统演示在冲刺结束后进行的原因。Scrum团队专注于他们的冲刺结束仪式,需要所有团队成员的参与。

毛线球
敏捷文化

毛线球-破冰活动

今天,我将向大家介绍一种小而有趣的破冰活动,它通常在敏捷领域中使用:毛线球。这个活动提供了一个愉快的时刻,让参与者以富有趣味的方式向团队介绍自己。 探索我们完整的破冰活动和激励活动系列! 毛线球 这个破冰活动的目标是鼓励参与者介绍自己,并与团队中的其他人建立可能的联系。它快速而高效,非常适合会议和敏捷培训。 毛线球的准备 参与者 要成功进行这个破冰活动,至少需要10名参与者。 材料 以下是为准备这个破冰活动所需的材料: 毛线球 时长:10分钟 步骤1:毛线球 主持人会向参与者解释规则,并将毛线球交给其中一位参与者。如果参与者众多,甚至可以提供第二个毛线球。 第一个参与者会简要介绍自己,说一些像:“我是[姓名],我从事[职位]工作。” 在介绍完自己后,参与者会将毛线球传给另一个他们认识的参与者,同时握住一端。如果他们不认识任何人,应该提到并然后将毛线球抛给自己选择的人。 步骤2:毛线球 第二个参与者会介绍自己,然后将毛线球传给另一个尚未接收毛线球的参与者,同时握住现在在他们手中的毛线的部分。 破冰活动以这种方式继续,直到所有参与者都收到毛线球。那时,所有参与者都会举起双臂,展示他们创建的复杂网络。 结论:毛线球 总之,这个破冰活动非常有趣,可以让参与者快速互相介绍。值得注意的是,主持人可以鼓励参与者利用这个活动的机会,在会议结束后(例如会议、培训等),与那些引起他们兴趣的人建立联系。

敏捷中的三位朋友
敏捷文化

敏捷中的三位朋友

今天,我们将探讨一种实践,我认为非常有趣,但似乎在当今不太常见:三位朋友。我们将借此文章来理解这种实践的含义。 敏捷中的三位朋友 三位朋友是一种仪式,可以添加到Scrum团队中,用于编写坚固的功能测试。这些测试是由产品负责人(或业务分析师/代理PO)、开发人员和测试人员编写的。 这种协作方式可以确保编写完整的测试,确保覆盖与每个关联的用户故事的所有期望。 以下是每个参与者为这种仪式带来的优势: 产品负责人: 通过用户故事提出用户需求以及相关规则。 开发人员: 指示将受需求影响的所有技术方面,这有助于指导需要编写的测试。还可以参与定义可能在某些情况下难以确定的测试数据。 测试人员: 准备数据集(JDD)并提供符合功能测试规则的场景(例如,不将测试与界面概念关联)。 有了如此强大的团队,我们的三位朋友将提供全面而高质量的测试,发挥了两个重要作用: 指导开发人员开发用户故事。 通过非回归测试提供无可争议的质量。 在敏捷团队中使用三位朋友来创建Gherkin语言并不罕见,这是最常用于BDD(行为驱动开发)的语言。简而言之,对于BDD,我们在开发之前编写测试,以指导开发人员的工作。 一些团队甚至利用此练习进行验收测试驱动开发(ATDD),这是一种软件工程技术,其中在开发功能之前技术上编写测试。 应该采用什么格式? 没有适用于实施三位朋友的理想格式。以下是一些我可以建议的格式;这将取决于您的情境是否合适。 在产品待办事项细化之前的仪式 一些团队在产品待办事项细化的前一天进行三位朋友的仪式,以便在团队精化和估算之前完成用户故事。由于产品待办事项细化通常用于验证用户故事是否“就绪”(符合“就绪定义”),最好事先完成测试。 在产品待办事项细化期间的工作 实际上,有些人会利用产品待办事项细化来进行这项工作。然而,三位朋友需要相当多的时间,有些人可能会认为整个开发团队的参与可能会浪费时间。 但是,其他人可能认为这种团队协作将使整个团队对用户故事有完美的理解。 最终,你自己来判断;最好的方法是尝试并得出结论。 结论:敏捷中的三位朋友 三位朋友是一种在当今较不常见但确实值得了解的概念。你是否认为这种额外仪式能使你的用户故事更加完整?

敏捷用户故事的INVEST原则?
Scrum

敏捷用户故事的INVEST原则?

在本文中,我们将探讨什么是敏捷用户故事中的INVEST原则,因为尽管这个首字母缩写很简单,但很难具体理解它的含义。 敏捷用户故事的INVEST原则 INVEST首字母缩写代表: I代表独立:每个用户故事至少在当前迭代中应该是独立的,不依赖于其他用户故事。 N代表可协商:细节应该是可协商的。这就是为什么我们将用户故事写成一个简短的句子,以避免强加细节。 V代表价值:每个用户故事应该为业务或客户带来价值。 E代表可估算:每个用户故事应该由开发团队估算;为了实现这一点,开发团队必须充分理解它们。 S代表足够小:每个用户故事应该被切割得足够小,以便在单个迭代中交付。 T代表可测试:每个用户故事都应该是可测试的。 现在,让我们深入了解,因为我发现仅凭这几行文字,不是每个人都能轻松理解什么是INVEST敏捷用户故事。 独立的用户故事 我经常听到人们说,在用户故事层面不可能完全独立。 如果仅从术语角度来看,这是完全正确的,但实际上我们谈论的是技术/功能上的依赖关系,而不是业务上的依赖关系。这个界限非常微妙,但绝对存在。 如果我正在开发一个电子商务网站,我可能会有一个用户故事用于身份验证,另一个用户故事用于创建账户。 很明显,从业务角度来看,身份验证必须伴随着账户创建,但从技术/功能角度来看并非如此。开发人员完全可以在没有创建账户的情况下执行身份验证。尽管从业务角度来看这没有多大意义,但在技术上是完全可行的。 因此,我们可以明确定义这两个用户故事是独立的,尽管在没有另一个的情况下发布产品是没有意义的。 可协商的用户故事 我们通常通过简单的功能摘要开始用户故事。并不禁止包含一些管理规则等细节,但所有这些内容都应该以非常简单的方式编写,以便开发人员甚至客户能够迅速理解。 用户故事在精化阶段(产品待办事项的细化)中是可协商的,例如,如果所有开发人员都能够理解它,那么可以进行协商。因此,在编写用户故事的内容时,请始终使用简单的词语,以至于您自己都能确定一个10岁的孩子是否能理解用户故事的内容。 具有真实价值的用户故事 这一点有时被误解,但用户故事的概念仅用于具有应用程序中一个或多个用户类型的真实价值的功能请求。 我有时看到这样的用户故事:“作为开发人员,我希望数据库充满。”…对于任何用户类型都没有真正的价值,因此应该尽量避免。 在这种情况下,不要犹豫,可以创建不同类型的“故事原型”:参考文章“创建不同类型的故事原型”。所有对于用户类型没有真实价值的内容应该采用其他类型的任务。 仅将“作为….”用于真正的用户故事可以很好地区分具有业务价值和没有业务价值的任务。 可估算的用户故事 开发人员将估算每个用户故事,除非您采用“#无估算”哲学;否则,开发人员通常会默认在心中有一个估算的概念。 我们已经讨论的所有标准以及下一个标准通常应该使开发人员能够轻松估算用户故事;实际上,如果他们无法估算,他们将要求产品负责人提供更多细节。 足够小的用户故事 每个用户故事都应该在一个迭代内完成;如果有任何疑虑,它应该被切分成多个用户故事。通常情况下,建议产品负责人将每个用户故事切割到最小化(只要子用户故事仍然符合INVEST原则)。 可测试的用户故事 这一点相对容易理解,每个用户故事都应该是可测试的。事实上,关于这一点,我们要求产品负责人在用户故事上明确可见的结束标志。 以下是一个例子,以便更好地理解。 作为客户,我希望在网站上浏览 -> 这个动作没有明确的结束,客户可以在不停止的情况下浏览多个页面。 […]

Sonar(SonarQube) - 谨防陷阱
开发运营

Sonar(SonarQube) – 谨防陷阱

SonarQube通常称为Sonar,是一种用于衡量代码质量的免费工具。它很快成为了软件工艺领域的宠儿。然而,我们看到了关于使用这个工具的一些常见偏差。尽管这个工具非常出色,但它也可能导致糟糕的实践。 请放心,这篇文章不是在抨击Sonar(SonarQube);这个工具非常出色,它的受欢迎程度是完全应得的。如果您不熟悉它,SonarQube提供了仪表板,用于跟踪正在开发中的产品的源代码质量。用户只需点击几下,就可以获得更多有关如何改进的详细信息。这对于在整个产品开发过程中保持技术卓越非常理想。 Sonar(SonarQube) – 偏差 然而,我看到了很多关于这个工具使用的偏差…或者更准确地说,强制使用这个工具的偏差。 在一些组织中,这个工具实际上是由”工匠”团队强制使用的…但更糟糕的是,强制使用了所有的跟踪指标…尽管这些软件开发团队应该具有敏捷思维,但它们却陷入了ITIL的思维中。 但是,为什么要强制使用它? 根本原因最终与强制Scrum团队”精确”跟踪其速度的原因非常相似。 公司将使用这些指标来: 监测团队的技术质量 在团队之间进行比较 审查某些供应商的状况 提醒团队提供质量的义务 … 总之,不幸的是,Sonar(SonarQube)经常被用于非常糟糕的原因。团队失去了他们的自主权,供应商的存在(虽然他们没有承认)受到了条件的限制,而聪明的人会利用中等代码获得好的结果…因为是的,任何系统都可以被操纵。 当我看到一些公司要求团队接受软件工艺的审计时…他们简直忘了敏捷本身…而且在我看来,我们甚至不能称之为”软件工艺”! 因此,请注意,这并不是所有公司的情况! 那么,如何使用Sonar(SonarQube)? SonarQube应该为每个认为它可以帮助他们提高工作质量的团队提供的工具。我们不强加它,我们提供解决方案。 认为强制使用工具将能够强制提供质量是错误的!这些质量指标更有可能掩盖可怕的现实。 另一方面,想要使用Sonar(SonarQube)的团队有三倍多的机会编写真正干净的代码。为什么呢?因为他们受到了选择跟踪工作的动力。 软件开发者特别应该为那些希望得到帮助以不断改进的团队提供帮助。这正是技术教练非常有效的领域。 对团队进行强制性要求只会是画蛇添足…而由此产生的指标将在掩盖着更为严重的现实的数字中坚定不移。我们谈论的是”西瓜指标”! 实际上,Sonar(SonarQube)是一款出色的工具,但如果强制使用,它可能成为一种祸害。让我们保持敏捷,真正利用这个工具可以提供的好处!

Customer Journey Map
营销

Customer Journey Map – 概念

Customer Journey Map是一种小型实践,可以帮助您改进客户体验的各个阶段。尽管名称相似,但这种实践与Customer Journey(也称为User Journey)有很大不同。 Customer Journey Map(客户旅程地图) 有不同种类的Customer Journey Map模板,但在这里,我们将介绍一个模板,它可能会帮助您更好地满足用户需求。 有时,这个模板可以用来补充我们用于定义用户的典型旅程的User Journey。例如,我们会重新审视电子商务网站客户(用户)的User Journey: 我们可能需要更详细地了解,以确保我们在不同方面满足用户的需求: 如何创建一个完全适合的购物车? 当购买的产品出现问题时应该怎么办? 这两种情况都可以产生两个Customer Journey Map(客户旅程地图);这旨在更好地分析客户在我们的电子商务网站上可能有的需求。 这些Customer Journey Map将帮助我们更好地分析用户可能的不同旅程的每个阶段。而且,直接与用户一起构建它们将非常重要。 Customer Journey Map示例 以下是一个关于购物网站上执行购买操作的客户的Customer Journey Map示例。 Feeling(感觉): 我们将分析客户在每个阶段的感受。这将有助于分析用户感到不安的阶段。通过情感曲线和笑脸的图示,可以简单地可视化需要特别注意的阶段。 Thinking(思考): 了解用户在每个阶段的想法非常重要。我们将用简短的句子来定义他们的想法。 Fears(担忧): 充分了解用户的担忧至关重要。清楚地识别这些担忧将有助于更好地应对。 […]

Growth Hacking
营销

Growth Hacking:定义及其在当今商业环境中的重要性

Growth Hacking – 在不断发展的商业和市场营销世界中,增长黑客已经崭露头角,成为一种强大的策略。但什么是增长黑客,为什么在当前数字化风景中如此关键?本文将探讨这一概念,其关键要素以及对于寻求快速和可持续增长的企业的重要性。 理解增长黑客 增长黑客是一种专注于快速可扩展增长的营销方法。它利用基于数据、创意和深刻理解用户行为的策略来获取和保留客户。与传统营销不同,增长黑客不仅限于特定渠道或策略。它代表了各种策略的结合,以实现特定目标:增长。 “增长黑客”这个术语由Sean Ellis于2010年创造,从那时起在商界成为一个时髦词汇。增长黑客不是传统营销专家;他们是具有增长思维的人,使用创新技术来扩大公司的用户基础,通常预算有限。增长黑客基于实验、数据分析和创新问题解决。 增长黑客的关键要素 基于数据的决策:增长黑客以数据为依据来指导其策略。他们分析用户行为、转化率和其他指标,以识别改进机会。这种数据驱动方法使他们能够做出明智的决策并不断优化策略。 A/B测试:增长黑客的重要组成部分是A/B测试。通过创建网页、电子邮件或广告的两个或更多版本并比较其性能,增长黑客可以精细调整其策略以实现最大影响。 用户为中心的方法:了解用户旅程和问题点对增长黑客至关重要。通过将用户置于首位,企业可以调整其策略,提供价值和无缝体验。 创意和创新:增长黑客以创造力为核心。他们提出创新解决方案、病毒营销活动和独特策略,以在竞争激烈的数字环境中脱颖而出。 精益方法:增长黑客通常遵循精益创业方法的原则。这意味着要用更少的资源做更多的事情,减少浪费,专注于有效策略。 可扩展策略:增长黑客的策略设计成可扩展的。今天对一些用户有效的策略明天应该对数千或数百万用户有效。 增长黑客的重要性 增长黑客之所以重要,有以下几个原因: 效率:增长黑客专注于最有效的策略,避免在传统营销活动中的不必要开支。 速度:传统营销活动通常需要时间来规划和执行。增长黑客允许更快的迭代和更早的结果。 适应性:在不断变化的数字环境中,企业必须快速适应。增长黑客的数据驱动方法允许这种灵活性。 可持续性:增长黑客的目标是实现可持续增长。不仅仅是获取用户,还包括通过卓越的体验留住他们。 经济性:许多增长黑客策略经济实惠,这使其非常适合预算有限的初创公司和企业。 竞争优势:采用增长黑客方法的企业获得竞争优势。他们可以比竞争对手更快地创新和增长。 总之,增长黑客是一种基于数据、灵活和创新的方法,用于实现企业的快速和可持续增长。通过专注于效率、适应性和创造力,增长黑客可以充分利用有限资源,并在当前数字环境中超越竞争。无论是初创公司还是成熟企业,采用增长黑客方法都可以成为其增长之路上的重要资产。

编码约定
开发运营

编码约定 – 定义和重要性

编码约定,有时被称为编码标准,是一组旨在规范软件开发中的源代码风格和结构的指南和规则。这些约定作为开发人员一致编写代码的准则,使其更易阅读和维护。它们在团队协作和软件项目的长期成功中发挥着至关重要的作用。在本文中,我们将探讨编码约定的内容,以及为什么它们至关重要以及如何有效应用它们。 编码约定的基础 编码约定是代码质量和软件项目管理的基本要素。它们涵盖了源代码的各个方面,包括格式、变量命名、文档等。以下是编码约定涵盖的一些关键领域: 1. 代码格式:编码约定规定了代码的格式,包括缩进规则、空格或制表符的使用、行的最大长度等。一致的格式可以提高代码的可读性。 2. 变量和函数命名:约定规定了变量、函数、类和其他代码元素的命名风格。例如,它们可以支持命名约定,如“驼峰命名法”(首字母小写,后续单词首字母大写)或“下划线命名法”(单词之间用下划线分隔)。 3. 注释和文档:鼓励编写有意义的注释,以解释代码的功能、设计决策并为模块的公共接口提供清晰的文档。 4. 代码结构:约定提供了有关代码结构的准则,包括类、函数和文件的组织。这有助于代码的导航和维护。 5. 语言约定:在国际项目中,编码约定可以指定在变量名、函数名和注释中使用的语言。 6. 错误和异常处理:提供有关错误处理、异常处理规则以及一致的错误消息创建的指南。 编码约定的重要性 现在我们了解了编码约定的内容,让我们看看为什么它们对于任何软件开发项目都至关重要: 1. 可读性和理解:编码约定促进了代码的可读性。格式正确且有注释的代码更容易理解,这简化了维护和调试。 2. 一致性:确保整个代码库的一致性,即使多个开发人员合作开发项目。这会产生一致、可预测的代码。 3. 减少错误:编码约定鼓励最佳实践,减少常见错误。例如,正确的格式可以帮助避免语法错误。 4. 改进协作:开发团队可以更有效地合作,使用编码约定。这使得代码集成、同行审查和任务分配更容易。 5. 简化维护:对于大型或不断发展的项目,明确的编码约定简化了代码维护。更新和修复更加高效。 6. 遵守行业标准:在某些领域,如安全性或合规性,编码约定有助于满足行业标准,确保合规。 应用编码约定 编码约定的应用在开发团队内部应保持一致。以下是一些有效实施编码约定的步骤: 定义约定:团队应就要遵循的编码约定达成一致。这些约定可以根据项目的偏好和要求进行调整。 培训:确保所有团队成员了解编码约定并接受培训以了解如何应用它们。 Linting和格式工具:使用自动的Linting和格式化工具,以确保代码符合约定。流行的工具,如JavaScript的ESLint和Prettier,可以集成到开发工作流程中。 代码审查:定期进行代码审查,以确保符合约定。建设性的反馈有助于根据约定改进代码。 […]