(在这里发布问题,因为这是微软重定向到的'社区',带有'需要建议?询问社区'按钮。希望它不会被关闭为“主要基于意见”或“过于宽泛”
你好,
我想在我的部门开始使用AzureDevops来组织代码和工作。我们是一个小团队,他们创建了大量的应用程序和插件。
这些应用程序中的一些具有非常短的生命周期,即我们提供它们,并且它们工作多年而没有变化。其他应用程序更大,并在几个月或几年内更新/修复。 这些应用程序在所有方面都完全相互独立。
据我所知,Azure DevOps结构,我的部门应该成为一个“组织”(我们可以/需要与公司的其他部门分开)。
我对“项目”部分感到有些困惑。文档说
通常,我们建议您使用单个项目来支持您的组织或企业。
所以,假设我们有一个名为Our Apps
的项目 - 那么我们在哪里放置所有单独的应用程序项目?
据我所知,我们提供的每个产品(应用程序)都应该拥有自己的存储库(或者一组应用程序,如果它们是逻辑连接的)。
这是为了允许开发人员简单地在他们的机器上克隆repo并仅为该产品做贡献 - 而无需下载其他项目等。
我需要能够:
目前在我看来,我能看到我们所拥有的产品的“清单”的唯一地方是下面的下拉菜单:
只有这样才能看到在足够大的板块产品中发生了什么事情的方法是在项目中创建一个新的独立“SomeApp团队”(尽管其中有相同的人员),所以我可以为SomeApp配备一块板 - 并从这里查看板:
“one project to rule them all”是马丁·辛塞尔伍德(Martin Hinshelwood)和他的博客文章创造的,当时他解释了原因和限制。
通过在积压工作中引入标记和过滤,在单项目设置中有一种替代方法。
通过这种方式,每个团队都能看到他们可以从中获取的所有工作的完整视图。并且他们可以通过标签快速过滤工作,以便在讨论特定项目/产品时从视图中删除项目。
此外,当团队将重点从一个产品/项目更改为另一个产品/项目时,您只需更改该团队的分配区域即可更新其视图。
Plan View扩展提供了跨所有工作的额外跨团队视图。而Dependency Tracker扩展可以随着时间的推移可视化依赖关系。
您还可以使用Epic / Feature / PBI | UserStory树结构在工作项中创建其他分组。您可以自定义流程模板以引入产品级别,但是为了使规划功能起作用,这也意味着您还必须创建从Product down到PBI | UserStory的完全可跟踪性。
主要建议是以轻量级方式尝试其中一些方法,以了解它们如何工作并找到您自己的理想设置。
跨项目可视化的另一个选择是启用Analytics Extension和connect it to PowerBI。
您很快就会发现,标签,存储库,管道的命名准则将非常重要。能够快速过滤到正确的水平需要这个。