在敏捷/ scrum团队中负责选择敏捷规划工具

团队应决定是否使用工具;但我认为最常见的建议来自Scrum Master，因为他最有可能使用工具。任何团队成员当然都可以建议工具。无论如何，我的感觉是，鉴于Scrum哲学，整个团队需要在我看来同意这一点。通常事情以“让我们试试这个，看看它是否有效”开头，并且在整个过程中得到改进，就像Scrum中的任何其他内容一样。它不应该是自上而下的执行，就像使用Scrum方法应该是团队决策一样，而不是从顶部传下来。

杰黔轿缺

好问题。拥抱敏捷的自组织并允许团队选择他们的工具有很多价值。但是，通常会有业务限制。例如，企业可能无法支持/希望每个Scrum团队推出自己的scm解决方案。业务越成熟，就越有限制和推迟。即使是老牌企业也可以改变如果团队可以证明改变的合理性，不要害怕质疑约束。敏捷规划工具将遵循这些相同的规则。该企业可能拥有完整的软件生命周期管理解决方案。该解决方案可能有也可能没有敏捷模块。然而，企业可能有理由（例如受管制的行业）要求在他们拥有的生命周期管理软件解决方案中记录设计输入/输出。企业通常需要平衡保持团队满意度和生产力与业务保持一致。我不认为会有黑色或白色的解决方案（除非你是一个初创的开发者之一）。敏捷团队需要接受开放式沟通。如果工具是企业需要知道的障碍。

渐首洽陈染

我将简单回答，因为我实际上认为这是一个简单的问题。整个团队对此负责。让我解释一下。我们首先必须接受每个背景都不同，所以这不是圣经的答案。假设你开始你的项目。我总是喜欢什么都没有开始我的项目/产品。没有。有时候，只是一个任务板，有待办事处，正在进行中。而已。我填写todo专栏。这就是我的全部观点：我以递增和迭代的方式构建我的敏捷过程。我为什么要创建Burndown图表？因为读写能告诉我吗？不，不，因为，也许，最终，在某些时候，我可能需要对我的计划有一些可见性。一切都一样。永远不要忘记，敏捷工具可以作为流程的支持。所以，你是一个PO，你已经厌倦了简单的待办事项列表，并且不需要做Backlog？ 2解决方案： - 你已经在一个非常成熟的团队中，你必须在站立会议期间告诉所有人你正在带头。最终它需要一个回顾展来接受它。 - 您从V，W或任何产品管理模型迁移。然后，等待回顾并询问每个人并解释你的痛苦。给出解决方案（这里是积压工作），并要求一个镜头。所以，你是一个scrum大师，你在你的过程中发现了一个“系统性错误”，让我们采取经典的错误：太多的错误。然后带头推动TDD或系统测试。所以，你是技术领导，感觉......好吧，你了解我。我的观点是：从一开始就不要过度使用你的过程。慢慢构建过程，在需要时慢慢添加工具。通过这样做，不要担心，人们将采取可重复性来创建工具并将其添加到流程中，以便将其提供给团队的其他成员。希望这可以帮助。

渴翅吮斡撤

您从现实生活中获得的经验是什么，谁应该负责选择敏捷/ Scrum团队使用的敏捷规划工具？我从现实生活中获得的经验是，某些“敏捷规划工具”工具在他们开始进行Sprint之前已经交给了Scrum团队，幸运的是团队很喜欢它，但我们可以自由地检查和适应使用其他东西，如果有的话不适合我们。我认为团队应该以完全透明的方式使用，接受或拒绝工具。他们可以很好地接受Scrum Master或Agile Coach的建议，因为他可能对Agile Tools领域有更多的了解。其次，团队应该有足够的勇气进行集体讨论并决定使用基于敏捷教练建议的工具，看看它是如何为他们工作的，如果它不适合他们，则适应和调整使用它（生产力） -明智的）你没有问过的更大的问题是，当公司扩展到拥有多个使用自己的敏捷规划工具的Scrum团队时，你如何管理不同的工具集混乱？实际上，我认为，在规模敏捷的软件公司中，Scrum团队中工具使用的一点点均匀性可能是有益的和有效的，但可能由自组织企业项目团队指导，而不是每个团队都有自己的工具。当然可以有例外，某些团队正在开发完全不同的功能，他们需要一个完全不同的工具集，但使用常见的敏捷工具的好处将有助于扩展项目查看他们的团队进度而不需要太多的变化。上述工作可以通过技术，基础设施和流程工具故事来完成，这是很多公司使用或创建的。这个EPIC故事可以作为讨论可以使用敏捷工具和其他工具的起点，在项目中保持一致性。在得出EPIC故事时，整个项目团队可以参与项目启动，如果它太大，那么1-2个成员可以代表每个团队。故事可以像商业用户故事一样细分，并在基础设施和工具的基础上进行相应的修改，校准，估算和优先排序。如果您希望我详细了解这一点，请与我们联系。

田眯衅

理想情况下，scrum master，但他们可能会继承一些需要进化的遗产。如果组织是Scrum的新手，那么经验丰富的Scrum Master应该能够为团队的成熟提供最好的工具。通常，如果团队已经拥有一些工具，那么无论组织选择如何，Scrum master都可以调整已经存在的工具。一些最好的主板是在Excel Spreadsheets上工作，就像专用系统一样。每种技术都会产生“约束”。因此，由Scrum master支持业务，以确保工具符合目的并提供团队所需的价值。

豆兢

我作为教练经历的典型错误是由经理甚至高级管理层根据“专家”甚至外部顾问进行的一些研究做出的决定。这些人很多时候都不知道该工具的内容，方式和使用者。在这种情况下，一旦他们应该使用选择的工具，我会看到失望的人。你必须考虑一天中的大部分时间谁将使用该工具。团队成员是更好的目标社区。由于她需要完成日常工作，工具必须支持ScrumMaster角色。将经验丰富的产品所有者包括在工具的选择中，因为工具对规划有不同的支持，这是必要的。考虑您的组织（产品，项目，地点数量的复杂性）

量华

选择规划工具的责任（和权限）应该由团队负责。周边组织通常会在许可成本和团队之间的一致性方面占有一席之地。根据您的团队的自主程度，他们应该可以选择自己的工具。在团队中，产品所有者通常在决策中拥有最高权益，因为他将成为最能用于持续改进和优先排序的人。团队的其他成员通常仅在细化和计划会话期间与规划工具交互一次或两次sprint。所以他通常是推动决策的人，但绝对应该让团队参与其中。如果所选工具还包括团队每天用于跟踪其工作的板，他们将希望在选择中有更多的发言权。

在敏捷/ scrum团队中负责选择敏捷规划工具

7 个回复

发起人

问题状态

在敏捷/ scrum团队中负责选择敏捷规划工具

与内容相关的链接

7 个回复

发起人

问题状态