---- 修炼一:持续调整,持续学习 敏捷项目尤其需要如此! 在一定程度上,这也是敏捷项目管理被推崇的原因,用敏捷的方式拥抱变化,还能控制风险、有效的应对不确定性。 应对不确定性最好的方式是保持灵活,持续调整。 ---- 修炼七:行动敏捷,思维更要敏捷 计划做的再好,也不是一帆风顺的,项目和团队经常会被卡住! 作为项目经理,拥抱变化,快速做出反应是解决问题的关键,但除了行动上的敏捷,更需要思维上的敏捷,因为在复杂的场景中,有项目本身的事情,也有人的事情,要梳理新的需求,要制定新的计划,要进行客户谈判,还要稳定激励团队成员 所以,项目经理要应对复杂的场景,思维上要敏捷,甚至思维要先于行动敏捷起来。 所以,项目经理要应对复杂的场景,思维上要敏捷,甚至思维要先于行动敏捷起来。
本文旨在为企业管理系统选型者提供一份专业的敏捷工具选型指南。我们将深入探讨敏捷工具的定义、核心原理,分析最新的市场趋势,并重点对比分析国内敏捷团队常用的7款主流工具。 一、什么是敏捷工具?定义、背景与价值1.敏捷工具的精确定义敏捷工具(Agile Tools)是用于支持敏捷开发方法论(如 Scrum、Kanban、SAFe 等)的软件平台或系统。 本节总结:敏捷工具是通过软件化手段落地敏捷理念、提升研发协同效率的核心载体。 二、敏捷工具如何工作? 四、7 款主流敏捷工具深度对比(国内常用)国内敏捷团队在选型时,通常会综合考虑功能深度、易用性、成本、部署模式(SaaS 或私有化)以及本土化服务。以下是 7 款在市场上表现突出的敏捷工具。 7. Teambition(本土化团队协作)定位:国内老牌的团队协作与项目管理平台。核心特点:Teambition(阿里旗下)以其优秀的用户体验和友好的交互设计在国内积累了良好口碑。
终于经过各种海内外敏捷项目,在一线开发有了对敏捷更为深刻的认识,现在回过头来聊一聊这些问题。 ---- 为什么要敏捷? 敏捷作为一种软件开发方法,或者项目管理方法,很容易被说的玄乎。 但是敏捷团队按照同样的方式做的话,就变成了 “白天搞敏捷,晚上修 bug”,敏捷不仅不能让项目进展更快,反而拖慢项目,甚至导致项目失败。 再来说是的情况,敏捷这种开发方法确实能加快项目进度。 然而目前这种情况变得不能接受,所以越来越多的项目还是转向到敏捷开发上来。 ---- 敏捷开发有什么缺点和不足吗? 敏捷开发方法一点问题和缺点都没有吗? ---- 有了看板、站会、回顾会议就敏捷吗? 敏捷是一种理念和价值观,具体的软件开发方法主要是 Scrum,那么采用了 Scrum 中的实践就敏捷了吗? 第一个问题中谈到,敏捷的关键是迭代和响应变化。 敏捷的实践很重要,是团队重要的活动,但并不意味着采纳了一些敏捷实践,团队就是按照敏捷的方式运作。 ---- - 相关阅读 - 一页纸手把手教你怎么做敏捷项目管理 ThoughtWorks的敏捷开发
Paulo和TC一直在收集整理关于敏捷回顾的任何想法和活动。在这篇内容里面,他们分享了7步法来帮助你组织你的下一次回顾。 Agenda structure: 1.
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦,这篇文章还是非常轻松的。 到最后我们学习完了敏捷相关的知识后,大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些,这样对大家知识的掌握才更有好处。 目前来说公认的最佳的方案,就是:敏捷。 敏捷宣言 最后,总算到了我们这篇文章最核心的内容,那就是敏捷宣言。这个东西的历史很多教材以及文章中都会介绍,所以这里我就不再多说一遍了。 当然,你可以向客户阐明你的敏捷观点,进行详尽的沟通,但是,一切都是以交付客户价值为基础。 所以,敏捷将这四条视为原则,而不是准则、规则。 总结 今天这篇文章我们从传统的项目管理说起,通过 VUCA时代 这样一个时代现象来引出敏捷出现的必要性,最后介绍了敏捷的灵魂:敏捷宣言。当然,敏捷宣言很简单,就四句话,也可以概括成四个词。
敏捷是应对不确定因素的一种灵活管控方式,所以,在敏捷项目环境中,我们需要监控需求交付的价值来确保满足客户的期望,及时跟干系人沟通,反馈项目的真实状态。 实际工作序列每日更新,取决于敏捷团队的生产率和任务的复杂性。实际工作序列常常是易变的,因为团队收到干扰等原因使其并非呈直线。一般,在团队每日站会开完后,由团队更新燃尽图。 燃尽图 如下: ? 例如,一项风险最高风险度是25(5*5=25),最低风险是0.敏捷团队和客户/产品负责人识别到风险同时分配严重度值到风险登记册,并跟踪这些值。在理想情况下,风险严重度会随着时间降低。 因此,在敏捷项目中,风险管理也尤为重要。风险管理应该服务与工作进度,将高风险活动放入早期迭代中,并将风险对应的减轻措施放入待办事项。在项目进行中,风险管理需要持续进行,在风险成为问题前主动应对。 使用敏捷方法,有很多机会可以在项目风险变成问题前主动进行应对。迭代开发允许高风险的工作在项目生命周期中进行处理。具有高风险的功能和用户故事可以在项目早期进行实施。
其它敏捷框架 你们一定想知道为什么不接着讲 Scrum 呀?干嘛中间横插一脚。 可视性进度报告 可视性进度报告就是包括但不限于使用各种敏捷类的图表,或者其它非敏捷的,只要能够有效地反映项目进度情况的图表。当然,更推荐的是白板、大屏这些可视性效果极佳的方式进行进度报告的展示。 DSDM 的周期过程有 7 个阶段。 其实并不新,敏捷各个框架中都强调的让团队坐在一起,没有隔离,让客户也尽量和我们坐在一起。然后呢? 参考文档: 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试(第2版)》 《敏捷项目管理与PMI-ACP应试指南》
无论你的公司是在做敏捷转型还是一开始就使用敏捷,在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤:评估诊断、敏捷试点和大规模推广。 相关阅读: (1)如何正确理解敏捷? (2)如何正确推进敏捷? (3)如何填好推进的坑? (4)如何做服务型Scrum Master? 在敏捷转型实践中,大部分的企业都选择请外部的敏捷教练或者咨询师来帮助企业做敏捷转型,而评估诊断也通常是由他们来做。 如果没有请敏捷教练或者咨询师,那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。 最后,正如上一篇中提到的,无论它是不是知名的框架,又或者它是否打着敏捷的名头又或者冠以敏捷,本身是无所谓的,也觉得并非要全盘采纳框架的所有方法,只要在具体实践中能够体现敏捷思想,帮助我们解决实际问题就是敏捷的好实践
今天开始和你一起重新温习敏捷,先来正确理解一下敏捷吧。 相关阅读: (1)如何正确理解敏捷? (2)如何正确推进敏捷? (3)如何填好推进的坑? (5)无处不在的敏捷思想 1 敏捷的初心 2001年,一群大师聚集在美国犹他州,吃吃喝喝头脑风暴,搞出了一个敏捷宣言,阐述了5条价值观,如下图所示。 ? 2 敏捷的原则 只有敏捷价值观是无法具体指导我们具体工作的,因此由它的价值观又引出了经典的敏捷十二条原则,是每个学习敏捷的童鞋都应该反复理解的话: (1)我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 (7)工作的软件是首要的进度度量标准。 (8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 (9)不断地关注优秀的技能和好的设计会增强敏捷能力。 对于方法,无论它是不是Scrum,又或者它是否打着敏捷的名头又或者冠以敏捷,本身是无所谓的,我也更是觉得并非要全盘采纳敏捷的所有方法(很多时候我发现我们都很迷信3355的流程),只要在具体实践中能够体现敏捷思想
敏捷宣言的官方解释:12条敏捷原则 上一篇文章中说到的敏捷宣言,可以说是整个敏捷体系中最精髓的部分了。说实话,不仅你觉得,我也觉得这四句话有点太简单,太抽象了。 所以,各位大佬们在发布敏捷宣言的同时,还给出了 12 条敏捷原则,可以看成是对敏捷宣言的官方解释及补充。 既然这么说了,那么其实也就意味着这 12 条敏捷原则也是官方给出的东西了呗。 和原则四的内容很贴切吧,在原则四中我们也讲过了,面对面的交流沟通是敏捷中最重要的内容。 在人和人的交流中,面对面沟通时三大要素影响力的比率是:文字7%,声音38%,肢体动作55%。 要知道,敏捷区别于传统项目开发的一大特点就是不停地持续交付真正可用的软件产品。 在敏捷中,一个功能无法使用,也就意味着这个功能是没有交付的。 原则九:不断地关注优秀的技能和好的设计会增强敏捷能力 这一点可以说是更重视于软件开发中的架构设计。代码一旦变得复杂,冗余,就会失去敏捷性。
敏捷计划与适应 上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算,毕竟都是新东西,所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。 敏捷计划的实施 在学习敏捷计划的实施前,我们先来再看看敏捷计划和传统项目管理计划的不同。 首先,敏捷计划是通过实验和示范的方式来发现真正的需求,然后对其进行重新规划。 敏捷适应 敏捷适应其实就是在敏捷计划的执行过程中如何解决出现的问题。所以,在适应模块中,其实包含的就是识别和解决问题两个方面的内容。 识别问题 我们上面讲的那些敏捷监控工具是为了识别问题的。 7)团队雷达图:团队成员为个人和小组的表现打分。 8)挑选同义词:每名成员轮流做裁判,确定在他们的项目进行时,哪些事情或哪些因素最符合质量卡上的定义。 关于敏捷规划设计方面的内容我们就学习完了。其实到这里为止,敏捷中最核心的一些内容就已经差不多了。后面我们还将要学习的是团队、风险管理和过程改进相关的内容。
public void 我取出_元后(Double value) { this.account.withdraw(value); } } 注意,空格都必须一致 7 作为一名银行客户 我想要拥有一个账户 以便我可以存钱、取钱,并且显示当前余额 场景: 我没有账户 # src/test/java/hellocucumber/test.feature:7 确认完毕后,在迭代计划会上,敏捷软件开发团队根据验收标准承诺交付。 重复第2、 3 、4步,直至敏捷软件开发团队能够承诺交付,在这一过程中可能会拆分出多个用户故事。 敏捷软件开发团队根据客户最终确认的 Given-When-Then 测试用例编写自动化验收测试,并完成敏捷软件开发。 重复第2、 3、4步,直至敏捷软件开发团队能够承诺交付,在这一进程中可能会拆分出多个用户故事。 敏捷软件开发团队以通过测试人员编写的自动化测试为完成条件,完成敏捷软开发。
敏捷架构通过协作,紧急设计,有意架构和简单设计支持敏捷开发实践。与敏捷开发实践一样,敏捷架构也可以设计可测试性,可部署性和可发布性。快速原型设计,领域建模和分散式创新进一步支持了它。 敏捷架构师通过优化架构来支持业务一致性,以支持端到端的价值流。这使企业能够实现在最短的可持续交付周期内持续提供“价值”的目标。 SAFe的精益敏捷原则为敏捷架构实践提供了信息。 在进行特定设计之前,敏捷架构师使用快速学习周期(原理#4)来探索替代方案(原则#3)并获得最佳解决方案。 SAFe架构师体现了新的工作方式,参与创建组织的(实施)路线图,并有助于加速作为精益敏捷领导者的采用。
与流行的看法相反,架构是敏捷软件开发工作的一个重要方面,就像传统的工作一样,并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是,敏捷专家的架构方式与传统主义者的方式略有不同。 解决敏捷和架构周围的神话 1.迈向敏捷架构 体系结构提供了构建系统的基础,体系结构模型定义了体系结构所基于的愿景。 5.规模敏捷架构 在大型敏捷团队,地理位置分散的敏捷团队或企业范围的架构工作中,您将需要架构所有者团队或企业架构团队(在敏捷建模中,我最初将其称为核心架构团队,这是我从未真正喜欢过的术语)。 大多数敏捷团队将适当地结合前三种策略。 图4描绘了大规模敏捷项目的体系结构活动过程。 其他任何东西都是黑客攻击,黑客肯定不敏捷。 7.建模你的架构 架构建模的主要目标应该是就您打算如何构建系统达成共识或理解。换句话说,你将建模以理解。
关键的要点 许多组织都对敏捷感到厌倦 “敏捷工业综合体”是问题的一部分 敏捷者必须回到宣言和12个原则的基础和简单 敏捷和现代敏捷的核心是基本的、简单的框架 敏捷者需要从社会科学中学习很多东西,比如积极心理学 、欣赏式探究和解决方案聚焦 敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。 今天,“敏捷”意味着一切。渐渐地,它就毫无意义了。许多组织对“敏捷”感到厌倦和难以驾驭,或者抗拒“敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。” 它变得更糟。“ 名不正,言不顺 ”(孔子)。 所以这就是第一个问题:敏捷的工业综合体和这种强加的一种最好的做事方式。这是我们必须反对的。 敏捷工业综合体。黑暗的敏捷。假的敏捷。僵尸敏捷。更糟糕的是。 结论 跨学科研究、原则和实践是敏捷的未来。这使得我们与我们的根保持联系变得更加重要,只要我们继续使用“敏捷”这个名字。请不要再说“敏捷、敏捷、敏捷、等等”之类的话了。
兼并和收购,基础技术和竞争的变化,新兴标准以及其他因素往往会使企业超出敏捷团队的范围。 为了解决这个问题,Enterprise Architects拥有跨解决方案培训和敏捷发布列车(ART)的权威和知识。他们可以提供可以改善结果的战略技术方向。 实施战略 - 有效,渐进的敏捷实施战略的重要性几乎不为人知。将业务史诗的技术基础构建到建筑跑道必须是一个渐进的过程。持续的技术学习和快速反馈使架构和业务功能随着时间的推移同步增长。 敏捷团队和程序在必要时进行重构并保留多种可能的设计选项的能力支持这一点。抽象和泛化有助于过早地避免绑定特异性,这为未来的业务需求保留了架构灵活性。 尊重个人和不懈改进 精益敏捷心态创造了一个健康的环境,每个人都在事实而非假设的基础上运作。这对于企业架构师来说尤其重要,他们在日常开发活动中执行一个(或两个)步骤。
说来奇怪,敏捷宣言是任何谈论敏捷相关的话题的时候,首先要提到的。而我的专栏居然在第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.
“ 敏捷已逝,但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论,而不是价值。”当多数人都在从“敏捷”身上榨取利益时, Dave Thomas 成为了一位逆行者。 虽然 Dave 对敏捷本身的价值毫不存疑,但之后由于很多出于不同目的的人,将无限多的内容加到了“敏捷”中,导致“敏捷”越来越违背敏捷的实质。 此时的“敏捷"已非彼"敏捷",Dave 不愿再背上“敏捷”的标签,开始追求真正的敏捷性。 十几年的敏捷实践,带给 Dave 的不仅是项目效率的提升,也让他明白了目前敏捷的误区有多大。 直到2014年,Dave 在一次大会上撕碎了敏捷被很多自称敏捷专家的人赋予的华丽外衣:“敏捷已逝,但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论,而不是价值。” 显然,与市面上大量的敏捷认证及方法论相比,Dave 更专注于个体对敏捷实践的思考,而不是照搬敏捷专家的说法。 在 Dave 看来,敏捷不是一个产品。
敏捷大数据智能化的主要目标就是,结合敏捷大数据实施理念,研发灵活的、轻量化的智能模型,并在敏捷大数据平台上对数据流进行实时智能化处理,最终实现一站式的大数据智能分析实践。 三、敏捷AI 如前文所述,在实时AI数据处理过程中,基于敏捷大数据的各项业务组件,结合第三方的开源构件,通过简单配置即可快速编排、敏捷地实现算法运行的底层支持架构。 我们已经让数据处理变得敏捷,那么如何将数据智能也变得更加敏捷呢? 在上述敏捷AI的实施思路下,我们着手构建敏捷AI算法库,这是一套基于业务领域划分的轻量级通用数据模型集合。 四、结语 实时数据的智能化分析是未来大数据技术和人工智能技术发展的重要方向之一,如何降低这一实施过程的经济成本、时间成本、技术成本以及变更成本,是敏捷大数据和敏捷AI着重解决的关键问题。
没有移交 在我开始用敏捷回顾的时候,我跟同事们探讨过我们为什么要做敏捷回顾。我们已经做过项目评估,那么,回顾到底有哪些不同之处,做回顾又有些什么好处呢? 采用敏捷回顾 本篇介绍了怎样在组织内执行回顾。你可能需要敏捷教练或者咨询师来支持你。跟执行其他敏捷实践一样,采用敏捷回顾也是一场组织级变革,专业人员们籍此调整他们的工作方式和行为。 采用敏捷回顾 你怎么帮助参与者理解他们为什么应该做回顾呢?如下是一些参考: • 讨论对持续改进的需要,以便敏捷能有成效。 开展敏捷是一份艰难的工作,你需要处理对变革的抗拒。如果你能变得更敏捷些,事情就变得更容易。只要你具备了敏捷的文化和思维,事情就会开始走上正轨,做或者不做的决策也会变得更容易。 经常反思自己的敏捷之旅有助于你保持敏捷。无论你采用了哪种方式做回顾,确保你会坚持做下去。即便看起来发展态势良好,也总会有继续提高的机会!