- 综合排序
- 最热优先
- 最新优先
- 来自专栏一番码客
敏捷技术学习【1】
今天一番在gitchat上寻找到了一份敏捷技术的课程，阅读学习中时有共鸣，并用zimwiki做学习笔记来管理自己的知识体系和日常。 ---- 今天对敏捷技术的学习精华如下： * 敏捷教练职业产生背景 ： “追求更好”旅途的守护者 * PDSA : 计划-执行-学习-调整 * 戴明环，PDCA : 计划（plan）、执行 （do）、检查（check）、处理（act） * 敏捷技术：敏捷软件开发宣言 -> 4个关键价值 -> 敏捷宣言背后的原则(12个原则) * “精益”（改善效率）：消除浪费（muda)， 减少波动（ * 敏捷教练的职责：流程与人两手抓 * 精通管理规则，精通业务梳理，极强的沟通协作能力，技术熟练，懂业务管理。 * 做为团队和外部的接口，屏蔽外界对团队成员的干扰 * 体系化的参考书目 * 敏捷是敏捷教练的代码，书目是无须重新发明轮子的库函数。 ----
47320发布于 2019-08-02 - 来自专栏业余草
敏捷开发学习分享
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。 敏捷原则：主张简单，拥抱变化，可持续性，快速反馈，轻装前进。 敏捷思维：让开发过程轻量化(我们不是软件工厂)。 敏捷思想：摸着石头过河。软件开发是一个知识发现的过程。是一种管理风险的方式。 敏捷方法认为需求是涌现式的，范围是不确定的。 传统的项目经理：管理的是时间，成本，范围。 敏捷主张的是自主研发，市场推出的容忍度(研发周期)，快速识错(经验行的过程). 自组织的体现是管理放权。 价值驱动和成本驱动。 敏捷强调沟通，沟通三要素：倾听，表达，确认。 团队和po确定Done的标准。 敏捷误区：敏捷不是快，敏捷不需要架构，敏捷需要做到简洁，不是减少。 为什么需要三个角色？
69720发布于 2019-01-21 - 来自专栏杂七杂八杂九
为什么要学习敏捷？敏捷有哪些好处以及敏捷工具
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。那企业为什么要进行变革，实施敏捷开发呢？企业进行敏捷开发的原因主要有以下几点：1、拥抱变化敏捷开发的一个重要特点是能够快速响应和适应市场环境的变化。 3、适应需求变化敏捷开发强调持续的交互和反馈，可以更好地理解客户需求，并及时进行调整和改进。随着需求的变化和客户的反馈，项目可以及时调整方向，适应变化。4、提高效率敏捷开发的另一个优势是提高开发效率。 促进团队沟通：敏捷开发强调团队之间的沟通与协作，通过频繁的交流和合作，可以增强团队的凝聚力和合作精神，提高工作效率和质量。6、拥抱先进技术，提高开发质量敏捷开发的另一个特点是积极拥抱先进技术。 敏捷工具1、Leangoo领歌Leangoo领歌一款永久免费的专业敏捷研发管理工具，它覆盖了敏捷项目研发全流程，包括小型团队敏捷开发，规模化敏捷SAFe，Scrum of Scrums大规模敏捷。 4、VersionOneVersionOne在2002年帮助推出了敏捷管理工具，并且在2020年发布的敏捷状态报告中是国外颇受欢迎的敏捷管理工具之一。
52820编辑于 2023-09-21 - 来自专栏风中追风
敏捷软件开发学习笔记
敏捷设计：敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程，它致力于保持系统设计在任何实践都尽可能得简单，干净，及富有表现力； 也可以理解为：在敏捷开发的过程中 ，都尽量使用敏捷开发的原则，模式来实践，改进软件的结构和可读性的一个过程 当软件发出下面任何一种气味的时候就表明软件正在腐化， 1、僵化性：很难对系统进行改造，因为一改动全身； 2、脆弱性：对系统的改动会导致系统中和被改动的地方在概念
87190发布于 2018-05-11 - 来自专栏Java进阶
敏捷软件开发学习笔记
敏捷设计：敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程，它致力于保持系统设计在任何实践都尽可能得简单，干净，及富有表现力； 也可以理解为：在敏捷开发的过程中 ，都尽量使用敏捷开发的原则，模式来实践，改进软件的结构和可读性的一个过程 当软件发出下面任何一种气味的时候就表明软件正在腐化， 1、僵化性：很难对系统进行改造，因为一改动全身； 2、脆弱性：对系统的改动会导致系统中和被改动的地方在概念
60620发布于 2019-02-20 - 来自专栏TAPD
敏捷实践中，如何排列需求优先级？| 60秒敏捷知识点
在敏捷实践中，要如何优雅地排列需求优先级呢？小T今天给你介绍敏捷方法中的“莫斯科（MoSCoW）法则”。 大家也可以在留言中分享自己的经验，小T为大家准备了小惊喜，具体参与方式见文末。 敏捷方法中有个排列需求优先级的方法，被称为莫斯科（MoSCoW）法则。 需求的优先级并非是一成不变的，敏捷提倡的理念是“拥抱变化”，在每个迭代中，根据用户的需求变更和团队的开发进展情况，这些需求的优先级也可能被重新排列。 作为产品经理，你平时是怎么管理需求的优先级的呢？
1.9K30发布于 2018-08-23 - 来自专栏硬核项目经理的专栏
【敏捷1.1】敏捷项目管理与敏捷宣言
敏捷项目管理与敏捷宣言 说到敏捷项目管理就不得不提到那十分出名的敏捷宣言。这篇文章我们就来简单地了解一下敏捷项目管理的出现和敏捷宣言说的是什么。不要有太多的压力哦，这篇文章还是非常轻松的。 到最后我们学习完了敏捷相关的知识后，大家可以自己再回过头来想一想敏捷和传统项目管理的区别和联系都有哪些，这样对大家知识的掌握才更有好处。 在学习 PMP 的时候，我们会发现整个 PMP 这些领域中的计划和文档编制都是非常重要的部分。 综合这两块内容，相信大家看出来了。传统的项目管理以及由此产生的软件开发模式都有一个特点。 我们再将敏捷原则浓缩为四个词语，那就是：沟通、交付、合作、变化。请记住这四个词，也请记住完整的敏捷原则，在后面的学习中，我们将一直围绕着它们。 之后我们所学习的一切，都是围绕着这个宣言，所以想考试的、准备面试的、想装X的，背下来吧！
1.5K20发布于 2021-09-24 - 来自专栏硬核项目经理的专栏
【敏捷2.5】其它敏捷框架
好东西嘛，当然要留到最后，所以我在这里也就卖个关子，先陪着大家一起来学习一下其它好玩的敏捷框架，或许你能发现不一样的东西哦！ 要知道，能够在一定的领域开发模型必须要有这个领域的许多专业知识的，如果没有相关的这些知识，不能建立良好的模型的话，后面的一切都无从谈起。 具体的内容后面我们学习 PMP 或 信管师 的内容时还会讲解（大家可以先自行查阅 2/8 定律或帕累托法则相关的内容）。 以及我们后面马上要学习到的 Scrum 中的回顾会议，都是为了反思改进。 渗透式沟通：新名词呀？其实并不新，敏捷各个框架中都强调的让团队坐在一起，没有隔离，让客户也尽量和我们坐在一起。然后呢？ 总结 今天一口气了解了三种敏捷框架，是不是感觉意犹未尽。如果确实还不够爽的话，大家就自己查找一些相关的资料进行更深入的了解学习吧。
81220发布于 2021-11-26 - 来自专栏EdisonTalk
敏捷 | 如何正确推进敏捷？
无论你的公司是在做敏捷转型还是一开始就使用敏捷，在推进敏捷的过程中往往都碰到了很多的问题。今天和大家分享一下业界认可的正确推进敏捷的三个步骤：评估诊断、敏捷试点和大规模推广。 在敏捷转型实践中，大部分的企业都选择请外部的敏捷教练或者咨询师来帮助企业做敏捷转型，而评估诊断也通常是由他们来做。 如果没有请敏捷教练或者咨询师，那也应该从企业内部指定一个熟悉敏捷和了解业界敏捷实践的人来做评估诊断。 其次，针对选择的团队，调整好组织结构（确认PO，SM等角色），组织好人员（确保小团队内沟通顺畅），规定好需求（PO的知识储备和User Story的编写标准），搭建好架构（演进式架构），选择好方法和工具 4 小结 一般来说，对中小企业来说，由于团队数量较少，所以一般不会涉及到规模化推广的阶段以及规模化框架的使用，只要不断学习和实践Scrum并且有敏捷教练指导就可以做好敏捷实践。
1.2K30发布于 2020-12-25 - 来自专栏程序源代码
敏捷工作流开发平台（学习参考）
最近在网上找到一个“工作流程快速开发框架”，用JAVA编写的，大家可以下载下来学习参考下。主要：基于activiti5.22， 前后端分离，模块化，超低耦合。 此分享的源代码和文章是小编在项目中、学习中整理的一些认为不错的项目。用户产生的一些自愿下载或者付费行为。与平台没有直接关系。
2.4K10发布于 2018-09-21 - 来自专栏EdisonTalk
敏捷 | 如何正确理解敏捷？
今天开始和你一起重新温习敏捷，先来正确理解一下敏捷吧。 相关阅读： （1）如何正确理解敏捷？ （2）如何正确推进敏捷？ （3）如何填好推进的坑？ 对于敏捷宣言，在学习和实践的前期我和团队都有一个常见的误解：认为左边的最重要，右边的没有价值。 2 敏捷的原则 只有敏捷价值观是无法具体指导我们具体工作的，因此由它的价值观又引出了经典的敏捷十二条原则，是每个学习敏捷的童鞋都应该反复理解的话： （1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 因此，这里提一下大家可能都存在的另一个误解，也是我和团队在学习初期的一个常见误解：敏捷就是Scrum。 学习了3355，但是并不代表理解它和照搬它就可以做好Scrum，这也是初步实践Scrum的团队所经常犯的错误。
1.1K41发布于 2020-12-25 - 来自专栏硬核项目经理的专栏
【敏捷1.2】敏捷宣言的官方解释：12条敏捷原则
敏捷宣言的官方解释：12条敏捷原则 上一篇文章中说到的敏捷宣言，可以说是整个敏捷体系中最精髓的部分了。说实话，不仅你觉得，我也觉得这四句话有点太简单，太抽象了。 所以，各位大佬们在发布敏捷宣言的同时，还给出了 12 条敏捷原则，可以看成是对敏捷宣言的官方解释及补充。 既然这么说了，那么其实也就意味着这 12 条敏捷原则也是官方给出的东西了呗。 在将来的学习中，我们还会见到它们的身影。 原则六：在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈 不用多解释了吧？ 就像开头所说的，如果是有特殊的目的来进行学习的话，那这十二条原则是必须要背的内容。 通过这十二条原则以及一些相应的解释，相信大家看到了不少很熟悉但又陌生的名词。 别急，在后面的学习中我们还会见到并且学习到它们。 参考文档： 《某培训机构教材》 《用户故事与敏捷方法》 《高效通过PMI-ACP考试（第2版）》 《敏捷项目管理与PMI-ACP应试指南》
1.1K20编辑于 2023-03-09 - 来自专栏敏捷开发
【PMP必考点】2024年PMP敏捷知识必考点-工件篇
PMP自2023年8月起启动了PMBOK第七版教材，考试内容的侧重点也发生了改变：大幅增加了敏捷相关的内容。以往考纲只有不到10%的敏捷管理的内容，新考纲的敏捷管理题目增加至50%。 所以如果复习只用之前的题目是远远不够的，必须要多刷新考纲敏捷题。本文专门给大家整理汇总了新考纲所涉及敏捷的核心知识点。PMP新旧考纲变化对比PMP新旧考纲对比如下:第六版：5大过程组、十大领域。 在第七版考纲中，敏捷相关的知识在「过程」这一部分最集中。因为敏捷绝大部分的工具是在生命周期中的开发阶段使用，所以与过程管理最为密切。 敏捷管理必考知识-工件篇燃起图（Burnup Chart）燃起图能够直观展现项目时间与已完成的工作间的关系的一种图表，根据每天完成的story情况动态展现工作成果的曲线，通常是一个向上的曲线。 以上就是新版 PMP 中的敏捷知识考点-工件篇的全部内容。关注我，赠送PMP考试资料包，希望本文能为正在备考 PMP 的你提供帮助。预祝大家考试顺利！
80120编辑于 2024-05-29 - 来自专栏硬核项目经理的专栏
【敏捷5.4】敏捷计划与适应
敏捷计划与适应 上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算，毕竟都是新东西，所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。 敏捷计划的实施 在学习敏捷计划的实施前，我们先来再看看敏捷计划和传统项目管理计划的不同。 首先，敏捷计划是通过实验和示范的方式来发现真正的需求，然后对其进行重新规划。 其次，敏捷计划前期投入少，并且计划是贯穿整个项目始终的。对于 PMP 来说，在前期有很重的规划和设计压力，十大知识领域的内容都要在一起形成项目管理计划。 敏捷监控 计划实施了，但是到位不到位呢？有没有完成我们既定的目标呢？这些就要靠监控来实现。在 PMP 中，监控过程组 是一个贯穿项目开发始终的，并且在十大知识领域中都有的一个过程组。 这个时候，还是发挥大家的力量，自己去查找一些相关知识的解释吧。有的时候，自己去努力寻找的结果反而会让自己印象更加地深刻。 关于敏捷规划设计方面的内容我们就学习完了。
70520编辑于 2023-03-03 - 来自专栏超级架构师
「敏捷架构」SAFe(可扩展的敏捷)中的敏捷架构
在进行特定设计之前，敏捷架构师使用快速学习周期（原理＃4）来探索替代方案（原则＃3）并获得最佳解决方案。 因此，角色可以由不止一个人填补，以确保足够的知识并防止瓶颈团队的架构决策。 ? 图1. SAFe架构角色跨越架构域 架构也是与其他SAFe角色的合作。 他们还会考虑未来的功能，并在积压中定义启动器，以便团队探索并获取确保未来功能可行性的知识。 引领精益敏捷转型 由于他们的知识和经验，建筑师经常受到开发社区的尊重和高度重视。因此，建筑师在任何SAFe转型中都发挥着关键作用。 建筑师是精益敏捷的领导者，因此，模型更精简的思维和操作方式，以便开发人员从他们的榜样，指导和鼓励中学习。它们实现了自主权并鼓励掌握增长开发社区的知识库和技能。
1.2K20发布于 2019-08-29 - 来自专栏超级架构师
「敏捷模型」敏捷架构：规模化敏捷开发的策略
与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统的工作一样，并且是扩展敏捷方法以满足现代组织的现实需求的关键部分。但是，敏捷专家的架构方式与传统主义者的方式略有不同。 5.规模敏捷架构 在大型敏捷团队，地理位置分散的敏捷团队或企业范围的架构工作中，您将需要架构所有者团队或企业架构团队（在敏捷建模中，我最初将其称为核心架构团队，这是我从未真正喜欢过的术语）。 大多数敏捷团队将适当地结合前三种策略。 图4描绘了大规模敏捷项目的体系结构活动过程。 对于企业架构工作，企业架构师将最低限度地充当顾问，他们的专业知识是企业架构，但更好的是他们将成为关键项目团队的活跃成员，承担架构所有者在这些团队中的角色。 “模式系统：面向模式的软件体系结构”这本书是开始学习常见体系结构模式的好地方，例如图层，管道和过滤器，代理，模型 - 视图 - 控制器和Blackboard。
2.2K21发布于 2019-09-10 - 来自专栏超级架构师
「敏捷」也许敏捷就是问题所在
关键的要点 许多组织都对敏捷感到厌倦 “敏捷工业综合体”是问题的一部分 敏捷者必须回到宣言和12个原则的基础和简单 敏捷和现代敏捷的核心是基本的、简单的框架 敏捷者需要从社会科学中学习很多东西，比如积极心理学 、欣赏式探究和解决方案聚焦 敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。 今天，“敏捷”意味着一切。渐渐地，它就毫无意义了。许多组织对“敏捷”感到厌倦和难以驾驭，或者抗拒“敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷敏捷。” 它变得更糟。“ 名不正，言不顺 ”(孔子)。 所以这就是第一个问题:敏捷的工业综合体和这种强加的一种最好的做事方式。这是我们必须反对的。 敏捷工业综合体。黑暗的敏捷。假的敏捷。僵尸敏捷。更糟糕的是。 Joshua Kerievsky的现代敏捷基于四个简单的原则:让人变得优秀，把安全作为先决条件，快速地试验和学习，持续地交付价值。
58610编辑于 2023-01-05 - 来自专栏超级架构师
「敏捷」大型敏捷框架SAFe：企业架构
兼并和收购，基础技术和竞争的变化，新兴标准以及其他因素往往会使企业超出敏捷团队的范围。 为了解决这个问题，Enterprise Architects拥有跨解决方案培训和敏捷发布列车（ART）的权威和知识。他们可以提供可以改善结果的战略技术方向。 其中一些职责包括重用配置模式，通用物理基础设施，跨ART和解决方案列车的知识共享，尤其是系统团队。此外，一些开发和部署基础架构可能与内部IT系统相交叉。企业架构师也可以在那里提供方向。 实施战略 - 有效，渐进的敏捷实施战略的重要性几乎不为人知。将业务史诗的技术基础构建到建筑跑道必须是一个渐进的过程。持续的技术学习和快速反馈使架构和业务功能随着时间的推移同步增长。 敏捷团队和程序在必要时进行重构并保留多种可能的设计选项的能力支持这一点。抽象和泛化有助于过早地避免绑定特异性，这为未来的业务需求保留了架构灵活性。
1.2K30发布于 2019-09-03 - 来自专栏敏捷管理
【Kevin聊敏捷】敏捷宣言
说来奇怪，敏捷宣言是任何谈论敏捷相关的话题的时候，首先要提到的。而我的专栏居然在第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.
1.3K00发布于 2020-12-05 - 来自专栏敏捷开发
敏捷史话（五）：敏捷已逝 —— Dave Thomas
“ 敏捷已逝，但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论，而不是价值。”当多数人都在从“敏捷”身上榨取利益时， Dave Thomas 成为了一位逆行者。 虽然 Dave 对敏捷本身的价值毫不存疑，但之后由于很多出于不同目的的人，将无限多的内容加到了“敏捷”中，导致“敏捷”越来越违背敏捷的实质。 此时的“敏捷"已非彼"敏捷"，Dave 不愿再背上“敏捷”的标签，开始追求真正的敏捷性。 十几年的敏捷实践，带给 Dave 的不仅是项目效率的提升，也让他明白了目前敏捷的误区有多大。 直到2014年，Dave 在一次大会上撕碎了敏捷被很多自称敏捷专家的人赋予的华丽外衣：“敏捷已逝，但敏捷精神长存。因为所谓的敏捷专家卖给你的是方法论，而不是价值。” 由此，他还提到一万小时理论： 要成为某领域的专家，要花一万个小时去实践操作，这样此领域的知识在脑海中有一个根深蒂固的概念，大脑会自动去做这件事，才有可能成为这个领域的专家。
60330发布于 2021-02-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号