让敏捷失败的N种方法
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
老邓聊开发
扫码关注公众号
扫码阅读
手机扫码阅读
敏捷已经从小团队小项目的范畴走向主流,但是否真正带来价值仍需探讨。本文从颠覆的角度,分析了敏捷失败的几个原因。
敏捷仅发生在开发团队
如果敏捷实践只在开发团队中发生,业务团队与开发团队之间缺乏有效沟通,开发团队将无法对业务目标负责,最终导致产品设计不合理和僵化。
缺乏自动化测试
自动化测试,尤其是测试驱动开发(TDD),经常被低估。没有自动化测试,代码质量和维护性将受影响,导致技术债务增加和敏捷性降低。
忽视代码质量
一些团队为了赶工期而牺牲代码质量,但这是错误的。低质量的代码会造成效率低下,并且难以维护和扩展。
需求质量不高
需求质量直接影响软件质量。市场上优秀的产品经理不足,导致需求分析不完整,功能设计不切实际,以及交付效率低下。
以项目制导向团队配置
项目制导致团队成员频繁变动,磨合成本高,不利于敏捷实践的持续和知识的积累。
不注重人才培养
IT企业常忽略员工培养,导致人才流失,而员工只有不断学习和提升技能,才能支持敏捷的实践。
将敏捷视为工具
将敏捷转型简化为工具和流程的应用是错误的,敏捷的核心在于个体和互动。
过度人员复用和模块复用
人员和模块的过度复用导致效率降低和业务响应速度变慢。
团队内部职能分化
团队内部职能分化过细导致工作交接频繁,引起等待和浪费,不利于敏捷。
更多详细内容将在作者的公众号中陆续摘录、发布。
老邓聊开发
老邓聊开发
扫码关注公众号
项目总延期怎么办?
通过目标拆解、任务分派、进度追踪与质量闭环,实现从计划到交付的全流程可控。
查看项目管理方案
老邓聊开发的其他文章
需求在变,还要写自动化测试吗?
当问一个团队为什么不写自动化测试的时候,往往有两种答案。一是我们的系统已经没什么变化,写测试没意义;
产品和开发是对头吗?
这两天平安公司产品经理和开发因为变态需求互殴刷屏了(且不论真假,我不大相信)。这里折射一个IT行业的普遍问题
九转大肠的组织设计
今天看到微信群里转了一张图片,内容如下:可以看出来作者对多个部门都有洗大肠专员这事儿深恶痛绝,认为是
依赖倒转以及为何要倒转
SOLID原则里面的D,就是依赖倒转原则。我们为何要依赖倒转?在面向对象中如何利用依赖倒转?
解决产品经理和开发团队撕逼
有个问题很有趣:有一块蛋糕两个人分,如何保证公平?很简单的答案是,让切的人后选。那么,在开发团队中,产品经理
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线