项目管理和敏捷项目管理_设计敏捷项目，第4部分-CSDN博客

项目管理和敏捷项目管理

如果您将敏捷视为计划的一部分，那么每个团队都必须拥有自己的敏捷方法。为什么？因为每个团队都有自己的风险和问题。您无需为任何人标准化敏捷。如果您像对待成年人一样对待人们，并解释所需的原理（一直在使用软件并显示相互依赖），提供培训或他们需要的其他任何资源，您很可能会得到想要的。

这就是为什么我为并置且可以使用任何方法进行敏捷开发的团队编写“ 设计敏捷项目”（第1部分）的原因。设计您的敏捷项目，第2部分适用于面临许多挑战但并置在一起并且可以应对这些挑战的团队。设计敏捷项目，第3部分适用于在地理上分散并且必须考虑如何做的团队。

在该计划中，您需要的是让每个团队始终交付。该程序希望尽可能接近连续交付。您可以减少相互依赖关系或为它们进行计划。您当然可以暴露它们。

您是否看到过杰森·叶（Jason Yip）的推文（@jchyip），他在这条新闻中说：“大型组织……失去弹性是因为反馈机制……具有太多的延迟和失真层。”

这就是为什么您不能为程序中的任何团队标准化任何东西的原因。为什么？程序需要弹性。它需要能够提前且经常发布。仅仅因为它是一个程序并不意味着它不需要能够获得反馈。

每个团队都必须了解以下原则：

团队使用敏捷和精益原则。管理层将团队中的人当作成年人。团队会审视自己的问题，并设计自己的敏捷/精益方法，始终牢记他们需要及早交付的想法。

现在，让我们谈谈要将这些团队融合到程序中时会发生什么。

您可能会认为事情从计划经理或核心团队中滚了下来。不在我的世界里。这是每个团队的自主权，每个团队如何决定如何实现其敏捷或精益方法的能力的关键。

团队是该计划的核心。所有团队：核心团队，技术团队，核心团队代表的团队。

这是对传统过程思维的一种转变。这是对传统程序管理思想的改变。这种想法要求团队已经知道如何进行敏捷，并且对程序是新的，而不是敏捷。这种想法也意味着程序经理是仆人领导。

在程序中，您将具有相互依赖性。您要最小化它们。你是怎样做的？通过减小批处理大小，每个功能的大小。通过将功能与计划路线图进行协调。而且，通过查看每个功能的价值，而不是其成本（估算）。

这意味着团队需要变得擅长交付而不是估计。这也意味着产品所有者需要非常擅长为团队创建排名的待办事项并进行更改。这意味着该程序需要一个可以并且确实会发生变化的路线图。

记住，敏捷是指改变的能力，因为团队是按固定的时间间隔完成的，无论这些间隔是迭代还是团队都在工作。

如果您想为刚加入敏捷或精益团队的团队准备一个程序，该怎么办？您可以在程序上执行任何操作。您需要评估您的风险。让我们看一下Cynefin框架，以了解如果您的团队不熟悉敏捷，您可能会将风险置于何处。

如果您的团队刚接触敏捷，并且都集中在一个物理位置，并且他们知道开发中的产品的领域，即您仅更改他们的开发方式，也许您只是在框架的复杂部分。您正在改变程序的文化。

但是，如果您有不熟悉产品领域的新敏捷团队，并且在地理上彼此分布或分散，并且想要过渡到敏捷，您是否看到自己可能处于混乱状态？框架？您没有办法知道风险吗？

那要困难得多。

让我给你举个例子。想象一下，您正在与拥有15人开发团队的欧洲开发人员合作。他们的团队中只有程序员。他们从未与测试人员合作过。为什么？他们从未见过这样做的必要。据他们说，到目前为止，他们已经取得了成功。

您位于产品管理所在的纽约。您知道产品领域。开发人员？好吧，也许没有那么多。

几年前，我咨询了一家拥有如此精确组织的公司。他们将“革命化航空航天”。只有产品经理才能了解航空航天信息。开发人员没有领域专业知识，而且距离几个时区。开发人员以前曾一起工作过，但从未与测试人员一起工作过。他们从未见过这种需要。他们以前从未研究过受管制的产品。

当我建议他们“未知的未知数”，并且他们的风险比他们想象的要高时，高级管理层嘲笑我。我告诉他们是的，敏捷很好，但是我认为他们应该对看板使用一到两周的迭代来暴露瓶颈。

他们无视我的建议。该公司进行了四个星期的迭代，花了一大笔钱，在18个月后没有产品可以展示。哦，开发人员用了诸如“重构”，“ TDD”和“ BDD”之类的词。他们所做的是BDUF（前期大型设计），因为他们不知道自己在做什么。公司倒闭了。

当不是每个人都知道“敏捷”是什么，创建新产品，引入如此多的文化变革时，您会怎么做？

不要惊慌！您以降低风险的方式工作。

请继续关注第5部分。

翻译自: https://www.javacodegeeks.com/2014/04/design-your-agile-project-part-4.html

项目管理和敏捷项目管理