关键的要点 许多组织都对敏捷感到厌倦 “敏捷工业综合体”是问题的一部分 敏捷者必须回到宣言和12个原则的基础和简单 敏捷和现代敏捷的核心是基本的、简单的框架 敏捷者需要从社会科学中学习很多东西,比如积
在敏捷项目里面,更多的度量数据是故事点(Story Point),在每一个迭代周期开始之前,会让团队人员评估每个需求的故事点。这就相当于是传统项目里面的评估工时(一个需求完成需要多少时间)。
「持续创新」是对现在客户需求的交付;「产品自适应」是对未来客户需求的交付;「团队和流程自适应」是对产品或者商业变化的迅速反应;「减少交付周期」是为了快速交付可工作的产品;「可靠的结果」是为了支撑商业的增长和盈利能力。
《2020年敏捷状态报告》中显示,现今许多组织还在学习如何实施敏捷。受访者中也有大约50%的人表示,他们的团队中只有不到一半的人在使用敏捷,而其中仍有高达84%的人承认他们的组织没有达到高水平的能力。
Agile Project Management的创始人也是敏捷宣言的十七大佬之一,Jim Highsmith。
流程圈包括 每周40小时工作制(40-Hour Week),系统愿景(System Metaphor),小型发布(Short Releases),简单设计(Simple Design)。
企业不敏捷就out了 很多企业已经走在敏捷转型的路上,首先始于电信和互联网公司,然后是金融行业,现在连零售这样的传统行业都在尝试转向敏捷。 从2001年敏捷宣言宣布到现在,已经有将近十五年的历史。十五年,在我们这个变化迅速的软件工程行业已经是一个非常悠久的时期了。敏捷并不是什么新玩意,而已经成为我们行业主流的管理运营体系。 如果一个企业还没开始拥抱敏捷思想并付诸实践,那它很快要就out了!原因很简单,为了快速响应市场需求的变化,企业采用和拥抱一些敏捷的方法和思维是必须的。 走向敏捷并不表示完全放
敏捷虽然始于软件研发领域,但是其思想却并不止于此,它的很多思想其实可以应用到很多行业,可以在多个领域和工作中发挥价值。
不管是什么样的流程,都值得不断地去优化。针对不同的项目,不通的阶段,都可以做调整。因为敏捷是适应变化的,而不是一成不变的。所以,在敏捷中,也有个口号,用中国的大白话来说就是“没有最好,最优更好”。
这几年,很多公司都在使用敏捷开发,所以现在再去聊“是否敏捷”已经不合适了,更多的是要关注到敏捷的细节讨论、工具化、组织团队、多团队扩展,及其企业级敏捷、数字化转型等更深入的层面。不过近几年,我经常在知乎上看到很多人在说为什么敏捷总是不成功,敏捷很难,敏捷不好,甚至敏捷不适合我,与我无关。这些问题看似简单,实则是一些常见的误区。
因为网上关于敏捷宣言的文章实在太多了,有深入浅出的,有详尽的。所以我的这篇文章就挑重点来说。
大家对这张图一定不陌生,你可以认为这是敏捷流派划分。敏捷和看板Kanban都脱胎于精益Lean。
精益敏捷要求我们站在用户的角度来看待问题,这样的话也就是企业产品(服务)的价值只能由最终用户来确定,价值也只有满足特定用户需求才有存在的意义。
早在2009年,Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》,国内在2010年出了它的中文版本,在第1章就论述了敏捷测试的定义,侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试,对敏捷测试和传统测试的区别进行了分析(虽然作者把传统测试局限于瀑布模型,这显然是不对的),让我们看到一些敏捷测试的特点,如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。
过去我辅导的转型案例里,起手式都是依据看板之父也就是 David J. Anderson 先生所谓的一种成功的方式(注1,第一步、专注于质量)的切入法来开始改变组织的行为模式的,也就是从「要求品质」开始,更具体的说;就是从开发部门开始改起。
敏捷的原则:尽早地给客户持续交付 有价值的 成果物。不断地反省调整、最有效的解决方案是面对面沟通。
提到精益,大家首先想到的肯定是“精益生产”,其中最具代表的就是日本的丰田公司,其最终演变成为了一种新的管理方式。
15 传统项目管理模式如何往敏捷开发精益项目管理转型,如何做到敏捷开发与CMMI体系整合?
在中国移动互联网流行之前的2011年以前,B端软件的研发大多还是传统的瀑布式研发的方式,后面随着移动互联网的发展,To C端软件普遍使用敏捷模式来做。
团队圈分为:代码规范(Code Standards),持续集成(Continuous Integration),集体代码所有制(Continuous Integration)
“ 敏捷已逝,但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论,而不是价值。”当多数人都在从“敏捷”身上榨取利益时, Dave Thomas 成为了一位逆行者。在敏捷实践中他不断尝试,以寻找敏捷最务实的价值。
为快速推进敏捷方法在民生证券的进一步落地推广和成熟应用,日前民生证券携手嘉为蓝鲸开展了敏捷实践培训项目。近日,咨询培训项目圆满落幕并于现场进行颁奖仪式,这标志着民生证券的组织敏捷转型正式迈出新的步伐,为后续实现通过组织敏捷带动金融科技创新,提高工程技术能力,进一步强化企业敏捷实践能力打下了坚实的基础。
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享几个在推进过程中常见的坑,以及如何填坑。
本文摘取陈晓鹏(晨小菜公众号)敏捷/测试/DevOps专家 随着这几年敏捷概念和方法的流行,越来越多的组织和项目选择了敏捷开发模式。那么对于测试人员来说,究竟敏捷测试与传统测试有什么区别?测试人员在一个敏捷项目中需要如何转变才能适应当前这种流行的测试模式呢?请看下文介绍。
在过去的五年时间里,我所在的公司和团队一直使用的都是敏捷开发模式,我也在2018年底获取了Scrum联盟的CSM认证,对于敏捷的理解也是从最初的感性认识到现在的理性认识。今天开始和你一起重新温习敏捷,先来正确理解一下敏捷吧。
随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
Scrum Master敏捷教练,简称SM(不要想歪了)。PO是build the right thing,而SM则是build the thing right。很多人把PO对应上传统项目中的产品经理,SM对应传统项目的项目经理。他们有相同之处,更多的是不同之处。
在当今高度变化的时代,软件开发的环境和要求也在不断变化。传统的开发方法往往难以适应这种快速变化,因此,一种新的软件开发方法——敏捷开发逐渐得到了广泛的关注和应用。
在互联网行业中,永无止境的讨论主题之一是:敏捷与DevOps。对于这两个概念来说,过程彼此不同;但是它们仍然有一些相似之处。
今日洞见 文章作者、部分图片来自ThoughtWorks:刘建华。本文封面来自网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。 做敏捷QA五年多,看到了很多人加入,也看到了很多人放弃。其中有经验丰富的测试人员,也有刚刚步入职场的新人。 虽然“从入门到精通
今日洞见 文章作者来自ThoughtWorks:季炜,图片来自网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。 “Hi,A同学,敏捷宣言有几句?”,“4句呀,分别是个体和互动…” 如果你的答案和A同学一样,也认为是4句,那么请你请继续往下读,相信此文章会
在接触敏捷的这一段时间内,也听了不少曲折离奇的故事。很少有团队在转型敏捷的时候,没有系统学习或外力支持就能做的风生水起。毕竟这里面的“水”很深。
今天你敏捷了没有?“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。 我们使用 tapd 写 feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?(注:tapd 是腾讯内部的敏捷项目管理系统) 朋友,你听说过敏捷么? 离开敏捷工具,我们怎么敏? 设计也要介入敏捷流程? 敏捷跟文档是对立的? 我这有个几百亿的大项目,怎么敏? 尽信书,不如无书。 一、朋友,你听说过敏捷么? 程序员
正在写DevOps培训总结的我看到了Rick Chen的文章,深表赞同,转发一下!原文地址
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点和大规模推广。
在一次用例和敏捷技术交流大会上,Alistair给大家分享了自己比较崇尚的三个字: “守”“破”“离”,他用做面包的例子,形象地将这三个字与敏捷的不同阶段相贴合。结合 Alistair 丰富的经历,“守”“破”“离”三个字也恰好概括了他在敏捷中的不同阶段。
敏捷CMS(Agile CMS)是一种基于敏捷开发方法的内容管理系统。敏捷开发是一种迭代、自适应的开发方法,旨在通过频繁的版本迭代和快速响应变化来提高开发效率和产品质量。敏捷CMS就是将敏捷开发方法应用于内容管理系统的开发和管理过程中。敏捷方法打破了流程和内容孤岛,实现了更快的内容交付,使用敏捷CMS可以简化企业组织的内容和资产管理,使全球品牌能够跨多个国家/地区和平台与客户互动。
在当今快速变化的商业环境中,敏捷管理已成为企业追求高效和灵活的关键策略。作为软件开发领域的一种革命性实践,敏捷方法论已经超越了其最初的应用范围,影响了整个企业管理领域。我们将探讨敏捷管理组织的概念、实施策略、面临的挑战以及成功案例,以期为追求卓越的企业和个人提供启示。
对研发效能提升的研究,是近年来各家企业技术部门一直在研究的课题。早期,针对敏捷开发的实践,让大多技术管理者尝到了甜头,不再拘泥于三月两月一次发版,有些创新类研发项目已经可以做到一月半月乃至以周为单位进行投产。高效的科技运营促进了业务高增长,也增强了企业核心竞争力。
现在,越来越多的企业和软件从业者都接受了“敏捷”概念。在我做持续交付咨询的时候,也可以听到客户能够把“敏捷宣言”倒背如流:
从加入公司到现在快三年,从进入公司的那一刻开始实践敏捷,但是说起来惭愧,如果你问我敏捷是什么,我好像不能给出一个专业的回答。由此我开始探索敏捷的过去现在和未来,然后我发现了Bob大叔的新书 Clean Agile: Back to Basics。
不少公司都在考虑采用敏捷开发,或者在项目开发过程中融入敏捷的思想,在这里,我列出几个常见的误区,希望能对大家有所帮助。
敏捷是人的天性,是你与生俱来的东西。面对敏捷,Arie van Bennekum 下了这样一个结论。
目前软件开发业界已存在多种开发合作模式,各有其特点、适用性和局限性,没有一种开发模式是通用又完美的,可以适用任何组织、任何业务的研发协作。所以每个公司研发组织要根据自身业务特点、自身组织实际情况来采用合适的开发管理模式。
科技即商业 TECHNOLOGY IS BUSINESS 数字化大时代下传统企业面临着种种挑战:效率永远跟不上市场业务需求,质量总是修修补补过日子,协同在部门墙面前无从谈起。很多企业结识了「敏捷」,开始尝试用敏捷组织转型来应对这些问题。2008年我在国内接到了第一个敏捷转型项目,一转眼八年过去了。尽管在这个领域里,持续交付(Continuous Delivery)、开发自运维(DevOps)、规模化敏捷框架等一系列新概念如雨后春笋般冒出来,但敏捷宣言没变,敏捷核心实践没变,敏捷咨询好像也没有太大变化。最近在
在上一次的分享中,我们分析了ITIL 4之后,运维Management层面该如何发力,提到由于ITIL 4所提倡的建设重心从流程建设转到了价值流和价值链,企业不仅需要一个强大的工具,还需要敏捷的运维管理来适应工具的迭代。这一篇文章,依然由资深咨询顾问赵海兵老师为大家讲解:金融数字化转型大势下,运维组织管理该何去何从?
如今,在瞬息万变的商业环境中,企业不断受到压力以适应不断变化的市场条件。越来越多的公司采用敏捷开发实践来帮助他们保持竞争力。敏捷过程是高度协作的、迭代的,并且所有过程都集中在快速和可重复的软件交付上。
Scrum敏捷模式是一种灵活、适应性强的开发方法,其核心理念是以短周期、高频率的方式进行项目开发,确保团队能够快速响应变化。
缩短价值交付周期 开发团队通过提供最小化可用产品获取用户反馈,并在这个最小化可行产品上持续快速迭代,直到一个相对稳定的阶段产品。在此过程中,敏捷测试人员快速验证团队的目标,快速试错。
领取专属 10元无门槛券
手把手带您无忧上云