Questions tagged «scrum»

在敏捷方法（例如SCRUM）中，用户故事所需的复杂性/工作量是在故事点中衡量的。故事点用于计算团队在一次迭代中可以获取多少个用户故事。 引入一个抽象概念（故事点）有什么好处，在这里我们可以使用一个具体的度量，例如估计的工时？我们还可以使用估计的工时来计算速度，估计迭代的覆盖范围等。 相反，故事点更难使用（因为概念很抽象），也很难向涉众解释。它提供什么优势？

132 agile  scrum  estimation  user-story 

我们是一家只有一种产品的小型软件公司。 我们使用scrum，我们的开发人员选择他们想要包含在每个sprint中的功能。不幸的是，在过去的18个月中，该团队从未交付过他们致力于冲刺的功能。 我已经读过很多帖子/答案，它们都说“软件完成后立即完成工作，这无助于……给团队施加压力，让更多人参与其中， ……”我已经收到一位开发人员针对如何提高冲刺成功率提出的类似反馈。哦，是的，我们确实使用回顾。 我的问题基本上是： 寻找开发人员质量问题的公平时间是什么时候？ 我开始认为，如果您选择自己的工作/功能并且仍然无法使每个冲刺都失败，则-您将无法监督自己代码的复杂性；-或代码是如此复杂，以至于没有人能够监督复杂性。 我想念什么吗？

124 scrum  planning 

背景故事： 在过去的三年中，我一直作为这个团队的一员，这次我们有三个不同的Scrum Master，他们的运作方式各不相同。 由于Scrum Master的这种变化以及他们运行节目的方式，它使我的团队对Scrum的想法麻木了，因为原则并没有得到一致的执行，并且其中一位Scrum Master是一个不相信敏捷的人。开发和只是保留事件和工件，以作为新手遵守公司决策。 现在，当我们进行Scrum活动时，我的团队成员感到非常烦恼和无聊，尤其是一个人对此非常口头。 现在： 两个月前，该公司任命我为我的团队的Scrum Master，因为我致力于敏捷及其原则。 在不愿意做Scrum的团队成员的大气压下，我遭受了巨大的痛苦。 如前所述，他们对整个过程感到恼火，这对我来说非常困难，因为他们没有参与进行有效的计划，回顾和每日Scrum所需的必要对话。 对他们来说，计划只是浪费时间，因为我们只是将溢出转移到新的Sprint中，而无论如何都不会完成工作，所以为什么要打扰呢。 在回顾期间，我只能感觉到他们想说“停止做Scrum”。一个人这样做，但其他人则保持沉默，我每次都要处理。 每日Scrum再次对他们来说只是浪费时间，因为他们没有人打扰他们谈论和计划一天。他们只是说：“我昨天处理任务X，今天将再次处理。” 而且大多数时候，他们只是在开玩笑，直到我变得更加严厉。 关于他们在这些活动中如何度过的时光，我的心态很大。但是我要死在里面，因为我对此充满热情，他们不再关心。 今天，一直反对我的人告诉我不要说“他们说这是他们为Sprint所做的承诺”，因为用他的话说，“我们从不完成Sprint。我们只是在任务中移动并接受新的下一个Sprint填补配额。我们实际上是看板。所以不要再这么说了。” 我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的每个人都不在乎。他们只是做事而不是处理障碍。他们抱怨障碍，但不对他们做任何事情。而当我尝试帮助他们时，他们只是耸了耸肩。 他们曾经很讨厌，但在过去的两年中，他们的意愿或多或少地下降了。 我如何让他们看到在这些会议中开玩笑和浪费时间使公司损失了很多钱？

109 agile  scrum  scrum-master 

我是一名初级开发人员，如果我可以证明更改的合理性，并且可以帮助团队完成工作，则可以帮助调整团队的流程。这对我来说是新的，因为我过去的公司或多或少都严格定义了来自管理层的流程。 我的团队很小，有些新（不到3岁）。他们缺乏： 定义明确的软件开发/工作管理框架（如Scrum） 强大的产品所有权 定义明确的角色（例如，业务人员将进行手动测试） 定期站立会议 合并的问题跟踪流程（我们有一个工具，该流程仍在开发中） 单元，系统，回归或手动测试套件或列表 有关业务逻辑和流程的文档 知识库以记录内部和面向客户的提示 而这样的例子不胜枚举。只要价值是合理的，管理人员就可以实施改进措施，并且可以帮助完成最重要的工作（即开发）。但是，基本假设是您必须在实现中拥有所有权，因为没有人会为您做这件事。毋庸置疑，上述某些项目是不平凡的，无疑是耗时的，并且显然不是开发工作。 随着时间的流逝，（初级）开发人员尝试实现上述目标是否值得？还是最好“随心所欲”并专注于开发，将大部分流程定义和优化留给管理人员？

108 project-management  scrum  development-process  process  product-owner 

我是一个网络开发人员，由三个开发人员和一个设计师组成。现在，我们已经实施了五个月的敏捷Scrum软件开发方法。但是我有一种奇怪的感觉，我只想在这个网站上分享。 决策过程是人类生活中的重要因素。但是，您做出的决定有很大的不同。有些决定只是内部力量或外部力量的结果，而其他决定则完全基于您的自由意志，而某些决定只是介于两者之间。您做出决策的自由度越高，您的工作就会越自我驱动。这似乎是规则。因为我们倾向于自己塑造生活。 您决定做什么或被告知要做什么之间有很大的不同。 争球之前，我感觉自己就像做了哪些相关的发展，分析了决定，优先执行，等我有更多的感觉就像有更多的自由，我决定我在做什么。 但是，由于采用Scrum的方法论，现在许多决定只是来自产品所有者。他优先考虑PBI，他分析软件应如何工作，甚至有时应如何实现UI和功能。我知道这是Scrum方法论的一部分，我也知道这可能会导致将来更好的产品销售。但是，我现在感觉总是被告知要做某事，而不是决定做某事。现在，这种综合症使我对工作更加被动了。 我倾向于减少搜索以找到更好的解决方案，方法或技术 我不会在早上醒来，希望能得到愉快的工作。相反，我觉得自己被迫为了生存而工作 下班后我更渴望从事自己的业余爱好项目 我不会再推动团队达到更高的技术水平了 我现在花更多时间在晚餐或下午茶时间上，而对恢复工作的热情却降低了 我现在愿意为工作早日完成做好准备，以便我可以回家 最大的问题是，我也在同事中看到并诊断了这种行为。是混乱的结果吗？Scrum是否真的使开发团队感觉自己没有参与整个软件的开发，从而使项目变得被动了？我该如何克服这种感觉？

103 agile  self-improvement  scrum 

我的经理最近确实在推动使用速度作为生产率的目标和衡量标准。我们目前正在以50个故事点的平均速度进行工作。我的经理希望我们将其提高40％，达到70个故事点（团队成员不增加）。如果我们没有实现这一增长，他希望我们提供完整的细分说明原因。 以速度衡量团队绩效并将其用作目标的整个想法对我来说似乎是错误的，但是我发现很难解释为什么。有什么帮助吗？为什么这不是衡量和激励生产力的正确方法？

89 agile  scrum 

许多Scrum书籍和文章都说，失败的sprint（当团队无法完成Sprint Backlog的某些功能时）并不是一件坏事，它不时发生，并且如果团队从错误中吸取教训，这实际上很有用。并改善了以下冲刺中的一些功能。并且团队不应因未完成其承诺的工作而受到惩罚。 从开发人员的角度来看，这看起来不错，但是，我们有一家软件公司“ Scrum-Addicts LLC ”为认真的客户（“ Money-Bags Corporation ”）开发一些东西： Scrum-Addicts经理建议为Money-Bags开发一款软件 他们同意功能列表，Money-Bags要求提供发货日期 Scrum-Addicts经理咨询了他们的Scrum团队，该团队表示，将需要3周的冲刺来完成所有功能 Scrum-Addicts经理增加了1周的安全时间，承诺在1个月内发布该软件，并与Money-Bags签订了合同 经过4个冲刺（交付期限）后，Scrum团队只能交付80％的功能（由于新系统的经验不足，需要在生产环境中修复以前的功能中的关键错误等）。 正如Scrum所建议的那样，该产品目前可以交付，但是如合同中所述，Money-Bags需要100％的功能。因此，他们违反了合同，却一无所获。 Scrum-Addicts濒临破产，因为他们没有从Money-Bags获得任何收益，并且投资者对结果感到失望，不愿再为公司提供帮助。 显然，没有哪个软件公司愿意加入Scrum-Addicts的行列。我对敏捷和Scrum的不了解是，他们建议团队如何应对计划和截止日期，以避免上述情况。因此，总而言之，我有两个问题： 谁是罪魁祸首？ 经理，因为做适当的计划是他们的工作 团队，因为他们致力于做更多的工作 其他人 什么是要做？ 经理应将截止日期推迟到原团队的估计值的2倍（或3倍）。 无论如何，都应鼓励团队成员尽心尽力（通过对冲刺失败进行处罚） 团队应放弃Scrum，因为它不符合公司的截止日期政策 我们都应该放弃软件开发并加入修道院 ???

80 agile  scrum  sprint 

这个问题一直困扰着我一段时间，所以我想问那些在开发环境中遵循敏捷/敏捷实践的人。 我的公司终于冒险融入敏捷实践，并从一个由4个开发人员组成的团队开始在一个敏捷团队中进行试用。到目前为止，已经进行了3个月的迭代，为期4个月，他们继续这样做，而对我们其他人来说却没有足够的敏捷性。这是由于以下事实：管理层信任高层提供的大量临时类型请求，可以满足业务需求。 最近，我与参与该计划的开发人员进行了交谈。他们告诉我这不好玩。他们的Scrum管理员不允许他们与其他开发人员交谈，也不允许他们在工作区域内拨打任何电话（可能在一定程度上可以）。例如，如果我想和敏捷团队中的朋友聊天，未经Scrum主管的允许，我是不允许的。坐在敏捷团队旁边的人。 所有这一切或敏捷的想法是为敏捷开发人员提供一个不受干扰的完整真空，并将其投入6个以上的生产小时。好吧，伙计们，我不是敏捷专家，但是我读过Yahoo敏捷发布文档以及其他组织的类似文档时，给我的感觉是敏捷并不便宜。团队需要敏捷的资源和预算来灌输敏捷性，并在他们到达时纠正问题，使他们重回正轨。 对于初学者来说，它需要为开发人员提供培训，并为经理等提供指导。等等。目前的Scrum主管是一位经理，他参加了为期两天的敏捷培训课程，该课程由管理层支付，现在领导这个敏捷团队。我在会议上还听说过，敏捷宣言并不表示敏捷不是一成不变的，而是为每个公司定制的。好吧，这听起来不错，也很合理。 总之，我一直认为敏捷应该在开发团队中带来和谐，从而使开发人员感到满意。但是，当与敏捷团队中的开发人员交谈时，我的感觉却截然相反。他们为自己除了工作以外什么都不会说话感到不高兴，他们整日坐在办公室里安静地工作，他们觉得这是管理层提高工作效率的另一种方式。 请告诉我，这是否是为了获得更多美元而自私自利的良好做法的例子之一？也许是像我们这样的开发人员才是我们，这个敏捷的团队认为他们不喜欢在只能呼吸工作的环境中工作。 这是一家医疗保健领域的公司，在美国设有办事处。绝对感觉像是牛仔风格的敏捷，这使我真的根本不想去敏捷，尤其是在我目前的公司中。 所有这些都与管理完全便宜有关。削减昂贵的咖啡以获得更便宜的版本，强调节约和生产，同时保持尽可能的瘦。 我的感觉是，门后的管理层中有人拒绝了这个想法，敏捷使您可以生产更多，因此我们可以向我们的老板展示我们正在以相同的人数生产更多产品。或者，如果是这样的话，它可能使我们减少人员。 他们每天开会5分钟。但不允许与团队以外的人聊天或交谈。所有重点都放在工作上。

80 agile  scrum  methodology 

到目前为止，我一直在阅读和研究的所有内容都描述了敏捷/ Scrum如何与大约4至6名成员甚至更多的团队合作。 在我目前的商店中，我们大约有8个开发人员，但是考虑到项目数量的性质和我们支持的部门数量，给一个项目分配的人员永远不会超过1或2。 我仍然可以与1个或2个开发人员团队一起使用Agile / Scrum吗？我正在努力向经理推销，以开始使用这种方法，但是我需要能够解释如何为一小部分开发人员缩减规模，或者说服他们确保我们在给定的数量上拥有更多的成员。项目。

63 scrum  methodology  agile 

客户满意度的卡诺模型定义了不同类别的产品功能。其中有 必须具备的质量：如果未实施这些质量，则客户将不会接受该产品。 吸引人的品质（愉悦）：客户通常一开始并不期望的功能，但被发现时会引起兴奋和愉悦。 有吸引力的品质显然具有很大的商业价值。当使用不到5.000欧元的菲亚特汽车可以满足所有必不可少的条件时，他们会让人们以500.000的价格购买法拉利。 但是，我知道所有敏捷过程都强烈赞成必须满足的要求。这些总是获得最高优先级。似乎甚至没有在敏捷中获得吸引人的品质的地方。 我相信敏捷流程在软件开发中非常有用。但是，如何将它们应用于创建令人愉悦的高质量软件产品，而不仅仅是满足勉强满足最低要求的最低要求？ 附录：正如前两个答案所指出的那样，将必须满足的要求给予最高优先级确实是有意义的。但是我们（和客户）是否真的总是事先知道什么是必须满足的要求。我有几次这样的经验，即一开始就被高度重视的要求后来变得不那么重要了，即使不是毫无用处的。因此，我认为不应盲目地将注意力集中在必须满足的要求上。

61 agile  project-management  scrum  requirements 

我们是一个由3个开发人员，1个设计师，1个Scrum管理员和1个产品所有者组成的Scrum团队。但是，我们的团队中没有官方测试人员。我们一直面临的问题是，测试应用程序并通过这些测试并消除错误已被视为考虑完成PBI（产品待办事项）的标准之一。 但是问题在于，无论我们（3位开发人员和1位设计师）尝试测试应用程序和已实现的用例的多少，仍然看不到一些错误，并且破坏了向利益相关者的展示（墨菲定律）。 作为补救措施，我们建议公司雇用新的测试人员。工作的人只能进行测试，并且只能进行测试。官方专业测试人员。 但是，问题在于，Scrum负责人和利益相关者认为开发人员（或设计师）也应该是测试人员。 对吗 我们开发人员（还是设计师）也应该成为测试人员吗？

60 testing  scrum 

在我工作的地方，我们通过3周的迭代练习了Scrum驱动的敏捷。是的，如果迭代次数较短，那将是很好的选择，但目前暂时不能更改它。 在迭代结束时，我通常会发现最后一天进展非常缓慢。实际工作已经完成并被接受。有几次会议（回顾性会议和下一个迭代计划），但除此之外，会议进行得并不多。 我们团队可以使用哪种技术来维持最后一天的动力？我们应该解决缺陷吗？尽早开始下一轮迭代的工作吗？还有吗

56 agile  development-process  scrum 

根据您的经验（轶事或其他），有什么有效的方法将敏捷引入非敏捷组织或公司？ 更新：有人可以说出您试图引入敏捷但被“击落”的案例吗？另外，您现在是否有追溯性的了解，为什么会被“击落”？

55 agile  scrum  methodology  culture 

使用Scrum从瀑布到敏捷的过渡大约在中间。我们已经从技术/学科孤岛中的大型团队变为较小的跨职能团队。 不出所料，敏捷的改变并不适合所有人。少数开发人员很难适应敏捷的需求。我真的想让他们保持参与和挑战，并最终享受每天上班的乐趣。这些人都是聪明，快乐，有进取心的人，我个人和专业都尊重他们。 基本问题是这样的：有些开发人员的主要动机是乐于进行一些艰巨的工作，仔细考虑设计，仔细考虑潜在问题，然后逐步解决问题，而在与扩展人员的最小交互下一段的时间。他们通常会及时高质量地完成工作；他们的工作是可维护的，并且与整体架构相适应。过渡到重视交互作用和共同责任的跨职能团队，并在较短的时间间隔内交付工作功能后，团队不断发展壮大，整个团队将这一难题解决了。许多人发现这是一个积极的变化。一个喜欢承担一个问题并从头到尾独立承担责任的人会失去这样的工作机会。 人们乐于接受变革，这不是问题。当然，我们已经见过一些不喜欢变革的人，但是在我所关心的情况下，个人表现出色，真正乐于接受变革，他们努力工作，他们看到团队其余成员的表现不断变化，他们想适应。这不是某人遇到困难或阻碍主义者，或想ho积最充实的工作。他们只是没有像以前那样在工作中找到快乐。 我敢肯定，我们不可能是唯一一个没有撞到这个地方的地方。其他人如何处理呢？如果您是一个开发人员，因为自己是端到端拥有大量工作的动力，并且已经适应了另一种工作方式，那么对您有什么帮助？

52 agile  scrum 

我是一名开发人员，致力于开发具有大型后端组件的Android和iOS新移动应用程序。我们已经进入了该项目的三个冲刺阶段，并且我们将Scrum与它的所有仪式（完善，计划，每日，回顾等）一起使用。 在两次冲刺中，团队不得不加班和周末工作（无偿），因为管理层非常震惊，我们无法按时完成冲刺承诺。每个人都努力工作，但是一些外部依赖性和乐观估计使我们难以完成所有的冲刺故事。 以我的经验，在一些冲刺中完成一小部分故事是不正常的，可以在下一个中解决。但是我们的项目经理说，这是我们自己做的估算，这是我们的错，因此我们应该完成sprint中的所有项目。 我不知道这是Scrum的可接受/常见变化吗？ 您如何建议我对此采取行动？

52 agile  project-management  scrum  development-process