公司为了敏捷而犯下的十大错误

更新日期: 2022-08-18阅读: 788标签: 错误

敏捷(Agile)无处不在,似乎所有人都想变得敏捷,而如果你现在还没有自己的敏捷团队,那你得是上古恐龙级别的老古董。但是,一个组织并不会简单地就变得敏捷,本文中将列举组织为了敏捷而犯下的十类错误。

第十、从上而下地实施敏捷

作者所了解的一些从上而下的敏捷实施中,组织的管理层会通知团队要采用敏捷的方式开展工作,并列出了具体的时间和方式。但敏捷实际的意义在于团队通过自我规划来创建有价值的产品。管理层传达敏捷目标这一点没有问题,但为达到最佳效果,团队和管理层都应参与到具体实施中,一起踏上敏捷之旅。团队各不相同,产品也各有千秋,是时候让团队自己决定什么才是真正行得通的了。

第九、“实施”变革

和上一点类似,组织试图通过指导手册或者是凭空创建的工作流程来简单粗暴地“实施”敏捷的文化变革。这是不行的。组织的文化是在每一名团队成员的参与下,经过长年累月的积累而形成的。文化是无法轻易改变的。如要改变,管理层应以身作则,自觉遵守文化指导手册(最好是由员工协作编写的),展示预期行为,并对其他成员的模范行为给予鼓励,同时还需要保持耐心。

第八、聚焦输出

许多公司的敏捷团队完全将工作的重心放在了创造与交付产品上。他们关注上市时间和测试自动化,关注 CI/CD,以做到更快的交付。但这种把重心放在输出的做法是反敏捷的。如果你所交付的应用并不是客户需要的,那么交付再快也都没了意义。很多新功能都因为派不上用场而从没有人使用过。真正重要的是我们通过输出所能达成的效果。

第七、忽视客户和用户

很多敏捷团队对用户画像或客户需求只有模糊的概念。他们从不和这些关键的利害关系人接触,即使有定期演示或评审,也只是面向内部的利益关系人。而他们只要见到销量增长就会欢呼成功。但销量只是指标,它们不代表客户。团队创造的产品是为客户和用户服务的,我们需要让客户和用户参与进来。敏捷的意义就在于定期与你的用户一起验证产品。没有这层验证,你的敏捷之旅就是毫无根基的。

第六、敏捷仅面向 IT

人人常常误以为敏捷只适用于 IT,只有 IT 需要敏捷,组织的其他部分完全无需改动。这是忽略了团队内除了 IT 之外其他成员为提供用户体验而做出的贡献。没有大家共同的努力,客户不会得到满意的结果。IT 只是产品体验的一部分,而产品体验也是客户体验的一部分。客户对产品的体验还包含了销售、售后、政策法规以及第三方。在不断变化的环境中,最大化产品价值是所有人的共同目标。我们需要团队协作以及快速的反馈循环,我们都需要变得敏捷。

第五、敏捷只限于团队层面

敏捷的一大错觉是其只需应用于创造产品的团队。只要这些团队是敏捷的,那么一切就都不会有问题。但这是行不通的。团队在组织中工作,并会不断被组织所影响。当组织展现出反敏捷的行为时,只会给团队帮倒忙,甚至会给创造价值的团队带来潜在伤害。管理层、领导者、人力资源以及其他的成员都应鼓励团队,帮助他们成为更高效的敏捷团队。对于如何以敏捷的方式创建产品体验及达成目标方面,整个组织应该有统一的认识。

第四、敏捷只为更快的交付

“我们需要变得敏捷并更快地交付”。大型公司的顶层管理者也曾做出过这种言论,清晰地展示了他们对自己在说什么完全没有丝毫的认知。敏捷不是为了更快的交付。敏捷是意识到我们无法提前预知一切,所以便通过增量构建来和用户进行确认。敏捷是更快的反馈,是更好地了解下一步要做什么,是通过与用户的协作,更及时地了解什么会得到认可,什么不会。将注意力集中在更快的交付并无视反馈循环只会让你成为一个功能工厂,你在创建输出上非常在行,但你也只会创造出人们并不想要的结果。

第三、用瀑布式管理实施敏捷

敏捷不是通过漫长的研究、长期规划的阶段性工作流达成的。敏捷的工作方式是从传统“瀑布式管理”思考模式的一种明显的转变。团队不再会过度分析工作内容,而是会从产品的升级换代中学习。他们会更快地认识到到产品的价值,并找到更好的合作工作模式。在敏捷之旅的开始,你会为团队设定目标,并找到达成目标的最佳途径。你会从你所完成的工作中学到什么可行,什么是不可行的。你会和团队一起协作奋进。

第二、应用不变的流程及工具

最痛苦的一种变得敏捷的方式之一就是直接应用别人的东西。想象一下,团队如果按指示使用 Scrum,用预先配置好的工具比如 Jira,在固定时长的 Sprint 周期里以预设好的速度交付。这样的灾难场景在 SAFe 里就发生了,并且还扩大了规模,成了组织内部自上而下的敏捷实施。拿来主义并不适合 Scrum 和其他的敏捷方式。每个团队都是不同的,每个产品的应用场景也不尽相同。直接应用标准流程只会给团队套上枷锁。团队或许还会发展提升的空间,但如果没办法采取改进措施,那么他们的效率只会越发低下。敏捷方法的引入只是真正旅程的开始,通过这一步,我们应放开对团队的限制,并期望他们可以自行寻求进步。这才是敏捷真正的含义所在。不断的变化,不断的提升,挑战将会是新的日常。尽管这段路程看起来非常吓人。

第一、想要变得敏捷

组织常犯的第一大错误便是对变得敏捷的渴望。敏捷不应是目标,没有人会因为你是敏捷的而选择你的产品。对市场和你的股东而言,敏捷没有任何意义,这只是一个词语。非要说的话,敏捷还可能是有害的。因为你会暴露出自己已经落伍了,已经过时了,即使是起步最晚的,多数也早在五年前就到达了你所在的阶段。与其设法变得敏捷,组织应当将重点放在他们所希望造成的影响上,并设定达成预期影响所需要的目标。你应确保组织中的所有人都目标一致,应让人们都愿意为了这个目标拼尽全力。你还应帮助人们消灭前行道路上的障碍,无论是竖井、过于繁琐的过程还是任何其他形式的累赘。无论你想怎么称呼它都不重要, 因为你的用户和股东不会因为你称自己为敏捷就会高看你一等,他们只会根据你所造成的影响和你所带来的利润评价你的工作。

感谢 Matt DiBerardino 及 Erik de Bos。
英文原文:https://medium.com/awesome-agile/top-10-mistakes-organizations-make-to-become-agile-3a83536e3285

链接: https://fly63.com/article/detial/12024

解决Cannot read property range of null 错误

vue工程npm run serve/start/dev启动时,node_modules文件报:Cannot read property range of null 错误,该问题是babel-eslint版本更新问题导致的;

HTTP 400 错误 - 请求无效 (Bad request)

在ajax请求后台数据时有时会报 HTTP 400 错误 - 请求无效 (Bad request);出现这个请求无效报错说明请求没有进入到后台服务里;原因:前端提交数据的字段名称或者是字段类型和后台的实体类不一致

js异步错误捕获

我们都知道 try catch 无法捕获 setTimeout 异步任务中的错误,那其中的原因是什么。以及异步代码在 js 中是特别常见的,我们该怎么做才比较?

不能执行已释放Script的代码

父页面初始化声明变量a为数组(数组对象是引用类型,赋值传递的是地址),创建iframe子页面后给父页面变量a赋值,赋值后销毁iframe子页面,再次调用变量a的时候就会抛出异常‘SCRIPT5011:不能执行已释放Script的代码’。

JS错误处理:前端JS/Vue/React/Iframe/跨域/Node

js错误的实质,也是发出一个事件,处理他,error实例对象message:错误提示信息,name:错误名称(非标准属性)宿主环境赋予

nodejs提示 cross-device link not permitted, rename 错误解决方法

文件上传的功能时候,调用fs.renameSync方法错误,这个提示是跨区重命名文件出现的权限问题。先从源文件拷贝到另外分区的目标文件,然后再unlink,就可以了。

Js中使用innerHTML的缺点是什么?

如果在JavaScript中使用innerHTML,缺点是:内容随处可见;不能像“追加到innerHTML”一样使用;innerHTML不提供验证,因此我们可能会在文档中插入有效的和破坏性的HTML并将其中断

Web前端开发,必须规避的8个错误点!

现在,有越来越多所谓的“教程”来帮助我们提高网站的易用性。我们收集了一些在Web开发中容易出错和被忽略的小问题,并且提供了参考的解决方案,以便于帮助Web开发者更好的完善网站。

web前端错误监控

为什么要做前端错误监控?1. 为了保证产品的质量2. 有些问题只存在于线上特定的环境3. 后端错误有监控,前端错误没有监控,前端错误分为两类: 即时运行错误和资源加载错误

自定义错误及扩展错误

当我们在进行开发的时候,通常需要属于我们自己的错误类来反映任务中可能出现的特殊情况。对于网络操作错误,我们需要 HttpError,对于数据库操作错误,我们需要 DbError,对于搜索操作错误,我们需要 NotFoundError,等等

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!