Questions tagged «agile»

我们是一个由大约200名开发人员组成的组织，他们正在不断开发单个产品（使用版本控制Git），并计划在某个日期发布该产品。 由于开发人员数量众多，我们正在尝试创建“跨职能”团队，每个团队中约有10个开发人员，因此组织中大约有20个开发团队。 由于我们希望在主存储库中保持产品的连续“高标准”（意味着当开发人员进行拉动时，产品至少应是可编译的，等等），因此我们想使用某种质量保证。 我不太确定如何表达这个问题，但是我想知道是否可以为如此大量开发单个产品的开发人员提供一些开发方法的建议。 我们认为，范围的一端是允许每个开发人员直接提交到主存储库，但是我们担心由于开发人员/提交的数量过多，“主存储库”可能一直处于崩溃状态，这是由于我们不能为每次提交都提供苛刻的“质量门”。 频谱的另一端可能像是树或金字塔结构（我们认为是Linus Torvalds / Linux做到了），其中“主存储库”仅具有三个拉取源，这三个仅具有少数受信任的拉取源，依此类推但是，我们认为，采用这样的结构，为了进入“主存储库”，更改需要爬很长的链。另外，如果发生合并冲突，问题将落在“原始开发人员”之外的其他开发人员上。 陈述了所有这些背景信息和意见后，我们如何才能学习和阅读针对众多开发人员的推荐开发方法？大型组织（Microsoft，Facebook，Ubuntu等）如何组织其发展？

19 agile  workflows  software  development-methodologies  gitflow 

我在Pivotal Tracker板上添加了一些解决一些技术问题的用户案例。我应该将它们视为特征（保持速度水平）还是杂务/虫子（降低速度）？我知道，如果我坚持一贯做下去，从长远来看不会有任何区别，但是每次我添加技术债务的故事时，我都必须做出决定。 一些想法： 它们实际上不是错误，它们不会破坏任何东西 用户没有要求任何东西，因为它是不影响他们的低级实施，但是它将使长期开发变得更容易 如果您将功能定义为能够为用户增加价值的故事，那么a）他们不会，因为用户不会看到任何直接的利益，但是b）它们会这样做，因为它们使将来的开发/维护成为可能，从而确实可以增加价值，只是现在不行 我不决定是否真正进行这项工作，或何时安排它，我只是想知道我应该在项目管理工具中称其为技术债务的原因，以及原因。

19 project-management  agile  technical-debt  kanban 

我们在项目中关注scrum。我经常看到Scrum管理员为我们分配任务。但是，我从许多Scrum书籍中读到，Scrum的工作方式相反（“拉动”方法），团队成员负责任务或功能。Scrum Master分配任务是正确的方法还是违背了敏捷思想？

19 project-management  agile  scrum 

有人告诉我“用户故事不是需求，它只是在提醒客户需要什么，您不能在故事中放入需求”。但让我们举一个例子，客户希望对不同的信用卡进行不同的处理。必须执行并知道严格的要求，以便可以编写测试用例。如果不在用户故事中，需求应该去哪里？ 如果没有更低的要求，开发人员如何从故事中发展？测试人员如何根据用户故事编写测试用例（详细的用例）？用户故事之外还存在DB约束，字段验证等需求吗？

18 agile  scrum  requirements 

在我们的项目中，我们采用零缺陷（也称为零缺陷）方法。基本思想是，错误的优先级始终高于功能。如果您正在处理一个故事，并且有错误，则必须解决该问题才能使该故事被接受。如果在sprint期间发现了较旧的故事中的错误，我们需要将其放在待办事项列表上并加以解决-最高优先级。 我说解决的原因是我们并不总是修复该错误。有时我们只是宣布它“不会修复”，因为它并不那么重要。总而言之，这听起来很棒。我们正在运送高品质的产品，并且不会以积压大量错误的形式出现“驼峰”。 但是我不确定这种方法是否正确。我确实同意，我们总是需要尽快修复严重的错误，并且需要丢弃无用的错误。但是重要但不如新功能重要的错误又如何呢？我倾向于认为应将它们以适当的优先级提交待办事项清单。 为了使它更清晰，我将举一个示例-在我的项目中，我们使用用flex编写的UI。我们有一个向导屏幕，它以每种屏幕分辨率打开的大小相同。事实证明，当我们扩展向导窗口时，其中一个页面看起来并不好（虽然向导现在可以显示所有内容并且不需要滚动条，但是垂直滚动条并不会消失）。我认为这个错误很难看。我确定它一定要修复。但是我们的时间表很紧，我们有很多功能，我们担心这些功能不会成功并进入发行版。我觉得我们可以忍受这样的错误。它确实需要修复，但是优先级低于其他功能（因此，如果我们无法完成它，至少我们没有遗漏更重要的功能）。但， 我很想听听有关如何管理我不想标记为“无法修复”但也不是最重要的错误的意见。

18 agile  scrum  bug  backlog 

在最近对Scrum进行激烈辩论之后，我意识到我的问题是我认为管理对于完全敏捷的团队来说是非常不必要和多余的活动。我相信成熟的敏捷团队不需要管理或任何非技术性的决策过程。在我看来（显然犯了错误）的眼中，唯一合适的，能够管理一支成熟的开发团队的人就是他们的教练（他是技术上最胜任的，具有适当沟通能力的同事）。我无法想象Scrum大师如何为这样的团队做出贡献。 作为一名经验丰富的开发人员，当团队中有一名教练时，我不是一个经验丰富的开发人员，但却善于计划生产周期，因此我很难在Scrum和经理中实现和理解这些东西的价值。那有什么意思？没有发展技能的人到底如何管理一支技术含量高的团队？也许这里的管理意味着其他？ 我认为管理是浪费时间，是不成熟的副产品。以我的理解，一个成熟的团队完全可以自我管理。显然，我错了，因为很多伟大的人都说了相反的话，但我无法说服自己。

18 agile  scrum  management  extreme-programming 

我在项目中主要使用了瀑布方法，但是现在我将眼光扩展到了敏捷方法中。到目前为止，从我读过的东西（也许我读错了东西）来看，敏捷意味着小瀑布。您不用持续一到两年的大瀑布，而是可以持续几周或最多几个月的小瀑布。 我的理解是正确的还是不仅仅如此？敏捷哲学是什么？

18 agile  development-process 

最近，产品负责人已将一个项目添加到产品待办事项列表中，该项目显示“当我从x页面转到登录页面时，我看到一个错误。我希望删除该错误”。 在我看来，这不是用例，也不应该是PBI（产品积压项目）。但是，当我讨论它时，Scrum管理员告诉我用户故事不是PBI，而PBI可能是错误报告，任务，用户故事，任何东西以及实际上应首先解决的任何项目。 我对此不确定。而且我在网络上找不到很好的PBI定义。因此，我的问题是，什么样的事情可以作为项目进入产品待办事项列表？产品积压项目是否映射到用户故事？他们是一样的吗？

18 agile  scrum  definition  product-backlog 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 “跨职能团队”的一般含义是将达到目标所需的不同领域的专家组合在一起的团队。 但是，在敏捷看来，跨功能意味着不仅要合并不同的专家，还要使他们混合在一起。Henrik Kniberg 以此方式定义了跨职能团队：“跨职能团队意味着整个团队拥有构建产品所需的所有技能，并且每个团队成员都愿意做更多的事情，而不仅仅是他们自己的事情。” 但是线在哪里？是否要求开发人员成为测试人员进行迭代是否正常？

18 agile  team  organization 

我想改善我开发软件的方式。我想开发更快的代码！今天，我使用瀑布方法作为自由职业者，编写Web东西（站点，系统等）。有没有办法使用以这种方式工作的敏捷开发（XP，SCRUM等）？我对敏捷开发一无所知，应该从哪里开始？非常感谢你。

18 agile  freelancing  scrum  web 

在创建工单时间估算时，应在工单估算中包括测试人员（QA）花费的时间吗？以前，我们一直在估计没有测试人员的时间，但是我们正在谈论总是将其包括在内。对于我们当前的sprint（发布前的最后一个）而言，这很有意义，因为我们需要知道一星期后的总时间。 我一直都知道估算只是为了开发人员时间，因为这往往是团队中的限制资源。一位同事说，无论在测试人员时间之前在哪里工作，也都包括在内。 需要明确的是，这是针对开发人员编写覆盖面广的单元测试，集成测试和UI测试的过程。

17 agile  scrum  estimation  qa 

在我的公司中，我们成功地采用了敏捷实践，但没有使用迭代。主要原因是我们找不到在迭代周期中适合QA的干净方法。 我们认为质量检查是对特定版本（候选版本）进行额外验证的一部分，然后再将其部署到客户。关键是要避免单个恶意提交会损坏整个发行版。由于您永远都不知道它是哪一个，因此质量检查人员必须等到该版本的所有功能/提交都在构建中。（不允许使用著名的最后一句话“这只是微小的变化”。） 如果质量检查人员在候选发行版中发现错误，则开发人员会在相应的发行分支中修复这些错误（并将其合并到主干中）。修复所有错误后，将部署新版本以进行质量检查以进行重新测试。仅当在某个发行候选版本中未发现错误时，才将其提供给客户进行验证。 每次发布通常需要大约2-3个候选人，大约一周。编写修补程序的时间通常比测试工作要少得多。因此，为了让开发人员忙，他们在版本N + 1上工作，而质量检查则在N上工作。 不使用迭代，这没问题，因为我们可以将版本N和N + 1的工作重叠。但是，据我了解，这与Scrum或XP等基于迭代的方法不兼容。他们要求在迭代结束时发布一个迭代，并将所有测试工作都包含在迭代中。 我发现这必然导致以下不良结果之一： （A）开发人员在迭代结束时处于闲置状态，因为质量检查需要时间来验证发布候选版本，并且错误修复工作并未完全使开发人员处于忙碌状态。 （B）质量保证在准备好第一个候选版本之前就已经开始工作。这是Stack Exchange上最推荐的方法。但这不是我公司所理解的质量检查，因为没有经过测试的特定候选发布版本。破坏一切的“微小变化”仍然可以被忽略。 （C）错误将继续进行下一次迭代。在Stack Exchange上也建议这样做。我认为这根本不是解决方案。从根本上讲，这意味着我们永远不会获得经过验证的内部版本，因​​为只要进行了错误修复，就会将未经验证的新提交也添加到同一分支中。 有没有办法摆脱这种困境？

17 agile  teamwork  qa  sdlc 

我的雇主（不是开发人员）认为CASE工具将帮助我们改善开发流程和文档。我不确定这一点，我们是一个由5个开发人员组成的小组，为本地客户构建移动银行解决方案。我认为CASE工具需要购买，将浪费时间和金钱，而且我们需要一些时间才能习惯它们并有效地使用它们进行建模和填充。代码生成是另一个问题，我真的认为CASE生成的代码不如优秀开发人员编写的代码好。 我认为，如果我们坚持敏捷原则，设计模式，使用TDD并保持代码干净。我们应该很好。至于分析和设计，我认为白板上的简单UML图应该可以解决问题。文档既好又重要，但应尽量减少，而且我们不应该只关注文档而忘记代码。这就是我的想法。 我对么？还是应该听我的雇主并开始研究合适的CASE工具？

17 agile  development-process 

我们有一个项目，每个人都说我们将以敏捷的方式进行，但是我怀疑我们已经清楚地了解了什么是敏捷。 在以前的项目中，我们召开了计划会议，然后定义了产品积压日志，并在2至3周的冲刺中将工作分配给了开发人员。每天早晨，我们都会召开Scrum会议（每次似乎要进行1/2小时的时间），然后每个开发人员都继续进行。在sprint结束之前几乎没有人编写任何测试，并且未完成的工作被添加到下一个sprint。 开发人员几乎没有互相交谈，开发也没有涉及TDD。实际上，大多数开发人员在开始时就有一个规范，并且只是在为冲刺计划的2或3周内着手进行。与客户/利益相关者几乎没有任何沟通。 质量检查通常在几个月后才参与，到那时，我们发现缺少要求，这进一步增加了我们必须做的工作量。显然没有反馈回路。 所以我的问题是，我们哪里出错了，如何防止团队犯同样的错误。

17 agile 

让我们假设一个由四个开发人员组成的团队正在构建应用程序的情况。在测试阶段，错误由用户报告。谁应该修复它们？提交错误代码的人，还是有空的人？ 敏捷开发（scrum）中首选的方法是什么？

17 agile  debugging