Questions tagged «agile»

我希望这不是一个普遍的问题。我真的可以使用一些经验丰富的建议。 我刚刚在一家规模很小的科学家商店中担任唯一的“软件工程师”，他们在过去的10到20年中花了很多时间编写了庞大的代码库。（它是用一种几乎过时的语言编写的：G2-用图形来思考Pascal）。该程序本身是复杂的化学加工厂的物理模型。编写该程序的团队具有难以置信的深厚知识，但是很少或没有正式的编程基础培训。他们最近学到了一些关于不存在的配置管理的后果的艰难教训。代码本身中大量未记录的“污泥”的积累也极大地阻碍了他们的维护工作。我会避免给您这种情况的“政治”（总是 政治！），但足以说，就未来的道路需要什么没有达成共识。 他们要求我开始向团队介绍现代软件开发的一些原理。他们希望我介绍一些有关编码约定，生命周期管理，高级设计模式和源代码控制的行业标准实践和策略。坦白地说，这是一项艰巨的任务，我不确定从哪里开始。 最初，我倾向于在The Pragmatic Programmer或Fowler's Refactoring（“代码气味”等）的一些中心概念中对它们进行辅导。我也希望介绍一些敏捷方法。但最终，要想发挥作用，我认为我需要磨练5-7个核心基础知识。换句话说，他们可以实际开始实施的最重要的原则或实践是什么，这将使他们获得最大的“收益”。 因此，这就是我的问题：您将在最有效的策略列表中包括哪些内容，以帮助理顺意大利面（并在以后防止出现这种情况）？

470 project-management  agile  development-process  maintenance  sdlc 

有人将如何作为单独开发人员实施敏捷流程概念？敏捷似乎有助于加快应用程序的开发速度，但似乎也非常面向团队。

133 agile  solo-development 

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

132 agile  scrum  estimation  user-story 

作为尚不熟悉敏捷的人，我不确定我是否完全了解用户故事，功能和史诗之间的关系或差异。 根据这个问题，特征是故事的集合。答案之一表明某个功能实际上是史诗。那么功能和史诗是否被认为是同一件事，基本上就是相关用户故事的集合？ 我们的项目经理坚持要有一个层次结构： 史诗->功能->用户故事 基本上所有用户故事都必须属于此结构。因此，所有用户故事都必须属于保护伞功能，而所有功能都必须属于史诗级功能。 对我来说，这听起来很尴尬。有人可以说明用户故事，功能和史诗之间的关系吗？还是有一篇文章清楚地概述了这些差异？

111 agile  terminology 

我和我的朋友一直在努力准确地对什么是集成测试进行分类。 现在，在回家的路上，我才意识到，每当我尝试给出一个真实的集成测试示例时，它实际上就是一个验收测试，即。业务人员会大声说出要指定系统应该提供的内容。 我检查了Ruby on Rails文档中对这些测试类型的分类，现在完全把我扔了。 您能否以一个真实的例子为我提供关于集成测试的简短学术描述？

110 testing  agile  tdd 

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

109 agile  scrum  scrum-master 

我是一个相对较新的开发人员，刚从大学毕业。在上大学时以及随后的求职过程中，我意识到我缺少很多“现代”软件开发方法：单元测试，日志记录，数据库规范化，敏捷开发（相对于通用敏捷概念），编码风格指南，重构，代码审查，没有标准化的文档方法（甚至要求）等。 总体而言，我认为这不是问题。我希望我的第一份工作会包含所有这些想法，并在工作中教给我。然后我在一家大公司获得了第一份工作（全栈Web开发），我意识到我们不做任何事情。实际上，我是团队中经验最少的人，是率先尝试使我的团队掌握“现代”编程技术的人，因为我担心不这样做会导致职业自杀。 首先，我开始使用日志记录软件（log4J），但随后我迅速着手编写自己的样式指南，然后放弃了它，而改用Google样式指南-然后我意识到我们的Java Web开发使用手写的前端控制器，因此我坚持我们对Spring的采用-但后来我意识到我们也没有单元测试，但是我已经在学习Spring ...正如您所看到的，它变得太快了，尤其是与正常的开发工作结合使用时。此外，我很难在这些方法论中变得足够的“专家”来教给其中的任何其他人，而又不花太多的时间去研究其中的一个，更不用说全部了。 在所有这些技术中，我认为在当今的软件开发世界中这些技术都是“预期的”，我如何将它们作为一个新的参与者整合到团队中，而又不让自己和团队感到不知所措？ 我如何影响我的团队变得更加敏捷？是相关的，但我不是像这里的问询者那样的敏捷开发人员，并且我正在寻找比敏捷更广泛的方法集。

106 agile  teamwork 

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

103 agile  self-improvement  scrum 

为了清楚起见，截止日期为： 时间限制或最后期限是必须完成目标或任务的狭窄时间范围或特定时间点。 来自维基百科 在我整个软件开发生涯中，我一直在做“敏捷”，到处似乎都意味着至少遵循以下实践： 每周或每两周冲刺 回顾性冲刺计划 产品负责人 Scrum 用户故事 但是，我参加过的每个项目都坚持设定截止日期。鉴于敏捷试图将重点放在适应性计划，灵活性和变更上；截止日期是敏捷的吗？ 我个人认为它们不是，因为我认为截止日期会导致缺乏灵活性和质量。相反，我认为将精力集中在Sprint和早期交付方面可以提供更多价值。然而，似乎在我所经历的每个圈子中，情况并非如此，并且截止日期与敏捷开发紧密相关。

100 agile 

我的经理最近确实在推动使用速度作为生产率的目标和衡量标准。我们目前正在以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 

因此，我是敏捷的新手，但不是测试驱动的开发。我在大学里的教授都是关于测试的思想，然后是代码然后是测试。我不确定我理解为什么。从我的角度来看，随着代码的发展，很可能会改变很多前期成本。 这就是我对TDD的想象以及为什么让我感到困惑。如果我要作为TDD承包商来盖房子。 给我您所有的规格（故事）。 获得有关规格的批准。 将所有规格分解为我认为需要的检查（展望未来）。 打电话给检查员看一下这些要点，然后告诉我，我现在检查不及格（谢谢）。 开始盖房子。 每天召回检查员（通过2/100）。 抱歉，我的理解存在问题，现在我需要再添加9个检查并更改其中的27个。 呼叫检查员通过1/109。 该死的。检查员为什么不喜欢这个...哦，我更新了该方法名称... 建立更多。 UGGGGHHHH更多更改让我更新了该死的检查器。哦，我没有失败。 我做完了吗 好的，那可能有些古怪，但是直到我的代码在那里，我才看不到如何知道所有方法以及事情将如何工作。99％的时间我必须返回并以任何方式更新单元测试，并在添加时添加更多内容。似乎倒退了。 似乎更合适的是DDT或开发驱动的测试，这似乎是社区几乎忘却的事情。 据我了解，房屋的滴滴涕看起来像： 给我您所有的规格（故事）。 获得有关规格的批准并将其发布。 启动一个单元（基础）。 记下一些棘手的逻辑（注释）。 在开始下一个单元的最后，进行检查（创建测试）。 解决发现的所有问题，然后再次检查。 批准将本单元移至下一个。 如果我们都说实话，这听起来不是更人性化，而是集中在开发人员和业务上吗？似乎可以更快地进行更改，而且似乎不会产生开销的TDD。

74 agile  tdd  development-methodologies 

我认为，敏捷方法最适合需求模糊且需要大量交互以帮助塑造最终用户想法的项目。 但是...在我的专业工作中，我一直不停地被那些使用“敏捷”方法作为为什么不花精力在前期设计上的公司作为最终结果。当要求很容易理解时。 我忍不住想，如果没有敏捷方法，我会坐在这里，拥有一个很好的高级规范，而不必在第二天左右出现其他问题时隔天重新访问相同的屏幕和功能所以没有想到这一点。 敏捷方法学的好处真的足以超过给牛仔技术领导者带来la脚的借口吗？ 更新：具有讽刺意味的是，我现在是一名认证的Scrum Master。在Scrum课程上发表的一篇论文指出，最好的开发过程是只有一个专家或专家来进行设计决策的过程，但是它存在明显的弱点。Scrum将生产高质量软件的责任转移到“团队”，这意味着不合格的团队可以摆脱意大利面条的困扰，我想这与其他敏捷和非敏捷开发流程没有什么不同。

73 agile  cowboy-coding 

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

63 scrum  methodology  agile