Questions tagged «agile»

敏捷的新手，我不确定如何开始。这个想法是在sprint中创建项目的一小部分。但是，我正在处理的项目需要一个数据库，并且该数据库必须具有几乎可以正常运行的功能才能对该项目执行任何操作。 那么，敏捷项目如何处理这个问题，首先要创建数据库吗？ 您将如何操作，例如，如果使用Scrum，您将如何处理用户故事并测试数据库。 您是否愿意在还需要代码的故事中做数据库的一部分。 假设您有一个故事“作为用户，您必须能够注册...”，您是否会在数据库中创建user表作为该故事的一部分？ 敏捷如何帮助您设计数据库？

12 agile  database  scrum  database-design  user-story 

我对一位不了解迭代开发的高级主管有疑问（更不用说敏捷了）。他坚持要在编写任何代码行之前先完成我们的软件设计规范（SDS）。对他来说，完整意味着所有功能细节都在那里。另外，作为一名前Cobol程序员，他希望查看“模块”和流程图。这是一个Java Web应用程序，可大声喊叫！ 无论如何，我试图找到一个简单的位置来轻轻地指点他，以表明在开始编码之前SDS不一定是100％完整的（也不能完整）。有什么建议？ 谢谢！

12 design  agile  specifications 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 在我的团队中，我们不进行正式的代码审查。我们倾向于认为使用结对编程和经常旋转结对就足够了。 我们应该考虑进行正式的代码审查吗？有什么好处？

12 agile  code-reviews  pragmatism 

在我的公司（拥有3年历史的网络行业初创公司）中，我们的产品团队经常遇到这样的问题：“哦，现在这是一个危机补丁！” （不是每个人吗？） 这会影响包括自我在内的工程人员的生产率（和士气）。管理层花了一些时间思考如何减少这些当日请求的频率，并提出了我们每周都会发布的解决方案。（以前，我们每两周进行一次，通常会拖延几天左右。） 有13位开发人员和6位本地/ 9位离岸测试人员；从理论上讲，只有4个开发人员（和所有测试人员）才能处理偶数版本的发布，除非要完成的工作确实需要其他开发人员中的一些专门知识。每个周期将包含两天的开发工作和两天的质量检查工作（加上1天的范围界定/分类/ ...）。 我的问题是： （a）在这个发布周期的长度上是否有人有经验？ （b）是否有人听说过试图释放的时间如此长？ （c）如果是（a）或（b），您在地球上如何运作？（也应避免任何陷阱，以此类推。） （d）如果这项努力失败了，我们如何才能使损害最小化？

12 agile  quality  release-management 

Scrum团队 3 x开发人员 2个测试仪 1 x自动化测试分析师 我们不是一个多功能的团队，因为开发人员不进行测试，测试人员也不进行开发。我相信这是问题的根本原因。 我们目前进行两周的冲刺。 冲刺开始时，每个人都很忙，开发人员开始开发工作，而测试人员正在准备测试（编写测试用例等）。 一旦测试人员完成了准备工作，他们现在正在等待开发工作完成，或者开发工作已经完成，开发人员正在等待反馈/错误。 开发人员在这里发痒，开始处理积压中当前冲刺之外的项目。这产生了一种奇怪的影响，即我们总是在当前的Sprint中开发下一个Sprint。对我来说，这感觉不对。 从管理层的角度来看，他们宁愿开发人员做工作，也不愿坐在办公桌前不做任何事情，但与此同时，我觉得Scrum团队的目标和重点应该完全放在当前的sprint上。我希望我们的团队是多功能的，但不幸的是这是无法实现的。测试人员没有进行开发工作所必需的技能，并且大多数开发人员都认为测试在他们之下。 这是Scrum中的问题吗？有针对这个的解决方法吗？Scrum仅与多功能团队一起工作吗？ 如果可能的话，我想知道其他人的经验:)

12 agile  scrum 

我是一个相当大的敏捷团队的软件开发人员（我们有8个开发人员积极地对单个代码存储库进行更改）。每隔两周，我们会将软件的新版本投入生产。这是我们当前的工作流程： 在开始新任务时，开发人员在主开发分支（我们使用git）的基础上创建一个“功能分支”，并在此新分支上工作 开发人员完成任务后，将其功能分支合并回开发分支 开发人员将开发分支合并到质量检查分支。 质量检查分支会触发构建。此构建的输出已部署到我们的QA环境中，以允许测试人员开始其测试。 对于我们的测试人员来说，发现这些已合并到QA分支中的新功能的问题很常见。这意味着在任何给定的时间，QA环境都可能包含一些新功能-一些经过测试且没有错误，还有一些已损坏。这使得发布变得困难，因为很少有QA版本处于生产就绪状态。 为了减轻这种情况，我们一直试图启动“质量检查冻结”，这意味着开发人员在发布前几天不会将我们的开发分支合并到质量检查分支中。质量检查环境的错误修复程序直接在质量检查分支中进行，并合并到开发分支中。从理论上讲，这使新的，已损坏的功能无法进入质量检查，同时仍使我们能够解决质量检查中已有的问题。 虽然“质量检查冻结”的概念已部分成功，但很难进行协调，人们常常对是否允许其合并到质量检查中感到困惑。设置“ QA冻结”截止日期也很困难-每个人都喜欢在冻结和发布之间留出一些喘息的想法，但是实际上，他们宁愿在下一个发行版中发挥自己的功能，也不愿遵守截止日期。 是否有更好的方法来确保我们每两周发布一次新版本？

12 agile  version-control  development-process  branching  release-management 

我在一个由4个开发人员组成的小组中工作。我们正在实施的Agile版本似乎每周又一周不断给我们带来同样的困难，我正在寻找可以帮助我们改善流程的建议。 背景： 我们通常进行2周的冲刺，而每次冲刺都容易低估我们的工作，并且由于进度落后，我们与经理发生了麻烦。 我们从开始每个冲刺开始，将任务经理为我们创建的故事分配出去。有时他也会抛出任务，我们会估算它们。我们不使用故事点。我们使用Urban Turtle软件来“管理我们的冲刺”，这实际上只是故事和任务以及相关的消耗。我们不打算在冲刺结束时发布版本。 发生的最常见问题是，我们计划在sprint的开头执行一项任务，只是发现它的范围要大得多，但是优先级仍然很高，因此我们需要在它上面花费更多的时间。第二个最常见的问题是我们当中的一个人遇到了技术问题，该问题减慢了燃烧的时间，造成了障碍。 提供给我们的唯一建议是更加主动地调整估计值，并在早上的站立训练中提供更新，以便我们可以调整所需的额外时间。 但是，我们的处理方式似乎存在根本性的错误。经理对项目的期望与对冲刺的期望之间可能存在脱节。因为我们正在根据项目计划进行这些sprint迭代，所以扩展sprint或推迟项目会破坏项目计划。因此，作为开发人员，我们被鼓励通过在必要时扩展估计值来执行敏捷，而且还要按时完成冲刺，这令人困惑。 这不是一个不常见的问题，所以我希望比那些聪明的人提出一个或两个建议，说明我们如何才能在每次冲刺时都不再遇到相同的问题。真令人沮丧

12 agile 

我是一个由4个开发人员组成的项目团队，其中包括我自己。我们一直在讨论如何处理单个工作项中出现的额外工作。 这些额外的工作通常是与任务稍有相关的事情，但并非总是必须达到项目目标（可能是一种观点）。示例包括但不限于： 重构工作项更改的代码 与项目更改的代码相邻的重构代码 重新设计票证周围较大的代码区域。例如，如果某个项目要更改单个功能，那么您意识到现在可以重做整个类以更好地适应此更改。 改进刚修改过的表单上的用户界面 当这笔额外的工作很少时，我们不在乎。问题是，当这项额外的工作导致项目的实质扩展超出了原始特征点估计时。有时，一个5分的物品实际上需要13个时间。在一种情况下，我们得到了13分，回想起来可能是80分或更高。 在我们的讨论中，有两种解决方案。 我们可以在同一个工作项中接受额外的工作，并将其记为错误估计。对此的论点包括： 我们计划在sprint末尾进行“填充”以解决此类问题。 始终使代码保持比发现的状态更好的形状。不要签入半途而废的工作。 如果我们将重构留给以后使用，则很难安排时间，并且可能永远无法完成。 您现在处于最佳的心理“环境”中来处理此工作，因为您已经在代码中深陷其中。最好是现在就解决它，并且比以后再丢失该上下文时更有效。 我们为当前工作项目划了一条线，并说额外的工作进入单独的工单。参数包括： 拥有单独的票证可以进行新的估算，因此我们不必对自己的真实情况撒谎，也不必承认我们所有的估算都是可怕的。 冲刺“填充”用于应对意想不到的技术挑战，这些挑战是完成票证要求的直接障碍。它不适用于仅“精打细算”的附带物品。 如果要安排重构，只需将其放在待办事项列表的顶部即可。 我们没有办法在估算中正确考虑这些内容，因为出现时似乎有些武断。代码检查者可能会说“那些UI控件（您实际上未在此工作项中对其进行修改）有些令人困惑，您也可以解决吗？” 这就像一个小时，但他们可能会说：“好吧，如果此控件现在与其他控件继承自相同的基类，为什么不将所有这些（几百行）代码都移到基类中并重新连接所有这些内容，级联的变化等？” 那需要一个星期。 它通过在票证中添加无关的工作来“污染犯罪现场”，从而使我们的原始特征点估计毫无意义。 在某些情况下，额外的工作会推迟检入，从而导致开发人员之间的阻塞。 我们中有些人现在说，我们应该决定一些截止日期，例如，如果其他物料少于2 FP，则将其放入同一票证中；如果更多，则将其设为新票证。 既然我们只需要几个月就可以使用敏捷，那么这里周围所有经验丰富的敏捷退伍军人对此有何看法？

12 agile  refactoring  estimation  sprint 

我对故事估计的理解是，应该像想象中的普通开发商那样估计故事的大小，这有点像法律上的“合理旁观者”概念。也就是说，如果您必须这样做，则不应该估计故事的大小。 举个例子：在我之前的工作中，我是一个团队的成员，而我是最自信的Ruby开发人员。我的队友通常会估计与Ruby有关的故事要比我估计的要大得多，并带有诸如“好吧，我不知道X在Ruby中如何工作，所以这需要我很多年。” 我反对这一观点的原因是，冲刺计划是团队能力发挥作用的地方。那是正确的说法，“由于大多数任务都是基于Ruby的，而且我们只有一名强大的Ruby开发人员，因此我们的Sprint容量将比平时低一些”。在估计期间将此因素考虑在内会使该方面加倍。 我会很乐意回答任何权威性的参考文献，但是简单的意见也将是很好的。

11 agile  estimation 

我们的Scrum团队由通常的Scrum角色组成。我们没有UI / UX设计器，开发人员与产品所有者一起使用UI / UX。这是一个问题。每次我们要创建积压订单时，我们都没有在sprint开始之前定义确切的UI / UX设计，我们最终在sprint中花费太多时间试图确定UI / UX设计。 对于功能的分析和架构，这是完全正确的。您是否认为应该在sprint开始之前将有关功能的所有可能的细节都提供给开发人员，或者这应该是功能内的任务？我们已经对此进行了体验，它导致了一些没有任何标准的未定义功能。

11 agile  scrum 

Scrum中允许使用技术用户故事吗？如果是这样，在Scrum中编写技术用户故事的标准模板是什么？一样As a <user> I want to do <task> so that I can <goal>吗？ 我在一些博客中读到，“ 开发人员不是用户故事”，但我也读到Scrum并没有强制要求这些。在有些情况下，他们有共同的一些博客用户故事与系统用户，它像as a <user who is not end user> i want to <system functionality> so that <some techinical thing>。那么哪个是标准？ 例如，有一些用户故事，例如： 作为评论者，我想上传任何酒店/食物的照片，以便其他用户可以看到并喜欢它们 作为用户，我想添加照片评论，以便更好地解释我的观点 现在，对于这两个用户故事，都有一个重要的技术项目-保存和检索图像 因此，我可以添加带有以下描述的标题为“图像存储和检索机制”的技术故事吗？ 作为开发人员，我想开发一种存储和检索图像的机制，以便用户可以在需要时添加/查看图像

11 project-management  agile  scrum  project  user-story 

我加入了一个使用敏捷/ Scrum的新团队，其开发过程如下： 1）开发人员在每次冲刺之前都要审查每个故事，以确保它不会遗漏任何关键内容。在工作流中有一个正式的状态。 2）在Sprint启动期间，整个团队都会对每个故事要花费多少故事点进行估算（扑克计划）。 3）最后，在每个sprint开始之后，每个开发人员都必须立即将所有分配的故事快速地分解为带有时间估计的子任务（与开始每个故事之前的子任务不同）。 最后一步的主要论点是，它有助于发现实施故事是否会比预期花费更长的时间，并警告Scrum主管有关缺少冲刺截止日期的潜在风险。 但是我发现这适得其反，主要是由于以下原因： 如果目的是提供粗略的估计，那么故事要点（步骤2）是做什么的。否则，为什么还要烦恼故事点呢？-尽早进行子任务。 如果目的是提供准确的估算值，那么这就是“ 认为有害的人类任务开关”中所描述内容的清晰示例。我认为，对于刚加入现有团队并参与大型项目的新开发人员而言，情况尤其如此，因为他们需要了解需要做什么才能花费多达50％的时间。您需要先进入故事1的详细信息，然后再进入故事2、3等等，等等，这会产生大量的信息流失。 有人告诉我，这种做法是“按书进行的”，甚至我都不打算讨论这一点。谁能提供这种做法的参考-Scrum圣经中是否明确定义了这种做法，并且/或者也许提供了任何额外的见解？

11 agile  scrum 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我目前在一家大公司实习，他们的软件交付结构正在发生许多变化（迁移到敏捷）。 在过去的几个月中，我注意到这种对Clean Code实践的宗教依恋，而这本书 对于开发人员来说就像一本圣经。 现在，干净代码的最重要特征之一是自解释代码，它基于可理解的命名和严格的重构。这是no commenting规则。 我知道这段干净的代码是一项长期投资，可以减轻代码维护和改进的负担，但是...这真的值得大惊小怪吗？ 任何人都可以分享他们在“清洁法规”方面的经验以及任何意见，无论我是太保守还是只是暂时的趋势。

11 programming-practices  agile  clean-code 

我正在阅读Scrum文档，它说Sprint中的任务应该是“潜在的”。 我对这意味着什么感到困惑。假设在Sprint 1中，目标是“用户注册表”。 我需要添加多少细节才能准备好发货？例如： 我可以使用没有任何花哨样式的字段来显示简单表单并将其标记为完成 我可以将客户端验证标记为已完成，但是服务器端也可以选择这两者 我还可以为表单添加一些jQuery花式工具提示，鼠标悬停，验证码，颜色，标签 然后有很多关于如何在屏幕上显示错误消息的样式 我可以在一个主题上无休止地做。因此，我们如何进行划分以及何时可以将其视为已准备好发货。 还是我需要写一些最小的东西，例如将错误，弹出窗口或灯箱文本显示为子任务，然后将它们作为sprint。这将导致整个项目执行数千个任务。 我的意思是再说一次，如果Internet Explorer和Firefox都可以使用，那么我也需要将其划分为任务。必须花时间在上面，当经理问我您当时的工作时，我没有任何要说的任务，但实际上，它们都是用户注册的一部分

11 web-development  agile  project-management  scrum 

每当出现关于使用哪种敏捷工具的问题时，总会有一些人回答“不要使用电子工具，因为您将失去看得见的板子优势，而这会更好地促进团队对话。” 总是这样吗？或者在任何情况下电子工具都是更好的选择？每种方法的优缺点有哪些？

11 agile  tools