敏捷，高效的方式

目录

介绍

背景

敏捷阶段

冲刺(sprint)前

容量规划

任务估算

 在冲刺(sprint)期间

修饰

每日站立会议

 冲刺(sprint)之后

冲刺(sprint)演示

冲刺(sprint)回顾

总结

---

本文将帮助您了解如何使用敏捷方法获得即时结果，无论您是刚开始新的还是已经处于项目/产品开发的中间位置。

介绍

许多软件开发团队遵循敏捷方法论进行日常开发，但只有少数人以正确的方式进行。你询问任何开发人员，他们中的大多数人不知道为什么他们要在公司或客户要求他们这样做的情况下使用敏捷开发。

在软件开发方面保持敏捷是一件好事，但只有在你做得正确的时候。有许多成功案例可以获得灵感，但获得灵感与提高效率有很大不同。

在即将发布的内容中，我将讨论如何在开发过程中保持敏捷的同时提高效率。

背景

如果我必须快速概述一下敏捷是什么，我们通常会遵循一般称为冲刺(sprint)的开发周期，这些周期是固定的。这是持续的基础，目标是在每个冲刺(sprint)结束时实现、测试和部署特定的工作单元。 

敏捷应该为你做什么

有效的计划，隔离和问责制

这些是我们敏捷哲学的三大基石。我们事先计划好我们的工作。我们将工作细分为适当的任务，这些任务可以在一个冲刺(sprint)中实现，测试和部署，并将多个任务包含在用户故事中。用户故事通常跨越冲刺(sprint)。我们单独跟踪每项任务的进度，端到端完成的责任是受让人的责任。

敏捷阶段

通常，敏捷软件开发生命周期有3个阶段。

• 冲刺(sprint)前
• 冲刺(sprint)期间
• 冲刺(sprint)后

了解究竟应该做什么以及什么时候能够产生最大效果非常重要。据我所知，根据您的项目/产品需求调整传统的Scrum流程非常重要，因为上述3个角石得到了适当的维护。

冲刺(sprint)前

我们在冲刺(sprint)开始之前跟随的新冲刺(sprint)的唯一活动是冲刺(sprint)计划，其中包括以下活动

容量规划

这项活动是关于我们在特定冲刺(sprint)中可以做多少工作的。

我们所做的

• 通过考虑计划的假期和公共假期，清楚地阐明团队/个人能力。
• 根据团队的集体可用性确定最佳工作分工。而不是通过取消休假/根据总工作重新安排重要的培训来操纵可用性。

它有什么帮助

• 这使我们能够全面了解团队在特定冲刺(sprint)中可以完成的任务，并有助于正确分离工作。

任务估算

当我们从这个活动开始时，我们确保已经决定了在这个冲刺(sprint)中必须达到的目标（也称为修饰）。

我们所做的

• 我们完成了所有预定义的任务，并尝试提供完成所需时间的估算。我们遵循一种计划扑克的系统，在这个系统中，我们匿名地从每个人那里获取任务的估计值，并与大多数人一起前进。
• 最后，如果整体工作超过集体能力，我们会根据个人能力（而不是技术实力）将任务分配给团队成员，并将工作移动到积压工作（我们保留所有计划但未分组的工作的地方）。

它有什么帮助

• 它确保我们阻止创建对特定资源的未来技术依赖性，并且每个人都可以做好工作。
• 这也有助于我们保持积极的团队礼仪，促进工作生活平衡来。

 在冲刺(sprint)期间

通常，您会认为此时间仅适用于估算的任务并完成计划的工作。但请相信我，你不会错的更多。这是重大举重应该发生的时间。

修饰

在这里，我们介绍Scrum主管/团队负责人（又名技术顾问）和项目/产品/项目经理（又称股权持有人）的角色。我们在这里做的将决定下一个冲刺(sprint)将如何开展。

我们所做的

• 技术顾问和利益相关者将聚在一起，根据项目/组织的目标和优先事项，计划作为下一个/未来冲刺的一部分提供哪些工作。
• 利益相关者帮助设定每个单独工作项目的验收标准，并且技术顾问负责将它们分离成可以作为冲刺的一部分交付的孤立任务。
• 技术顾问负责为任务添加适当的描述，并捕获上述验收标准。 

它有什么帮助

• 这使我们对即将开展的工作有了全面的了解，并有助于其适当的隔离。
• 由于我们已经完成了所有计划，我们可以避免接受ad-hoc / mid 冲刺(sprint)任务，这些任务通常是来自其他团队的协作请求或紧急不切实际的客户要求（通常对于客户而言，每个要求都非常紧急）。
• 它为团队提供了在实际开始工作之前加强新技术的机会，因为他们对将来可能需要做的工作有了一个愿景。

每日站立会议

敏捷方法的重复但非常重要的部分，特别是Scrum。

我们所做的

• 在开始工作之前的每一天（理想情况是大约上午9点到10点），整个团队聚在一起讨论他们工作项目的当前进展。
• 这里有三点。
  • 我昨天做了什么？
  • 我今天打算做什么？
  • 有阻滞因素吗？

它有什么帮助

• 让每个人都了解整个冲刺(sprint)进度，并提供可能由于任何原因而延迟交付的早期工作指示。
• 通过提供一个论坛来协助团队解决一个开发人员与另一个开发人员的依赖关系。

 冲刺(sprint)之后

这是我们回顾冲刺(sprint)最后一次做什么的时候，我们怎样才能让自己更好。

冲刺(sprint)演示

顾名思义，这是我们聚集在一起并演示我们所处理过的东西的地方。当我们有多个更高级别的利益相关者，如产品负责人，参与经理等，深入参与该项目时，这一部分尤为重要。对于规模较小的团队和孤立的团队，我建议将其作为一项可选活动，但仍建议团队完成演示。

我们所做的

• 技术顾问提名应该在冲刺(sprint)结束时演示的工作。个人开发人员负责他的演示部分。
• 对于多个演示功能，整个会议不会超过1小时，对于单个大功能，整个会议将不超过30分钟。

它有什么帮助

• 每个人都知道作为商定工作的一部分所取得的成就。开发人员可以了解作为演示任务的一部分实现的任何可重用代码，这些代码是可以利用的。
• 高级管理层可以了解项目/产品交付的时间，并为他们提供市场信心。

冲刺(sprint)回顾

对于几乎每个开发团队来说，回顾都是敏捷过程的继子。大多时候它被忽略了。回顾是另一个不应该被忽略的重要部分。通常我们从每个团队成员那里获得3种输入。什么进展顺利，什么可以做得更好，任何立即行动项目。典型的回顾不应超过1小时。

我们所做的

• 浏览冲刺(sprint)的工作项目，看看是否有任何事情蔓延到下一个冲刺(sprint)。我们捕获溢出的原因并确保它不会再次发生。
• 打开以前冲刺(sprint)可以做得更好的几点，并讨论我们是否有任何进展。
• 接下来，我们走过桌子，向每个开发人员询问他们对哪些进展顺利，哪些可以做得更好以及任何即时行动项目的看法。

它有什么帮助

• 这确保了我们在流程和开发方面走在正确的轨道上。说出不顺利的事情，尤其有助于我们在将来避免同样的问题。
• 帮助我们确定可能正在拉低所有交付速度的持续趋势和外部因素。

总结

基本上整个敏捷过程就像减肥一样。当你开始时，一切看起来都很困难，目标看起来很难实现。你必须牺牲很多东西才能保持正轨，但是一旦你开始看到结果，你知道你正朝着正确的方向前进。

我没有在这里讨论过多项内容，例如关于Velocity和Burn Down图表的讨论，或者团队正在进行量化团队士气、动机和其他参数的会议。我只是相信花时间在那方些面并不是很有成效。

如果你曾经在敏捷模型中工作过一段时间，你可能已经遵循了上面提到的一些东西，但是你仍然在这里，因为你看不到正确的结果。如果你的团队致力于遵循上面提到的每一件事情，你一定会见证每一次按时完成工作的奇迹。

 

原文地址：https://www.codeproject.com/Articles/1274792/Being-Agile-The-Efficient-Way