认识达内从这里开始

随着互联网的不断发展，敏捷开发也被越来越多的程序员掌握，下面我们就通过案例分析来了解一下，影响敏捷开发效果都有哪些问题。

1、团队凝聚力差

换句话说：团队没有形成一个有凝聚力的组织，而是各自为战

原因

个体将自己的目标置于团队需求之上

不同团队成员就团队该如何完成工作的问题存在冲突

团队中的工程师没有发自内心产生的团队合作动机

有可能出现这种情况的环境

团队中的许多成员是在不同时间加入进来的，没有和其他人“打成一片”

牛仔开发者文化，每个人都优先在为自己考虑

如何打破这个障碍

让每个人都负起团队合作的责任，例如为团队OKR做出贡献

鼓励团队成员以建设性的方式评论彼此的工作

每日scrum或站会之外再举办一些定期社交聚会

成功打破障碍、实现敏捷后，可以看到这样的成果……

整个团队会作为一个整体SLO目标，获得整体奖励，而并不会过分强调个体表现。在团队内部，成员之间依旧可以排定荣誉级别，但外在的奖励(来自上级和外部)总是属于团队整体的。

2、缺乏冗余

换句话说：团队人手不足时没有后备力量

原因

每个人都被要求留在自己的车道上，或者他们自己就更愿意这么做

成员职责被细分到非常具体的级别

有可能出现这种情况的环境

其实很多时候都会有这种情况发生，没有特别突出的场景

如何打破这个障碍

举办交叉培训课程，向更有经验的队友学习

实施相邻角色的工作轮换(例如，每个团队成员应将10%的工作时间花在非核心活动上)

在日常scrum中促进相关角色之间的交流，鼓励他们互相帮助

重复的角色(即2个或更多具有相同职责的成员)安排也是可行的，但这里也有风险，因为在没有设置常规任务边界时人们很容易干扰相同岗位的同事的工作

成功打破障碍、实现敏捷后，可以看到这样的成果……

一名混沌工程师突然离开了公司，剩下的成员平稳接手工作。他们有一些混沌实践的经验，并主动向其他团队寻求帮助。他们在下一个sprint中调整了工作负载，以将认知负荷保持在合理的水平上。

3、薄弱的学习文化

换句话说：不要重新发明轮子，只把工作做好就行了

原因

每个人都急着把事情做完，然后赶快回家

除了sprint结束时的强制性要求之外，敏捷流程中没有任何学习环节

有可能出现这种情况的环境

有的团队习惯了雇佣“专家”，这些专家认为自己已经了解世界的运转方式，并没有持续学习和改进的动力和欲望

领导层认为AAR和事后分析并不重要

如何打破这个障碍

分享在受人尊敬的公司中失败的故事来吓唬团队

建议在突发事件后增加深度学习课程

使用微学习工具，可在对认知负荷影响小的前提下分享改进想法

成功打破障碍、实现敏捷后，可以看到这样的成果……

每个团队成员都在努力寻找和分享关于如何改进事件分析任务的想法。当团队聚在一起讨论事件时，这是很有用的。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。