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