在我的公司，我们让程序员，前端开发人员，设计人员和UX团队都参与敏捷团队。我不是敏捷大师，但我明白团队的所有成员都应该能够完成任何工作。让设计师，UX团队，最终开发人员和系统管理员参与投票，以估计后端任务需要多长时间对我来说似乎很疯狂。我几乎不知道！所以我的问题是我太苛刻了吗？这可以在敏捷环境中工作吗？
答案 0 :(得分：4)
你的基本概念错了......所有成员都应该能够跨越故事。不是全面的交叉功能......开发人员不能突然成为UI设计师。
不。每队的成员数限制在7-10。因此，该组应相应地进行细分。
答案 1 :(得分：3)
IMO，这是一个误解。作为一个跨职能的团队并不意味着团队中的每个人都应该能够完成每项工作。这意味着团队应该是具有合适技能（作为一个整体）朝着共同目标努力的人的正确组合。换句话说，敏捷并不是在寻找拥有所有技能的人，敏捷并不反对专业化。每个人都不能也不会同样擅长一切。在我的公司，我们让程序员，前端开发人员，设计人员和UX团队都参与敏捷团队。我不是敏捷大师，但我明白团队的所有成员都应该能够完成任何工作。
让设计师，UX团队，最终开发人员和系统管理员参与投票，以估计后端任务需要多长时间对我来说似乎很疯狂。我几乎不知道！所以我的问题是我太苛刻了吗？这可以在敏捷环境中工作吗？
首先，在使用计划扑克时，没有任何东西表明你需要在第一轮融合。实际上，我认为有分歧是好的，只要让人们解释为什么他们以这种方式投票，以及他们的确定性和疑虑，并进入下一轮。无论人们的专业领域如何，我敢打赌它不会超过3轮才能找到共识。其次，经过几次迭代后，你将有足够的历史数据进行比较（“这个故事就像这个故事”），这将有很大帮助，与团队成员的专业化无关。第三，正如JeremyMcGee在评论中提醒的那样，团队成员将更好地了解正在发生的事情以及彼此的角色，这是另一个重要的影响。所以，对我来说，是，这可以起作用，拥有不同的技能组合是一种力量，而不是真正的弱点。
答案 2 :(得分：1)
简短的回答是肯定的。
即使是纯粹开发人员的团队也倾向于自我组织成特定子系统的专业或所有者（除非您倾向于强制他们轮换工作，但这是一个针对不同问题的主题）。因此，您将评估会议室中有大量成员的故事，这些成员对与故事相关的子系统工作知之甚少。
故事估计应该更多地是关于比较复杂性/工作的尺度。它比定义的基点更多地工作两次，四次，八次（或类似比例）。或者，它与我们评为8的其他项目类似。至少这是目标。在冲刺水平（相对于整体积压），我发现团队更愿意用更具体的尺度（即小时）进行估算。
对于特定学科的人，您可能希望也可能不希望将它们纳入估算过程。如果这些人对任务的复杂性有合理的理解，那么估计可能与其他成员一样好。如果没有，那么他们就不应该提供估计。
包括他们的估计值的一个好处是，它通常会产生更多的边远估计（过高或过低）。当我们有一个估计超出合理信封的项目时，就可以对这项工作进行简短而深入的讨论。通常，该讨论迫使小组发现工作/复杂性，这在故事描述和接受标准中并不明显。
答案 3 :(得分：0)
敏捷团队应该是“跨职能的” - 即有很多专家一起工作并且有一些重叠。
对于Web开发，甚至对于IT基础架构而言，拥有DBA，设计人员，业务分析师，程序员（您需要的任何不同技能组合）和同一团队中的IT基础架构人员都是有意义的。
并非团队的所有成员都必须全职工作 - 但任何可能因项目延误而导致误解的部门或专业都必须由足够的人代表做这些行动的能力或技巧。
不要忘记让人们参与：
我参与了软件准时准备但是DNS或硬件不是的项目 - 就客户而言，这是一个#fail。 你无法控制的是什么东西需要帮助？团队领导，教练和scrum大师应该提前一两步，以吸引合适的人参与。
让所有合适的人参与估算和启动会议 - 包括技术销售和业务至关重要。技术销售人员可能认为他们无能为力，但他们通常可以回答有关客户的问题希望这有助于在估算中建立共识。
答案 4 :(得分：0)
敏捷是关于合作和常识。也就是说，我认为它基本上归结为实际团队。他们能有效合作吗？如果没有，您可能需要修复它。你的回顾告诉你什么？ 敏捷是一条路径，而不是目的地
今天，所有必须在产品中协同工作的混合技术，所有开发人员都必须更广泛地了解他们的部分如何与产品的其余部分进行交互。因此，我认为让团队变得更好，但让团队公开谈话并一起工作并不总是那么容易。人们可能很难。