jira 敏捷看板_如何配置Jira以支持多个敏捷团队
jira 敏捷看板
过渡到敏捷实践的大型组织通常会陷入两个相互竞争的原则之间：
- 授权自组织团队自行解决问题并管理团队中协作的敏捷原则。
- 组织需要制定可在多个敏捷团队中应用的治理，标准，报告和关键绩效指标。
两者看似矛盾。 如果您实施过多的治理或标准，则会限制团队的自由，以制定能够使其成功的战术决策。 但是，提供的指导太少会使新团队难以采用最佳实践，或者使团队很容易因疏忽而使组织脱离合规性。 没有标准的组织也不知道在哪里以及如何管理那些偏离路线或表现不佳的敏捷团队 。
要找到适当的平衡，需要敏捷的领导者定义在哪里以及如何应用一致的标准，同时仍然要赋予团队自我组织的能力。
为此，一些组织采用了标准框架来扩展敏捷性，例如Scaled Agile框架（SAFe） ， Large-Scale Scrum（LeSS）或Spotify推广的Squad框架 。 许多组织通过采用最佳实践的混合，并经常使用敏捷教练来指导他们，从而围绕目标，文化和物流发展自己的实践。
根据我在多个组织中担任“敏捷发起人”并领导其敏捷转型计划的经验，我发现找到一致兴趣的一个地方是配置敏捷项目管理和协作工具。 团队宁愿不必花费大量时间来配置这些工具，并且如果它们易于学习和使用，它们通常会接受标准化配置。 然后，只要团队不认为实施过于苛刻，组织就可以创建标准和引入实施的治理。
这是我在Atlassian流行的敏捷协作工具Jira中配置的一些标准。 尽管我的建议围绕Jira展开，但您可能会在其他敏捷工具中找到等效的配置。
1.标准化有关定义史诗，故事和子任务的约定
Jira具有三级层次结构，其中的史诗可以包含一个或多个用户故事以及其他问题类型。 Jira使用通用术语“问题”来反映组织选择选择配置的史诗，故事，任务，子任务，缺陷和其他自定义类型。 然后，一些团队将其用户故事分解为子任务，并将其分配给个人。
这是我的有关使配置和语言在多个团队中有用的指导原则：
- 史诗应该是与多个发行版相关的主题，并且应该为项目配置可管理数量的活动史诗。 利益相关者应该能够有效地审查积压工作，而最好的做法是使用5到12个史诗。 更少的内容和史诗可能会包含太多用户故事，而创建太多史诗则需要更多工作扫描和滚动来消化项目。 同样，当史诗在多个发行版和几个月的开发活动中有意义时，围绕史诗进行报告会更加有用。
- 遵循基本的敏捷故事编写指南 ，并使产品所有者和利益相关者可以使用故事摘要。 让业务领导者积极参与冲刺过程并使其易于使用和高效，这一点至关重要。 他们很少会点击用户故事的详细信息，因此，用商务友好语言编写史诗名称和故事摘要非常重要。
- 让团队决定是否以及如何使用子任务。 例如，子任务对于地理上分散的团队，对于刚开始合作的团队或在实现一个或多个用户案例的技术复杂性时可能很有用。 在这种情况下，团队可能希望使用子任务来共同了解谁在做什么以及何时在做什么。 另一方面，位于同一地点的更有经验的团队可能会发现添加子任务在管理上过于繁琐且不必要地完成他们的承诺。
- 一些团队需要第四层次的层次结构，即“功能”，其中包含多个用户故事并具有史诗般的父级。 这对于帮助想要在发行版中完成一组功能并想要一种简单方法进行跟踪的产品所有者很有用。 跟踪功能改进和与功能相关的成本也很有用。
开箱即用，Jira不支持此添加的层次结构，但是有两种方法可以实现它。 您可以使用自定义标签或使用“选择列表”自定义字段来执行此操作，但这需要进行一些管理才能将功能列表作为选项进行维护。 另一种选择是要求故事编写者在其故事摘要中添加一个或两个单词的前缀，并以定界符分隔。 例如，“登录：如果用户忘记密码，则允许用户输入电子邮件”可能是功能“登录”和史诗般的“用户身份验证和授权”中的一个故事。
领导者应提醒团队成员的主要内容是使史诗和故事可供可能不是每天都在看Jira的利益相关者使用。
2.定义冲刺名称和版本的约定
定义的史诗，特点，故事的标准，和子任务有助于沟通一下团队以一致的方式工作。 下一件要做的事是在什么时候要交付时进行交流。 这样做的方法是使用sprint命名约定和有关创建版本的一些准则。
默认情况下，Jira为您的冲刺自动编号，并为每个项目创建单独的冲刺。 我认为，覆盖默认值并具有sprint命名约定（在所有项目中分配一致的sprint编号以及开始日期和结束日期）至关重要。 例如，它看起来像“ SP 011 10-14 – 10-28”，表示从10月14日开始到11月28日结束的第11个冲刺。 这个简单的约定让Jira临时用户了解时间表。 这也意味着sprint 11在项目之间是一致的。
我更喜欢在所有项目中使用一个冲刺，但是如果您有很多团队，这可能不切实际。 另外，如果您有多个团队在一个项目中工作，那么Jira的并行冲刺可能会有用。
当版本与软件的实际生产版本或其他更改相对应时，最好使用版本。 我对团队的指导原则是，即使团队不知道要发布的内容的完整范围或目标发布日期，也要在构想后尽快创建版本。 这允许将故事和其他问题类型标记到版本中，并可以更早地使用版本燃尽图。 创建有关版本号的准则也很重要，并且语义版本控制很容易使用。
3.商定标准
一旦有什么团队正在和时间 ，估计指南，通过添加标准可以帮助团队在一致的方式与商界领袖承诺译作预测和路线图得体。
在有关如何正确估算的教程中 ，我提供了许多有关使用故事点以及如何在报告中使用它们的基本准则。
与多个团队合作时，重要的是要设定指导方针，以便故事点可以保持一致。 具有多个团队的组织应采用准则； 例如，“一点和三点故事应该只量化少量用户界面更改，而无需更改业务逻辑或API”，而21点故事可能是“任何需要创建新的API和用户功能的故事。” 然后，团队可以定义如何解释适合其项目的一分对三分与五分对的故事。 例如，开发Node.js应用程序的团队可以根据准则进一步定义其点定义，因此，单点故事只涉及用户界面更改，而三点故事只包含对前端功能的小改进。
4.定义标记约定以对Jira问题进行分类
Jira开箱即用，提供标签和组件以进一步对故事和问题进行分类。 组件可以以多种方式使用，但是我喜欢使用它们来表示不同的体系结构组件。 例如，如果一个故事需要更改Node.js组件和数据库，则可以使用两个组件来捕获体系结构的哪些方面受到了影响。 这对于希望跟踪和预测对特定技术技能的需求或了解发行版中正在更改哪些组件的组织很有用。
标签提供了一种结构较少的工具来对故事进行分类，但是当跨项目和团队进行标准化时，标签将具有很高的价值。 考虑与故事涉及的改进类型相对应的标签，例如“技术债务”，“ UX”，“性能”和“安全性”。 然后，它们可以用于识别团队何时对其应用程序体系结构进行前期投资，并警告其他在解决技术债务方面投入不足的团队。
5.使实践与标准报告和仪表板保持一致
在Jira中还有许多其他值得配置的领域，以更好地协调团队。
大多数组织将定义一个或多个工作流来定义故事如何从待办状态过渡到完成状态。 大型组织和经过合规性审核的组织必须为角色和权限配置一个标准，该标准可能与Jira的现成默认值不同。 有些将配置其他问题类型，屏幕架构以及其他满足组织需求的自定义字段。
但是组织必须创建反馈循环来帮助推动行为，而这可以通过对定期使用的报告和仪表板进行标准化来实现。 在Jira内部，我倾向于使用史诗并发布燃尽报告。 速度图对于希望确保兑现承诺的团队很有用，而控制图对于具有CI / CD并经常发布的团队则特别有用。
组织还可以利用Atlassian的市场来获得第三方功能和集成。 例如，我使用一种集成来帮助将Jira数据链接到Tableau，以可视化按存储为标签和组件的尺寸分解的燃尽和团队速度。
我在这里描述的方法不应妨碍您的团队管理其承诺，冲刺，故事完成和发布的能力。 但是它们确实需要一些开销，以确保史诗，故事，冲刺和版本符合标准，这些标准可以由Scrum管理员进行管理，也可以由团队成员轮流负责。
敏捷领导者可以使用这些标准来提高团队的生产力和质量，同时使他们能够管理内部协作，问题解决和交付。
翻译自: https://www.infoworld.com/article/3314616/how-to-configure-jira-to-support-multiple-agile-teams.html
jira 敏捷看板