[关闭]
@yishuailuo 2017-03-28T12:57:25.000000Z 字数 21235 阅读 17011

两万字谈谈如何使用 Scrum 框架进行敏捷开发


〇、本文概述

本文介绍『 敏捷开发 』中的一个重要流派 —— 『 Scrum 』,主要从敏捷开发宣言、原则、 Scrum 的价值观、原则、角色、活动以及工件等几大方面阐述如何使用 Scrum 框架进行敏捷开发,其中会有关于敏捷型组织Cynefiin 框架技术债等相关知识的介绍。

一、前言

前不久我在团队做过一段时间 Scrum Master, 当 Scrum Master 的实践过程中,曾经很浅略地做过一些关于迭代开发的思考和总结(《关于迭代的一些思考》 ,不过里面关于 Scrum 框架和敏捷开发大多是经验和直觉上的认知,缺少相应理论知识的理解和支持。

为了更深入地理解 Scrum 框架和敏捷开发,春节前后以及工作之余阅读了一些关于敏捷和 Scrum 框架的书籍和文章,从中收获颇多;恰逢 3 月 10、11 号公司作了敏捷培训,过程中我更是获益匪浅,并且自己对于敏捷和 Scrum 的认知和理解在培训中得到了进一步的验证和调整。

所以,在这里我将敏捷和 Scrum 框架的相关知识做适当的取舍、调整并整合起来(做知识的搬运工),同时也把从理论和实践所得的这些认知和理解写出来,希望能就 如何使用 scrum 框架做敏捷开发 这个主题做一个足够的阐述。

注:敏捷或者 Scrum 框架的知识浩如烟海,难以用一篇文章将其说透说全,这里主要讲解 Scrum 框架的重要组成部分 —— 角色、工件与活动;另外敏捷或者 Scrum 不像实打实的技术,里面很多观点都可能比较主观,希望自己认知和理解的内容能尽量客观地对其作出阐述;当然,由于知识和经验有限,如有偏颇,欢迎探讨和指正。

在下一章节,我们先来谈谈一下敏捷开发,往后再继续谈 Scrum 框架。

二、敏捷开发

2.1 敏捷开发的含义

敏捷开发是一种从上个世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。常言道:“天下武功,唯快不破”,此言用于形容“敏捷”的威力相当合适;但我更喜欢另一句西方谚语:“A chess novice can defeat a master if moving twice each round(如果允许一个新手一次走两步,那么他就可以击败象棋大师)”。敏捷意思为快,但敏捷思想不仅仅求快,它更多强调“多快好省”,产出得多,产出得快,产出得好,同时节省各种成本,既经济又实用。

它们更强调程序员团队与业务专家之间的紧密协作面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用

2.2 敏捷开发正式诞生的标志

2001 年,17 位软件开发人员(包括来自于极限编程ScrumDSDM自适应软件开发水晶系列特征驱动开发实效编程 的代表们,还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者)齐聚犹他州的雪鸟镇,共同探讨一种轻量级的开发方法。雪鸟会议上,所有的与会代表就使用『 敏捷 』一词概括这种新型的轻量级方法达成了共识,并签署且发表了《Manifesto for Agile Software Development》(即《敏捷软件开发宣言》),这成为敏捷开发正式诞生的标志,他们称自己为“敏捷联盟”。

那么,究竟《敏捷软件开发宣言》都宣言了些什么呢?接下来我们仔细看看。

2.3 敏捷开发宣言和原则

2.3.1 敏捷宣言的价值观

雪鸟会议上发表的《敏捷软件开发宣言》摘录如下:

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值

2.3.2 敏捷宣言的原则

另外,宣言中还包括以下十二条原则:

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现

敏捷宣言中这些价值观和原则,所谓入门容易精通难,在旁人或者入门者看来也许略显空洞,所言无物;然而,敏捷精髓的实践者们一直坚信着这些理念,觉得它们字字珠玑,所言极是。不管我们是走敏捷的哪个流派,都不妨在实践敏捷的过程中,回过头来看看这些价值观和原则,想必会常看常新,大有裨益。

2.3.3 其他具体的敏捷原则

以下思维导图是其他具体的敏捷原则的说明。

作为敏捷众多流派中的被广泛实践的 Scrum 流派,同时也是我工作之后的两年多时间里团队中使用的敏捷开发方式,下一章我们来初步了解一下。

不过正式介绍 Scrum 框架之前,我想有必要先谈谈一个词 ——『 敏捷型组织 』。在实践敏捷的过程中,个人要敏捷,团队要敏捷,更重要的是组织也要敏捷,而且我认为组织的敏捷是团队和个人真正实践敏捷的重要基石。

2.4 敏捷型组织

组织结构指的是一个组织内部团队之间相互关系的布局。

它包括把员工分配到不同的部门和团队,也包括为了发号施令而安排的层次结构。各公司有不同的组织结构,职能型矩阵型两种基本结构已经使用多年,然而一种被称为敏捷型结构的组织结构更适用于软件开发行业。

我们先来看看这三种组织结构:

2.4.1 职能型组织

2.4.1.1 职能型组织的含义

军队和工业界曾经使用过职能型结构的组织形式,这形式的结构按照主要目的或职能来设置部门,基本上根据员工的基本职能来组织。在技术组织内,按照职能的不同分成不同的部门,如工程部,质量保证部,运维部,项目管理部等;同时,每个部门都有自己的管理层级结构,都有自己的负责人。在工程部,工程师向工程经理汇报,工程经理向工程副总汇报;在其他部门的汇报关系类似。

2.4.1.2 职能型组织的优缺点

这种职能型组织结构很多优点,比如

当然,职能型组织结构有它的问题:

考虑到这些利弊,当其同质性的好处超过整体协调和所有权带来的问题的时候,可以考虑采用职能型组织结构。比如,采用瀑布式开发的组织,经常能从按职能划分的组织结构中获益。因为该结构下号与瀑布型方法中固有的阶段控制相匹配。

2.4.2 矩阵型组织

2.4.2.1 矩阵型组织的含义

尽管职能型组织结构有一些不可否认的优点,但仍存在弊端。为了克服这个问题,公司甚至军事机构演化出矩阵型组织。矩阵型组织机构的主要概念是层级的两个维度。在职能型组织的每个团队有一个经理,每个团队的成员向一个老板汇报;而矩阵型组织与职能型组织相反,包括至少两个管理维度,每个团队的成员或许有两个或多个老板,比如,传统的职能组织旁边增加了项目管理团队

如上图,深蓝色标注的员工,包括项目经理 1、工程师 1、工程师 2、质量保证工程师 1、质量保证工程师 2、产品 1、产品 2 组成了一个项目团队在一起工作;深蓝色标注的员工组成一个团队;橙色标注的员工又组成另一个团队;每个团队里的项目经理对任务分配和项目进度负有责任。在更大和更复杂的组织里,许多来自不同团队的人可以属于同一个项目团队。

2.4.2.2 矩阵型组织的优缺点

职能型组织的是三个问题:缺乏单一的项目负责人;跨部门的沟通效果不佳;部门间存在情感性冲突。而在矩阵型组织里,存在以下优点:

同样的,矩阵型组织也有其弊端:

矩阵型组织结构解决了一些问题的同时,又引入了一些新的问题。假如保持职能型和矩阵型组织结构的优点,“是否有更好的办法?”答案是“有”,这就是“敏捷型组织”。

2.4.3 敏捷型组织

2.4.3.1 敏捷型组织的含义

随着从提供软件向提供服务方向的发展(SaaS —— 软件即服务,现在还有 PaaS —— 平台即服务 和 IaaS —— 基础架构即服务),技术人员开始思考如何做个好的服务提供者而不是软件开发者。伴随着这一演进,人们开始思考服务的质量和可靠性。另外,敏捷开发方式的出现,还有职能型和矩阵型组织弊端的存在,使被称为敏捷型的新组织结构应运而生。

我们把跨职能同时符合服务架构的组织,标示为敏捷性组织。在这种组织中,团队是完全自主管理自给自足的。从形成概念,到研发,再到生产系统中的服务支持,团队负有全部的责任。跨职能部门的额总监、副总裁以及敏捷型团队替代了工程副总裁这样的常规管理角色。

2.4.3.1 敏捷型组织的优缺点

敏捷性组织具有如下优点:

敏捷性组织的缺点:

没有一个组织结构是完美的,即便敏捷型组织存在着弊端,那些正在挣扎着试图解决不良的服务支持、大量的冲突、员工自我驱动力不强和整体缺乏创新的公司来说,敏捷型组织模式是个理想的选择。

我个人一个浅薄的观点:公司内部建设走“战区主战,军种主建”之路,其中的“战区”正是由相应的业务、产品,研发,测试、运维,设计等主力提供智能投顾和余额代偿服务的相关人员共同组成的敏捷型组织的阵地。

敏捷的相关知识介绍到此,接下来主要是介绍 Scrum 框架,首先从 Scrum 的含义、起源和发展开始。

三、Scrum 含义、起源和发展

3.1 Scrum 的原意和隐喻

3.1.1 Scrum 英语单词的含义 —— 原意

3.1.2 Scrum 在软件业的含义 —— 隐喻

在软件开发历史过程中,Scrum 先驱们将 Scrum 这个词的隐喻应用于软件开发。它是一套轻量级的核心价值观、原则和实践,统称为 Scrum 框架,在这个框架中人们可以解决复杂的自适应问题,同时也能高效并有创造性地交付尽可能高价值的产品。

在这个框架下,我们可以检验 Scrum 团队是否符合 Scrum 原意的要求:

如果我们的 Scrum 团队遭遇困难,可以思考一下如何向优秀的球队学习,也许是一个突破困境的机会。在进一步探讨 Scrum 框架之前,我们先来了解一下 Scrum 的起源和发展。

3.2 Scrum 的起源和发展

1986 年,『 竹内弘高 』和『 野中郁次郎 』在《哈佛商业评论》中刊登一篇题为“新型新产品开发策略(The New New Product Development Game)”的文章,将橄榄球和争球—— Scrum 的隐约应用于软件开发:

产品开发的“接力赛”方式......可能和要求最快,最灵活的目标有冲突。一种整体方式或“橄榄球”方式(即团队作为一个整体打完比赛,来回传球),也许能够更好地迎合当下的竞争需求。

(英文原文:The traditional sequential or “relay race” approach to product development—exemplified by the National Aeronautics and Space Administration’s phased program planning (PPP) system—may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.)

这篇文章描述了本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的“蜂拥式”的方式开发世界一流的产品。

1993 年,被誉为 Scrum 之父的其中一位 —— Jeff Sutherland(曾参与敏捷软件开发宣言的起草,是Scrum的共同发明人,现为Scrum基金会总裁) 和他的团队把 1986 年竹内弘高野中郁次郎那篇文章的概念与面向对象开发,基于经验的过程控制、迭代和增量开发、软件过程和生产率研究、复杂适应系统中的概念结合起来,创立了用于指导软件开发工作的 Scrum 过程。

1995 年,被誉为 Scrum 之父的另外一位 —— Ken Schwaber(敏捷软件开发宣言的17位发起人之一,与 Jeff Sutherland 合作,共同建立了 Scrum 软件开发方法)在 OOPSLA 上发表第一篇关于 Scrum 的论文 —— 《SCRUM 开发过程(SCRUM Development Process)》。

此后,Sutherland 和 Schwaber 一起完成了一份关于 Scrum 的重要文档 ——《Scrum 指南The Scrum Guide)》。两位 Scrum 先驱把这本指南描述为 “Scrum 金科玉律,Scrum 专有文档”,并把它比作是象棋游戏的游戏规则说明:“描述棋子(各个部件)的行走规则,顺序,输赢如何定义,等等。”尽管指南有像说明书一样的价值,但是这本身也是指南的局限 —— 我们并不能仅依靠一份说明书就能把象棋下好,关于 Scrum 更多的原则,价值和实践需要进一步的去探讨。

四、Scrum 框架概述

4.1 迭代 VS 增量 VS 冲刺

在日常开发中,我们经常定义迭代名为 Sprint 1、Sprint 2 ... Sprint N,这里 Sprint 的英文原意是冲刺的意思,所以对应着 Sprint 1、Sprint 2 更合适的称呼是冲刺 1、冲刺 2。但这里更想强调的一点是,迭代式开发增量式开发冲刺开发不仅仅是术语的不同,其在开发方式上也是有区别的。

4.1.1 迭代式开发

4.1.2 增量式开发

4.1.3 冲刺开发

4.2 Scrum 概要框架

这一节主要是简单描述一下 Scrum 的概要框架,让大家有个初步的认识,后面会有关于 Scrum 框架更为详细的说明。

4.2.1 Scrum 概要框架图示

4.2.2 Scrum 概要框架说明

上图描述了一个 Scrum 冲刺的概要框架,就像大家所熟知的那样:

  1. 产品列表 』首先要建立产品列表 —— 一个按优先级排序的、有粗略估算的、成功开发产品所需特性及其他功能的列表。
    • 在产品列表的指导下,我们总是先做优先级最高的条目(比如上图中的特性 A、B、C);
    • 换句话说就是,当一个冲刺完成时,已完成的条目都是优先级最高的。
  2. 冲刺计划会 』一般情况下,产品列表中的工作量远远不是一个短期冲刺内能够完成的。所以冲刺开始时,团队需要制定计划,说明在下一个冲刺中要创建产品列表中的哪几个高优先级的特性。
  3. 冲刺 』工作本身是在一些短周期、时长固定的冲刺中完成的,每个冲刺从一周到一个月。
    • 在每个冲刺中,自组织,跨职能的团队完成所有必需的工作 —— 例如设计、开发、构建和测试 —— 产生完整的、可工作的、可以放入产品的特性。
  4. 冲刺评审会回顾会 』在冲刺结束时,团队与利益干系人一起评审已经完成的特性,获得它们的反馈,产品负责人和团队既可以对下一步工作内容进行修改(在评审会上),也可以修改以前的工作方式(在回顾会上)。
    • 评审会上,如果利益干系人在看到一个完成的特性时,意识到自己没有考虑到另一个必须包含在产品中的特性,此时,产品负责人只需要建立一个代表该特性的新条目,并把它以适当的有线顺序插入产品列表,留到后面的冲刺中完成。
    • 回顾会上,如果开发团队在回顾冲刺过程中,意识到自己没有考虑到依赖风险导致开发过程不必要的等待时,开发团队可以提出下一冲刺计划会上考虑依赖风险并做好相应的控制。
  5. 潜在可发布产品增量 』在冲刺结束时,团队应当得到一个潜在可发布产品(或者产品增量)。如果业务上适合,就可以发布;如果不适合在每次冲刺后发布,可以把多个冲刺的一组特性合并在一起发布。

到这里为止,我们对 Scrum 框架有了个初步的了解,这时候我们可能会有疑问,为什么我们要使用这样的框架来做软件开发呢?它适用于所有的软件开发活动吗?下面一节我们来做个简单的探讨。

4.3 为什么选择 Scrum

4.2.1 Cynefin 框架与 Scrum 适用性

我们先来看一下著名的 Cynefin 框架,它可以帮助我们更好地理解工作环境并确定适合的工作方式。

Cynefin 框架最早是在 1999 年威尔士学者 Dave Snowden 在知识管理组织战略中提出的。Cynefin 是威尔士语,意为 “栖息地” 或 “住所”,指人们对生活环境的共同文化、宗教、地理和部落的总体经验和感受。这个框架用于描述问题、环境与系统说明什么环境适合使用什么解决方案

Cynefin 框架定义了五种域:复杂、繁杂、混乱
、简单和无序,并且比较了各个域的差别,以及描述了 Scrum 适合哪些域。

4.2.1.1 复杂域
4.2.1.2 繁杂域
4.2.1.3 混乱域
4.2.1.4 简单域
4.2.1.5 无序域

如果不知道自己处于哪个域,说明就是在无序域中。因为无法理解自己的处境,所以这个域很危险;如果处于无序域,要考虑的不是在无序域中如何使用 Scrum,而是要尽早摆脱这个域;摆脱无序域需要把问题分解为小的组成部分,并安排到另外 4 种域之一中

4.2.1.6 事务性工作

4.2.2 Scrum 的好处

从上一节的 Cynefin 框架可知,Scrum 框架最适用于复杂域、适用于繁杂域但非最佳。如果我们的软件开发活动所处的领域很复杂,未知的东西比已经的多,那么我们需要一种开发方式,能够让我们快速探索新想法和新方法,快速了解哪些解决方案可行、哪些不可行(即快速探索和反馈)。

如果把没有采用敏捷(或者 Scrum )而是采用传统开发方式或者没有任何开发方式的业务人员和开发人员找到一起,问他们“你们对软件开发工作的结果感到满意吗?”或者“你们认为我们是否及时、经济、高质量地交付了良好的客户价值?”,通常他们的回答都是“否”,并如出一辙地补充说:

而认真踏实地使用 Scrum 的团队和组织,却是另一番不一样的情况。

Scrum 关注在每个冲刺交付可以工作的、集成好的、经过测试的、具有业务价值的特性,力争更快交付成果。处于复杂域的组织必须根据竞争对手、客户、用户、监管部门和其他利益干系人的互动快速做出调整,Scrum 能很好地帮助他们取得成功。

五、Scrum 框架详述

本章节会详细讲解 Scrum 框架的各大角色、工件以及活动。

参考下图,图中绿色标记的是三大角色(产品负责人、Scrum Master、开发团队)、蓝色部分标记的是三大工件(产品列表、冲刺列表、潜在可交付产品增量)、橙色标记的是七大活动(冲刺、产品列表梳理、冲刺计划会、冲刺执行、每日站会、冲刺评审会、冲刺回顾会)。

5.1 三大角色

5.1.1 产品负责人

5.1.1.1 产品负责人概述
5.1.1.2 产品负责人主要职责

产品负责人勾勒产品愿景、为产品指明方向、计划开发节奏、考虑开发成本等,他责任重大,一方面要理解组织中利益干系人、客户、用户(有时候还包括开发团队)的需求,是他们的代言人,担任的是产品经理的角色;另一方面,对正在开发的特性和开发顺序,要和开发团队紧密合作,验收开发出来的产品,担任的是业务分析员测试人员的角色。

以下思维导图是产品负责人主要职责的说明。

5.1.1.3 产品负责人特征或技能

虽然优秀的产品负责人体现出很多特征或技能,但可以归为四类:领域知识人际交往能力决策力责任心

以下思维导图是产品负责人主要特征或技能的说明。

5.1.1.2 产品负责人日常工作

为了更好地理解产品负责人的职责,这里也通过一张图大致列一下产品负责人的日常工作内容。

以下图片是产品负责人主要日常工作内容的说明。

5.1.2 Scrum Master

5.1.2.1 Scrum Master 概述
5.1.2.1 Scrum Master 主要职责

Scrum Master 既是 Scrum 团队的教练、是 Scrum 过程权威,也是团队服务型领导、“保护伞”和“清道夫”,一个真正优秀的 Master 同样不易养成。

以下思维导图是 Scrum Master 主要职责的说明。

5.1.2.2 Scrum Master 特征或技能

Scrum Master 必须见多识广,具备领域知识和技术知识,要善于提问,要有耐心和协作精神,要懂得保护团队,并且让沟通公开透明。

以下思维导图是 Scrum Master 主要特征或技能的说明。

5.1.2.2 Scrum Master 日常工作

为了更好地理解 Scrum Master 的职责,这里也通过一张图大致列一下 Scrum Master 的日常工作内容。

以下思维导图是 Scrum Master 主要日常工作内容的说明。

5.1.3 开发团队

5.1.3.1 开发团队概述
5.1.3.2 开发团队主要职责

以下图片是开发团队主要职责的说明。

5.1.3.3 开发团队特征或技能

以下思维导图是开发团队主要特征或技能的说明。

5.1.4 职能经理(非 Scrum 角色)

虽然 Scrum 框架中并没有明确定义经理的角色,但经理在敏捷组织中依然发挥着重要的作用。

以下思维导图是职能经理主要职责的说明。

5.2 三大工件

5.2.1 需求和用户故事(非 Scrum 工件)

5.2.1.1 需求

瀑布开发以及 Scrum 开发对待需求的不同:

5.2.1.2 用户故事

5.2.2 产品列表

5.2.3 冲刺列表

5.2.4 潜在可交付产品增量

5.3 七大活动

5.3.1 产品列表梳理

5.3.2 冲刺

5.3.2.1 时间盒固定(前一冲刺结束后马上开始新冲刺)
5.3.2.2 长度一致(如无例外,每个冲刺时间长度固定)

团队在当前冲刺中无法完成所有的工作,这并不是延长冲刺长度的正当理由。到了冲刺最后一天才意识到无法完成工作,所以想通融通融,增加一天两天来完成,这种做法是不合适的。需要延长冲刺是不能正常工作或者有改进空间的征兆

5.3.2.3 短迭代(一周到一个月不等,一般为两周)
5.3.2.3 冲刺目标锁定(不允许改变冲刺目标或者更换人员)
5.3.2.4 一致认同的完成定义(产出潜在可发布产品增量)

5.3.3 冲刺计划会

以下图片是冲刺计划会的参与者、输入和输出。

除了图片所示,我们还应该关注的是:

5.3.4 每日例会

5.3.5 冲刺执行

以下图片是冲刺执行的参与者、输入和输出。

除了图片所示,我们还应该关注的是:

5.3.6 冲刺评审会

以下图片是冲刺评审会的参与者、输入和输出。

除了图片所示,我们还应该关注的是:

5.3.7 冲刺回顾会

以下图片是冲刺回顾会的参与者、输入和输出。

除了图片所示,我们还应该关注的是:

到这里,关于 Scrum 框架的角色、工件与活动已经大体讲完,下面讲一个重要的概 念 —— 技术债作为本文的结束。

六、技术债

本章节主要讲什么是技术债,有哪些类型技术债,技术债有什么影响,以及如何处理技术债。

6.1 什么是技术债

1992年,Ward Cunningham 率先提出技术债的概念,他的定义如下:

代码写好就交,意味着欠债的开始。稍微欠点技术债的确可以加快开发速度,但前提是事后及时重写代码,...... 如果只结不还,后果很危险。在不确定的代码上花的每一分钟,都算是技术债的应付利息。不稳定,脆弱的代码所引发的债务负担,会使整个工程陷入裹足不前的艰难境地......

6.2 技术债有什么影响

6.3 如何处理技术债


最后插播个广告 —— 我们公司(数禾)招数据工程师,详情请点 拉勾招聘链接


参考书籍:
1.《Scrum 精髓 - 敏捷转型指南》
2.《Scrum敏捷软件开发》
3.《架构即未来》 —— 好书,推荐!

其他参考资料:
1. wiki 敏捷软件开发
2. wiki Scrum
3. Scrum 指南
4.【第一领导力专栏】从美式橄榄球的Scrum 看敏捷组织的“形”“意”“神”
5. Scrum這個字是什麼意思
6. Scrum懶人包 – 10分鐘讀懂Scrum與敏捷軟體開發入門
7. 历史:敏捷宣言诞生记
8. 敏捷进化趣
9. 敏捷拥护者眼中敏捷开发的常见问题


更多阅读:

一万六千字谈谈如何实现经典“四则运算”算法优化 Redis 集合运算


与其临渊羡鱼 不如退而结网 | 与其诅咒黑暗 不如燃亮灯火 | 与其哀叹路遥 不如上下求索

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注