筒仓计算表格_小时，速度，筒仓团队和甘特兹

最新推荐文章于 2024-11-04 22:26:34 发布

danpu1174

最新推荐文章于 2024-11-04 22:26:34 发布

阅读量165

点赞数

文章标签：项目管理 java python 人工智能大数据

原文链接：https://www.javacodegeeks.com/2012/07/hours-velocity-silod-teams-gantts.html

版权

筒仓计算表格

我一直在和一些项目经理和项目经理进行电子邮件对话，后来他们变成了Scrum Master。总的来说，事情是这样进行的：

他们的组织认为敏捷是一个好主意
他们的组织认为Scrum是实施敏捷的好主意（因为他们不知道Scrum和敏捷之间的区别）
团队开始进行为期两周的迭代，直到迭代结束时才接近完成

但是，如果您揭开封面，您看到的并不是真正的Scrum。具有Scrum Master头衔的人正在做一些时髦的事情，例如：

为迭代准备甘特图，因此您可以看到谁将在什么时候做什么
根据小时预测速度（!!）
预测每人每天的故事点数
告诉团队他们可以为故事做些什么
还有其他与敏捷无关的陌生性

而且，这些团队仍然是孤立的团队。也就是说，有开发人员团队，测试人员团队，架构师领导的组件团队。这里有2人和3人团队，也许那里有4人团队。

这些Scrum Master /项目经理/项目经理的心在正确的地方。但是他们还没有接受过培训，他们也不知道敏捷可以为他们做些什么。因此，当他们的迭代为他们和他们的项目提供帮助时，他们环顾四周说：“为什么敏捷没有帮助我？”

如果您是其中之一，则可以选择。这是我的建议清单：

停止为团队预测任何事情。让团队像团队一样工作，这使我们进入了第二名。
转到跨职能团队。使他们的大小合理，例如5-7人。确保每个团队至少有一名测试人员。如果您没有足够的测试人员来解决问题，那就是一个障碍，您的团队将不得不为您的代码开发测试。但是2人的团队太小了。很多时候，由3个人组成的团队规模太小。测试团队是错误的，只是完全错误。测试人员和开发人员一起去。您需要一个跨职能团队来交付功能。
将您所有的架构师整合到功能团队中。如果架构师多于团队，那么架构师就太多了。（是的，我的一位通讯员有这个问题。）

现在，您的团队可能可以一起工作。您，作为敏捷项目经理/以前的Scrum Master，请远离中间！

现在，当您召开迭代计划会议时，这就是您要做的。您要求产品负责人介绍故事，并询问团队是否可以为该迭代做出故事。而已。您不承诺，团队承诺。团队可以估计，但是团队会做出承诺。如果您开始预测速度并且开始预测团队可以提交的故事，那么您就没有敏捷。您正在迭代中进行命令和控制。
哦，如果有人开始告诉别人，“吉姆，那是你的故事，苏，那是你的故事，”那个人g住了。好吧，也许这有点极端。但是只有一点。记住，想法是团队致力于故事，而不是一个人。您可以说的是：“作为一个团队致力于我们的故事是否符合我们的最大利益？请记住，我们要确保所有故事都在迭代结束时完成。这意味着必须进行测试。并且，必须完成所有用户体验。（以及其他任何针对您产品的特殊操作都必须完成。）如果某人是专家，那么其他所有部分会如何处理？这有助于我们完成所有故事吗？” 那你安静您可以随时为回顾提供便利，并帮助人们从发生的事情中学习。
在迭代过程中，如果有人想知道给定的团队成员正在做什么，则可以说“看一下董事会”。如果该人想通过看甘特树了解更多信息，则可以说：“不，我们没有敏捷的甘特斯。” 如果该人在您的薪水单上签字，您可以提醒该人每两周进行一次演示。如果这个人坚持不懈，您可以问真正的问题是什么。因为如果那个人看着正在工作的人，那么那个人不会看到团队中的每个人都在头脑冷静吗？寻找人们想要的信息，并找到另一种方式来传递它。
如果您无法查看实际情况，请考虑在您的迭代中添加看板，以查看是否存在瓶颈。许多组织在某些地方或其他地方人手不足，在添加看板之前，看不到它。看板可让您可视化流程。
确保在每次迭代结束时进行回顾。每一次。回顾会为您提供比您所知道的更多的帮助。每次复古后选择一件要处理的东西（好的，也许最多三件事情），然后看看您的改进速度如何。

对于团队来说，关键是要变成自我指导的团队，而不是经理领导的团队。团队必须对自己的工作负责，而且要快速。他们必须认识到自己的障碍。

对于许多这样的团队来说，主要障碍之一是故事太大。他们没有意识到这一点，因此他们尝试在迭代开始时处理太多故事。他们无法完成所有任务，因此无法获得信誉，并且在迭代结束时还有未完成的工作。好吧，这让每个人都感到沮丧。谁是“不良”估算者？

也许没人如果故事较小，或者如果有足够大的团队围绕这些故事，则这些团队可以在迭代中完成故事。但是，要一个2人团队完成一项需要6人团队1周才能完成的任务，这真是太疯狂了。当然，我认为一个由6人组成的团队花费1周的故事实在太大了。

因此，如果您属于这些敏捷程度不高的团队之一，请振作起来。首先，你并不孤单。就像你一样，世界各地都有人。如果您的管理层不允许您接受培训，请开始阅读。我敢肯定会有关于其他阅读内容的评论。

这是我的阅读建议：

加入scrumdevelopment组，这是一个Yahoo组。那里有很多免费的建议。很多都很好。听Ron Jeffries所说的话。

管理它！您的现代实用项目管理指南。我为您提供了大量有关促进项目管理的想法。（是的，您可以在亚马逊上购买我的书。但是您只能在Prag网站上购买电子版本，因为那样您可以免费获得更新。）

探索Scrum：基础知识。 Rawsthorne和Shimp带您了解Scrum的细节。

参考：我们的JCG合作伙伴 Johanna Rothman在《产品开发管理》博客中的小时，速度，筒仓团队和Gantts 。