Questions tagged «agile»

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

61 agile  project-management  scrum  requirements 

我在努力跟踪自己和团队中每一个人每天的实际工作。每周检查完已完成的卡片后，我会得到一个全面的了解，并且站立式会有所帮助，但是我觉得我对团队的日常工作没有很好的处理能力。卡片将连续数天保持运行状态，而每天的站立状态不会有任何更新，而且某些工程师是我的团队中沟通能力最弱的。 我已经考虑过实施某种日常记录，每个人都可以填写（通过邮件列表或共享的Google文档），但这似乎很繁琐且手动。 监视GitHub的活动可以很好地完成工作，但每天发送多少封电子邮件可能会使您有些不知所措。我曾经考虑过要为其构建摘要系统，但没有时间可以节省时间。 您实施了哪些策略以保持团队日常工作的最高级，从而可以评估“进行中”任务的工作量？

61 project-management  agile  time-tracking 

我已阅读《敏捷架构师原则》，其中定义了以下原则： 原则1：对系统进行编码的团队设计系统。 原则2构建最简单的可行架构。 原则＃3如有疑问，请将其编码。 原则4：他们构建，测试。 原则5：系统越大，跑道越长。 原则6系统架构是角色协作。 原则7：创新没有垄断。 该论文说，大多数架构设计是在编码阶段完成的，而在此之前只有系统设计。那也行。 那么，系统设计如何完成？使用UML？还是定义接口和主要块的文档？也许还有别的吗？

59 architecture  agile  large-scale-project 

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

56 agile  development-process  scrum 

错误已被打开，修复，验证和关闭。一个月后，它经过几次迭代，没有任何回归，再次出现在后续版本中。 如果错误特征相同，您将重新打开现有的错误ID还是使用链接到已关闭错误的链接打开一个新 ID ？

55 project-management  agile  issue-tracking 

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

55 agile  scrum  methodology  culture 

在为期2周的冲刺结束时，一个任务进行了代码审查，在审查中我们发现了一个功能正常，可读性强的功能，但它相当长且有一些代码异味。轻松的重构工作。 否则，该任务将符合完成的定义。 我们有两个选择。 代码审查失败，因此该票证不会在此Sprint中关闭，并且我们在士气上受到了一些打击，因为我们无法通过该票证。 重构只是一小部分工作，并且将在下一个冲刺（甚至在开始之前）中完成，只是一个很小的半点故事。 我的问题是：从审阅的背后提出票证而不是通过失败有任何内在的问题或考虑吗？ 我可以找到并已阅读详细代码评论的资源通常为100％或什么都没有，但是我发现这通常是不现实的。

53 agile  code-reviews 

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

52 agile  scrum 

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

52 agile  project-management  scrum  development-process 

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

51 agile  scrum  sprint  meetings  process-improvement 

并非一直在刻苦地配对编程，而是在团队中选择性地使用配对编程。我认为在以下情况下效果最佳： 加强项目中全新的团队成员（而不是让他们自己浏览文档或代码）。 初级和高级人员一起工作（有助于显示经验丰富的开发人员的一些技能和技巧，此外，它还允许老狗有时学习新的技巧）。 当某人试图查找缺陷时，通常可以帮助您与另一只眼睛配对。 什么时候使用配对程序，为什么？ 什么时候避免成对编程？为什么？

51 agile  pair-programming 

我只是想知道我们是否应该将故事点分配给错误修复任务。我们的问题跟踪软件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 

这一周的工作中，我又变得敏捷了。经历了标准的敏捷，TDD，共享所有权，临时开发方法，从未计划过一张卡片上的几个用户故事，口头上嚼了一个第三方集成广告恶心的技术，却从未真正做过思考或应尽的努力，并将所有生产代码与过去几个月来遇到的第一个测试在体系结构上耦合起来，我们到达了发布周期的结尾，并且发现我们一直在开发的主要外部可见功能太慢而无法使用，越野车，迷宫般变得复杂而完全不灵活。 在此过程中，“尖刺”完成了，但从未记录下来，也没有生产出任何单一的建筑设计（没有FS，所以，如果您不知道自己在开发什么，该如何计划或研究它？ ？）-项目是成对进行的，每个人一次只专注于一个用户故事，结果是不可避免的。 为了解决这个问题，我放弃了雷达，去了（可怕的）瀑布，进行了计划，编码，基本上并没有放弃这一对，并尝试了我一个人尽可能多的工作-专注于坚实的体系结构和规范，而不是单元测试。一切确定后，我们将在以后发布。该代码现在更好，并且实际上完全可用，灵活且快速。某些人似乎真的很讨厌我这样做，并且竭尽全力破坏我的努力（可能是无意识地），因为这违背了敏捷的神圣过程。 因此，作为开发人员，您如何向团队解释计划他们的工作并非“不敏捷”，您如何使计划适合敏捷过程？（我不是在谈论IPM；我是在谈论坐着一个问题，并草拟一个端到端设计，该设计说出应该如何充分详细地解决问题，以便从事该问题的任何人都知道他们应该使用的架构和模式，以及新代码应集成到​​现有代码中的位置）

50 agile  planning 

我们的开发部门确实希望执行更多的敏捷项目，但是在吸引客户方面存在问题。许多客户想要预算和截止日期。当我们的竞争对手提出基于瀑布的固定期限和固定价格时，很难在敏捷项目上出售客户。我们知道他们的固定号码不好，但是客户不知道。因此，我们最终对客户不利，因为我们无法确定价格或期限，但我们的竞争对手可以。 因此，如何使您的销售人员成功销售使用敏捷开发方法的项目或使用此类方法开发的产品？我发现的所有信息似乎都集中在项目管理和开发人员上。

49 agile