项目管理和敏捷项目管理_设计敏捷项目，第1部分

项目管理和敏捷项目管理

我越看到团队过渡到敏捷，就越相信每个团队都是独一无二的。 每个项目都是唯一的。 每个组织环境都是唯一的。 您为什么要采用不适合您情况的现成解决方案？ （我写了Manage It !，因为我通常相信上下文驱动的项目管理方法。）

Scrum的优点之一是对其进行检查和适应的方法。 不幸的是，大多数人没有将XP工程实践与Scrum结合使用，这意味着他们不理解为什么向敏捷过渡失败的原因。 实际上，他们认为没有工程实践的Scrum本身就是敏捷的。 您听到几次“ Scrum / Agile”？ （我听过太多次了。方式太多了。）

我喜欢看板，因为您可以看到工作地点。 “我们正在处理许多功能。” 或者，“我们的测试人员永远都做不到。” （我讨厌听到这个消息。讨厌它！这是一个例子，说明人们没有像跨职能团队那样努力完成工作。让我发疯了。但这是一种症状，而不是原因。）看板通常会提供更多数据比Scrum板要好。

是否有指导人们过渡到敏捷的准则？ 还是程序中项目的准则？ 可以有原则。 让我们来探索它们。

第一个是从了解最终目标开始，首先了解产品的发布方式。 我非常喜欢将代码不断传递到代码库中。 您能以这种方式交付产品吗？ 也许。

您的产品如何发布？

我希望只有两种产品：在软件即服务中不断发布的产品，以及很少发布的带有硬件的产品。 由于发布成本高，很少发布的版本会以这种方式发布。 但是，发布频率是连续的：

释放频率的潜力

发布产品的价格是多少？ 发布费用将改变您决定何时发布产品的业务决策。

您要将发布产品的业务决策与使软件可发布分开。

也就是说，连续体越靠左，如果需要的话，您就可以将您的发行版与您的迭代或功能结合得越多。 您的项目投资组合决策更容易制定，并且只要您想完成，就可以经常进行每个功能或迭代。

连续体越靠右，就越需要将发布的业务决策与完成功能或迭代分开。 连续体越靠右，能够定期完成就越重要，这样您就可以做出良好的项目组合决策。 为什么？ 因为您经常把钱花在长提前期项目费用上。 您必须尽早做出决定，以承担硬件或非经常性工程费用。

您的产品有多复杂？

让我们看一下Cynefin模型，看看它是否对如何考虑我们的项目有建议：

我将在以后的文章中进一步讨论您可能想使用Cynefin模型来分析您的项目或程序。 抱歉，这是一个系统，我无法一劳永逸。

同时，请看一下Cynefin模型，并查看您认为可能会落入模型的位置。

您是否有一个并置的跨职能团队想要过渡到敏捷？ 您处于敏捷的“已知已知”情况。 对于您的产品，您可能处于“未知未知数”的情况。 您愿意使用工程实践并在一到两周的迭代中进行工作吗？ 敏捷或精益社区中的几乎所有事物都将为您工作。

一旦您拥有一个或两个以上的团队，或者您在地理位置上分散了团队，或者您位于上面的“发布频率潜力”图表的右侧，您是否会发现自己不再处于“复杂”状态或Cynefin模型的“明显”一面？ 您有太多未知数。

我们现在在哪？

这是我的原则：

1. 将产品发布的业务决策与始终可发布的软件分开。 无论您拥有什么产品，都希望该软件可以发布。
2. 了解您拥有什么样的产品。 您越接近产品发布频率的右侧，就越需要一个程序，就越需要看板来了解组织中的所有内容，因此您可以选择对它们进行处理。
3. 确保您的批量大小尽可能小，可以通过程序或项目完成。 功能越小，您看到的吞吐量就越大。 迭代时间越短，您从产品所有者和“企业”那里获得的反馈就越多。 您需要反馈，以便您可以学习，以便您的管理层可以管理项目组合。
4. 使用工程实践。 我对此不够强调。 如果您不使故事保持小规模，以便可以开发自动化的单元测试，自动化的系统测试，使用持续集成，围绕故事或配对进行学习，以及通常使用XP做法，那么您将没有敏捷提供的安全网。以可持续的速度练习。 您将开始想知道为什么您总是呼吸困难，加班，却永远无法做自己想做的事情。

如果您有技术债务，请在实施功能时开始一次偿还。 您没有一次累积全部。 一次还清一点。 或者，确定您需要一个项目来防止延迟发布的成本 。 如果您是技术团队，则可以选择专业。 没有人要求您提供自己的安全网进行估算。 不要这样做。

这篇文章是为更轻松的过渡，想要过渡的人，并置的人，知道多于未知的人准备的。 下一篇文章面向的是鲜为人知的人。 敬请关注。

参考： 设计敏捷项目，第1部分，来自我们的JCG合作伙伴 Johanna Rothman，在《 产品开发管理》博客中。

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

项目管理和敏捷项目管理