小咬合敏捷:最适合于雄鹿[紧闭]

我非常喜欢混合和匹配,并且是开发过程的一个增量变更。我同意迭代开发应该是您的第一个目标,但我认为您可以用更小的步骤来实现它。

根据我的经验,我建议您先选择您还没有选择的订单:

• 首先修复错误。 我希望我不必这么说。这是理智的召唤,也需要有更短的周期。

• 小步。 训练实现对下一个特性可见的一步最小变化的习惯,然后编译和测试。在开始编码之前,将所有任务分解为<1h个单位。目标是至少每15分钟生成一个可构建的功能代码。这不需要进行太多的基础设施更改-除了修复增量构建和拥有快速机器。

对!首先要确保开发人员拥有快速的机器。有多少更好的建议可以得到?!

• 每天做每件事。 在源代码管理和安装介质之间建立一个双击的完整版本,最好是在一台单独的PC上。这是实现频繁版本的第一步,但它们本身已经帮助了很多。对于我们来说,这是获得可靠、可复制的构建结果的关键一步。

• 开始编写单元测试。 不要为覆盖率操心,不要强制“先写测试”,而是将框架放在适当的位置。为新代码和更改编写测试。然后用你的每日构建运行它们。

• 短周期。 现在是时候了,您已经准备好了每周或每周两次的内部发布的所有工具:代码库每天都处于可交付状态很多次,使得构建需要双击,并且至少有些东西正在工作。

迭代建筑

当我们开始在一致的基础上进行构建(在我们的例子中,每周或每周两次)时,我们看到了最大的改进。

当每一个构建都被生成时,我们与开发团队、QA团队和产品管理团队坐下来,创建了一个新构建中包含的工作列表。

然后,每个人都帮助回答了下一个构建中应该包含什么的问题。

从那时起,我们已经添加了许多敏捷开发的其他特性(包括尝试实现一个Scrum),但是没有什么比迭代构建更能给我们带来“大回报”。

迭代开发。在小的迭代中工作(比如说2周),在每次和单个迭代结束时都有“准备好”的应用程序,也就是说,您的测试人员应该乐于将结果发布给您的客户。

这是核心。你可以建立在这个基础上。

见 Best concrete “how-to manual” on MANAGING Test Driven and/or Agile development? .

我的建议是先从TDD开始。它很容易做到,对质量有着深远的影响。

这有几个部分。

1. 每个人都必须得到工具(JUnit或其他什么东西——在某些文化中这很难做到。)

2. 管理者必须要求测试完成。他们决不能(决不能)规避单元测试。一旦有人说“这些测试无关紧要,无论如何都要发送它”,你就失去了TDD的所有好处。

3. 你必须通过测试用例来管理:写了多少,通过了多少。您必须通过测试用例定义功能:功能[X]有[N]个测试用例,其中一些已经完成,一些正在进行中。

敏捷现在已经成为流行语,但是请记住它是 不是 一 silver bullet ;它不会像那样修复您的开发过程。你可能想读 Steve Yegge's excellent article 关于敏捷开发来平衡炒作。

如果您不掌握敏捷的核心,那么敏捷开发的某些方面可能很困难。敏捷是最重要的 一种思考的方式 :要灵活,接受变化,在短迭代中编写代码,重点是获得一个或几个特性。 完成 . 与获取单一的、完整的、单一的规范相反,编写所有的代码、文档,然后发送它。

如果你想证明敏捷开发是可行的,我可能会投票赞成使用Sprint来展示“早期发布,经常发布”的含义。

与程序员、测试人员、技术作者以及可能的销售/服务人员组成一个跨职能的团队。让他们认识到“完成”的概念,即要完成的事情是为客户编写、测试、记录、安装、部署和准备使用的事情。

这一点很重要,因为除非来自不同职能领域的每个人聚在一起,专注于为客户提供某种东西的单一目标,否则您无法实现敏捷框架的任何其他方面。

完全取决于您现有的流程,但我会告诉您,我们所做的最佳举措之一是获得项目积压和每日3个问题的概念(自从我们上次见面以来,您在做什么工作?)你今天要做什么?阻碍你前进的障碍是什么?早上开会,看看我们在哪里,我们可以做些什么来向我们的短迭代周期终点前进。

很高兴能够看到动态积压的工作要做,现在正在做什么,以及什么将使它进入下一个迭代。能够了解单个开发人员的位置并帮助他们消除前进的障碍是很好的。它使开发人员 going dark .

不管怎样,这是我的想法。它对我们有用。

从单元测试开始,如果你还没有这样做的话。如果您是单元测试,请切换到测试驱动开发。这些都很容易添加到现有流程中,并将立即支付股息。当您准备好处理流程变更时,引入迭代开发。如果您当前的流程已经是迭代的,那么就开始频繁地向客户发布迭代以获得反馈。

如果我必须总结一下“敏捷”的方法,我会说尽早并且经常提供高质量的业务价值。上面的实践会让你沿着这条路走很长一段路。

[编辑]

在自动生成中运行的自动测试。

我将尝试进行测试驱动开发。这会给你很多东西:

• 你会得到一个很好的单元测试覆盖率(我不是说单元测试覆盖率很重要)。
• 开发人员将对代码的实际工作有更多的信心(有关更多信息,请参阅*后面的内容)
• 您将能够更容易地重构代码(因为您有测试)。

[*]-Kent Beck在这方面提到了影响图。在影响图中,节点之间的箭头表示第一个节点的增加意味着第二个节点的增加。带圆的箭头表示第一个节点的增加意味着第二个节点的减少。

-----> [Stress] <--o-- / --o--> [RunTests]

压力越大,你做的测试就越少。测试越少,错误就越多。你犯的错误越多,你感到的压力就越大。重复…

如何解决这个循环,导致压力过大的开发人员在一段时间后不信任自己的代码?

测试优先开发更改影响图:

[TestFirst] <--o-- / --o--> [Stress]

你越是测试第一次开发,你感觉到的压力就越小。你感受到的压力越小,你做的测试越多。

这将导致由信任其代码的开发人员开发的更好的测试代码。

除了已经提供的所有好建议和我同意的建议之外,我还建议通过自动的、可重复的测试来加强QA。投资自动化将使您在更改已经部署的代码时更加自信。

在实现新特性的同时,为它们创建回归套件。

QA可以使用 exploratory testing 作为在开发过程中寻找漏洞的替代方法。

我认为敏捷最有价值和最容易实现的两个方面是

1. 每日站立-与团队进行一次简短的每日会议,以检查状态。使用3个问题。避免相声、闲聊和抱怨。保持速度快,注意重点。

2. 时间限制的迭代——将项目分解为两个或三个星期的周期,迫使您在合理的期限内朝着可管理的目标努力。