你在现实生活中的经验是什么?谁应该负责敏捷/scrum团队使用的敏捷规划工具的选择?
发布于 2010-12-06 04:31:41
团队应该决定是否使用工具;但我认为建议通常来自Scrum Master,因为他最有可能有使用工具的经验。当然,任何团队成员都可以建议工具。
无论如何,我的感觉是,鉴于Scrum的理念,在我看来,整个团队都需要在这一点上达成一致。通常,事情从“让我们试试这个,看看它是否有效”开始,并在此过程中不断改进,就像Scrum中的任何其他东西一样。它不应该是自上而下的执行,就像使用Scrum方法一样,应该是团队决定,而不是自上而下。
发布于 2010-12-06 04:46:50
问得好。拥抱敏捷的自组织并允许团队选择他们的工具有很大的价值。但是,业务通常会施加一些限制。例如,企业可能无法支持/希望每个scrum团队滚动自己的scm解决方案。业务越成熟,约束和回推就越多。即使是成熟的企业也可以改变。如果团队可以证明更改是合理的,那么不要害怕质疑约束。
敏捷规划工具将遵循同样的规则。企业可能有一个完整的软件生命周期管理解决方案。这个解决方案可能有也可能没有敏捷模块。但是,企业可能有理由(例如,受监管的行业)要求在其拥有的生命周期管理软件解决方案中记录设计输入/输出。业务通常需要在保持团队愉快/高效与保持业务之间取得平衡。
我不认为会有非黑即白的解决方案(除非你是初创公司的第一批开发者之一)。敏捷团队将需要接受开放的沟通。如果工具是障碍,那么业务需要知道。
发布于 2010-12-07 01:17:31
我将做一个简单的回答,因为我实际上认为这是一个简单的问题。
整个团队都要对此负责。
让我来解释一下。我们首先必须接受每个上下文都是不同的,所以这不是一个圣经上的答案。
假设你开始了你的项目。我总是喜欢白手起家开始我的项目/产品。没什么。有时,只是一个任务板,有待办事项,正在进行中,完成了。
就这样。我填写了待办事项栏。
这就是我要说的:我以增量和迭代的方式构建我的敏捷流程。为什么我必须创建燃尽表?因为识字告诉我这一点?
地狱没有,因为,也许,最终,在某个时候,我可能需要一些可见性来制定我的计划。
一切都是一样的。永远不要忘记,敏捷工具是对这个过程的支持。
所以,你是一个PO,你厌倦了简单的待办事项列表,并且觉得有必要做一个积压工作?2解决方案:--你已经是一个高度成熟的团队,你只需要在站立会议上告诉每个人你正在领导这个任务。最终,它需要回顾一下才能接受这一点。--您正在从V、W或任何产品管理模型迁移。然后,等待回顾,询问每个人并解释你的痛苦。给出解决方案(这里是待办事项),并要求尝试。
所以,你是一个scrum大师,你在你的过程中发现了一个“系统bug”,让我们来看看经典的一个:太多的bug。然后带头推动TDD,或系统测试。
所以,你是技术主管,我觉得...好吧,你理解我了。
我的观点是:永远不要在一开始就过度使用你的过程。慢慢构建流程,在需要的时候慢慢添加工具。通过这样做,不用担心,人们将承担创建工具的责任,并将其添加到流程中,向团队的其他成员游说。
希望这能有所帮助。
https://stackoverflow.com/questions/4360939
复制相似问题