问敏捷环境中的需求、规范和管理

EN

让我们看看我的取舍是否增加了什么(不确定，无论如何.)

1. 我不确定“给每个人分配一个版本”的问题。我认为这样做的目的是为每个故事/功能点/开发单元设定一个“价格”，并选择当前sprint中的内容。其他都是待办事项--您可以提供一些剩余工作的指示(请参阅基于证据的调度 in FogBugz)，但我认为您不应该将其分配给特定的sprints -首先，您不知道待办事项完成时会出现什么。你只知道它会改变，那为什么还要浪费时间呢？
2. 应有一名指定的用户代表。或者不止一个，如果领域知识不能集中在一个人身上。但是，业务领域的人应该全面负责决定什么进入冲刺，当然，这取决于可用的努力。可以为业务分析师类型提供一个位置，但他们需要是领域专家。如果你的用户不能写故事，即使在你的帮助下(这是一个合作的事情，或者应该是)，那么你们都需要帮助。考虑让教练参加一两次冲刺。
3. 您不会在敏捷环境中编写功能规范。你会写代码的。您的用户将随时在场(或者您已经面临重大风险)，它们是您的规范。故事告诉你“什么”，并将是一个足够小的工作单位，你应该能够决定“如何”相当快。和重构。总是重构。这不是一个开销，它是过程的一部分，如果没有它，您的设计就不会发展得令人满意。
4. 如果你有副总裁(嘿，我是副总裁，我们都不坏！)如果有人问你这样的问题，那么你公司的一些部门还没有搞清楚。选择一个人(最有能力与非技术人员打交道的人，也许，或者是能力最差的人，因为他们显然需要实践)来向他们解释。如果建好的东西对他们来说很重要，也许他们的问题就表明某人没有像他们应该的那样参与其中。

1. 您应该将您的需求转换为Product。这个待办事项是您用来决定为每个Sprint迭代选择什么Sprint项的。管理层决定产品待办事项清单上的内容，但是团队需要同意他们可以在Sprint中产生什么(这是在每个sprint上都会发生的协商)。
2. 产品负责人(通常是产品经理)推动故事的创建。故事很简单(作为一个系统管理员，我需要能够添加一个用户)。如果你的产品管理不理解你的产品，你就有麻烦了。
3. 敏捷是指根据需要进行设计。这个设计从来没有出现在故事里。规范可以是每个故事，也可以是每个特性。您可以在一个规范中设计所有CRUD，该规范涵盖多个故事。
4. 产品负责人在每个Sprint的末尾得到一个产品演示。因此，价值在每一个周期都会被证明。所以你的副总裁每月都会得到报告(通常是开发3周+1周，为Sprint演示做准备)。

如果您要在编写或设计代码方面做任何事情，那么您应该做的事情之一就是编写一个规范，不管您使用的是什么方法，无论是Scrum、XP、敏捷还是SDLC。许多人说写说明书太不灵活了，是浪费官僚文书工作的丰碑。简单的事实是，当他们说代码是规范时，他们被误导了。

一个明确的事实是，规范允许您预先制定您的想法和设计，更改规范要比更改程序容易得多，特别是当您在简单LOB应用程序的范围之外工作时。规范确保您在开始编码时对所需的内容有了更清楚的了解。

使用规范、设计更好的软件的团队不断地被展示出来。在我看来，如果有人说代码是规范，那就是教条、简单、简单，并为将来积累了巨大的可维护性问题。

顺便说一句，我没有任何反对敏捷宣言或轻量级管理过程中心的方法，比如Scrum。在过去的几年里，我使用过它很多次，而且它提供了。我也看到了好的软件，在那里，敏捷的焦点本来可以拯救它。但这不是灵丹妙药，也不是银弹。