Questions tagged «scrum»

我正在研究一种方法，以更好地理解采用scrum方法的持续集成工作流程如何更好地适合于软件开发公司。 我在想这样的事情： 那将是一个不错的工作流程吗？

16 testing  development-process  scrum  continuous-integration  workflows 

根据您的经验，Sprint计划会议（Scrum）应该持续多长时间？8小时？还是应该缩短（简洁），并计划将更多讨论作为冲刺的一部分？我们的Sprint为期10天。

16 agile  scrum  planning 

我敢肯定这不是一个罕见的主题。我们有两个Scrum团队可以很好地使用故事点来估计用户故事（当前团队的星座只有大约8个月大，尽管团队成员具有几年的Scrum经验）。但是，对于公司的业务部门而言，很难与用户故事相关联。他们想要实际的时间单位（或“将故事点转换为小时数的公式”），以便他们可以为何时准备就绪制定计划（“我们需要知道何时可以告诉客户Feature X即将投入生产”。 我和我的Scrum大师的前任当然已经解释说：“故事点和实际时间之间没有明确的关系”，并且“故事点用于确定团队适合冲刺的程度”，我确保您可以猜出他们对该答案的满意程度。他们仍然想在日历时间内知道何时获得积压的第27个用户案例。 无论如何，我一直在编辑一些统计数据，我们的SP估计值转化为实际花费的时间差异很大（由我们的Scrum Board软件衡量，该软件可以跟踪“在”列中花费的时间） ）。对于1-SP用户故事，当然会非常倾向于很短的时间跨度（偶尔会出现爆炸），但是特别是对于2-SP用户故事，它们无处不在：大约有20倍在“最快”和“最慢”完成之间。对于3、5和8-SP故事，传播也超过2倍。 这表明（a）团队需要在估计相似程度（应该是）的用户故事方面更加一致，并且（b）团队需要提高时间报告的准确性（即记住将票证移出当他们在会议上，午餐时或打足球时进行“锻炼”。 我已经计划改善（a）和（b），但是我觉得这还远远不够，因为企业期望比这些计划产生的结果更“具体”。 有什么好的策略可以使业务方面愉悦，从而使它们不会对我们的工作产生太大干扰（例如，通过使用单独的时间跟踪，恕我直言，这是愚蠢的，因为在任何情况下它的准确性都不如当前的“自动”跟踪），同时又让他们获得一些具体的度量标准来确定故事何时完成？ （从历史上看，在规划过程中，我们确实将用户故事分解为工作项目，然后在实际工作时间中分别进行估算，但是我在这里要说的是备用日志中的用户故事，而这些细节或详细程度不会-下。） 更新：我的经理有一种预感，即每个故事点花费的小时数呈钟形分布，但我整理的数据和他制作的图表使他完全没有这个想法。:-)

15 scrum  estimation 

我们的业务分析师和项目负责人告诉我们客户的故事要求。在每个Sprint计划中，我们（开发人员）都被要求玩计划扑克。 他们要求我们所有人考虑“复杂性”而不是“努力”。我们真的很困惑，我们在浪费时间开会。一位开发人员提出了一个问题：“我们真正要考虑什么？是关于我们在此需求（时间估计）中必须进行的代码/ DDL更改，还是关于我们是否已理解该需求？ 但是，他们（业务分析师和项目负责人）真正的含义是“了解需求”并“举起名片”？ 另外，我们为各个Scrum团队举行切片会议，每个开发人员都为每个Scrum团队估计完成给定任务的时间。那么，他们在计划扑克中真正谈论的是什么呢？ 谁能用一个例子解释一下？当他们说“复杂性”和“努力”时，尝试区分他们真正在谈论什么。

15 agile  scrum  planning 

一些团队成员只是等到讨论他们最有可能从事的故事，然后才参与。否则，他们只会玩手机而不听。 我从某种程度上理解了这个立场。为什么要听有关您不太可能在Sprint中帮助开发的功能的讨论？ 您认为我们应该怎么做？

15 agile  scrum 

我有一种需要移植到新平台的现有语言。我可能会通过更改现有编译器的后端进行尝试。 重写后端需要大量的工作。在不违反INVEST标准的情况下，我看不到将其分解为明智的故事的方法。 我看不到每个故事如何可以面议-它们都是正常工作的编译器所必需的。这些故事都具有同等优先权，无论我按什么顺序发表它们都无所谓。我需要全部做。 我正在实施的软件中某些部分的优先级比其他部分低，我可以看到我们可以逐步提供该部分。但是，必须具备一个重要的核心。 我计划尝试遵循Scrum，但是我只是在进行议案吗？ 有针对此类项目的推荐做法吗？

15 scrum  compiler  porting 

我目前正在与我所在大学的一位教授合作，为我学院提供的软件工程和Capstone设计课程开发新课程。 直到最近，这两个课程都只使用瀑布模型，因此，学生们大部分时间都在写冗长的报告。在我施加很大压力之后，我的教授决定在上学期将Scrum纳入软件工程课程。 本学期的前半段仍然是瀑布式的，学生们撰写了40页的设计报告和软件规格文档。学期中，所有团队都必须发布其应用程序演示。那时，课程切换到Scrum，进行了两个为期3周的冲刺。现在，我们正在尝试找出如何完全消除瀑布并创建完全基于Scrum的课程。 不幸的是，我们在Scrum和学生之间遇到了一些不兼容性： 对于学生来说，每天召开Scrum会议几乎是不可能的。即使在上课期间，由于教授通常是在讲课，所以学生召开Scrum会议也不方便。 由于学生缺乏经验，因此无法准确地预测要花费多长时间，因此很难估计积分/小时。 Scrum与全职，位于同一地点的开发人员最适合，但学生都不是。学生最多每周奉献15至20个小时的课程，组织工作会议可能非常困难。团队最多可以有10个学生（并且总是有一两个懒人）。 教授们渴望文档！我还没有听说过Scrum的任何报告，只有积压的工作量和燃尽图（我不确定这是否足以使学者安心）。 学生通常认为敏捷的意思是“立即跳入并开始编码而无需回头”。这导致了一些可以想象的最可怕的代码。因此，我正在寻找一种方法来执行适当的设计，而不需要50页的文档或一堆UML图。 鉴于这些问题，您如何看待我和我的教授如何使Scrum在学术环境中发挥作用（并且我们一开始甚至应该为Scrum烦恼）？此外，教导瀑布模型是否仍然有价值？ 预先感谢您的任何反馈！

15 agile  scrum  documentation 

我是我公司新项目的开发团队负责人。这是公司将使用Scrum的第一个项目。我们有一个瀑布/迭代式SDLC。BA编写需求文档，移交给开发人员和测试，开发人员开始开发并将在迭代中发布以进行测试。测试人员需要花费很长时间来测试发行版，开发人员可以通过该发行版继续进行开发，还需要修复当前发行版的错误。我有几个问题 在一个包含5个故事的冲刺中，您什么时候发布测试？是开发人员在故事完成后立即完成，还是在所有故事完成后但在sprint结束之前给出测试所需的测试时间。 如果广管局写用户故事，那么细节应该是什么。传统上，编写带有所有UI布局，行为，文本等要最终确定的规范需要很长时间。我想我的问题是如何编写可实施和可测试的故事。 我们的测试团队是非技术人员。对Scrum进行自动UI测试有多么重要。UI基于WPF。 我在使用敏捷方法（TDD，代码审查，重构等）方面拥有扎实的开发经验，但对Scrum还是陌生的。 编辑：通过迭代，我的意思是，如果有100个需求，我们可以在完成30、35、35个需求时发布测试，而不是等到所有100个需求都完成了。

15 scrum 

我在嵌入式系统中有两个Scrum问题。首先，有许多任务要做，尤其是在早期阶段，这些任务是无法证明的。我们从开发板开始，没有操作系统，没有显示器，没有串行通讯，等等。我们没有六个冲刺的显示器。 前四个冲刺是： 获取RTOS和运行 创建编写网络和串行驱动程序的任务 编写按钮，通讯等中断例程 编写主要的数据库类和方法 编写串行调试菜单 这些任务大多数都不适合用户案例。实际上，进入整个系统的唯一接口是内置在sprint 3中的串行调试菜单，因此在sprint的末尾没有任何内容可以说明。甚至串行菜单也只供内部使用，而不是最终用户。尽管如此，我仍然想通过Scrum跟踪和管理这些开发活动。 我们最终写了“用户故事”这样的词组，例如“作为开发人员...”，我对此并不满意，但是在使用Target Process（www.targetprocess.com）时，没有积压的概念，任务或琐事。 其次，您如何处理发布和测试？对我们来说，这是真正的痛苦，因为测试人员没有硬件调试器，因此我们必须构建代码的闪存版本，并将其刻录到开发板上进行测试。测试人员在技术上不如开发人员那么敏锐，并且通常需要大量支持才能使它们在早期阶段正常工作（重置板子，连接串行通信等），甚至理解输出。 最后，关于完成的定义，只有在所有故事完成之前，冲刺才能完成。在测试人员验证之前，所有故事都是不完整的。无法避免“浪费”开发人员的时间给测试人员。换句话说，如果冲刺中的最后三个用户故事需要五天的时间进行测试，则必须在冲刺结束前五天对它们进行编码和单元测试。开发人员应该做什么？停止工作？ 我正在开玩笑，但尝试遵守规则确实是一个问题。现在，我可以遵循规则了，但是我遇到的问题是，如果在测试之前无法将所有工作标记为已完成，它将使我的所有燃尽指标变糟。 我很想听听其他人如何处理这些情况。

15 agile  scrum  embedded-systems 

我们最近进入了Scrum流程，并且正在sprint中处理任务和用户故事。我们希望经常进行代码审查，以减轻他们的负担。我们正在考虑在用户故事级别上执行这些操作，但是不确定如何分支我们的代码来解决此问题。 我们使用的是VS和TFS 2010，我们由6人组成。 我们目前为功能分支，但正在努力更改为Scrum分支。 我们目前不使用架子集，如果有其他可用的技术，我们也不想真正实现。 您如何建议我们针对每个用户案例实施代码审查？

15 agile  code-reviews  scrum 

在过去的9年中，我曾在许多小型团队中工作。每个人都有明显的良好做法，例如短期会议，版本控制，持续集成软件，问题跟踪等。 在这9年中，我从未听说过很多开发方法。例如，从来没有过“我们在做Scrum”，“让我们敏捷”，或者是传递引用。所有团队的运作似乎都很好，没有经过很多程序，我们只是自由流动，自然就很好。 有没有其他人长时间进步而没有遇到混乱/敏捷/等问题？ 我唯一接触过这些内容的地方就是通过此类网站。我读过诸如Sprint Meetings之类的问题-谈论什么 ...，所有的讨论似乎都描述了几乎机器人，就像遵循方法论有限状态机的人一样。真的（尽管有些夸张）吗？我想知道在互联网上发布的人们是否只是“最佳实践”的拥护者，具有类似的教科书观点，没有真正反映人们的工作方式吗？或者我遇到过一些团队自然地制定自己的流程。 此外（我在英国，这可能是相关的）...我认为，如果将一种方法论引入我要研究的任何团队中，他们只会拒绝它是愚蠢且不必要的...然后上。我倾向于同意，遵循流程似乎有些不自然。这是典型的还是常见的？

15 development-process  agile  scrum 

在理想的敏捷世界中，您可以快速构建所需终端系统的一个小而有用的子集，并将其提供给用户。他们很兴奋，因为它很有用，他们开始使用它并提供反馈。然后，您可以计算出要添加的内容，然后进行构建，然后重复进行，直到用完时间。 我最近有几个项目，涉及更换某种工作系统。上面的模型根本不起作用：在您构建了一个包含现有系统几乎所有功能的系统之前，用户完全没有兴趣。他们不会使用它。 当“最小的有用子集”是“全部”时，如何应用敏捷？

15 agile  scrum  users  iterative-development 

我花了5个小时以上的冲刺计划来进行为期一周的冲刺。似乎太过分了。 由于大多数团队成员都不高级，因此我们将在sprint计划中详细讨论事情。如果我们不这样做，将会在实现过程中导致错误，并在sprint过程中进行重新设计。 我们该如何处理？ 我应该在计划期间讨论多少细节，以使其适合每周冲刺仅2小时的时间？

14 agile  scrum  planning  sprint 

如果我正确理解Scrum，这就是我确定团队在下一个冲刺中可以从事的工作的方式： 我平均了过去几个冲刺的完成点数。 这个量是我们的平均速度。在下一个冲刺中，我们要讲很多故事。 这是一个平均数，因此，如果历史重演，则此冲刺是我们承担的故事点过多的可能性为50％，而我们承担的故事点过多的可能性为50％。 在50％的情况下，我们承担了太多的故事要点，我们可以： 无法完成冲刺。这意味着我们将有一半时间无法实现冲刺承诺。 额外工作以赶上。问题在于，棘轮只有一种方式。我们将完成冲刺，完成的故事点数将反映出这一点。由于我们总是会结束，所以随着时间的流逝，我们的平均水平将趋于上升，直到我们总是完成大量的故事点并熬夜。 我对平均速度和冲刺承诺的理解正确吗？ 如果是这样，对于落后于平均水平的50％的冲刺，我们应该怎么做？ 如果没有，我怎么了？

14 scrum  user-story  sprint  scrum-master 

在我目前在公司工作的我们开始进行Scrum项目。说服经理们从瀑布式迁移到Scrum并不难。我们正在做一个从头开始重建平台的项目。因此，（大多数）功能是已知的，大多数改进都是技术性的。 在这种情况下，拥有技术任务而非用户故事是合理的。我们的积压工作涉及各种技术任务，例如： 将数据库类从MySQL重写为PostgreSQL。 实施系统日志记录。 重写对象缓存。 站立时出现的事情包括需要长时间的“研究任务”，但它们从未完成。此外，团队成员在冲刺中声称需要添加计划外任务。 Scrum Master应该如何处理？难道对于这样的项目来说，Scrum不是要走的路吗？

14 project-management  scrum  user-story  product-backlog