问题标签 [scrum]

Recently with my coworkers we were discussing how to organize the version control in a Scrum project. More specifically, the criteria for branches creation (per developer, per task, per Story, per Sprint?) and the methods of integration.

My opinion was that a useful way to organize it is to create a branch for each User Story, so you can integrate each Story in the releasable trunk once it is completed and it also allows that you always have a "deliverable version" of the application at any moment.

So if a story cannot be completed, it can be just left out and does not compromise the sprint release. (That considering a centralized tool, may be if using a distributed one the considerations would be different)

I'd like to know your own approaches, which kind of tools you prefer and the pros and cons that you have seen with the experience and the lessons learned.

背景：

我是一家中型网络托管公司的产品经理，除了网络托管之外，我们还提供各种补充服务。

今天，我们公司有大约 3-6 个开发团队，每个团队致力于不同方面的网络托管（即 DNS 注册、共享托管、云计算、专用服务器、转售等）。

我们已经非常有机地成长，因此用户界面极大地反映了我们公司的组织，而不是我们的客户会觉得直观的内容组织。

除了这个问题，许多后端系统属于每个团队的领域，但也需要被其他团队使用。例如，共享主机团队需要在其面板上使用 DNS 注册服务。另一个例子，一键式网络应用程序安装程序等网络托管功能是由共享托管团队开发的，但我们也希望将它们提供给专门的托管客户。

仅供参考，我们有一个非常注重敏捷方法和极限编程 (XP) 的编程环境。

问题：

对于那些拥有与我类似的公司工作/编程环境的人，您有什么解决方案/建议可以使这种安排发挥作用，以便我们可以改善用户体验以及代码的协调和共享，同时也让团队保持独立?

即这里有人用过Scrum of Scrums。如果是这样，您对实施它有什么建议？

Scrum of scrums 的任何替代解决方案？

使用 Scrum，用户故事的主体和这些词干提取任务等会迭代到成品——这很好。

但是，假设我有 100 个需要实现的功能，在现实世界中，在完成许多正常的辅助工作之前，我不能让任何开发人员参与这些功能 - 例如，做一个 UI 设计（当然你需要有对此功能的总体概念？），或构建不一定表现为功能的底层内容。

那么，这发生在哪里？

我开始学习 Scrum，我有兴趣与我们的开发团队一起尝试。我对此有很多疑问……但我最大的心理障碍是实际的图形设计。

在我们当前的开发周期 [瀑布式] 中，我们的图形设计师根据松散的 PRD 来布置带有所有图像等的页面。如果我们要利用 Scrum 的方法，这种发展将如何进行？我认为我们习惯于看到全局并朝着它前进……而不是在我们进行时将视觉部分组合在一起，这就是我期望的图形设计的 Scrum 政策。

至少线框积压中的所有功能是闻所未闻的吗？还是更明智的做法——对于第一个 sprint——以这样一种方式设计它的功能，以便我们可以随时添加其他 sprint 的新特性？（即，当需要新功能时，讨论“这适合当前设计的什么地方？”）

我工作的公司一直在一个项目上试用 Scrum，现在正在寻求将 scum 推广到三四个不同的项目团队。我们设想这些团队将在不同的功能分支中工作（我们使用的是 SVN）。

我们不确定不同团队的 sprint 是否应该同时结束，或者我们是否应该错开 sprint 以便 sprint 结束和发布是分开的。该产品是一个网站，因此部署不是问题。

我们关心代码集成，如果三个团队同时集成他们的代码，这是否容易导致冲突。但是如果发布是错开的，那么这个负载可能只会转移到处于冲刺中期的团队。

有没有人尝试过这两种方法，他们发现什么有效？

我在哪里可以找到 Scrum 开发的示例图表？

例如：烧毁或积压图表。

我所在的 Web 开发团队与遵循以用户为中心的设计原则的用户体验团队合作。我们一起在 Scrum 中工作。

我们应该针对哪些最佳实践来交付出色的产品？

我们正在尝试为一个开发在线应用程序的小型开发团队（三个半开发人员）运行 SCRUM，但我们无法从非开发资源（例如产品所有者、用户测试等）那里获得时间。

我正在研究一个商业案例，以获取更多非开发资源，并使其更能响应我们对他们参与的要求。

现在的情况：

• 产品负责人是一个5人的团队，其中一半是从开发团队跨大西洋而来（这比之前完全没有负责人的情况要好）
• 产品负责人“团队”几乎每月只开两次会
• 没有专门的用户测试或 QA 资源
• 完成用户测试的最快时间是 3 周，大约需要 2 个工作日的测试
• 我们正在努力实现每月冲刺

具体问题：

• 产品负责人（如果他们是一个人）每周应该花多少时间在他们的产品负责人角色上？
• 您是否希望产品负责人“每天一整天”都可用？
• 您希望每月有多少专用测试/QA 资源可用？

我试过用谷歌搜索“权威”答案，或者只是关于团队资源水平的任何报告，但没有找到任何东西。

有谁知道这样的事情，所以我的商业案例不仅仅是“我认为......”，而是可以参考专家意见和现实世界的统计数据？

要执行敏捷项目，您首先需要一份合同。没有合同——没有项目！没有项目——没有敏捷、SCRUM 或任何东西！

如果我们谈论的是大中型项目，合同必须有明确定义的安全触发器。即客户希望非常确定，如果我们同意按时结束项目 = T、预算 = B 和范围 = S，我们最终不会得到时间 = T×2、预算 = B×3 或范围 = S /2。

另一方面，作为交付产品的公司，我们不希望项目意外结束。即，如果经过一些迭代客户说“现在我看到这实际上就是我们所需要的。我们现在停止。” 并且该项目计划了另外 2 个月，而不是我们有没有计划工作的人。如果 3-6 人不是大问题，那么 15-25 人可能是一个真正的问题！

然而，我没有找到任何具有安全功能的合同的真实示例，该合同允许项目以完全敏捷的方式执行（向客户说明或未说明）。我在许多论坛上发现的标准说法——与客户交谈，向他解释这是更有成效的工作方式等，这并不能说服我和我的管理层。并不是说我们不相信敏捷实际上是一种更好的方法。只是安全触发器的差距是如此明显，以至于我们的客户都没有购买它，我们也不喜欢它们（差距，而不是客户；））。

请不要“它可能会以这种方式工作......” - 我已经阅读了大量的内容。只对“对我们来说它是这样工作的”感兴趣。毫无疑问，跳过其中的所有自信信息。

PS 据我所知，标准的迭代、功能驱动的方法建议客户在每次迭代（迭代次数）后付费，并且能够在任何迭代后由客户和项目执行者停止项目，而无需多说后果，而不是说“无论如何它都会失败，所以越早越好”（这是正确的，但在签署合同时不是很有帮助）。

我的组织一直在尝试引入更多“敏捷”方法。我们已经尝试了一段时间的 Scrum 方法，并且团队中的大多数人或多或少地适应了它。我喜欢它作为一个整体，但我担心该方法的一个潜在的严重影响：由于团队始终专注于功能和积压项目，并且测试人员与整个开发过程更加集成，似乎技能组合正在成为模糊，人们对个人能力的尊重越来越少。

我们的一些开发人员在服务器端技术和重量级数据供应的优化方面表现出色。其他人则投入了大量的职业来学习 GUI 技术，并对用户和应用程序的可用性有了基本的了解。两种技能都不比另一种好，但它们肯定是不同的。

这是 Scrum 过程的必然结果吗？由于团队中的每个人（据我所知）都为满足手头的下一个功能/要求、待办事项或测试目标做出了贡献，因此基本理念似乎是“任何人都可以做到”。根据我的经验，这根本不是真的。大多数工程师（开发人员、测试人员等）都有他们多年来磨练出来的特定技能，而在我看来，Scrum 方法往往会贬低他们以前受到尊重的那些能力。

这是一个澄清的例子：

如果服务器端数据配置发生技术突然变化，并且冲刺的待办事项列表中的每一项都基于这种新变化，那么 GUI 开发人员（他们可能还没有时间适应新技术）可能无法为冲刺做出贡献。至少，他们需要投入时间来提升，然后他们的代码会因为缺乏经验而受到怀疑。

我理解快速发展的必要性以阻止“角色孤岛”，但这并没有贬低一个基本现实：人们根据需要、他们的兴趣或他们的经验发展技能。当人们认为他们的位置是一种“插入能力”（例如，我们可以“插入”任何人来完成这项特定任务）时，他们似乎就没有那么积极了。Scrum 如何解决这个问题？如果没有，是否有人在采用 Scrum 方法时解决了这个问题？