Questions tagged «scrum»

我们的Sprint计划会议不仅不好玩，而且简直令人恐惧。 这些会议既乏味又无聊，而且要花很多时间（一天，但感觉要更长一些）。 开发人员对此表示抱怨，并担心即将到来的计划。 我们的例程非常标准（按优先级将用户故事插入到sprint待办事项中>>将故事分解为任务>>按小时数估算任务>>重复），我无法弄清楚我们在做什么错。 我们如何使会议变得更加愉快？ ... 应要求提供更多信息的更多详细信息： 为什么在sprint启动之前未插入待办事项并按优先级排序？ 用户故事确实是优先的；我们不知道他们会花多长时间，直到将他们分解成任务！从这里的（优秀）答案中，我看到也许我们根本不应该估计任务，而应该仅估计用户故事。我们估计任务（而不是故事）的原因是因为我们一直在错误地估计故事，但我想这是一个完全不同的问题。 开发人员为何抱怨？ 会议很长。 会议是单调的。一个接一个的故事，一个接一个的任务，奋斗（是的，奋斗）来估计需要多长时间和涉及什么。 估计任务使用户故事的估计显得毫无意义。 会议时间越长，会议室的焦点就越少。同事注意力越集中，会议花费的时间就越长。递归的仇恨螺旋发展。我们已经考虑将会议分成两天，以使人们集中注意力，但是开发人员对此一无所知。一天的计划已经够糟糕了；现在我们有两个？ 问题的一部分是我们进入了非常小的细节（以便获得更准确的估计）。但是，当我们粗略估算时，我们远远超出了预期！ 总结一下问题： 我们做错了什么？ 还有什么其他方法可以使会议更加愉快？

51 agile  scrum  sprint  meetings  process-improvement 

我只是想知道我们是否应该将故事点分配给错误修复任务。我们的问题跟踪软件JIRA没有Bug类型问题的故事点字段（仅适用于Story和Epic）。 我们是否应该将Bug问题类型添加到Story Points字段的适用问题类型中？优缺点都有什么？它适合Scrum吗？

50 agile  scrum  bug  user-story 

我们正在使用Scrum，偶尔发现我们无法在计划的sprint中完成用户故事。无论如何，我们都会以真正的Scrum风格交付软件，并考虑在下一个Sprint计划会议期间的下一个Sprint中包括用户故事。鉴于我们要继续执行的用户故事已部分完成，我们如何在下一个Sprint计划会话中对其进行正确估算？我们考虑过： a）向下调整故事点的数量以仅反映完成用户故事所需的工作。不幸的是，这会使报告产品积压工作变得混乱。 b）关闭部分完成的用户故事，然后提出一个新故事来实施该功能的其余部分，这将减少故事点。这将影响我们回顾性地查看在该冲刺中未完成的工作的能力，这似乎很耗时。 c）不用理会a或b，并在Sprint Planning期间继续猜测，诸如“用户故事可能是X故事点，但我知道它已经完成了95％，所以我确定我们可以适应它”。

50 agile  scrum  estimation  planning 

我的工作团队正在迁移到Scrum，其他团队也开始使用单元测试和用户接受测试来进行测试驱动的开发。我喜欢UAT，但是对于测试驱动的开发或通常测试驱动的开发，我不出售单元测试。 看来编写测试是一项额外的工作，使人们在编写实际代码时显得cr不休，而且可能并不经常有效。 我了解单元测试如何工作以及如何编写它们，但是任何人都可以证明这确实是一个好主意，值得付出时间和精力吗？ 另外，还有什么使TDD特别适合Scrum的？

48 unit-testing  scrum  tdd 

一个公共组织要求我举办一个有关敏捷开发101的非正式研讨会，解释Scrum，看板等的术语和概念。我已经在敏捷环境中工作了大约五年，但是我不认为我是Scrum的传播者。 研讨会结束后，他们喜欢这个主意。但是，他们解释说，这种方法可能不适用于他们，因为他们需要委托外部软件公司为他们开发软件（他们自己只有很少的开发人员）。这项活动需要在公开招标过程中完成，描述结果，价格和时间范围。这是为该组织（公共研究机构）申请预算的法律要求。 这些约束似乎与敏捷开发的基本原理矛盾，不是吗？ 在这种环境下Scrum只是不兼容吗？ 您对这个组织有什么建议？

43 agile  project-management  scrum  government 

刚接到一个电话，开发人员对每个sprint中将其故事集成到master分支表示担忧。开发人员所有代码都在自己的分支中，并且在冲刺结束时，他们都合并到一个主分支中。 然后，让一名开发人员（通常是同一位开发人员）负责确保所有内容都与其他开发人员的代码很好地集成在一起（大多数更改都在同一页面上。例如，数据显示故事，数据过滤故事和SLA指标）。 我们如何减轻这种负担并使我们的代码更容易合并在一起？从我的角度来看，让PO或SM以更有效的方式对故事进行优先级排序，以便我们在同一sprint中没有此类依赖关系可能会解决某些问题。其他人如何解决呢？还是这只是过程的一部分？

42 agile  scrum  branching  stories 

在非敏捷开发团队中，首席开发人员通常： 设置标准（编码等） 为团队研究新技术 为团队设定技术方向 对事情有最终决定权 设计系统架构 但是，敏捷团队的工作方式有所不同： 敏捷团队将依靠紧急设计，而不是预先设计 敏捷团队一起设计，而不是由一个人决定设计 敏捷团队决定自己的技术方向，这是交付项目的最佳选择 这将使敏捷开发团队中的首席开发人员离开哪里？在敏捷团队中是否可能有首席开发人员？敏捷团队是否需要与领导不同的职责？

42 design  architecture  agile  scrum  team-leader 

敏捷宣言的创始原则之一是 敏捷过程促进可持续发展。赞助者，开发者和用户应该能够无限期地保持恒定的步伐。 Scrum团队使用术语sprint来指工作周期（也称为迭代）。 但这对我来说没有意义。根据谷歌的冲刺是： 在短距离内全速运行。 换句话说，这是不可持续的。为什么Scrum团队使用sprint这个词？在我看来，这与敏捷的基本原则之一相抵触。

41 agile  terminology  scrum 

我是敏捷开发的忠实拥护者，几年前在一个非常成功的项目中使用了XP。我喜欢它的所有内容，迭代开发方法，围绕测试编写代码，配对编程，让客户在现场运行。那是一个高产的工作环境，我从没有感到自己受到压力。 但是我工作的最后几个地方使用/使用了Scrum。我知道这几天是敏捷开发的榜样，但我不是100％相信它是敏捷的。以下是它对我不敏捷的两个主要原因。 项目经理喜欢它 从本质上讲，他们迷恋时间表的项目经理似乎都喜欢Scrum。以我的经验，他们似乎将Sprint Backlog用作跟踪时间要求并记录在给定任务上花费了多少时间的方法。他们都没有使用白板，而是使用一张excel表格，每个开发人员都必须认真地填写该表格。 在我看来，这对于敏捷过程来说是太多的文档/时间跟踪。当我可以继续进行任务本身时，为什么我会浪费时间估计一项任务要花多长时间。或类似地，为什么我会浪费时间记录任务可以花多长时间才能转到下一个任务。 站立会议 我以前工作过的站立会议是一场噩梦。每天我们都必须解释昨天的工作以及当天的工作。如果我们按照时间“完成”一项任务，那么项目经理会发臭，并参考“ Sprint待办事项列表”，以表明您不称职不称职。 现在，我了解了交流的必要性，但可以肯定的是，日常会议的气氛应该轻松愉快，并专注于知识共享。我认为这不应该成为您家庭作业风格的诱人之处。同样可以肯定的是，敏捷的漏洞在于时间线会发生变化，它们不应该一成不变。 结论 敏捷的想法是通过使开发人员的生活更轻松来使软件更好。因此，在我看来，团队使用的任何敏捷过程都应由开发人员领导。我不认为让项目经理使用他们标记为“敏捷”的流程来跟踪项目与敏捷开发有关。 有人在想吗？

41 agile  scrum 

我成为一个新成立的团队的Scrum Master，负责创建软件和维护其他已部署的应用程序。因此，基本上每个团队成员都有开发和运营任务。 在过去的几周中，我一直在观察他们的工作方式，我注意到团队在协调这些任务时遇到了麻烦。当开发人员专注于编码时，他会被打扰以解决生产中出现的问题，这使他很难再次专注于先前的任务。 我尝试分配％的开发人员时间用于操作工作，但是显然，这不能解决问题。我很想听听曾经遇到过这种情况的Scrum管理员的来信，您如何处理这种情况以及您有什么建议？

40 agile  scrum  scrum-master 

举行每日Scrum有很多优点，例如： 团队互相协调 每个人都知道完成了多少任务 燃尽图变得越来越完整 任务板已更新 它不会持续那么长时间，十五分钟不会杀死任何人 但是，最近（在实施和使用Scrum的6个月之后），我觉得我们的开发人员已经不再每天都喜欢Scrum。人们只是更新任务板，而没有解释足够，这似乎使他们感到无聊。我看到，无论出于什么原因，如果我们不坚持，他们就会变得特别高兴。 我只是不知道这可能是什么问题。有什么理由提到“每日混乱”可能给团队带来的不利吗？开发人员厌倦了日常混乱的原因可能是什么？

40 project-management  scrum  meetings 

您认为每日站立会议有多有价值（或没有）？ 如果您不熟悉它，则指的是Scrum拥护者（以及其他一些敏捷方法论）中的日常会议。这个想法是，您每天召开一次会议，时间限制为15分钟，每个人都必须参加会议（以鼓励人们直截了当）。 在会议上，您到处走走，每个人都说：-昨天您做了什么-您今天打算做什么-任何阻碍或阻碍您前进的障碍。 您认为这种做法有价值吗？有没有人在一个做过的地方工作，您觉得呢？

40 agile  scrum  meetings  development-methodologies 

因此，Scrum冲刺是一个固定的时间段，在此期间应实现一组特定的功能。Scrum团队由致力于提供这些功能的所有人员组成，其中大多数通常是开发人员和测试人员。 建立了这些规则后，您可能会想知道如何在整个冲刺期间让所有这些人都忙。在sprint的开始阶段，没有什么要测试，而在sprint的末尾，通常没有什么东西可以开发/修复。 我已经看到了两种方法可以解决此问题，但是它们似乎都无法正确解决问题。 1）让团队成员决定在任务结束时应该做什么。 缺点： 如果他们的工作没有得到充分的计划（例如，重大的重构，改用新的测试框架），那么他们的工作可能会变得毫无用处，或者被困在中间 另一方面，计划这样的工作可能要花费大量时间，并且客户可能会失望地看到团队浪费时间在无法带来即时价值的事情上 通常无法对这些任务进行彻底的估算，因此，无原则的工作人员很容易花时间看YouTube猫，而不会在Scrum板或其他任何地方反映出来 2）在sprint中留出仅用于开发的空间，并在sprint完成后开始测试（当开发人员开始处理下一个sprint的功能时） 缺点： 在为当前sprint开发功能时，开发人员会通过修正前一个bug来分心，而他们可能无法执行估计在当前sprint期间完成的工作量 需要两个Scrum板：一个用于当前的sprint功能，一个用于以前的sprint错误 所以我的问题是：如何在开发人员和测试人员之间的冲刺期间正确分配工作，以使任何人都不会负担过多的工作，或者在任何时候都没有任务而最终失败？有什么方法可以改善上述方法？还是有更好的方法？

33 agile  scrum  sprint 

Scrum团队如何在计划会议中解决开发/基础架构任务？ 乍一看，它们似乎不像用户故事，因为它们无法传递最终用户价值。 但是，将它们作为任务附加到特定用户故事有时也没有意义。例如，说任务是：“安装竹子”。不需要完成该任务即可完成任何用户案例，因为团队可以手动构建和部署。因此，将其附加到用户故事没有意义，因为不需要完成此任务即可完成用户故事。 因此，这表明这些任务成为了用户故事。但是，如果团队故事指向他们，那么这将改变速度，这是奇怪的，因为产品负责人想知道积压的速度，而不是积压了大量技术用户故事的积压速度。

33 scrum  planning 

我们有一个“典型的” SCRUM团队，我们致力于冲刺，并保持积压。最近，我们遇到了一个问题，即试图集成/处理一个超能力的开发人员进行带外工作（选择在正常工作时间/冲刺之外工作）的工作。 举个例子，如果团队承担了50个工作点，那么说他们将在sprint结束之前完成SCRUM框架内的所有工作，并且他们和公司都很高兴。团队成员之一决定自己在空闲时间上处理积压项目。他们不签入此工作，而是保存它（我们使用TFS，它在架子集中）。 如何处理呢？一些问题.. 在下一次冲刺期间，该团队成员说，编程工作已完成99％，仅需要代码审查和测试。您如何在SCRUM和敏捷方法中处理此问题？ 其他开发人员抱怨说，由于工作是在带外完成的，因此没有参与与这些故事相关的设计决策。 我们的产品负责人很想参加这项“免费”的工作，而过分追求成就的成员可能会故意这样做，以便使产品获得更多功能，否则团队将无法在冲刺中完成这些功能。有观点认为这正在打破“进程”。显然，质量检查，UI和文档工作仍需要完成。 我看到了很多关于不强迫SCRUM团队加班的讨论，但是团队成员的工作超出了Sprint计划和执行过程中提出的期望又超出了预期吗？我会犹豫要与这个人打交道，并说你不能做更多的工作（当然要小心烧伤），但与此同时，这似乎在团队的某些成员（但不是全部）上引起了一些问题。 如何将一个过高的成员完成的工作整合到SCRUM和敏捷过程中进行软件开发？

32 agile  scrum  team