在敏捷实践中,要如何优雅地排列需求优先级呢?小T今天给你介绍敏捷方法中的“莫斯科(MoSCoW)法则”。 大家也可以在留言中分享自己的经验,小T为大家准备了小惊喜,具体参与方式见文末。 敏捷方法中有个排列需求优先级的方法,被称为莫斯科(MoSCoW)法则。 需求的优先级并非是一成不变的,敏捷提倡的理念是“拥抱变化”,在每个迭代中,根据用户的需求变更和团队的开发进展情况,这些需求的优先级也可能被重新排列。 作为产品经理,你平时是怎么管理需求的优先级的呢?
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 目前来说公认的最佳的方案,就是:敏捷。 敏捷宣言 最后,总算到了我们这篇文章最核心的内容,那就是敏捷宣言。这个东西的历史很多教材以及文章中都会介绍,所以这里我就不再多说一遍了。 当然,你可以向客户阐明你的敏捷观点,进行详尽的沟通,但是,一切都是以交付客户价值为基础。 所以,敏捷将这四条视为原则,而不是准则、规则。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
其它敏捷框架 你们一定想知道为什么不接着讲 Scrum 呀?干嘛中间横插一脚。 要知道,能够在一定的领域开发模型必须要有这个领域的许多专业知识的,如果没有相关的这些知识,不能建立良好的模型的话,后面的一切都无从谈起。 可视性进度报告 可视性进度报告就是包括但不限于使用各种敏捷类的图表,或者其它非敏捷的,只要能够有效地反映项目进度情况的图表。当然,更推荐的是白板、大屏这些可视性效果极佳的方式进行进度报告的展示。 其实并不新,敏捷各个框架中都强调的让团队坐在一起,没有隔离,让客户也尽量和我们坐在一起。然后呢? 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点和大规模推广。 在敏捷转型实践中,大部分的企业都选择请外部的敏捷教练或者咨询师来帮助企业做敏捷转型,而评估诊断也通常是由他们来做。 如果没有请敏捷教练或者咨询师,那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。 其次,针对选择的团队,调整好组织结构(确认PO,SM等角色),组织好人员(确保小团队内沟通顺畅),规定好需求(PO的知识储备和User Story的编写标准),搭建好架构(演进式架构),选择好方法和工具 最后,正如上一篇中提到的,无论它是不是知名的框架,又或者它是否打着敏捷的名头又或者冠以敏捷,本身是无所谓的,也觉得并非要全盘采纳框架的所有方法,只要在具体实践中能够体现敏捷思想,帮助我们解决实际问题就是敏捷的好实践
今天开始和你一起重新温习敏捷,先来正确理解一下敏捷吧。 相关阅读: (1)如何正确理解敏捷? (2)如何正确推进敏捷? (3)如何填好推进的坑? (5)无处不在的敏捷思想 1 敏捷的初心 2001年,一群大师聚集在美国犹他州,吃吃喝喝头脑风暴,搞出了一个敏捷宣言,阐述了5条价值观,如下图所示。 ? 2 敏捷的原则 只有敏捷价值观是无法具体指导我们具体工作的,因此由它的价值观又引出了经典的敏捷十二条原则,是每个学习敏捷的童鞋都应该反复理解的话: (1)我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 但是,从上面可以了解到,Scrum不是敏捷的全部,它只是敏捷的一个落地方法之一。 对于方法,无论它是不是Scrum,又或者它是否打着敏捷的名头又或者冠以敏捷,本身是无所谓的,我也更是觉得并非要全盘采纳敏捷的所有方法(很多时候我发现我们都很迷信3355的流程),只要在具体实践中能够体现敏捷思想
敏捷宣言的官方解释:12条敏捷原则 上一篇文章中说到的敏捷宣言,可以说是整个敏捷体系中最精髓的部分了。说实话,不仅你觉得,我也觉得这四句话有点太简单,太抽象了。 所以,各位大佬们在发布敏捷宣言的同时,还给出了 12 条敏捷原则,可以看成是对敏捷宣言的官方解释及补充。 既然这么说了,那么其实也就意味着这 12 条敏捷原则也是官方给出的东西了呗。 要知道,敏捷区别于传统项目开发的一大特点就是不停地持续交付真正可用的软件产品。 在敏捷中,一个功能无法使用,也就意味着这个功能是没有交付的。 原则九:不断地关注优秀的技能和好的设计会增强敏捷能力 这一点可以说是更重视于软件开发中的架构设计。代码一旦变得复杂,冗余,就会失去敏捷性。 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
PMP自2023年8月起启动了PMBOK第七版教材,考试内容的侧重点也发生了改变:大幅增加了敏捷相关的内容。以往考纲只有不到10%的敏捷管理的内容,新考纲的敏捷管理题目增加至50%。 所以如果复习只用之前的题目是远远不够的,必须要多刷新考纲敏捷题。本文专门给大家整理汇总了新考纲所涉及敏捷的核心知识点。PMP新旧考纲变化对比PMP新旧考纲对比如下:第六版:5大过程组、十大领域。 在第七版考纲中,敏捷相关的知识在「过程」这一部分最集中。因为敏捷绝大部分的工具是在生命周期中的开发阶段使用,所以与过程管理最为密切。 敏捷管理必考知识-工件篇燃起图(Burnup Chart)燃起图能够直观展现项目时间与已完成的工作间的关系的一种图表,根据每天完成的story情况动态展现工作成果的曲线,通常是一个向上的曲线。 以上就是新版 PMP 中的敏捷知识考点-工件篇的全部内容。关注我,赠送PMP考试资料包,希望本文能为正在备考 PMP 的你提供帮助。预祝大家考试顺利!
敏捷计划与适应 上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算,毕竟都是新东西,所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。 敏捷计划的实施 在学习敏捷计划的实施前,我们先来再看看敏捷计划和传统项目管理计划的不同。 首先,敏捷计划是通过实验和示范的方式来发现真正的需求,然后对其进行重新规划。 其次,敏捷计划前期投入少,并且计划是贯穿整个项目始终的。对于 PMP 来说,在前期有很重的规划和设计压力,十大知识领域的内容都要在一起形成项目管理计划。 敏捷监控 计划实施了,但是到位不到位呢?有没有完成我们既定的目标呢?这些就要靠监控来实现。在 PMP 中,监控过程组 是一个贯穿项目开发始终的,并且在十大知识领域中都有的一个过程组。 这个时候,还是发挥大家的力量,自己去查找一些相关知识的解释吧。有的时候,自己去努力寻找的结果反而会让自己印象更加地深刻。 关于敏捷规划设计方面的内容我们就学习完了。
因此,角色可以由不止一个人填补,以确保足够的知识并防止瓶颈团队的架构决策。 ? 图1. SAFe架构角色跨越架构域 架构也是与其他SAFe角色的合作。 他们还会考虑未来的功能,并在积压中定义启动器,以便团队探索并获取确保未来功能可行性的知识。 每个增量,架构师都可以确保团队演示启动器工作的结果,包括新知识,架构跑道添加以及对Continuous Delivery Pipeline的任何添加。 引领精益敏捷转型 由于他们的知识和经验,建筑师经常受到开发社区的尊重和高度重视。因此,建筑师在任何SAFe转型中都发挥着关键作用。 建筑师是精益敏捷的领导者,因此,模型更精简的思维和操作方式,以便开发人员从他们的榜样,指导和鼓励中学习。它们实现了自主权并鼓励掌握增长开发社区的知识库和技能。
与流行的看法相反,架构是敏捷软件开发工作的一个重要方面,就像传统的工作一样,并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是,敏捷专家的架构方式与传统主义者的方式略有不同。 解决敏捷和架构周围的神话 1.迈向敏捷架构 体系结构提供了构建系统的基础,体系结构模型定义了体系结构所基于的愿景。 5.规模敏捷架构 在大型敏捷团队,地理位置分散的敏捷团队或企业范围的架构工作中,您将需要架构所有者团队或企业架构团队(在敏捷建模中,我最初将其称为核心架构团队,这是我从未真正喜欢过的术语)。 大多数敏捷团队将适当地结合前三种策略。 图4描绘了大规模敏捷项目的体系结构活动过程。 对于企业架构工作,企业架构师将最低限度地充当顾问,他们的专业知识是企业架构,但更好的是他们将成为关键项目团队的活跃成员,承担架构所有者在这些团队中的角色。
兼并和收购,基础技术和竞争的变化,新兴标准以及其他因素往往会使企业超出敏捷团队的范围。 为了解决这个问题,Enterprise Architects拥有跨解决方案培训和敏捷发布列车(ART)的权威和知识。他们可以提供可以改善结果的战略技术方向。 其中一些职责包括重用配置模式,通用物理基础设施,跨ART和解决方案列车的知识共享,尤其是系统团队。此外,一些开发和部署基础架构可能与内部IT系统相交叉。企业架构师也可以在那里提供方向。 敏捷团队和程序在必要时进行重构并保留多种可能的设计选项的能力支持这一点。抽象和泛化有助于过早地避免绑定特异性,这为未来的业务需求保留了架构灵活性。 尊重个人和不懈改进 精益敏捷心态创造了一个健康的环境,每个人都在事实而非假设的基础上运作。这对于企业架构师来说尤其重要,他们在日常开发活动中执行一个(或两个)步骤。
说来奇怪,敏捷宣言是任何谈论敏捷相关的话题的时候,首先要提到的。而我的专栏居然在第31篇文章才来说「敏捷宣言」,真的是罪过~ = =#。 因为网上关于敏捷宣言的文章实在太多了,有深入浅出的,有详尽的。 【Kevin聊敏捷】精益敏捷(Lean Agile)的5个原则 26.【Kevin聊敏捷】精益敏捷(Lean Agile)导论 25.【Kevin聊敏捷】极限编程XP2实践 24. 【Kevin聊敏捷】敏捷项目管理之Scrum Events 敏捷活动 13.【Kevin聊敏捷】敏捷项目管理之Scrum Master 敏捷教练 12. 【Kevin聊敏捷】敏捷项目管理之Product Owner 产品负责人(一) 09.【Kevin聊敏捷】敏捷项目管理之Scrum三大支柱 08. 【Kevin聊敏捷】敏捷项目管理之Scrum价值 07.【Kevin聊敏捷】敏捷项目管理之Scrum 06.【Kevin聊敏捷】项目生命周期之敏捷型生命周期 05.
关键的要点 许多组织都对敏捷感到厌倦 “敏捷工业综合体”是问题的一部分 敏捷者必须回到宣言和12个原则的基础和简单 敏捷和现代敏捷的核心是基本的、简单的框架 敏捷者需要从社会科学中学习很多东西,比如积极心理学 、欣赏式探究和解决方案聚焦 敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。 今天,“敏捷”意味着一切。渐渐地,它就毫无意义了。许多组织对“敏捷”感到厌倦和难以驾驭,或者抗拒“敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。” 它变得更糟。“ 名不正,言不顺 ”(孔子)。 所以这就是第一个问题:敏捷的工业综合体和这种强加的一种最好的做事方式。这是我们必须反对的。 敏捷工业综合体。黑暗的敏捷。假的敏捷。僵尸敏捷。更糟糕的是。 结论 跨学科研究、原则和实践是敏捷的未来。这使得我们与我们的根保持联系变得更加重要,只要我们继续使用“敏捷”这个名字。请不要再说“敏捷、敏捷、敏捷、等等”之类的话了。
“ 敏捷已逝,但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论,而不是价值。”当多数人都在从“敏捷”身上榨取利益时, Dave Thomas 成为了一位逆行者。 虽然 Dave 对敏捷本身的价值毫不存疑,但之后由于很多出于不同目的的人,将无限多的内容加到了“敏捷”中,导致“敏捷”越来越违背敏捷的实质。 此时的“敏捷"已非彼"敏捷",Dave 不愿再背上“敏捷”的标签,开始追求真正的敏捷性。 十几年的敏捷实践,带给 Dave 的不仅是项目效率的提升,也让他明白了目前敏捷的误区有多大。 直到2014年,Dave 在一次大会上撕碎了敏捷被很多自称敏捷专家的人赋予的华丽外衣:“敏捷已逝,但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论,而不是价值。” 由此,他还提到一万小时理论: 要成为某领域的专家,要花一万个小时去实践操作,这样此领域的知识在脑海中有一个根深蒂固的概念,大脑会自动去做这件事,才有可能成为这个领域的专家。
敏捷大数据智能化的主要目标就是,结合敏捷大数据实施理念,研发灵活的、轻量化的智能模型,并在敏捷大数据平台上对数据流进行实时智能化处理,最终实现一站式的大数据智能分析实践。 为实现上述目标,我们对人工智能、机器学习、实时运算等技术,以及相关业务领域知识,乃至产品用户体验都进行了深入的研究与分析,本系列文章将把我们的理念和在上述过程中所获得的一些经验、成果与大家分享。 三、敏捷AI 如前文所述,在实时AI数据处理过程中,基于敏捷大数据的各项业务组件,结合第三方的开源构件,通过简单配置即可快速编排、敏捷地实现算法运行的底层支持架构。 我们已经让数据处理变得敏捷,那么如何将数据智能也变得更加敏捷呢? 在上述敏捷AI的实施思路下,我们着手构建敏捷AI算法库,这是一套基于业务领域划分的轻量级通用数据模型集合。
没有移交 在我开始用敏捷回顾的时候,我跟同事们探讨过我们为什么要做敏捷回顾。我们已经做过项目评估,那么,回顾到底有哪些不同之处,做回顾又有些什么好处呢? 采用敏捷回顾 本篇介绍了怎样在组织内执行回顾。你可能需要敏捷教练或者咨询师来支持你。跟执行其他敏捷实践一样,采用敏捷回顾也是一场组织级变革,专业人员们籍此调整他们的工作方式和行为。 采用敏捷回顾 你怎么帮助参与者理解他们为什么应该做回顾呢?如下是一些参考: • 讨论对持续改进的需要,以便敏捷能有成效。 开展敏捷是一份艰难的工作,你需要处理对变革的抗拒。如果你能变得更敏捷些,事情就变得更容易。只要你具备了敏捷的文化和思维,事情就会开始走上正轨,做或者不做的决策也会变得更容易。 经常反思自己的敏捷之旅有助于你保持敏捷。无论你采用了哪种方式做回顾,确保你会坚持做下去。即便看起来发展态势良好,也总会有继续提高的机会!
【Kevin聊敏捷】敏捷项目管理APM-Agile Project Management(一) 31.【Kevin聊敏捷】敏捷宣言 30.【Kevin聊敏捷】看板Kanban的5个核心实践 29. 【Kevin聊敏捷】敏捷项目管理之Sprint Review 迭代评审会 16.【Kevin聊敏捷】敏捷项目管理之Daily Scrum 每日站立会 15. 【Kevin聊敏捷】敏捷项目管理之Sprint Planning 迭代规划会 14.【Kevin聊敏捷】敏捷项目管理之Scrum Events 敏捷活动 13. 【Kevin聊敏捷】敏捷项目管理之Scrum Master 敏捷教练 12.【Kevin聊敏捷】敏捷项目管理之Development Team 开发团队 11. 【Kevin聊敏捷】敏捷项目管理之Scrum三大支柱 08.【Kevin聊敏捷】敏捷项目管理之Scrum价值 07.【Kevin聊敏捷】敏捷项目管理之Scrum 06.
下面图例是从一个团队的Scrum电子看板中两个Dev的开发状态,这个团队刚刚从传统瀑布开发方式转型,当前这个项目是第一次用Scrum方式跑Sprint。每个Sprint为期3周,这是第一周周五时候的Snapshot。
带着个小团队学习敏捷运作也有三个多月了,目前执行了近八轮迭代,对比以前的瀑布式运作,感觉运作差别比较大的主要是每日晨会、测试前移、持续交付; 第一次尝试敏捷,就在我们今年的部门重点项目w上试点,确实有点突然 因为敏捷运作对于我们来说是一种全新的项目运作方式,按正常试点流程,应该会先在一些小项目上进行完整实验之后,再铺开推广会比较合适些。 其实,需求梳理这一块,敏捷运作跟以前的瀑布式模型并没有太大本质性区别,该做的业务需求分析还是得做,只是交付成果由以前的use case变成了故事,将边界条件与前后置条件变成了验收条件,但终究都是为了满足业务功能实现 结对编程 在敏捷运作过程中,笔者还进行了结对编程的尝试,但是目前来看,效果并不如预期那么明显——能力弱的员工并没有预想中的那样得到很快的能力提升。
在过去几年中,一种创建软件的新方式已经风靡软件开发和测试世界:敏捷。 事实上,根据VersionOne的敏捷状态报告,截至2018年,97%的组织以某种形式实践敏捷。 那么究竟什么是敏捷的,为什么它如此迅速地变得如此受欢迎? 让我们更详细地探索敏捷方法所涉及的内容以及如何在组织中引入它。 具体来说,我们将涵盖: 测试如何适应敏捷方法? 在敏捷团队上测试的不同方法有哪些? 敏捷运动的下一步是什么? 关于敏捷方法论 敏捷方法已经风靡软件开发世界并迅速巩固其作为“黄金标准”的地位。敏捷方法论都是基于敏捷宣言中概述的四个核心原则开始的。 总体而言,探索性测试遵循以下四个关键原则: 并行测试计划,测试设计和测试执行 具体而灵活 协调调查潜在的机会 知识共享 它与标准瀑布测试有何不同? 为什么领先的公司正在通过敏捷测试实现敏捷 超过300家领先的公司选择改进他们的软件测试流程,并通过采用敏捷。