敏捷开发方法
介绍Scrum,XP, SAFe,LeSS,精益看板等敏捷主流敏捷方法的价值观,原则与具体实践,并分享业内的实际案例。
麦哲思科技任甲林
麦哲思科技(北京)有限公司总经理
敏捷性能合弄模型评估师
认证的Scrum Master
认证的大规模敏捷顾问SPC
CMMI高成熟度主任评估师
COSMIC MPC,IAC 成员,中国分部主席
展开
-
唐僧团队是否是一个优秀的Scrum团队?
唐僧团队通常被认为是一个成功的团队,因为他们是不同风格的成员组合在一起,经过了磨合后,同心协力达成了最初的目标,封神成佛。一个成功的团队,未必是一个优秀的Scrum团队。如果站在Scrum的角度来检视唐僧团队,他们有哪些突出的待改进之处呢?1 不是学习型团队在整个团队组建以后,团队成员的技能没有发生变化,孙悟空仍然还是那些绝技,猪八戒沙僧也没有学到新技能。每次打完妖怪后,没有总结经验教训,如何更好、更快地降服妖怪,打完一次妖怪,团队的整体技能没有提升,说明该团队不是一个学习型团队!...原创 2020-12-05 07:09:48 · 903 阅读 · 0 评论 -
敏捷团队章程的实践精要
无规矩不成方圆。任何一个团队都要有大家共同遵守的做事规则,这些规则定义下来就成为了国家的大政方针与法律法规、组织的管理方针和流程、团队的章程或工作协议。对于敏捷团队而言,也是如此。需要在团队组建的初期,大家共同制定团队的做事规则,并协商一致,共同承诺。有了团队章程,团队才能统一思想、统一价值观、统一做事的方式,为协同合作建立一个良好的基础,才能成为一个高效的团队。 制定敏捷团队章程要把握4个要点: 1 不求大而全,但求简单实用。 敏捷团队章...原创 2020-10-06 15:21:03 · 1074 阅读 · 0 评论 -
开好迭代回顾会议的5个原则
迭代回顾会议是Scrum五个仪式之一,是在迭代评审会议之后对本次迭代的优点与改进点进行复盘的一个活动,其最主要的目的是提升团队的整体能力,持续改进,形成一个自学习的团队。通过回顾会议可以使团队每个迭代都能比上个迭代做得更好。在很多敏捷团队中,最容易忽略该活动,很多团队没有意识到该活动的重要性。为什么呢?最主要的原因是开了会议,没有实际效果,大家认为没用,所以也就不开了。实践中,在开迭代回顾会议时常犯的错误有: 把回顾会议开成了吐槽大会,大家只提意见,不提改进措施; 把回顾会议开成原创 2020-10-05 17:45:21 · 3530 阅读 · 0 评论 -
一表搞定最小可行产品(MVP)与最小可市场化特性(MMF)
MVP是最小可行产品,MMF是最小可市场化特性,这是精益与敏捷中的两个术语,很多人不能准确理解这2个概念的差别,我试图用一个表格对这2个概念进行概括总结: MVP(Minimum Viable Product),最小可行产品 MMF(minimum marketable feature),最小可市场化特性 含义 最小:抓住用户核心诉求提供最优解,控制需求范围和项目预算,降低产品创新试错成本。 可行:提供足够的价值,客户愿意花钱(或其他货币,如个人信息)……...原创 2020-06-07 13:59:08 · 5445 阅读 · 0 评论 -
图解APH之engaging合弄
图一:Engaging合弄的目的与性能等级图二:Engaging合弄的活动 图三:Engaging合弄使用的敏捷仪式与技术原创 2019-02-19 08:55:05 · 633 阅读 · 0 评论 -
图解敏捷性能合弄结构APH之:valuing合弄
图一:valuing合弄的目的与性能等级图二:valuing合弄的活动各种敏捷方法的原则参见博客:https://blog.csdn.net/dylanren/article/details/87184790。 图三:valuing合弄使用的敏捷仪式和技术说明:为便于图形化表达,每种敏捷仪式或技术没有映射到具体的活动,敏捷活动与敏捷仪式是多对多的映射关系。 ...原创 2019-02-16 08:29:38 · 653 阅读 · 0 评论 -
什么是敏捷性能合弄结构(APH)?
1 综述敏捷性能合弄结构(APH)是由美国AgileCxO研究院出品的全球范围首个专门用来评价企业敏捷性能的模型。该方法分析、提取了当前流行的各种敏捷方法、精益方法的先进理念与实践。它可以帮助企业评价当前的敏捷能力等级、指导落地实施敏捷方法、循序渐进地识别改进点。它将企业可能的65种敏捷仪式(来源于各种敏捷方法,将来还会扩充)映射到70种行为,归类到18个合弄单元,6个性能圈,从角色、行为、敏...原创 2019-02-15 10:28:44 · 4158 阅读 · 0 评论 -
要言不繁的DoD指南
DoD(The definition of done:DoD)完成的定义、完成的标准或完成的准则是敏捷开发方法中的一个重要概念,一个重要实践。本文对DoD如何理解、如何定义DoD及其作用给了简明扼要的论述,供各位实践者参考。 1 DoD的定义 可以从不同的维度理解DoD的定义: 1)DoD就是完成准则,完成就是不需要再做其他任何事情,可以直接交付了...原创 2018-11-07 16:39:53 · 5107 阅读 · 1 评论 -
三个团队的站立会议旁观笔记
今天早晨我旁观了3个团队的站立会议,三个团队的站会参与人员都是7个人,其中第2个团队是scrum of scrum,7个人是7个团队的代表,有高层领导旁观了第2个团队的站会。 做得好的地方归纳如下: 1在每日站会上沟通了需求、接口设计的变化,让整个团队都了解这些变化。 2开发人员在提到完成了,都强调完成...原创 2019-12-30 13:27:34 · 1113 阅读 · 0 评论 -
聊聊故事点背后的故事
聊聊故事点背后的故事Q1、敏捷项目能不能不估算故事点,直接估算工作量?【观点一】:在策划扑克法中先估算故事点有其固有的优点,最无法替代的优点是故事点不是绝对的工作量,避免了团队在迭代早期盲目的承诺,第一个迭代可以只估故事点不估工作量,是一种保护团队的行为,体现了敏捷以人与团队为本的文化,多数策划扑克法没用起来的团队往往也是这种文化薄弱甚至背道而驰的。此时策划扑克就不是最适合的方法...原创 2019-11-29 23:16:20 · 939 阅读 · 0 评论 -
敏捷与CMMI的同与不同
CMM我是从1998年开始接触的,到现在大概20年了,自己亲自实施过CMMI,也辅导了很多企业做基于CMMI的过程改进。2013年我成为了CMMI的评估师,后来成为高成熟度的评估师,去年又成为了教员。 敏捷我是2005年接触的,到现在14个年头了,2008年左右也成了认证的Scrum Master, 去年成为认证的大规模敏捷顾问,2018年成为敏捷性能合弄模型的评估师。10多年来...原创 2019-08-09 09:52:34 · 6842 阅读 · 3 评论 -
白话透解验收标准(AC)与完成标准(DoD)的区别
Accept criteria 与 Definition of Done是敏捷开发中的两个概念,容易混淆。AC是针对每个需求定义的。DoD是针对所有需求,任务,迭代,交付定义的。打个比方解释二者的区别:需求1:晚饭吃饱。验收标准AC: 1 牛肉+蔬菜+啤酒; 2 18点到19点之间完成。需求2:午饭吃饱。验收标准AC: ...原创 2019-08-02 16:37:55 · 6239 阅读 · 1 评论 -
《敏捷估计与规划》读书笔记
CH1-1 策划过程比计划书更重要。CH1-2 必须做计划,但是不必过度投入时间。CH1-3 对瀑布模型的不确定性锥:CH1-4 PMI认为的估算偏差率:初步估算,order of magnitude estimate, 误差范围+75%到-25%;预算估算,budgetary estimate, 误差范围+25%到-10%;确定性估算,definitive est...原创 2019-07-29 10:59:14 · 692 阅读 · 0 评论 -
硝烟中的Scrum和XP读书笔记
CH1-1 Scrum不是方法学,它是一个框架。CH1-2 Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情 况来对它进行调整;CH2-1 产品Backlog中包含了:故事、特性、需求+优先级并且是用用户的术语的表达;CH2-2 how to demo实际是对用户故事的细化,是设想的用户操作场景,可以作为用户故事的验收准则。CH2-3 指出如何解决问题的应该是...原创 2019-07-20 23:12:51 · 447 阅读 · 0 评论 -
好书没废话:《看板和Scrum相得益彰》读书笔记
今天花了大概90分钟读了《看板和Scrum相得益彰》一书,让我击节赞叹,确实是一本好书! 1 本书很薄。薄的书能让人有耐心读完。 2 本书言简意赅,观点明确。能让人产生共鸣,能解惑。 3 充满了干货,读后让人有收获,可实际操作。对于我的收获整理如下: CH1-1 Scrum方法:团队拆小,任务拆小,时间拆小;看板:可视化、WIP、...原创 2019-07-16 16:31:56 · 900 阅读 · 0 评论 -
理解敏捷思想的63句话!
序号 类别 箴言 解释 1 持续提升 敏捷转型是文化变革,前景美好,道路曲折,,必须领导先行。 冰冻三尺,非一日之寒。要想转型到敏捷文化,需要领导投入、开发人员配合、管理部门理解和支持才可能成功。 敏捷始于领导,死于领导,领导往往会...原创 2019-04-17 13:41:49 · 2274 阅读 · 0 评论 -
实施敏捷的四个致命障碍
敏捷方法在中国推行的如火如荼,我也为多家公司做了敏捷的导入咨询,在实践中遇到了几个致命障碍,限制甚至阻止了敏捷方法的推行,我把有深刻体会的障碍总结出来,供大家在实践中规避之。障碍一:没有建立组织级的敏捷价值观与环境。 很多公司在导入敏捷时,先从一个项目开始尝试敏捷方法,试图在单项目内成功了,再推广到其他项目。这种初衷是好的,但是往往事与愿违,为什么呢?因为缺乏组...原创 2019-03-28 10:41:50 · 2592 阅读 · 0 评论 -
敏捷方法的价值观与原则汇编
敏捷宣言1 个体和沟通胜过流程和工具 2 可以工作的软件胜过详尽的文档 3 与客户合作胜过合同谈判 4 响应变化胜过遵循计划也就是说,尽管右项有其价值,我们更重视左项的价值。 敏捷方法的12个原则1 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。2 欣然面对需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。3 经常...原创 2019-02-13 15:31:08 · 1784 阅读 · 0 评论 -
迭代评审的十个成功要点
迭代评审会议是在每次迭代结束时给项目组内外部的相关人员展示本次迭代完成的功能,以获得相关人员对软件的反馈意见。这是客户、最终用户、管理者等对项目组完成的功能进行反馈的一个渠道。如何召开一个成功的迭代评审会议呢?我根据对多次迭 代评审会议的观察,总结了如下1 鸡类角色与猪类角色都要参与迭代评审会议; 以下两类人员都应该参与:项目组的所有成员,包括PO,SM...原创 2018-08-30 10:05:35 · 4601 阅读 · 0 评论 -
迭代回顾会议咨询记录
每次敏捷迭代都是一次PDCA循环, 迭代的回顾会议则是其中的A(adjust),不断的复盘总结可以帮助项目一次比一次做的更好,使团队形成一个自学习的组织。 近日我旁观了一个敏捷项目组的迭代回顾会议,项目组成员对本次迭代的经验教训进行了总结,我作为外部顾问旁观了整个过程,并对项目组中存在的问题,本次回归会议的优缺点进行了点评,咨询记录如下: ...原创 2018-08-28 11:13:55 · 2645 阅读 · 0 评论 -
迭代策划会议(Sprint Planning) 的实际案例
某项目组第一次采用敏捷方法进行开发,确定了迭代周期为三周。该项目组投入的资源如下:前端开发工程师一名;后端开发工程师一名;测试工程师一名;PO一名;SM一名;前后端开发采用不同的技术,熟悉前端开发的工程师不熟悉后端的技术,后端开发的工程师也不熟悉前端使用的技术。当第1周结束后,由于前端开发人员使用的是新技术,需要熟悉新技术,而后端工程师与测试工程师的投入都不到位,因此估算工作量与实际工作量差别比较...原创 2018-06-15 09:45:11 · 4406 阅读 · 0 评论 -
漫谈敏捷方法中的信任
在实施敏捷的方法中需要组织建立信任的文化,即管理者信任项目组,可以放手让项目组去做事情。 人对其他人都是有信任关系的。你走在大街上,你不会认为你看到的任何人会过来刺杀你,否则你就会穿着一身盔甲上路了,这就是一种信任。 人对其他人的信任都不是无底线的。比如,当有人过来找你问路,找你推销商品时,你可能就避而远之,这就是一种不信任。 无约束的信任只可能是一些短期的、不重要的小事。原创 2018-01-16 12:38:00 · 1238 阅读 · 1 评论 -
面对面沟通与文档沟通
1994年McCarthy J.和Monk, A.在一篇论文"Channels, conversation,cooperation and relevance: all you wanted to know about communication but wereafraid to ask"中给出了下图所示一个研究结论。即在所有的沟通方式中,两个人守着白板,边讨论边写写画画地进行沟通是最高效的。原创 2017-12-12 13:40:12 · 2071 阅读 · 0 评论 -
一个敏捷项目的咨询记录
近日对一个敏捷项目进行了2小时的简单访谈,对他们的一些实践点评如下:综述: 1 敏捷的实践看着简单做着难,实践少,但是实践的很多细节要做到位。 2 要让团队的成员知其然知其所以然,才能够进行经验化过程控制。 3 要在团队内建立承诺的文化,说到一定要做到。 4 目标、需求、任务、任务状态、问题、团队规则都要可视化! 5 牺牲质量追求速度,是原创 2017-11-28 15:59:40 · 1298 阅读 · 0 评论 -
2017年10月站立会议旁观笔记
近期旁观了一个项目的晨会,识别了一些改进点,记录与点评如下:序号现象改进建议1与会成员22人拆成2-3个小组分别召开站立会议,以提高会议效率。2有2人迟到站立会议是固定时间、固定地点、固定人员、固定话题的,不需要会前通知,有人迟到要定义规则惩罚之:1 微信群发红包;2 会议室放置一个储钱罐,迟到者投币;……要建立团队的文化。3白板状态列包括:待办任务池,编码,代码评审,待修复,完成明确列出等待的状原创 2017-10-20 15:28:13 · 1049 阅读 · 0 评论 -
项目进度跟踪的最佳实践:每日站立会议
项目进度跟踪的最佳实践:每日站立会议1 每日站立会议的具体做法每日站立会议是Scrum方法中的一条关键实践,看似很简单的一个活动,其实内涵丰富,站立会议通过每天面对面的沟通,可以: (1)快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 (2)给每个人一种精神压力,信守承诺。这是一种面对面的精神压力,直面项目进展。 (3)培养团队的文化,让每个人意识到:我不是一原创 2015-11-26 09:28:00 · 14163 阅读 · 3 评论 -
案例:每日站立会议落实情况的再跟踪
2010年深圳某客户在公司内推广站立会议,2010年4月份我曾经到这家客户观察过1个大产品的10多个项目小组执行站立会议的情况,并将结果与体会记录整理成了一篇博文:《每日站立会议的10个成功要点》,2013年8月23日上午(深圳,滂沱大雨,雨声如鼓)故地重游,我又观察了该公司一个项目的站立会议,记录如下: (1)某项目组站立会议,早上9点13分开始,9点26分结束,费时13分钟。 (2原创 2013-08-23 17:11:35 · 3065 阅读 · 0 评论 -
敏捷方法开发总结的点评记录
某项目组采用敏捷的方法完成了一个项目,在此过程中,每次迭代结束后,项目组的每个成员都总结了本次迭代的经验教训,我汇总这些经验教训后,点评如下:原创 2013-05-29 14:31:25 · 2528 阅读 · 0 评论 -
白话SCRUM之五:四种会议
在SCRUM方法中定义了4种会议活动: Sprint planning Daily meeting Sprint review Sprint retrospective 除去开发活动外这4种会议构成了scrum方法的核心活动。 这四种会议的要点如下:原创 2012-03-12 11:27:50 · 3632 阅读 · 0 评论 -
白话SCRUM 之四:燃尽图
Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典! 燃尽图的样例如下: 横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩原创 2012-03-06 14:19:26 · 7675 阅读 · 0 评论 -
白话SCRUM 之三:sprint backlog
Sprint Backlog就是任务列表,如果映射到传统的项目管理理论中就是WBS(work breakdown structure),而且是典型的采用面向交付物的任务分解方法得到的WBS。比如有一个Product backlog 条目为: 作为系统的合法用户,可以通过录入账号和密码登录到系统中。为了实现此需求,team member识别出了的任务,进行了工作量的估计,进行了任务了领用,其结原创 2012-02-27 16:48:13 · 18847 阅读 · 0 评论 -
白话SCRUM 之二:product backlog
在SCRUM方法中明确要求了3个文档: 1 product backlog 2 sprint backlog 3 burn-down chart Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲原创 2011-12-15 09:27:13 · 12819 阅读 · 2 评论 -
白话SCRUM之一:SCRUM 的三个角色
在SCRUM方法中将项目的利益相关者分成两大类:Pigs角色与chickens角色,pigs即为项目组的实际参与人员,chickens为项目组的外部人员,包括经理、最终用户等等。Pigs在scrum中细分为三个角色:Scrum master、Product owner、Team,这三个对等地位的角色构成一个平衡的铁三角推动整个项目的进展。 Scrum master不是项目经理,他没有分配任务原创 2011-11-05 23:58:34 · 7755 阅读 · 1 评论 -
杂谈Barry Boehm的软件工程七原则与敏捷实践
大概在5年以前曾经从网上搜到了Barry Boehm提出的软件工程的七原则(Seven Basic Principles of Software Engineering),这是Barry Boehm1983年发表的文章,在网上搜到的是别人对这七个原则的转译与介绍,看后觉得怪怪的,总是觉得有些地方不能准确把握这七个原则的含义。于是去google搜其原文,未果,最近终于搜到了原文,因此更能准确把握Ba原创 2011-06-05 14:36:00 · 3337 阅读 · 0 评论 -
时间箱管理
<br />时间箱管理是敏捷方法中的一条实践,其含义是在项目中的某些活动的完成时间必须在规定的时间内完成。该实践有助于提高整个项目的工作效率,避免帕金森现象。<br /> 在敏捷方法里时间箱管理的具体体现包括:<br />(1) 每次迭代必须在固定的时间内完成,比如2周或1个月等,本次迭代必须交付一个质量得到充分检验的、可以运行的软件版本,如果有些需求不能在本次迭代内完成,则推迟到下一个迭代中完成。<br />(2) 项目的策划会议必须在4个小时内完成,某次迭代的策划会议必须在4个小原创 2010-12-20 16:31:00 · 3268 阅读 · 0 评论 -
再谈站立会议的实施要点
昨天在东莞客户封闭开发的现场,观察了一个产品开发组四个小组实施站立会议的情况,分析了他们执行的优缺点,对如何执行站立会议,如何获得站立会议的成功进行了再次归纳总结,要点如下:1 任务的分配与领用i)任务的责任人要明确;ii)任务的颗粒度小于2天;iii)如果有的任务颗粒度实在无法拆分到2天以内,则需要设置中间的检查点;iv)任务的完成时间要明确;v)任务的完成标准要明确;vi)任务识别的要尽可能完原创 2010-04-20 10:38:00 · 1738 阅读 · 1 评论 -
每日站立会议的10个成功要点
每日站立会议是SCRUM方法中的一条关键实践,看似很简单的一个活动,其实内涵丰富,如果能够成为一种习惯,还是不容易的。其成功的要点为: 1 站立会议通过每天面对面的沟通,可以: (1)快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 (2)给每个人一种精神压力,信守承诺。这是一种面对面的精神压力,直面项目进展。 (原创 2010-04-06 09:54:00 · 2678 阅读 · 0 评论 -
敏捷始于客户
每个失败的项目了都可以找这个借口:项目周期短、需求变化快、人员有限。 需求、工期是由客户确定的。作为客户来讲,他不可能去合理评价给定的需求是否可以在某个时间内能够完成,至于投入多少人那更是开发方自己的问题。开发方对客户做出了承诺就要兑现承诺,否则就不要承诺,既然承诺了,就没有理由再去抱怨工期短、需求变化快。开发方必须接受这个现实,认可这个现实,然后才可以玩这个游戏,否则你就出局。 CMMI是应原创 2009-12-08 16:11:00 · 1320 阅读 · 0 评论 -
两个浪漫的人,一本理性的书
“两个浪漫的人,一本理性的书”是我对《重构极限编程》一书的评价。 书买了有一段时间了,浏览过一遍,感觉很受启发。今天是第2遍读,边读边乐边反思。 两位作者很浪漫,每个章节的开头,都改编了一首歌曲作为前言; 两位作者很幽默,在文章里轻松、犀利地调侃极限编程的缺点; 两位作者也很理性,对极限编程的某些优点也进行了充分的肯定。 第一次读此书时,只注意了作者的理性,没有去读书里的歌词与调侃,第二遍读时,仔原创 2009-12-08 15:45:00 · 1223 阅读 · 0 评论 -
规模估算的敏捷方法:策划扑克法
策划扑克是估算软件规模的一种敏捷方法。该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度等其他因素的度量。故事点并非业界统一的一个度量单位,不象度量长度的单位:米,大家都知道1米有多长,你说的1米和他说的1米是等长的。故事点仅对本项目具有近似相等的规模,不同的项目所定义的故事点原创 2009-12-08 15:25:00 · 1882 阅读 · 0 评论