设计敏捷项目，第5部分

最新推荐文章于 2024-11-03 11:01:20 发布

danpu1174

最新推荐文章于 2024-11-03 11:01:20 发布

阅读量113

点赞数

文章标签： java python 项目管理数据库编程语言

这篇文章是您在担任程序经理时的工作，并不是每个人都知道“敏捷”是什么，当您创建新产品时，当您介绍如此大的文化变化时？（在书中，我将更具体地讨论更改和做什么。这篇文章是重点。）

项目管理和计划管理都与风险管理有关。我们如何在敏捷项目或程序中将变更管理和风险管理结合在一起？

让我们再次回顾一下这些原则：

将产品发布的业务决策与始终可发布的软件分开。你想这意味着该软件可释放所有的时间，但你不必将其释放。我在“ 设计敏捷项目”第1部分中谈到了这一点。
将每个团队的功能保持较小，以便您可以查看吞吐量。
使用工程实践，因此在进行过程中不会招致技术债务。
了解释放频率的潜力。

你现在在做这些事吗？它们是您每天工作方式的一部分吗？如果没有，则需要进行更改。我将解决该程序需要做什么才能成功。

您的程序代表团队

从某种意义上说，该程序将代表团队的敏捷状态。可以将其视为康威定律所揭示的内容。（Conway说系统设计反映了设计者的沟通结构。）

您可能认为您需要标准化敏捷或精益方法。您可能认为您需要对如何敏捷化保持僵化。

您可能会错失该过程。您将对工程实践更加正确。

您需要为组织创造最大的弹性。这就是我的意思。

如果您拥有自治的协作团队，那么您将拥有独立的协作代码。如果您看一下Cynefin框架，您会发现它是正确的，没有太多麻烦。（我并不是说这很容易。只是它更有可能。）

但是，如果您的团队分布在地理位置上，或者您的团队不熟悉敏捷/精益，或者由于组织的其他成员还不太了解敏捷，您仍在响应所有程序的请求，该怎么办？那会发生什么呢？

您位于Cynefin框架的Complex或Chaotic一侧。也许您不将我们已经知道的良好实践用于程序管理，对吗？也许您不使用我们已经了解的项目信息，因为它们不会扩展到该程序。

这就是每个团队都需要审查第2部分和第3 部分的原因，尤其是如果它们是计划的一部分。

这就是为什么计划管理需要在核心团队级别上担任仆人领导。查看您管理的是哪个计划团队？一些项目经理认为他们正在管理技术团队。他们可能是。但是，他们可能需要管理除技术团队之外的核心团队。

这对程序意味着什么？

如果您想改变一切，那么您将有许多未知数。您不在 Cynefin框架的右边。您在框架的左侧。敏捷“开箱即用”是行不通的。
团队需要成为团队的一部分，然后才能练习敏捷。他们可以在一起为程序服务。而且，由于每个团队都设计其敏捷项目，因此除非团队要求更改，否则任何经理都不能更改团队中的人员。没有“ 我可以像棋子一样移动人 ”的事。经理为团队服务。
当心层次结构。他们会降低您的程序速度。什么是层次结构？ Scrum的混乱。强化冲刺，尤其是在其他发布团队与功能团队集成的地方，可以创建层次结构。为什么？因为说“我的工作完成了”太容易了。

如果您将敏捷项目设计为计划的一部分，则需要考虑：“我们如何确保我们在计划的其余部分始终如一地交付？”

这与最大化吞吐量无关。这是关于满足可交付成果的要求，并确保团队足够长地了解彼此之间的相互依存关系，然后才能与他们见面。然后，团队可以见面。

在程序中，您始终会相互依赖。总是。

设计每个团队的项目以在程序级别进行优化

如果您是计划的一部分，仅为团队设计项目是不够的。您还必须考虑程序的需求。

每个团队都需要问自己：“我们如何根据计划的需要交付计划其余部分的需求？”

您可能想看Phil Evans Ted的演讲， “数据将如何转变业务” 。在层次结构中，我们的交易成本过高。（在地理位置分散的团队中，我们的交易成本也过高，但这是一个不同的问题。）请注意他如何说“ 小就是美” 。呵呵呵呵。要爱它。

层次结构响应缓慢。它们在您不需要的地方设置了障碍。程序的问题在于它们很大。您想在可能的情况下减少较大的问题。一种方法是减少层次结构的影响。怎么样？通过尽可能不涉及层次结构。这意味着使用小型世界网络来解决团队之间和团队之间的问题。这样，您可以在存在问题的地方解决问题。

如果我运行了世界上所有的程序，该怎么办？

到处都有功能团队，而不是地理位置分散的项目团队。我更喜欢并置的团队，但我意识到在大型程序中并不总是可能的。（叹。）
拥有一个使用看板运行自己的核心程序团队（跨职能业务团队）。如果需要节奏，请使用一到两周的迭代来解决团队的问题。
对于技术程序团队，请使用看板运行自己。解决问题的节奏相同的想法。
让项目团队使用他们自己的方法来敏捷和精益，认识到他们的工作是减小批处理大小，始终保持可发布状态，并且在进行过程中不会招致任何技术债务。项目团队在敏捷方法上的自主权越强，彼此之间的协作就越多。他们将更加自由地探索自己可以做什么。
让程序架构师（向核心团队代表业务价值）一直在产品中寻找错误实施Conway定律的示例。这将有助于创造建筑业务价值。是的，还有更多要做的事情。
在职能领域鼓励实践社区。鼓励社区之间的异花授粉。普通的开发人员和测试人员都需要知道架构师的想法。开发人员需要知道测试人员正在解决什么问题，等等。组织和促进CoP可能是一项管理工作。这可能是程序管理工作。这是仆人的领导角色。绝对不是命令和控制角色。（“星期二下午4点。该学习了。”否。）这里的字眼是“鼓励”，不是强制性的。
作为项目经理，您需要知道何时需要人们进行更多的培训以了解可交付成果或这些交付成果是什么。他们了解流程吗？他们了解敏捷吗？他们了解反馈吗？球队需要教练吗？团队是否需要项目管理方面的帮助（是的，团队正在进行项目管理）？团队在敏捷还是精益方面需要帮助吗？团队需要人际交往技巧方面的帮助吗？团队是否需要工程实践方面的帮助，以帮助他们每天左右在代码库中提供干净的功能？

这些只是您对程序的可交付成果。这与您向管理团队提供的内容无关。

为团队保留这三个词：自治，协作和探索。团队需要自治。您关心的是他们的可交付成果。不是团队处于同步状态。

您关心团队之间的合作。您如何鼓励呢？具有小的功能和拥有明确定义的功能积压和路线图的产品所有者。团队检查签入完成的功能的频率越高，冲突越少，并且冲突越容易管理。你会以这种方式获得动力。我谈到了组织敏捷计划的动力，第3部分，大型计划要求仆人领导。

当团队（包括建筑师）猛增或探索团队认为选项是什么时，就会进行探索。或者，当团队之间互相交谈以解决问题时。团队首先可以自己解决问题。他们确实需要一个小的世界网络，并且知道您希望他们解决他们的问题。他们不需要解决问题的层次结构。这些人很聪明。那不是为什么要雇用他们？

好的，本系列以前的所有文章都是：

对不起，这个系列花了我这么长时间。旅行和我们的新房子受到干扰。成为产品负责人是万能的。