敏捷开发已成为软件开发的默认方式；有时，似乎每个组织都在做（或想做）敏捷。但是，许多公司并没有尝试改变他们的文化来适应敏捷，而是试图将 scrum 等框架强加给开发者，寻找提高生产力的神奇配方。不幸的是，这造成了一些糟糕的体验，并导致开发者觉得敏捷是他们宁愿避免的事情。这很可惜，因为如果做得正确，开发者及其项目将受益于参与其中。以下是四个原因。
敏捷，回归基础
开发者不害怕敏捷的第一个方法是回归基础，记住敏捷的真正含义。许多人将敏捷视为 scrum、kanban、故事点或每日站立会议的同义词。虽然这些是 敏捷保护伞 的重要组成部分，但这种看法使人们远离了敏捷的最初精神。
回归敏捷的起源意味着查看 敏捷宣言，以及我认为最重要的部分，即介绍
通过实践和帮助他人，我们正在探索更好的软件开发方式。
我坚信持续改进，这句话引起了我的共鸣。它强调了拥有 成长型思维模式 在成为敏捷团队成员时的重要性。事实上，我认为这种观点是团队在采用敏捷时可能面临的大部分问题的解决方案。
Scrum 对你的团队不起作用？好的，让我们探索一种更好的组织方式。你正在一个跨多个时区的分布式团队中工作，每天进行站立会议并不理想？没问题，让我们找到一种更好的沟通和共享信息的方式。
敏捷的关键在于灵活性以及适应变化的能力，因此请保持开放的心态并发挥创造力，以发现更好的协作和开发软件的方式。
敏捷指标是一种改进方式，而不是控制
的确，敏捷是关于采用和拥抱变化。指标在这个过程中起着重要的作用，因为它们可以帮助团队确定它是否朝着正确的方向前进。作为一名敏捷开发者，你希望指标提供你的团队需要的数据来支持其决策，包括是否应该改变方向。这种从事实和经验中学习的过程被称为经验主义，并且通过敏捷的三个支柱得到了很好的说明。
不幸的是，在我合作过的大多数团队中，项目管理部门使用指标来衡量团队的绩效，这导致团队中的人员害怕实施更改或为了达到期望而偷工减料。
为了避免这些结果，开发者需要控制其团队的指标。他们需要确切地知道正在衡量什么，最重要的是，为什么要衡量它。一旦团队对这些因素有了很好的理解，他们就可以更轻松地尝试新的实践并衡量其影响。
不要使用指标来衡量你团队的绩效，而是与管理层互动，以找到一种更好的方式来定义成功对你的团队意味着什么。
开发者力量在于团队
作为敏捷团队的成员，你拥有比你想象的更大的力量来帮助建立一个具有重大影响的团队。丰田生产系统很久以前就意识到了这一点。的确，丰田认为员工而不是流程是构建伟大产品的关键。
这意味着，即使团队使用了最好的流程，如果团队中的人员彼此合作不舒服，那么团队失败的可能性很高。作为一名开发者，投入时间在团队内部建立信任，并了解激励其成员的原因。
如果你对如何做到这一点感到好奇，我建议阅读 Alexis Monville 的书 从内部改变你的团队。
使开发者工作可见
任何敏捷方法论的重要组成部分是使信息和工作可见；这通常被称为 信息散热器。在 Gen. Stanley McChrystal 的书 团队的团队中，Gen. Stanley McChrystal 解释了美国陆军如何必须从一个以生产力为优化的组织转变为一个适应性优化的组织。我们从他的书中了解到，我们生活的世界已经发生了变化。在 20 世纪末，提高生产力的问题基本上得到了解决，而公司现在面临的挑战是如何适应一个不断发展的世界。
我特别喜欢 Gen. McChrystal 关于他如何创建强大的信息散热器的解释。当他掌管 联合特种作战司令部时，Gen. McChrystal 开始每天与他的高级指挥官通电话，讨论和计划未来的行动。他很快意识到这不是最佳方案，而是开始每天早上为全球 7,000 人举行 90 分钟的简报会。这使每个特遣部队都能获得完成其任务所需的知识，并使他们了解其他特遣部队的任务和情况。Gen. McChrystal 将此称为“共享意识”。
那么，作为一名开发者，你如何帮助你的团队建立共享意识？首先，简单地分享你正在做的工作和/或计划做的工作，并对你的同事正在做的事情感到好奇。
如果你在你的开发组织中使用敏捷，你认为它的主要好处是什么？如果你没有使用敏捷，是什么障碍阻碍了你的团队？请在评论中分享你的想法。
4 条评论