您在现实生活中有哪些经验？谁应该负责选择敏捷计划工具供敏捷/Scrum团队使用？
7个回答
8
团队应该决定是否使用工具；但我认为建议最常来自Scrum Master，因为他/她最有可能有使用工具的经验。当然，任何团队成员都可以提出工具建议。
无论如何，我的感觉是，鉴于Scrum的理念，整个团队需要就此达成一致意见。通常情况下，事情会以“让我们尝试一下，看看效果”开始，并在途中进行改进，就像Scrum中的其他任何事情一样。它不应该是自上而下的强制执行方式，同样，使用Scrum方法论应该是团队决策，而不是从上面下达的。
- StaxMan
6
1如果有疑问，请询问团队。 - kenwarner
@qntmfred 我认为更重要的是具备“让我们试试这个，看看是否可行”的态度，并且有很多常识，而不是完全交给团队并询问他们。Scrum非常透明，如果你组建了一个由一群对软件开发一无所知的白痴组成的跨职能团队，他们会选择一个糟糕的工具，做出愚蠢的决定，生产出糟糕的软件，Scrum会在1个迭代（2周或一个月）后让管理层意识到这一点，然后进行一些检查和适应来改变事情。 - sjt
我的观点是决策应该使用常识。一个组织不应该只是盲目地按照团队的决定行事，特别是在一个没有经验的团队的情况下。如果团队在那个领域没有足够的经验，他们很可能会选择一个差劲的工具，并浪费一个月的时间去弄清楚它。如果可以从更有经验的人那里获得建议，为什么要浪费一个月呢？相反，团队应该开放并在必要时接受建议，并基于此做出决策。一个很好的接受建议的人是一位经验丰富的ScrumMas。 - sjt
sht：您的评论似乎有些矛盾；一方面说因为自己感受到了痛苦，所以犯错误是可以接受的，但另一方面却因为同样的原因认为这是不好的。我认为团队确实应该被信任去尝试新事物，甚至可能会犯错。但是优秀的开发人员和团队不应该坚持要犯自己的错误；他们应该从别人身上学习。而且我完全不相信任何组织“更懂得”。但也许这只是我的看法。 - StaxMan
@StaxMan 我的评论并不矛盾，只是被误解了。我再试一次。例如：可能有一个跨职能Scrum团队共同努力完成用户故事，但他们可能会意识到在实施过程中需要某个专业知识领域的知识，而该团队没有这方面的知识。在这种情况下，团队不应为了玩而做出非专家决策，应该运用常识，通知Scrum Master需要迭代资源（续） - sjt
如果自主管理的团队没有能力，组织应该帮助寻找解决方案。相反地（在这种特定情况下），如果要求团队仅仅因为他们是自主管理的就尽其所能，那么这样做是不明智的。我的例子只涉及可能在某个特定领域缺乏经验的团队。我想说的是，在需要时应咨询专家（无论是团队内部还是外部）以获得他们专业领域的解决方案，同时记住他们是跨职能团队的一员，除了“团队成员”之外没有特定的职称。 - sjt
2
很好的问题。采用敏捷自组织并允许团队选择工具有很大价值。然而，通常业务会施加一些限制。例如，业务可能无法支持/希望每个Scrum团队都使用自己的源码管理解决方案。企业越成熟，限制和反弹就越多。即使是成熟的企业也可以改变。如果团队能够证明变化的合理性，不要害怕质疑限制。
敏捷规划工具将遵循相同的规则。业务可能已经有了完整的软件生命周期管理解决方案。这个解决方案可能有或没有敏捷模块。然而，业务可能有理由（例如受监管行业）要求设计输入/输出在他们拥有的生命周期管理软件解决方案中进行记录。业务通常需要平衡保持团队的快乐/生产力和保持业务运转之间的关系。
我认为不会有黑白分明的解决方案（除非你是初创企业的第一批开发人员之一）。敏捷团队需要拥抱开放式沟通。如果工具是障碍，业务需要知道。
敏捷规划工具将遵循相同的规则。业务可能已经有了完整的软件生命周期管理解决方案。这个解决方案可能有或没有敏捷模块。然而，业务可能有理由（例如受监管行业）要求设计输入/输出在他们拥有的生命周期管理软件解决方案中进行记录。业务通常需要平衡保持团队的快乐/生产力和保持业务运转之间的关系。
我认为不会有黑白分明的解决方案（除非你是初创企业的第一批开发人员之一）。敏捷团队需要拥抱开放式沟通。如果工具是障碍，业务需要知道。
- rcravens
2
我会给出简单的回答，因为我认为这是一个简单的问题。
整个团队都要对此负责。让我解释一下。我们首先必须接受每种情境都是不同的，所以这不是一个权威的答案。假设你开始了你的项目。我总是喜欢从零开始我的项目/产品。什么也没有。有时候只有一个任务板，带有待办、进行中和完成三栏。就是这样。然后我填写待办事项。这就是我的观点：我增量地和迭代地构建我的敏捷过程。为什么我要创建燃尽图？因为文化告诉我这样做吗？当然不是，因为也许在某个时刻，我需要对我的计划有一些可见性。所有工具都是支持流程的。所以，你是产品负责人，厌倦了简单的待办清单，并感到需要做一个产品待办清单？有两种解决方案：1. 你已经在一个高度成熟的团队中，你只需在站立会议上告诉大家你正在领导它。最终需要回顾一下才能接受。2. 你正在从 V、W 或其他产品管理模型迁移。然后，等待回顾会议，向每个人解释你的痛苦。给出解决方案（这里是待办清单），并要求一次尝试。所以，你是 scrum 主管，发现你的过程中存在“系统性缺陷”，让我们来看看经典的一个：太多的漏洞。然后采取领导作用，推广 TDD 或系统化测试。所以，你是技术主管，感觉...好吧，你懂我的意思。我的观点是：在开始时不要过度使用工具来优化流程。慢慢地建立流程，慢慢地添加工具，当你需要它们时再添加。这样做，不用担心，人们会负责创建工具并将其添加到流程中，为了游说整个团队加入进来。希望这有所帮助。
整个团队都要对此负责。让我解释一下。我们首先必须接受每种情境都是不同的，所以这不是一个权威的答案。假设你开始了你的项目。我总是喜欢从零开始我的项目/产品。什么也没有。有时候只有一个任务板，带有待办、进行中和完成三栏。就是这样。然后我填写待办事项。这就是我的观点：我增量地和迭代地构建我的敏捷过程。为什么我要创建燃尽图？因为文化告诉我这样做吗？当然不是，因为也许在某个时刻，我需要对我的计划有一些可见性。所有工具都是支持流程的。所以，你是产品负责人，厌倦了简单的待办清单，并感到需要做一个产品待办清单？有两种解决方案：1. 你已经在一个高度成熟的团队中，你只需在站立会议上告诉大家你正在领导它。最终需要回顾一下才能接受。2. 你正在从 V、W 或其他产品管理模型迁移。然后，等待回顾会议，向每个人解释你的痛苦。给出解决方案（这里是待办清单），并要求一次尝试。所以，你是 scrum 主管，发现你的过程中存在“系统性缺陷”，让我们来看看经典的一个：太多的漏洞。然后采取领导作用，推广 TDD 或系统化测试。所以，你是技术主管，感觉...好吧，你懂我的意思。我的观点是：在开始时不要过度使用工具来优化流程。慢慢地建立流程，慢慢地添加工具，当你需要它们时再添加。这样做，不用担心，人们会负责创建工具并将其添加到流程中，为了游说整个团队加入进来。希望这有所帮助。
- Pasta
1
理想情况下由Scrum Master负责，但他们可能需要继承一些需要发展的遗留问题。
如果组织是新使用Scrum，则经验丰富的Scrum Master应该能够为团队的成熟度提供最佳建议工具。
通常，如果团队已经有了一些工具，Scrum Master可以根据现有条件进行适应，无论组织选择如何。一些最好的看板在Excel电子表格上，同样适用于特定构建系统。每种技术都会创建“约束条件”。因此，Scrum Master需要支持业务确保工具适合目标，并为团队提供价值。
如果组织是新使用Scrum，则经验丰富的Scrum Master应该能够为团队的成熟度提供最佳建议工具。
通常，如果团队已经有了一些工具，Scrum Master可以根据现有条件进行适应，无论组织选择如何。一些最好的看板在Excel电子表格上，同样适用于特定构建系统。每种技术都会创建“约束条件”。因此，Scrum Master需要支持业务确保工具适合目标，并为团队提供价值。
- ScrummyBear
1
你在现实生活中的经验是什么？谁应该对敏捷规划工具的选择负责，以供敏捷/Scrum团队使用？
我的真实经验是，在Scrum团队开始Sprint之前，某些“敏捷规划工具”就被交给了他们。幸运的是，团队喜欢它，但如果不适合我们，我们可以自由地检查和适应使用其他工具。
我认为，完全透明地使用、接受或拒绝工具应该由团队决定。他们可以很好地听取Scrum Master或敏捷教练的建议，因为他可能在敏捷工具领域有更多的知识。其次，团队应该勇敢地进行集体讨论，并根据敏捷教练的建议决定是否使用工具，并看看它对他们的工作效率有何影响，并从中适应和调整。
你没有提出的更大的问题是，当公司扩展到拥有多个使用自己敏捷计划工具的Scrum团队时，如何管理不同的工具集混乱？在实际情况下，在一个规模化的敏捷软件公司中，跨Scrum团队使用工具的一些统一性可能是有益和生产力的，但这可能由自组织企业项目团队指导，而不是每个团队都有自己的工具。当然，也可以有例外情况，某些团队正在开发完全不同的功能，他们需要完全不同的工具集，但使用共同的敏捷工具的好处将帮助扩展项目查看其团队的进展，而不需要太多的变化。
以上可以通过拥有技术、基础设施和流程工具故事来完成，但很少有公司使用或创建。这个史诗故事可以作为讨论使用哪些敏捷工具和其他工具以在项目内部实现一定的统一性的起点。在制定史诗故事时，整个项目团队可以参与项目启动，如果项目太大，则可以由1-2名成员代表各个团队。该故事可以像业务用户故事一样进行细分，并从基础设施和工具的角度进行修改、校准、估算和优先排序。如果您想更详细地了解此事，请告诉我。
我的真实经验是，在Scrum团队开始Sprint之前，某些“敏捷规划工具”就被交给了他们。幸运的是，团队喜欢它，但如果不适合我们，我们可以自由地检查和适应使用其他工具。
我认为，完全透明地使用、接受或拒绝工具应该由团队决定。他们可以很好地听取Scrum Master或敏捷教练的建议，因为他可能在敏捷工具领域有更多的知识。其次，团队应该勇敢地进行集体讨论，并根据敏捷教练的建议决定是否使用工具，并看看它对他们的工作效率有何影响，并从中适应和调整。
你没有提出的更大的问题是，当公司扩展到拥有多个使用自己敏捷计划工具的Scrum团队时，如何管理不同的工具集混乱？在实际情况下，在一个规模化的敏捷软件公司中，跨Scrum团队使用工具的一些统一性可能是有益和生产力的，但这可能由自组织企业项目团队指导，而不是每个团队都有自己的工具。当然，也可以有例外情况，某些团队正在开发完全不同的功能，他们需要完全不同的工具集，但使用共同的敏捷工具的好处将帮助扩展项目查看其团队的进展，而不需要太多的变化。
以上可以通过拥有技术、基础设施和流程工具故事来完成，但很少有公司使用或创建。这个史诗故事可以作为讨论使用哪些敏捷工具和其他工具以在项目内部实现一定的统一性的起点。在制定史诗故事时，整个项目团队可以参与项目启动，如果项目太大，则可以由1-2名成员代表各个团队。该故事可以像业务用户故事一样进行细分，并从基础设施和工具的角度进行修改、校准、估算和优先排序。如果您想更详细地了解此事，请告诉我。
- sjt
0
选择规划工具的责任（和权力）应该由团队承担。通常，周围的组织在许可成本和团队间的一致性方面会有利益。根据您的团队的自治程度，他们选择自己的工具应该是可以的。
在团队内部，产品负责人通常对决策有最高的利益，因为他将在持续改进和优先排序中使用它最多。团队的其他成员通常只在每个迭代期内的改进和计划会议中与规划工具进行交互一两次。因此，他通常是推动决策的人，但一定要涉及整个团队。
如果所选工具还包括团队每天用来跟踪工作的看板，则他们希望在选择中发表更多意见。
- Manuel
0
作为一名教练，我经常遇到的典型错误是由经理或高级管理层根据“专家”或外部顾问所做的某项研究做出的决策。这些人很多时候并不清楚工具的使用对象、使用方式和使用者是谁。在这种情况下，当他们应该使用所选择的工具时，我看到了失望的人们。
你必须考虑谁会在大部分时间内使用这个工具。团队成员是更好的目标群体。工具必须支持ScrumMaster角色，因为她需要完成日常工作。将有经验的产品负责人纳入工具选择中，因为不同的工具对于必须可用的计划支持有所不同。
考虑你的组织（产品复杂度、项目、地点数量）。
你必须考虑谁会在大部分时间内使用这个工具。团队成员是更好的目标群体。工具必须支持ScrumMaster角色，因为她需要完成日常工作。将有经验的产品负责人纳入工具选择中，因为不同的工具对于必须可用的计划支持有所不同。
考虑你的组织（产品复杂度、项目、地点数量）。
- Dusan Kocurek
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接