Questions tagged «agile»

我在读敏捷宣言原则。除以下几点外，一切似乎都清晰合理： 简单性-最大化未完成工作量的艺术-是必不可少的。 我不明白这一点。这是否意味着应该以某种方式夸大未完成的工作？如果是这样，那真的没有意义。

24 agile  management 

我经营一家只有2个开发人员的小公司。我们正在为我们的一位客户构建非常大的应用程序。这个项目的开发已经进行了1.5年。 现在，该客户已获得了重要的赞助，他们正在组织与此项目有关的活动。所以现在我们有两个月的截止日期，我们不能错过。 我们正在考虑向团队中添加新的开发人员，我想知道我们能做些什么来帮助他整合。 这种情况： 我们正在接近布鲁克斯法则的门槛-添加新的开发人员将适得其反。 该应用程序的设计相对较好，但是在某些方面（尤其是较旧的代码）的实现是混乱的。 仅对最新代码进行单元测试。这个项目开始时，我们没有定期进行测试。 文档和注释不完整。 该应用程序既大又复杂。 客户以一种非常清晰且“程序员友好”的方式写下了有关其项目的几乎所有细节。 现在添加一个人是个好主意吗？如果是这样，我们应该怎么做才能帮助新开发人员融入团队？ 编辑： 赞助商将在明年春季组织基于互联网的体育赛事。它必须在一年中的特定日期开始。我们无法更改。 我们的开发人员（我是两者之一）需要做的是： 完成现有的应用程序（大约需要完成的工作的25％）。 创建一个新模块，对于组织此次活动至关重要（大约需要完成的工作的75％）。如果不了解主程序的API，就无法开发此新模块。 我无法准确估算时间，但我们处于危险境地。

24 project-management  agile  teamwork  estimation  knowledge-transfer 

前面的敏捷讨论在这里有很好的答案，指出了对于在软件开发中成功实施敏捷方法学至关重要的因素。大多数要点是典型的组织和管理挑战，但我要担心的一点是，在整个过程中必须让客户参与。 客户是您无法实际控制的一件事，也许您的商业模式使您适应政府签约的工作，例如，严格的合同迫使公司必须： 完全按照要求提供X功能 功能请求将被扔在墙上，不要打扰我们，我们不想听到它。 客户心中没有优先功能的概念，它们都很重要，或者我们不会要求它们。 无论超支或截止日期如何，该项目的成本都不会超过Y，且不得低于Y。 完全交付所有工作的绝对，严格，最终和不可协商的截止日期。 我们以前从未与这样的客户合作过，但是该项目的资金实在太可惜了。我们需要这项工作。 我来到这里工作是在HARD上更改流程，以朝着敏捷开发方向发展，在这里，我不知道如何协调该项目适合我们新流程的位置。我从来没有像现在这样拥有过开放式的手动管理能力，这使我相信可以领导开发团队并沿着这条道路前进，而现在我们在这里，我不能诚实地告诉自己，这个项目将真正在敏捷的方式。我觉得管理层相信我可以带领这条路走下去，并且让他们失望，因为我们现在所处的这种情况非常明确地要求瀑布。恐怕如果我现在回溯，我可能会失去他们的信任。 其他答案，例如这里所说的，对于这种客户来说，敏捷是不可能的，您同意吗？你们有没有遇到过类似的情况并使它工作？您实施了哪些策略来使敏捷成功实现？

24 agile  requirements  government 

我公司中的某人最近提出了对核心产品的更改，经理们认为这些更改应触发我认为我公司认为完整的质量检查周期（即，从头开始测试整个产品套件）。显然，我们的质量检查需要12周才能完成产品的完整质量检查周期。我的问题是我们正在尝试进行敏捷开发（尽管在我看来，这大多是半估的）。我们将完成一整套冲刺，然后发布，我想质量检查将永远花费那一次。问题是，如果我们的质量检查要花12周才能完成工作，我们是否就应该放弃尝试敏捷开发？在这种情况下尝试敏捷的意义何在？

24 agile  qa 

因此，您已经多次从不真正了解测试价值的人那里听到过。刚开始时，我是敏捷和测试的追随者... 我最近在讨论有关在产品重写上执行TDD的问题，其中当前团队不进行任何级别的单元测试，并且可能从未听说过依赖注入技术或测试模式/设计等（我们什至不会继续清理代码）。 现在，我对产品的重写负全部责任，并被告知，以TDD的方式进行尝试，只会使它成为维护的噩梦，并且对于团队维护来说是不可能的。此外，由于它是一个前端应用程序（不是基于Web的），因此添加测试是没有意义的，因为业务驱动力发生了变化（通过更改当然意味着有所改进），这些测试将过时，其他开发人员将来的项目将无法维护它们，并且将成为它们修复等方面的负担。 我可以理解，在目前没有任何测试经验的团队中，TDD听起来并不好，但是在这种情况下，我的观点是我可以向周围的人教我的实践，但更进一步，我知道TDD会让您变得更好软件。即使我要使用TDD来生产软件，并抛弃所有测试以将其交给维护团队，与从一开始就完全不使用TDD相比，这肯定是更好的方法吗？ 我被提到在一个从未听说过的团队的大多数项目中执行TDD时被击落。“接口”的想法和外观奇特的DI构造函数使他们望而却步。 在尝试出售TDD的简短对话中，有人可以帮助我吗？在屈服于公司/团队之前，我通常会有一个简短的辩论窗口。

24 testing  agile  tdd  bdd 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我淹没在用户电子邮件中，我想采用一种更好的方法来管理我收到的所有这些请求，并将它们排在队列中，以便团队中的这些人员以及用户可以访问它们并可以使它们变得通用笔记。我正在考虑某种任务管理工具，该工具将允许在一个项目中创建多个任务，在该项目中可以删除/输入电子邮件，评论，想法等，并且易于访问。 我需要各方都能参与的工作-用户，经理，团队负责人，开发人员。我正在寻找一种可以允许的工具： 用户只需拖放电子邮件即可提交维护或增强请求。 开发人员只需查看他们的队列和每个任务/项目的加权优先级即可。 一组开发人员可以实时查看每个人的工作。 管理层要保持在每个任务上花费的时间日志。 我正在开始寻求更多的敏捷/敏捷方向来解决这个问题。我找到了Scrum敏捷软件项目管理开源工具列表。由于时间有限，有人使用过这些吗？我应该测试哪一个来满足我的需求？TeamPulse是一个很好的方向，但认为它有点too肿。我需要所有各方简单的东西。

24 project-management  agile  scrum  issue-tracking 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 我正在为最近刚入职的一些新手编写敏捷课程，并且我想补充一个警告性的故事，以便他们理解敏捷并不适用于所有项目。 我的问题是，由于到目前为止与我合作的项目的性质一直很好，所以我不能坦诚地说出可能出问题的原因以及在错误类型的项目中使用它的原因。 敏捷项目出错时要注意什么？

23 agile 

有时在项目中，我们需要花时间在以下任务上： 探索替代框架和工具 学习为项目选择的框架和工具 设置服务器和项目基础结构（版本控制，构建环境，数据库等） 如果我们正在使用用户故事，那么所有这些工作应该去哪儿？ 一种选择是使它们全部成为第一个用户故事的一部分（例如，制作应用程序主页）。另一个选择是对这些任务执行加急操作。第三种选择是使任务成为问题 / 障碍（例如，尚未选择的开发环境）而不是用户故事的一部分。

23 project-management  agile  scrum  user-story 

已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 在过去的4.5年中，我一直在企业领域中工作，并且注意到，一般而言，企业对于测试优先的开发风格不是一个有利的环境。项目通常是固定成本，固定时间表和瀑布式的。任何单元测试（如果有的话）通常都在QA阶段开发后由另一个团队完成。 在为企业工作之前，我曾为许多中小型公司提供咨询服务，但没有一家公司愿意为测试优先的开发项目付费。他们通常希望开发立即开始，或者经过短暂的设计工作：即，类似于敏捷的东西，尽管有些客户希望将所有东西都映射为类似于瀑布的东西。 在哪种类型的商店，公司和客户中，测试驱动的开发最有效？哪些类型的项目倾向于有利于TDD？

23 testing  agile  unit-testing  tdd 

我无法写有关敏捷的书。我曾在几家称为敏捷流程的商店工作过。敏捷开发的要点之一是定期的客户参与。经过冲刺，可以将作品演示给客户以获取他们的反馈。冲洗并重复。 我遇到的问题是，许多客户不想参与其中。他们将更喜欢瀑布方法。预先收集需求，然后在完成后再回来。以我的经验，瀑布不起作用。客户直到看到他们才知道他们想要什么。瀑布式的困境由希望提前满足所有要求的大量开发人员进一步传播。这样，他们便知道要构建的内容，可以相应地进行架构设计，而客户应对此负责，因为他们“拒绝”了上述要求。 我不正确吗？无需客户参与就能敏捷工作吗？如果是这样，您如何以及如何克服我所讨论的问题？

23 agile  waterfall 

我是敏捷团队的开发人员，我们尝试使用Scrum。 因此，我将在此处提出一个假设问题来说明这种情况。 我们有一个非常老的应用程序，使用了一些凌乱且糟糕的可维护性JQuery代码。我们也有部分使用React的应用程序，这些部分更易于更新/维护。除此之外，公司的目标是在React上开发一个客户端单页应用程序，因此使用JQuery可以使您走得更远。 在进行规划时，我们总是会在开发时间方面寻求简单的解决方案，因此例如，如果我们要创建新对话框或其他内容，我们会使用旧的JQuery，因为它的速度更快，并且我们说我们要回去后来整理并转化为React，但这很少发生。 我们从用户故事中获得了我们必须做的事情的要求（IMO做得很好，虽然很苗条，但是它们可以解释我们在做什么，以及为什么要这样做）。 有时，对新功能的要求非常渺茫，例如，如果某个要求说“创建一个加载大量内容的对话框”却没有说要实现加载功能，那么在大多数情况下，我们不会实现它，尽管我们都知道这对客户会更好，因为这样做可能会损害我们的sprint目标（即使我个人认为不会）。 结果是我们的代码库混乱不堪，可维护性很差，并且新功能有时非常小，需要花很多时间（在良好的代码库中一天就可以实现），这主要是因为此开发策略，快走，做到极简。 在这种情况下，我们做错了什么？我们是否应该以更完整的方式解决解决方案，以便我们不浪费编写糟糕的代码并重写上周刚刚编写的代码？还是应该确保仅重写所有代码，就继续这样做？什么是解决此问题的敏捷方法？

22 agile  scrum 

最近，在我公司中，有人建议一位开发人员应该（仅一位）专注于一项功能。这意味着要像将开发人员置于正常的团队常规工作之外，再将其承担其他职责（会议等），而此人将是负责该功能（技术上明智）的“唯一”人员。 作为记录，我们在SAFe中使用SCRUM，并且每个团队都有专职开发人员，在我们两个团队（Android和iOS）之间共享质量检查和产品所有者。 尽管我同意这会在短期内提高生产率，但我有一种感觉（我认为我是在大学里学到的），这是一个不好的做法，原因有很多： 代码审查失去价值。 最少的知识共享。 风险增加。 失去团队灵活性。 我说的对吗，或者这不是一个坏习惯？

22 agile  team  code-ownership 

如果直到冲刺结束才完成全部或大部分编码，如何在与编码相同的冲刺中处理测试？（我指的是冲刺中单个PBI的“汤对坚果”开发和测试。） 我在网上看到的大多数答案都涉及QA自动化，但这实际上是不可能的，因为您通常需要功能性UI来记录或创建自动化测试。我只有故事板随着我开发功能和发现新需求而不断发展。 就我而言，我正在开发一个新的桌面应用程序。桌面应用程序通常无法很好地进行自动化测试。我有一些自动化的单元测试，但它们不是QA专业人员执行的手动功能/集成测试。 因此，我现在的状态是明天的sprint结束，我仍然需要完成编码，而且我的质量检查人员还没有要测试的东西，也不知道如何测试如果不握住我的手给我的东西。 我确定我不是第一个遇到这种困境的人。 过去，我做过一个管道：在当前的sprint中，测试团队测试在上一个sprint中已实现的功能。在我目前的工作中，PM将这种方法称为“瀑布”，因此是不可接受的。

22 agile  testing  unit-testing  scrum  qa 

据我了解，敏捷方法论的思想是，您交付的是功能性的东西，并且您经常交付。递增后，应用程序进入其最终形状递增。 但是在早期的迭代中，您可能会构建应用程序所依赖的框架或基础，因此它很重要，但对用户不可见。 在这些最初的迭代中，什么交付给客户？在构建脚手架代码时，如何显示正确方向的进度？

22 agile  development-process  frameworks  development-methodologies  iterative-development 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 6年前。 我已经遇到过几次挑战，希望有人可以提供一些参考，培训或建议，以帮助您解释产品待办事项与TFS中的任务之间的区别。 我了解并已经说明，产品待办事项是“什么”，任务是“如何”。我还解释了PBI是要求，而Task是如何满足要求。 当我解释这一点时，我反复遇到空白的凝视和头部抓挠。看来我所解释的软件工程师无法区分。对他们来说都是一样的。 我相信我的另一个挑战是，我无法有效地说明为什么区分这一点很重要。

22 team-foundation-server  scrum  agile