敏捷发布路线图_路线图和战略规划在敏捷项目团队中的作用

敏捷发布路线图

关于如何组建团队来处理软件项目已经进行了大量的研究和开发。 这些新团队有不同的版本。 一些练习Scrum，一些使用看板，敏捷一词就泛滥了！

我们今天所知道的大多数方法论都是对软件团队中高故障率的一种回应。 Standish Group在1994年的报告中以《混沌报告 》为标题，该报告著名地记录了只有16.2％的软件项目按时且在预算内完成。 这导致了研究开发过程的许多新方法和创新方法，包括1995年的Scrum和1996年的极限编程 。

通常，这些技术现在统称为敏捷方法，因为它们都具有相似的价值：将团队放在首位并确保他们能够响应开发过程中发生的更改，而不是遵循严格的计划。

敏捷方法可以为采用它们的团队带来巨大利益。 团队之间的协作更加紧密，这将导致更好的解决方案和最终产品更可能满足用户需求，而积极反馈和批评也可能导致团队成员的积极性增加。

但是，采用敏捷方法时经常会错过的一件事是高层或战略计划。 没有战略计划，团队可能会开始偏离轨道，将精力集中在对业务而言最不重要的事情上或丢失的事情上。 否则，如果工作流程感觉像是持续不断，那么团队可能在完成冲刺或里程碑后失去成就感。

我当然不建议我们放弃敏捷，但是我认为敏捷过程中有一个我们经常会错过的计划阶段：战略计划或长期计划。 通过将集体战略计划纳入敏捷流程，我们可以帮助降低开发团队中偏离轨道或失去动力的风险。

战略计划

战略计划是对企业长期目标和期望的高度概括。 良好的战略规划应涵盖广泛的范围，而不必赘述不必要的细节，它应尽可能精简。

战略计划的主要目的是发展共识，消除人们可能持有的任何错误假设，并确定目标，优先事项和利益相关者。 因此，它完美地融入了其他敏捷流程，例如，冲刺计划。

除了精简之外，还应该迭代。 当我第一次遇到战略计划时，我认为它违反了《敏捷宣言》的原则：在敏捷计划旨在灵活应对计划不可避免的变更时，花时间计划似乎毫无意义。

但是战略计划既不是项目的指南也不是项目的合同。 这是一个抽象的摘要，因此它应该具有与项目其他资产相同的灵活性。 应该定期重新审查该计划，以了解愿景，优先级和目标是如何变化的。

保持战略计划可行是很重要的。 该计划将导致的行动对于团队中的每个成员都是不同的。 迫使利益相关者保持一致，推动发展或激发跨部门合作是良好战略计划应采取的行动的一些例子。

项目路线图是在团队中实现战略计划的一个非常有用的工具。

项目路线图

路线图详细说明了团队或企业在未来几个月或几年中要完成的旅程。 可以为特定产品或项目创建路线图，但从整体上看，路线图同样有效。

他们专注于定义目标或抱负。 这有助于对一段时间内的预期结果达成共识。 此外，在路线图中，大问题被分解为里程碑。 这有助于确定任务的优先级和组织。

为了创建有价值的战略计划和路线图，重要的是要收集尽可能多的想法和观点。 这就是跨职能团队进来的地方。

跨职能团队

跨职能团队的确切含义是：一个通常在公司内执行不同职能或角色的人员组成的团队。 团队可以包括软件开发人员，经理，设计师，市场营销专家或客户服务代表。 价值来自于许多不同的观点和经验。

在会议期间寻求每个人的意见很重要，因为每个人都将能够以独特的方式解决问题。 由于开发过程遍历公司中的每个角色，因此战略计划也应如此。 为了确保每个人都有贡献的机会，应该给每个职能小组一些时间进行执行，在那里他们将从其他人那里获得信息，并在参与其中，他们将提供信息和见解。 这确保了该计划是多方面的，这意味着它将比侧重于单个议程的计划更加全面和包罗万象。

战略计划的要素

与跨职能团队进行战略规划会议时，有五个阶段可以帮助您了解：

目标和成功因素

目标或期望是企业要实现的目标：产品或服务的理想状态。 它们不一定特定于最终客户，而是应该从整体上考虑业务。

将每个目标分解成更小的工作量可能会有所帮助。 做到这一点的一种方法是从团队中每个部门或职能的角度来看待它。 每个职能部门将采取不同的行动来为团队做出贡献，从而实现其目标。

与目标一起，应该写出成功因素。 成功因素是指标或观察结果，它们将指示目标是否已实现。 这些将特定于他们打算评估的目标，并且对于团队中的每个成员而言都可能有所不同。 重要的是，成功的因素不能像合同那样。 他们在此阶段不应该设置估计。 取而代之的是，成功因素应确定可用于判断目标是否实现的指标。

一个示例目标可能是与特定角色或类型的客户发展更好的客户互动。 这个目标非常模糊，但可以分解为一些任务。

设计师可以研究如何改善外观以适合客户，客户支持可以评估他们如何更好地为客户提供建议或指导，技术团队可以推出满足他们需求的新功能。 一个明显的成功因素将是评估针对此类客户的产品/服务的销售或使用。

利益相关者，客户和交易

利益相关者是一群人或一群人，在实现目标时必须征求他们的意见。 在战略规划期间，应通过分析谁需要参与实现目标的过程来确定利益相关者。 识别利益相关者是战略计划中最重要的阶段之一，因为如果不与投资成果的各方合作，就无法实现目标。

在确定利益相关者时，重要的是要注意他们与目标的关系，以便每个人都了解谁负责流程的每个部分。 此外，整个团队在达成目标时应该知道谁是利益相关者，以便每个团队成员都知道他们应该向谁报告或从中接收输入。

一些利益相关者仅在某些阶段参与工作：一些将成为领导者，而其他一些则将由团队的其他成员来依赖。 企业应该旨在在所有利益相关者之间达成对目标的共识。

客户与交易并存； 客户是最终用户，交易是企业与那些最终用户之间必须进行的任何交换。 如果能够及早识别出客户，则可以更轻松地确保根据正确的用户需求来设计和开发产品或服务。 识别交易还可以从技术和人员管理的角度促进对基础架构的讨论。

回到客户参与的例子，利益相关者可以包括软件开发人员，设计人员和客户支持团队以及一些管理人员。 客户将成为目标角色，而交易将是产品或服务的营销以及企业与客户之间的持续参与。

建筑与基础设施

根据目标，此阶段将具有不同的权重。 它涉及评估需要对现有体系结构或基础架构进行的任何更改，以确保目标能够成功实现。 它既包含技术基础架构又包含业务基础架构，因此可以包含数据存储或员工等内容。

许多项目失败或被延迟，因为在此过程中没有对基础架构进行足够的早期评估，因此这是形成战略计划的关键阶段。

在我们的示例目标中，可能需要升级系统以应对更高的吞吐量或数据收集。 此外，客户支持团队可能需要扩大规模或接受一些培训。

重点和挑战

应该确定目标的优先级，以便对什么对业务最重要有共同的理解。 由于不同的团队成员对目标的优先顺序可能有不同的看法，因此讨论通常会很困难。 最终，此阶段的重要部分是对开始开发时目标应遵循的顺序有共同的了解。

在此阶段，实现目标时可能面临的挑战尚不得而知。 但是，通常会遇到共同的挑战。 通过讨论可能的挑战，可以提示团队进行进一步的研究或培训，在解决目标的特定部分时更改开发过程，或寻求专家的咨询。

客户参与目标中可能面临的挑战是对目标客户需求的误解。 可以通过进行研究和需求启发来缓解这种情况。

发布和最终用户

这是一个多方面的步骤。 在整个过程中可能会发生技术发布或部署，当用户可以使用新功能或产品时会发布业务发布，而在寻求潜在客户注意时会发布营销发布。 如果某些目标可以轻松分解为可以独立工作的部分，则它们适合增量发行。

与发布一样，重要的是弄清楚如何评估最终用户的目标。 这可能与上述成功因素有所不同； 它旨在确定最终用户是否对新产品或服务进行了很好的参与。 用于此目的的一项强大技术是A / B测试 。

目标示例可能涉及多个版本，包括一些新功能和设计更改。 使用A / B测试，团队可以评估目标客户与旧内容相关的新内容的使用方式。

将战略计划添加到您的敏捷开发流程中

敏捷开发方法非常有助于我们实现目标。 但是，如果不将它们与有效且协作的战略计划配合使用，那么它们通常会导致我们偏离轨道或失去动力。 通过使用跨职能团队和路线图，将战略计划纳入敏捷开发流程确实很容易。

翻译自: https://www.javacodegeeks.com/2019/02/strategic-planning-agile-project.html

敏捷发布路线图