使用Nexus实践缩放专业Scrum
Scrum是流程演进的框架。Scrum团队或组织将通过组合合适的实践来构建他们的过程,他们认为这些实践将帮助他们以Scrum为核心取得成功。
联系扩展Scrum以指导多个Scrum团队如何在每个Sprint中一起工作以交付工作产品。它展示了这些团队在一起时所经历的过程,如何在团队之间分担工作,以及如何管理和最小化依赖关系。在使用Nexus缩放专业Scrum当然,学生们可以学习许多可以帮助他们的团队更好地扩展的实践。下面图表的目的是帮助读者理解这些实践,并找到学习更多的方法。
形成一个联系-组织团队
实践 | 为什么使用? | |
从一个小团队开始,然后发展壮大 | 从一个小团队开始的团队扩展技术。随着团队的发展,团队会分裂,成员会开始组建新的团队。 | 首先帮助一个团队变得高效,然后帮助另一个团队,然后帮助另一个团队。避免了衡量平庸团队绩效的问题。 |
实习模式 | 保留原始团队的团队扩展技术。在高效团队中加入新成员,然后新成员开始创建自己的团队。 | 在扩大团队数量时,在团队之间共享知识,并在团队之间灌输共享文化。 |
特性团队 | 一种由跨职能团队组成的团队组建方法,该团队能够拉动、交付和支持端到端特性。 | 让团队更深入地了解客户需求,并通过减少工作移交给团队以外的人来减少浪费和等待时间。 |
Microservices | 一种体系结构风格,它围绕一组专注范围较窄、可独立部署的服务组织应用程序的体系结构。 | 提高代码的模块化,从而提高其可维护性,使其更容易独立于其他部分更改代码的不同部分。 |
UI驱动器功能区域 | 一种团队组建技术,它使用用户界面来识别高内聚和低耦合的区域,然后围绕这些区域组建团队。 | 为了减少跨团队的依赖,基于这样一个假设:UI的不同部分服务于不同的需求,并且可以与其他部分解耦。 |
团队角色 | 一种团队组建方法,团队围绕角色组建,角色是应用程序用户类型的虚构抽象描述。 | 让团队更深入地了解应用程序的用户,这可以帮助他们与用户建立更紧密的联系,这可以帮助他们构建更好的解决方案。 |
特性集团队 | 团队形成方法,团队围绕面向客户的产品领域(也称为价值领域)形成。 | 通过关注领域内一致的客户体验来扩展特性团队。 |
团队自我选择 | 一种团队组建技术,团队成员根据自己的兴趣、约束和团队的需要选择加入哪个团队。 | 通过赋予员工选择工作内容和合作伙伴的权利,增加团队认同感,减少团队冲突。 |
形成联系——组织工作
实践 | 总结 |
为什么使用? |
影响映射 | 一种使用可视化地图来帮助沟通和连接业务目标、角色、结果、影响和产品待办事项项(PBI)的计划技术 | 理解pbi与它们所满足的产品和业务目标之间的联系。 |
用户故事映射 | 一种计划技术,通过沿着两个独立的维度可视化用户故事,帮助团队将用户故事分解为可管理的工作块。 | 提供一种结构化的方法来细化pbi,以充实产品的初始可用版本,然后是附加功能。 |
跟踪产品待办事项列表中以业务为中心的项目 | 在分解产品待办事项列表时,帮助团队跟踪以业务为中心的项目的计划技术。 | 确保交付业务价值所需完成的工作的透明度和一致性(例如,开发、营销、支持等)。 |
跨团队的改进 | 由多个团队一起处理一个产品待办事项列表使用的细化技术,以减少或消除跨团队的产品待办事项列表项依赖关系。 | 当多个团队一起工作以构建单一产品时,改善工作流程。 |
创建尽可能“瘦”的pbi | 一种分解和拆分产品待办事项列表项及其接受标准的计划技术。 | 为了减少pbi在Sprint结束时被“撤消”的问题,并最小化依赖关系。 |
运行Nexus
实践 | 总结 |
为什么使用? |
想象你的工作 | 使产品待办事项列表项的状态和进展可见的策略,因此是透明的。 | 沟通并减少对PBIs状况的误解。 |
Nexus Sprint规划室布局 | 在Nexus Sprint Planning中组织团队(包括远程团队)的方法。 | 在Nexus Sprint计划活动期间帮助改善协作。 |
使用Nexus Sprint Backlog来管理工作流程 | 在Nexus Sprint期间,使用Nexus Sprint Backlog来可视化PBIs的状态和进度的技术。 | 通过可视化Sprint for the Nexus的pbi预测的顺序和依赖关系,消除使用其他工件使工作透明的需要。 |
科学展览/世博会 | 一组相关的技术,通过让利益相关者在Nexus Sprint评审期间按需看到他们想要/需要看到的东西,可以帮助大规模地改进Sprint评审。 | 为了使大型Sprint评审的运行更加有效,并在开发团队和涉众之间进行互动。 |
离线Sprint回顾 | 当涉众不能参加Sprint评审时,一组相关的技术使团队能够更好地与涉众交流。无论是面对面还是远程。 | 当涉众不在场时,提高Sprint评审的有效性。 |
回顾委员会 | 使Sprint回顾性项目透明的一组技术。 | 确保Sprint回顾项目不会被忽略或遗忘。 |
在产品中加入实验 | 使用已发布产品评估替代方案的验证方法。 | 从用户处获取产品反馈;以便更好地了解产品是否满足用户需求。 |
在产品中建立手工反馈 | 从发布的产品中收集兴趣和反馈的验证技术。 | 从用户处获取产品反馈;以便更好地了解产品是否满足用户需求。 |
在产品中建立自动反馈 | 在应用程序中使用检测来收集有关使用情况的信息的验证方法。 | 从用户处获取产品反馈;以便更好地了解产品是否满足用户需求。 |
规模化产品所有权 | 一种扩展产品所有权的方法,通过委托产品所有权的一些工作,同时仍然保持产品负责人的责任。 | 当他们有太多的工作要做,他们需要帮助时,扩大产品所有权。 |
持续集成 | 一种开发实践,要求开发人员每天多次将代码集成到共享存储库中。然后,每个签入都由一个自动化的构建和测试过程进行验证,允许团队尽早发现问题。 | 尽早发现编码和代码集成问题,而代码在开发人员的脑海中仍然是新鲜的。 |
自动化验收测试 | 一种使用测试自动化来验证需求被满足的方法。 | 减少验证需求是否被满足所需要的手工工作量。 |
功能切换 | 一种能够集成所有工作的技术,而不考虑特性是否就绪 | 通过保持代码“关闭”,直到所有的特性都准备好了才能使用,从而在不引入部分完成的工作的情况下使代码能够集成。 |
为运营开发 | 改进应用程序的可部署性和可支持性的技术 | 通过确保部署和支持PBI所需的所有工作都在同一个Sprint中完成,来改善产品的发布准备。 |
在产品待办事项列表中跟踪运营/基础设施工作 | 改进应用程序的可部署性和可支持性的技术 | 通过确保部署与PBI相关的代码所需的所有工作都在同一个Sprint中完成,从而提高产品的发布准备程度。 |
不同节奏的团队 | 当Sprint长度不同时,在Nexus中同步多个团队工作的技术。 | 处理并非Nexus中的所有团队都不能以相同的速度让pbi“完成”的情况。尤其适用于混合硬件/软件产品,以及需要对遗留代码做一些工作的产品。 |
实践社区 | 一种形成和支持具有共同兴趣的人群的技术,目的是分享知识和提高技能。 | 跨团队共享信息;提高整个团队的专业性。 |
跟踪产品待办事项列表中的架构工作 | 一种提高弹性并降低应用程序总生命周期成本的技术。 | 提高弹性,降低应用程序的总生命周期成本。 |
促进共享架构 | 一种跨应用程序和团队重构和共享组件的技术。 | 提高弹性,降低应用程序的总生命周期成本。 |
内部开源(又名“内部源”) | 一种允许多个团队同时对相同代码进行更改的技术。 | 从团队拥有组件转移到共享组件所有权。 |
管理Nexus
实践 | 总结 |
为什么使用? |
产品待办事项列表树图 | 一种可视化pbi的大小和完整性的技术。 | 提供一种可视化pbi的大小/复杂性的方法。也用于使工作状态透明。 |
燃尽特性 | 一种在特性级别上可视化工作完整性的技术。 | 为Sprint或发布提供一种可视化已完成和未完成工作的方法。 |
健康检查 | 一种帮助团队评估自身表现的技术。 | 为团队提供一种轻量级的自我诊断挑战的方法,这样他们就可以专注于改进对他们最有帮助的事情。 |
世界咖啡馆 | 一种促进大群体知识共享的技术,根据子主题将他们分成更小的子群体,并在小组中轮换人员。 | 提供一种在大群体环境中分享和讨论想法的方法。 |
开放空间 | 一种促进技术,通过自组织的方式,分成更小的小组,讨论和关注感兴趣的话题。 | 当整个小组可能对每个话题都不感兴趣时,提供一种将小组分成子小组的方法,以专注于想法或问题。 |
除锈 | 一种通过减少团队数量来恢复Nexus秩序的技术。 | 提供方法来简化由于规模不足或不必要而引起的问题,特别是涉及的人数过多而导致不稳定的情况。 |
Scrumble | 一种相当于“拉扯andon绳”的技术;停止工作和除垢,直到Nexus恢复稳定。 | 为了处理这种情况,Nexus已经无法做有用的工作,所有的工作都需要停止,直到秩序和一致性可以恢复(如果可能的话)。 |
分布式团队旅行 | 一种提高凝聚力和与分布式团队建立更强工作关系的方法。 | 通过建立个人关系和在分布式团队中创建共享文化来改善和增加跨团队协作。 |
分布式工具 | 一种使用技术来提高分布式团队协同工作的能力的技术。 | 通过适当地使用分布式协作技术,使分布式协作更加有效。 |