认识达内从这里开始

对于一些软件开发公司来说，一般他们的技术员和技术团队都知道关于敏捷开发的使用方法的，但是这些方法不一定适用于每一个公司，所以我们就需要根据实际情况来决定。

下面，我们就一起来了解一下通过哪些方法来确定自己的团队的敏捷开发适用方法。

从你的环境开始着手，思考哪些敏捷方法可以为你们所用。

每支团队都是独一无二的

每支团队都是独一无二的，所以每支团队都需要它自己的敏捷方法。有些团队可以使用现成的框架，比如Scrum、极限编辑或看板法。然而，以我的经验来看，大多数团队需要针对自己的条件定制他们自己的敏捷方法。

在以下情况下，你应考虑定制你自己的敏捷方法：

你的敏捷团队分布在全球各地，跨至少四个不同时区。对于你们来说，召开日例会或同步的细化会、计划会和回顾会非常得困难。

你的组织对敏捷方法仍很陌生，你们拥有一支开发团队和一支测试团队。你的界面设计人员是一支“共享服务”团队。在这种情况下，你可以使用看板去演示工作流程，使每个人了解工作到什么地步了、什么工作延期了。你可以用这块板及其数据把界面设计人员融入到团队中来。

你们以工作组的形式开展工作，而不是团队。你们的工作是独立的，没有互相依赖。软件团队有相互依赖的工作，比如，需要开发人员和测试人员协同完成的工作。想象一下客户支持“团队”。公司称这个团队为一支团队，但他们并没有相互依赖的工作。每个人都单独作战。在某些情况下，大家可能会协作处理难题，但大多数时间都是每个人单独完成他们的工作。当大家独立工作时，其实只是个工作组。

你的团队需要提供支持或维护，这些工作的优先级高于项目工作。它们会打断你的项目工作。

你的团队同时要应付多个项目。

在这些情况中每一个都需要一个计划、演示和发布的节奏。然而，你的团队可能会发现，同一节奏不适用于所有的工作。

你们的计划、演示和反思节奏是什么?

一般敏捷图是思考敏捷方法如何运转的一种方法：

负责人(通常称之为产品负责人，PO)从客户和/或组织那里了解到他们的想法，然后创建一个排好优先级的待办事项列表。跨职能团队从这份列表中领取任务，频繁定期地交付小的可运行的产品。在某个时间点，团队演示他们的工作并进行总结回顾。

如果你使用迭代，就要制定时间计划，因为迭代是个时间箱。按照定义，团队在时间结束时完成相应的工作。产品负责人决定未完成的工作移至下个迭代还是移到更往后的产品路线图。

一般认为，如果团队使用像Scrum中的迭代，那么就是以有优先级的待办事项为始，以演示和总结回顾为终。如果团队使用工作流，就可以随时演示和回顾。

坦白讲，基于迭代的敏捷方法并未限制你随时演示或回顾。只是许多团队都是等到迭代结束了才演示和反思。

有些团队已经发现更频繁的演示和反思对产品和工作流程都有帮助。Ben的团队一完成特性就进行演示。因为产品负责人大多数时间都有空，所以他们很方便演示。他们面对一些复杂特性时，想得到更多的反馈，不仅限于每迭代一次，所以开始尝试一边做一边演示的实践。结果这个实践效果很好，他们就延续了下来。

Ben知道组织中另一支团队有个叫做“持续反思”的实践。那支团队每天站立会之后进行五分钟的反思，为接下来的工作做准备。他们在午餐之前召开站立会。因为他们全都取在快餐厅用午餐，所以他们经常在午餐时间优化流程或做些讨论。

如果你使用工作流，就会为工作范围制定计划，因为工作流不关注你有多少工作，而是完成一件后，再做下一件。在某一时刻，你们会进行演示和回顾。团队决定何时演示和回顾对于他们来说是有意义的。使用工作流的团队没必要在每个特性完成后就进行演示，尽管我遇到过的大多数是这么安排演示的。

Sally的团队演示每个特性，尽管他们演示的方式与Ben的团队有所不同。Sally向产品负责人发电子邮件解释新的特性。Sally请产品负责人次日试试这个特性，然后反馈给团队。这名产品负责人经常用一两天时间给出反馈。

如果这名产品负责人对这个特性感到满意，那还好。但如果产品负责人对这个特性不怎么感冒，Sally会先请产品负责人阐明他的关注点。然后，基于这些关注点，再来推进团队工作，或者请产品负责人把故事或接下来的工作讲清楚。

因为产品负责人没有足够的时间，所以Sally的团队的工作延期了。

Sally的团队按节奏反思。他们每周进行异步的回顾，因为得考虑那么多不同的时区。另外，他们会每季度每个人都亲自出面聚到一起，开始亲自参与的包含回顾的会议。

理解时间箱和节奏的差异

我发现区分时间箱和节奏的差异很有用。

通过定义，时间箱可以帮助你划个期限说，“放下笔吧，时间到了!”节奏则说，“是时间再做这项活动了。”

可能团队在一个时间箱或迭代内完成故事有困难，这可能有这样那样的很多原因。我见过的三个共性原因是：故事太大了;人同时在处理多个故事，甚至更糟的是同时应付多个项目;以及团队没有像一支团队一样去完成故事。如果团队因为多重任务无法完成，节奏可能会使其更加糟糕。然而，把工作可视化可能会带来不同的影响。

Sally的团队在一个迭代内完成他们的故事有困难。他们出现了这些状况：

Sally的团队从未完成一个迭代的承诺。一部分原因是因为产品负责人在迭代期改变了他的想法，把讨论过的故事换成了没讨论过的。

Sally决定是时间做些改变了。她建议团队限制故事的数量，接下来要做的、要讨论的不要太多。团队决定限制为三个故事。然后，她要求产品负责人不要改变这些故事或把它们换出去。产品负责人同意了。团队同意每周在做好支持工作的情况下努力完成这三个故事。这意味着团队和产品负责人可以每周规划好三个故事了。而灵活性是产品负责人可以每周改变或增加一次故事。

Sally团队的节奏是每周计划和切换一批工作。随着特性的完成，团队演示了这些特性。他们所有人都很高兴。

Sally的团队以一周的节奏去计划和演示。他们经常使用短时间箱进行冲刺，或者一个早上，或者一个下午，但他们不再使用迭代了，因为对于他们来说有些东西变得太快了。

Sally的团队还以一周的节奏来开展回顾。他们检查已经完成的工作怎么样了，管理他们的风险和障碍，然后决定接下来做什么。

确定什么适合你的环境

你们可以使用时间箱还是迭代来管理团队承诺完成的工作?或者，你觉得用工作流有更多的灵活性?或许你可以同时使用这两种思想：时间箱让你有明确的节奏，让你清楚可以承诺完成什么，而工作流让你能看到在办任务做到什么地步了。

使用看板的团队，其准备栏中有八项。介于准备到完成之间的所有任务是：讨论故事、开发和单元测试、系统测试，也就是他们的在办任务。

这个特殊的团队有个完整的看板。在办任务的限制防止团队把太多的任务放到准备栏，直到他们真的有时间去处理它们了。

该团队将重心转至最右边的栏，当团队把工作移到完成栏，就表示工作彻底完成了。自从团队限制了系统测试，无论谁在做系统测试，都会有人去协助他完成了。然后，谁也就都可以把已经开发完成的工作提交到系统测试了。

当一支团队加了在办任务限制时，他们就可以控制自己工作流转和生产力了。有些团队发现创建不同的栏目并限制在办任务能帮助他们发现应在自己的敏捷方法中做些什么尝试。

Sally的团队已经转变了工作的方式。他们刻意限制了每种状态在办任务的数量。使用经典Scrum板时，他们不清楚每种状态下实际有多少工作。他们可以建个看板在迭代内使用，但是他们没有。

考虑你的团队的选择

尤其是，如果团队使用一个工具，最大的决策是如何管理工作流程。是使用迭代，还是应该使用工作流?我的参考意见是：如果团队能有相对稳定的故事集，在一或两周内不会被打断，就用迭代。如果团队需要快速响应一或两周内的变更，就使用工作流。

接下来，请团队考虑他们想要多长时间演示和反思一次。团队可以使用计划、演示和反思的节奏，也可以使用工作流。或者，团队可能使用迭代和有时间箱的迭代驱动他们的计划、演示和回顾。

我喜欢使用一周时间箱内的工作流。我制定一周内可以完成的计划。我可以调整这些工作的顺序，有时我还会在本周内因为中断或机会改变它本身。我一周反思一次，然后做下一周的计划，根据的是已经完成了的内容。因为我在周末中止工作，确定针对尚未完成或者仍未开始的工作再做些什么，所以我采用时间箱。

如何使用敏捷方法并没有所谓正确的方式。结合你的环境、团队和项目，才能定制出你自己的敏捷方法，使项目取得成功。

作者:JohannaRothman

译者:冬雨

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。