敏捷开发人员结构_开发人员可以在敏捷外观方面发表意见的4种方法

敏捷开发人员结构

敏捷已成为开发软件的默认方法。 有时，似乎每个组织都在做（或想做）敏捷。 但是，许多公司没有尝试改变其文化以使其变得敏捷，而是试图将诸如scrum的框架强加给开发人员，寻找提高生产率的神奇方法。 不幸的是，这造成了一些不好的体验，并使开发人员感到敏捷是他们宁愿避免的事情。 遗憾的是，如果正确完成，开发人员及其项目将从参与其中受益。 这有四个原因。

敏捷，回到基础

使开发人员不惧怕敏捷的第一种方法是回到其基础知识，并记住真正的敏捷性。 许多人将敏捷视为Scrum，看板，故事要点或日常站立的同义词。 尽管这些是敏捷保护伞的重要组成部分，但这种感知使人们远离了敏捷的原始精神。

回到敏捷的起源就意味着要研究《 敏捷宣言》 ，而我认为最重要的部分就是引言：

我们正在探索通过开发软件并帮助他人开发软件的更好方法。

我坚信不断的进步，这句话引起了我的共鸣。 它强调了成为敏捷团队的一员时具有成长心态的重要性。 实际上，我认为这种观点可以解决团队采用敏捷时可能面临的大多数问题。

Scrum对您的团队不起作用吗？ 是的，让我们发现一种更好的组织方式。 您正在跨多个时区的分布式团队中工作，而每天站起来不理想吗？ 没问题，让我们找到一种更好的交流和共享信息的方式。

敏捷就是灵活性，并且能够适应变化，因此要开放思想和创造力，以发现更好的协作和开发软件的方法。

敏捷指标是改进而非控制的一种方式

确实，敏捷是关于采用和拥抱变化。 度量标准在此过程中起着重要作用，因为它们可以帮助团队确定其是否朝着正确的方向发展。 作为敏捷开发人员，您希望指标提供团队支持其决策所需的数据，包括是否应更改方向。 从事实和经验中学习的过程被称为经验主义，敏捷的三个Struts很好地说明了这一过程。

不幸的是，在我工作过的大多数团队中，项目管理人员都使用度量作为衡量团队绩效的指标，这使团队中的人们害怕实施更改或偷工减料来满足期望。

与其使用指标来衡量团队的绩效，不如与管理层合作以找到更好的方法来定义成功对团队的意义。

开发人员的力量在团队中

作为敏捷团队的一员，您拥有比想像中强大的力量来帮助建立一支具有巨大影响力的团队。 丰田生产系统很早就意识到了这一点。 确实，丰田公司认为，员工而不是流程是制造优质产品的关键。

这意味着，即使团队使用了最佳的流程，但如果团队中的成员彼此之间不适应，团队很有可能会失败。 作为开发人员，请花时间在团队内部建立信任并了解激励其成员的动机。

如果您对如何执行此操作感到好奇，建议阅读Alexis Monville的《 从内部改变团队》一书。

使开发人员可见

任何敏捷方法中的很大一部分就是使信息和工作可见。 这通常被称为信息辐射器 。 斯坦利·麦克莱斯特（Stanley McChrystal）将军在他的《 团队的团队》一书中解释了美国陆军如何将自己从一个在生产率方面进行了优化的组织转变为一个可以适应的优化组织。 我们从他的书中学到的是我们生活的世界已经改变。 提高生产力的问题大部分在20世纪末解决，而企业现在面临的挑战是如何适应不断发展的世界。

我特别喜欢麦克莱斯特将军对他如何创建功能强大的信息辐射器的解释。 麦格莱斯塔尔将军接任联合特种作战司令部时 ，开始每天与其高级指挥官举行电话会议，以讨论和计划未来的行动。 他很快意识到这不是最佳选择，而是每天早晨开始为全球7,000人进行90分钟的简报。 这使每个工作队都能获得完成任务所需的知识，并使他们知道其他工作队的任务和情况。 麦克莱斯特将军将其称为“共享意识”。

因此，作为开发人员，您如何才能在团队中建立共同的意识？ 首先简单地分享您的工作和/或计划进行工作，并对同事的工作感到好奇。

---

如果您在开发组织中使用敏捷，您认为它的主要好处是什么？ 而且，如果您不使用敏捷，那么哪些障碍会使您的团队退缩？ 请在评论中分享您的想法。

翻译自: https://opensource.com/article/19/10/ways-developers-what-agile

敏捷开发人员结构