在Scrum中，是否应该将诸如开发环境设置和功能开发之类的任务作为子任务管理在实际用户故事中？

有时在项目中，我们需要花时间在以下任务上：

1. 探索替代框架和工具
2. 学习为项目选择的框架和工具
3. 设置服务器和项目基础结构（版本控制，构建环境，数据库等）

如果我们正在使用用户故事，那么所有这些工作应该去哪儿？

一种选择是使它们全部成为第一个用户故事的一部分（例如，制作应用程序主页）。另一个选择是对这些任务执行加急操作。第三种选择是使任务成为问题 / 障碍（例如，尚未选择的开发环境）而不是用户故事的一部分。

在过去的一年中，我们对这个问题进行了很多思考。

虽然我同意在项目开始之前应该存在一个基本框架，但在实际使用中它可以成为项目本身的一部分。因此，您必须以某种方式进行管理。

尽管有时将项目设置与用户案例相结合可能是有道理的，但有时我们还是决定将一些简单的任务添加到产品待办事项列表中，并获得与用户案例相同的关注。我们知道这些技术任务有时是必要的，但是无论如何都必须证明它们是合理的。如果团队认为实现某个目标绝对必要，那么他们将成为冲刺的一部分。

很难说什么最适合您，所以尝试一下！目前，峰值可能已足够，但我认为您稍后将遇到相同的问题，因此请提前计划。执行作为此类活动占位符的任务。为了将任务与故事分开，我将根据自己的经验对它们进行快速比较。

任务：任务是技术上的必需品。可能是用于配置管理或常规项目设置的事情，例如为提交设置存储库，或者将您见过的最热门的代码审查工具添加到开发过程中。与用户故事相同，在计划中应考虑任务。如果团队可以说服产品所有者使用最新，最好的代码审查工具来消除长时间的结对编程会话或亲自进行代码审查，从而提高性能并提高团队沟通水平，那么它将引起产品所有者的关注。

故事：故事仅专注于业务角度，总是为客户带来可见的价值。内部质量与创造业务价值息息相关。

我们甚至将故事点分配给任务，有时甚至像处理故事一样使用它们。

最后，在您的情况下，我将寻求该解决方案（也可以普遍应用）：

1. 将“设置”和技术资料分开进行任务（不会直接为产品所有者带来业务价值的资料）。
2. 也许在项目设置之前做一些准备工作，以使最重要的工具到位（SCM，开发工具，过程定义，编码标准等）。
3. 接受这些任务在项目期间弹出，并通过进行除故事以外的单独的“类型”活动来为此计划。

在公司中做最有意义的事情。永远不要让其他人做事成为常识的障碍。

但是我要说的是，所有这些任务听起来都应该在开始开发之前就已经发生了。因此，我质疑Scrum是否与这些任务相关。有一些正在进行的维护，例如源代码管理和数据库，但不应安排这些维护，它们应该是会发生并影响您速度的事情。

有时候，您在项目期间必须选择框架或其他任何东西，但是当我说我的意思是像nHibernate这样的框架，而不是.NET这样的框架时。在这种情况下，应该增加研究的时间和限度，更不用说简短了。尝试管理它，就好像您有几天的病情困扰着开发人员一样。

知识转移是另一个正在进行的过程，应在总体发展速度之外进行管理。

有一个名字可以在项目“正式”开始之前就尽可能多地做出设计决定。叫做瀑布。用户故事没有什么错，例如“作为开发人员，我需要选择一个框架，因此我们为网站提供了起点”。如果太大而无法迭代，请尝试将其分解，例如“作为开发人员，我需要在Drupal中实现一个基本主页，以便我们知道它是否符合我们的需求。”

一种选择是使他们成为第一用户故事的一部分，例如，制作应用程序主页。

打破了“用户故事”的概念。哪些用户参与其中？没有。这是您应该已经完成​​的工作。

另一个选择是为此加急。

不错。

第三种选择是使任务成为问题的一部分（例如尚未选择开发环境），而不是用户故事。

就计划和间接费用而言，这几乎与峰值相同。

安装不是用户故事。

这是您甚至在开始此项目之前就应该具备的功能。

除非您已准备好框架/工具和服务器，然后才能开始工作，否则您实际上无法启动项目。

我很清楚，直到签订合同后，许多组织才真正成立。我也很清楚，许多组织直到签订合同后才选择技术。这些都是所有用户故事之外的低效事物。

在工作中，我们使用一项任务来准备环境。对于某些人来说可能会造成混淆，但是我们使用的任务与用户故事中的任务几乎相同。该任务不属于用户故事，而是以小时为单位进行估算，必须由产品所有者同意才能完成特定的冲刺。

我们还将任务用于没有“明显”业务价值但会增加产品质量的体系结构工作，特别是对于具有大量代码库的现有产品。

这些可能不适用于您的工作环境，但对我们来说效果很好。

我认为您正在混合两种独立的事物。用户故事不应包含任何技术细节。

框架的选择，设置存储库和服务器以及其他任务应进入初始迭代。

我最近参加了一个Scrum课程，教师建议使用一个名为Sprint 0的特殊sprint 来解决这类问题。在课程中有些人对Scrum有不同程度的经验，几乎所有有经验的人都同意，他们说他们做了同样的事情。在某些情况下，这些公司使用Sprint 0来评估该项目，并确定该项目是否可行。

对于像我这样的Scrum方法新手来说，这似乎是一个绝佳的解决方案，因为它使您摆脱了用户故事和正常冲刺的所有其他方面的困扰，例如用户反馈。

由于Sprint 0与其他Sprint的时间长度相同，因此它可以确保您不必花费太多时间进行设置，因为以后可以随时对其进行调整。要点是使您进入可以真正开始开发产品的状态。

探索2-3个备用框架/工具

如果您有特殊要求，有时可能会发生这种情况，您必须做一些POC来选择最佳工具来解决该要求。这就是峰值的原因，因为在不知道您将使用哪种框架的情况下，您很可能无法估计故事，而无法估计的存储则无法计划并划分为任务。

然后在学习我们为项目选择的框架时

好。这很危险。当客户为您支付软件费用时，他期望您是专业人士，他们已经知道如何使用他的工具。客户无需为您的学习或试用/失败开发方法付费。开发人员有责任在业余时间或由员工而非客户支付的特殊分配时间内学习新工具。在没有通知客户的情况下将客户的钱花在学习上是不专业的。

如果您确实必须使用从未使用过的特殊功能（例如，某些客户的API或客户选择的工具），则必须告知客户价格将随着学习API的使用时间而增加。如果价格上涨幅度太大，客户可能会改变主意。

当然，我的意思不是您必须在已经使用了很多次的框架中寻找某些特定的新问题的情况。我的意思是您开始使用新的API或框架而没有花费大量时间（在项目外部）进行学习的情况。

如果您违反了此规定，那么无论如何您都可以看到它，因为您每次迭代都会带来非常少量的业务价值。如果客户不知道原因，他很可能会取消该项目。

对于内部项目，这仍然有效-您必须告知经理/企业有关学习新API或工具所需的时间。如果经理按您的正常生产力来工作，而您的生产力仅是零头，这是由于您尝试在任务期间尝试学习的新API，通常会带来非常糟糕的后果。如果某些销售人员在与客户签订合同时以正常的生产率进行计算，那显然更糟。

关于设置服务器（SVN，数据库等）

那就是您的基础架构和内部成本。启动项目时，预计已准备好基础架构。设置开发环境对客户没有任何价值，也不应该成为任何与项目相关的指标的一部分-例如Scrum的速度。我看到这是作为特殊的项目前迭代实现的，仅用于设置环境，创建基本基础结构等。