微服务敏捷开发_敏捷（微）管理

微服务敏捷开发

敏捷开发是否使您的开发团队感到恐惧？

几年前，我刚接触的一家公司一直在推动敏捷开发的需求。 经过无数次会议，讨论甚至是培训之后，每个人都很兴奋，随时准备出发。

但是，在敏捷发作后仅几周，我问了一个开发人员，他是否喜欢这种新做法。

他未经过滤的，诚实的答案（按照他通常的方式-有时是滑稽的方式）是：“嗯，这只是微管理的另一种方式”。

在接下来的几周里，我发现他并不孤单。 实际上，每个开发人员（其中一些正在寻找出路）都具有相同的感觉。

为了将来避免出现此问题，我在继续与该团队合作时学到了一些收获。

不要忽略早期的危险信号

正式分配给该公司15分钟的行业标准的每日站台服务通常会用完-有时需要一个小时或更长时间。 大团队，您可能会猜到？ 不，站立的人数总是少于10人。

站立时间过长通常是癌症可能会在敏捷团队中设立的第一个危险信号之一，并且事情越快恢复原状，癌症接管整个团队的机会就越少。

在参加了这个特殊团队的几次站起来之后，很明显他们为什么要花这么长时间。 迫在眉睫的是，为什么开发人员会感到如此的微管理……

微观管理者不应运行站立式

我认为，主要问题是由错误的人来推动站台活动-即，分配给该项目的任何PM。

就其性质而言，实际上往往是其职务描述，许多项目经理都是微观经理。 尽管这对于他们选择的职业来说可能是一件好事，但这意味着他们更有可能将讨论引向过多的细节，尤其是在解决障碍和按时完成任务方面。

对于开发人员而言，早上站立起来变得有些难了，他们能够期待每天早晨参加第一件事。 不用说，他们基本上开始害怕上班了。

无论是主持人，团队领导者还是其他人，无论主持人是谁，他或她基本上应该只是熟悉的声音来开始会议，或者是沉默的笔记记录者。 如果他或她不能将自己限制在这个角色上，那么可以选择其他人代替。

这真的是敏捷开发吗？

该团队还有其他重大问题，例如没有投票会议。 项目经理和业务分析人员将创建项目里程碑，将故事包裹起来，然后将开发人员分配给该项目。

意识到这个团队根本没有从事敏捷开发并没有天才。

不幸的是，这并不少见。 公司可能声称自己是一家敏捷商店，但无论是否有意，现实往往都大相径庭。

这全都归功于TRUST

这个团队的开发人员没有感到被重视，这是正确的。 他们在几个部门之间产生了明显的不信任感，这种不信任感完全是没有根据的。 这些都是（过去）都是优秀的开发人员，他们值得微管理环境无法提供的尊重和信任。

就我个人而言，我更喜欢一种较为宽松的敏捷开发风格，每周利用最多3个站立姿势，无任务的故事以及其他可以使微观管理者拔头发的做法。 我偏爱这种风格的部分原因是因为我觉得它灌输了这个特殊团队缺少的信任感。

我想与任何新团队分享以下指导原则：我们都是专业人士，而且我们都是成年人（除非另有证明）。 该原则是我的承诺，即不会对其进行微观管理，但我希望他们能够以专业的方式完成工作。

因此，简单明了地，您是否相信开发人员以专业的方式完成工作，不是吗？

当然，每个团队都有自己的细微差别。 因此，您团队中需要有人能够确定当前应该遵循的路径。

是时候重新评估您的敏捷实践了吗？

就像上面关于公司的故事所说明的那样，开始评估当前状态的好地方就是与开发人员交谈。

询问他们是否感到自己被重视和信任，或者是否感到受过微观管理。

如果您认为自己是一家敏捷商店，但是听到一些倾向于后者的答案，那么该是时候认真客观地看一下您的敏捷实践的时候了。 之后，不要害怕进行必要的调整，甚至进行较大的更改。

从长远来看，整个团队将变得更有生产力，更快乐，而且，作为奖励，他们在工作来面对那些早上站立时不会感到恐惧。

翻译自: https://www.javacodegeeks.com/2016/01/agile-micromanagement.html

微服务敏捷开发