Questions tagged «agile»

我最近与一位开发人员就敏捷软件开发进行了交谈。虽然我理解该原理，但似乎不断变化的需求为该项目带来了持续发展的潜力。但是，至少在我工作的地方，项目需要完成，因为这是合同。 也就是说，第一次迭代可能需要几个月的时间，因为对于某些项目，客户不能使用不完整的应用程序。对于某些项目，我认为您需要先定义完成，然后可以将其分解为多个迭代，并在每次迭代后完善定义。但是您必须始终具有此定义。 如果敏捷软件开发包含不断变化的需求，您如何知道它的结尾？当最终结果总是变化时，您如何为项目预算？ 敏捷软件开发是否与敏捷产品有关，而不是与敏捷产品有关？

14 agile 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 我最近一直在面试合作社（带薪实习），而我面试过的许多公司都说他们使用Scrum或其他敏捷方法（scrum是最受欢迎的）。我知道那里有真正的敏捷商店，有些地方说他们使用敏捷方法论，但实际上是在做其他事情，并以敏捷作为流行语。 我的问题是，在面试中我会问哪些问题将这些商店分开？ 编辑：当我在寻找实习机会时，我觉得这些问题与每个人都息息相关。实习部分是情境。

14 agile  scrum 

我一直在为承包人工作，他们带来了一些好的项目，但是它们都是固定价格的，通常都是固定时间的。 因此，他总是让我为宽松的要求报价，因为功能不断变化，这种要求永远不会带来太大的压力。 他声称，如果他不能先与客户达成价格协议，他将永远不会获得合同，但是就我而言，我不想按照这些条款进行另一个项目。 我有什么理由让他按小时支付我的工资，还是我应该少估计一下？

14 project-management  agile  freelancing 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 在我目前的工作中，感觉我们有很多需求变更。我们是一家“敏捷”商店，所以我认为我们应该进行调整，而不能进行调整，但是有时候变化很大，没有什么微不足道的。 我的问题是，您如何有效地传达变更成本？由于敏捷，如果更改足够大，将会从当前的sprint中删除某些内容，但是通常只会在下一次添加。由于我们的模型是SaaS，因此最终客户实际上是企业本身，他们知道n周后将获得削减功能。 我想我要了解的是删除某项功能实际上并没有什么用，因为它仅延迟了n周。您还需要通过什么其他方式来使企业了解变更成本？

14 development-process  agile 

我最近加入了一家公司，在该公司担任Scrum主管，从事构建Web应用程序的敏捷开发项目。 该团队即将成为敏捷团队的最大规模（预计下周为9人）。我们已经讨论过将团队分成两个团队的潜在问题，不是为了缩短站立时间（目前还不过分），而是为了防止人们在sprint计划会议中完全感到无聊（这又不会太长）。 该项目有两个截然不同的层-高技术后端开发人员（例如非常复杂的开发人员）和UI设计/构建/集成。看来，当后端人员正在讨论技术时，UI人员会划分区域，反之亦然。如果只是为了提高时间效率，将团队拆分似乎是合乎逻辑的方法，但是我有一个很大的保留意见，就是我可能真正要做的就是减少协作和知识共享。这两个团队对团队其余成员的构建并没有真正的好主意。 有没有人有处理这样的事情的经验？

14 web-development  project-management  agile  web-applications  user-experience 

我正在阅读《极限编程说明》第二版，在第11章“约束理论”中，作者讨论了过时和过时的“推”开发模型以及XP方式（“拉”开发模型）。它看起来像一个非常重要的概念，但是只用了一个很小的段落和两个图像，它们只是“瀑布”和迭代过程的说明，除了图像标题外，这些模型没有其他具体说明。我进行了搜索，在本书的其余部分中对此没有任何进一步的说明。我也无法在Internet上找到任何进一步的解释或讨论。 如果关于它们的唯一区别是一个是“瀑布”而另一个是迭代的，那么它们为什么推，为什么拉？ 有人知道这两者之间的真正区别是什么，并举一些很好的例子吗？

14 agile  development-process  extreme-programming 

一些背景资料 我是内部软件开发团队的一员。它包括 5位开发人员（经验从2到5年不等，我是其中之一） 3名实施人员（他们进行软件部署和培训） 和一名项目经理。 我们开发了大量的中小型项目，它们的时间表通常重叠。开发过程如下： “客户”给我们提出了一系列初步要求 我们按照上述规范开发系统 向“客户”展示所述系统 “客户”根据上述介绍向我们提出了其他要求 重复2-4，直到“客户”用完新要求或部署目标日期临近 设置和部署系统 这与事实是，大多数情况下都是由“客户”来处理最后期限（这是一个危险信号，根据我在Programmers和PM.SE中的了解），我们没有遵循明确的开发方法牛仔编码，几乎不可维护的代码以及通过生产而产生的错误等。这就是为什么我们选择采用像Scrum这样基于敏捷的方法。 为什么是Scrum？ 这是我们经理的倡议，鉴于我们目前的情况，每个人似乎都对此表示同意。 Scrum的问题 Scrum的某些元素与我们目前无法轻松解决的设置存在冲突，特别是敏捷开发人员的“万事通”性质。部署团队不知道如何编程，开发人员的沟通和培训技能低于平均水平。而且这个阵容不会很快改变。 问题 它会影响Scrum作为一种方法的有效性吗？是否需要进行其他更改以补偿？还是完全放弃这种想法而考虑另一种方法会更好吗？

13 agile  scrum  methodology 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我曾经在瀑布方法中工作，现在我在一个遵循敏捷方法的团队中工作。看来他们做错了。例如，我们每天进行25分钟以上的站立训练，这确实很烦人。此外，我觉得自己比起其他任何事情都可以向管理层证明自己的薪水。 我有这种感觉吗？这通常是站立式的吗？

13 agile  scrum  development-methodologies  meetings 

假设您必须使用敏捷方法重写整个应用程序，您将如何做？ 我猜您可以根据当前系统的行为编写大量用户案例。然后以小的迭代形式实现它们。但这并不意味着我们具有UP FRONT的要求？ 另外，什么时候开始发布？敏捷说我们应该早并且经常发布，但是在完全重写完成之前发布并没有多大意义。

13 agile  scrum  software  extreme-programming  rewrite 

我曾在几家商店工作过，在这些商店中，管理层已经将结对编程的想法传授给我或另一位经理/开发人员，而我对此一无所知。从开发人员的角度来看，我找不到改用这种编码样式会有所裨益的原因，或者作为一个小型团队的经理，我都看不出任何好处。 我了解它有助于解决基本的语法错误，并且在需要散列某些内容时可能会有所帮助，但是不在编程循环中的经理们似乎一直将其视为阻止设计师进入Facebook或Reddit的一种方式，而不是设计工具。 作为一个接近开发层的人，从高级管理职位看来，我似乎根本无法理解被扔给我的书或有关该主题的Wiki页面，因此，结对编程在处理Scrum或Agile时有什么好处？环境？

13 agile  scrum  management  pair-programming 

我公司的另一个团队开始记录他们的站立会议，但是我认为这是浪费时间。据我所知，站立会议仅用于交流，不用于状态报告（如果我错了，请纠正我） 那么，我们应该记录站立会议吗？

13 agile 

在SE和其他网站上阅读所有这些“敏捷开发”内容时，我总是想知道一件事： 在“传统”软件工程中，您 收集用户的需求， 根据这些要求编写规范， 把它交给客户，并向他收取到目前为止已完成的工作的费用， 做一个（粗略的）技术设计，以便您可以估算实施成本， 为用户提供实施的价格报价， 等待客户签署规格书并接受报价， 设计，实施，测试， 法案。 如果在此过程中需求发生变更，则您发送所需变更的报价（有价格）（如果变更很小，则免费提供，您喜欢客户，而客户却不经常这样做） 。 那么，这在敏捷项目中是如何工作的（财务上），而频繁的需求变更是流程的一部分？ 您是否为每次设计变更都写报价？（这不是很乱吗？） 还是您协商固定价格并希望客户不要经常更改要求？（可能会有风险，我知道客户会在接受该项目完成之前利用这个机会请求多年的新功能。） 还是只向客户收取所需的总时间费用？（对于事先不知道成本的客户可能会有风险。）

13 agile  business  financial  changes 

如果您为冲刺计划了许多用户故事，而一个候选故事则取决于某个外部提供商向您的团队提供一些东西。例如，在线服务提供商向其系统添加新的API调用，或在其系统上启用您的测试帐户等。 您知道即将来临。 您是否继续将故事添加到sprint中，希望他们能及时提供您完成故事所需的内容，还是等到下一个sprint，当您知道故事已经准备好就可以立即开始就算这意味着不及早开始故事。 如果是前者，您如何处理由于依赖性而失去的“无知的”故事点？部分信用（eek！）或放在下巴上。

13 project-management  agile  scrum  planning 

我离开了一份工作（搬到另一个国家），大部分时间我都使用Javascript和Haskell（某些python）进行编程。我真的很喜欢它，因为人们是客观，积极，数学的，却做了很多事情。这是一家真正的专业商店。 现在，我在一家敏捷/ XP商店工作。虽然这很好，但我觉得在选择技术和库时也许我们并不专业。我觉得我们编写软件的方法还有些不成熟且没有结构。我正在尝试阅读我提供的书籍，它们似乎鼓励这种风格（ugh）。很多时候，我们只是从git hub中摘取libs并使用它，而没有进行任何类型的审查。 即使对一个人来说这是一件小事，我也总是被迫与某人一起工作。即使规则可以被琐碎的反例破坏（每次我都误以为给出反例而被口头攻击），似乎所有事情都有一条“快速”规则。在美国，这正常吗？我该如何处理这种教条主义？

13 ruby  haskell  agile 

我所工作的公司正在努力地迈向敏捷项目管理策略-一次又一次地体验了瀑布的“欢乐”。这样做的关键是将重点转移到交付功能上，而不是满足艰巨的截止日期。 尽管通过敏捷开发的迭代发布肯定会改善开发过程和客户关系，但事实证明，将相同的原理应用于该项目的融资策略更加困难。客户通常不习惯诸如敏捷之类的概念，并且对他们认为“准备就绪后就会准备就绪”的情况表示极大的关注。 我想听听人们在资助敏捷项目方面的想法和经验 编辑： 我想强调的是，我不是在要求人们向我解释敏捷方法的优缺点，也不是我相信敏捷等同于“准备就绪后就会准备就绪”，这是由我提倡敏捷开发实践时曾与之合作的客户/企业。 我感兴趣的是人们解决了根深蒂固于业务客户/关系中的“传统”瀑布式预算方法与更先进的开发方法之间的冲突的经验，以及他们为支持这种演进而采用的预算策略。

13 agile