如何配置Jira以支持多个敏捷团队

最新推荐文章于 2021-08-05 00:10:06 发布

cxu0262

最新推荐文章于 2021-08-05 00:10:06 发布

阅读量752

点赞数

文章标签： jira javascript ux ViewUI

在大型组织中，找到敏捷实践的治理和团队自组织之间的平衡至关重要。通过标准化史诗、故事和子任务的定义，制定冲刺和版本命名约定，商定估算标准，定义Jira问题的标签分类，以及保持实践与标准报告一致，可以成功配置Jira以支持多个敏捷团队。这有助于团队协同工作，同时避免过度治理。

摘要由CSDN通过智能技术生成

过渡到敏捷实践的大型组织通常会陷入两个相互竞争的原则之间：

使自组织团队能够自行解决问题并管理团队中的协作的敏捷原则。
组织需要制定可在多个敏捷团队中应用的治理，标准，报告和关键绩效指标。

[了解您的企业如何在敏捷开发中脱颖而出。 | 将您的敏捷职业提升到一个新的水平：如何提高您的Scrum Master技能。 | 不确定“敏捷”的真正含义是什么？ InfoWorld 解释了敏捷方法。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

两者看似矛盾。如果您执行过多的治理或标准，则会限制团队的自由，以制定能够使其成功的战术决策。但是，提供的指导太少会使新团队难以采用最佳实践，或者使团队很容易因疏忽而使组织脱离合规性。没有适当标准的组织也不知道在哪里以及如何管理那些偏离路线或表现不佳的敏捷团队。

要找到适当的平衡，需要敏捷的领导者定义在哪里以及如何应用一致的标准，同时仍然要赋予团队自我组织的能力。

为此，一些组织采用了标准框架来扩展敏捷性，例如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”，“性能”和“安全性”。然后，它们可以用于识别团队何时对其应用程序体系结构进行前期投资，并警告其他在解决技术债务方面投入不足的团队。