文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

你准备好戴上拳击手套进入拳击场了吗?

你准备好变得困惑吗?

你准备好没完没了地讨论语义了吗? 想要聘请昂贵的顾问来告诉你你做错了什么,并且通过让每个人“被认证”能使你的团队达到更高的水平吗?

第 1 段(可获 0.61 积分)

那么,欢迎来到软件开发方法的世界。

我们没有蛋糕,但是在我们每天的站立会议中我们会有甜甜圈。

在软件开发社区,也许没有比软件开发方法及其实现工具的选择更能引起争论的了。

软件开发方法定义了我们构建软件的过程。

其中一些方法相当的轻量级,只是告诉你一系列原则而不会多说其他东西。

而其它一些方法,比如极限编程,却是极其的规范,会确切的告诉你该如何构建你的软件以及如何运作你的整个团队。

第 2 段(可获 1.26 积分)

在这一章节,我们将首先回顾过去,看一下老的开发模式:瀑布过程,实际上这一模型在如今许多公司组织中仍然被使用。

然而,我们要进入当今软件开发最流行的模式:准定义的一种模式,每一个人都在用它,但是没有人用对,在方法论中赫赫有名的敏捷开发。

最终,我将向你介绍我认为最基本的敏捷开发的三个主要实现,如今也是一直被使用的。

我不得不警告你,我不会尝试覆盖每一个存在的或者曾经存在的软件开发理论。

第 3 段(可获 1.35 积分)

而是我将行使作者的权利,告诉你我认为你应当知道的软件方法。

传统的瀑布模式

当我刚开始学习软件开发的时候,运用传统的瀑布模式是理所当然的。

它是描述软件如何建立的。

我们没有开玩笑。

我们只是将它作为软件开发的方式,并且我们尽我们最好的可能这么做了。

(注:这并不意味着那时没有其他的软件开发方法。有许多软件开发方法,只是它们并没有广泛熟知或运用,并且其中许多开发方法只是更正式的实行瀑布理念而已。.)

第 4 段(可获 1.51 积分)

瀑布模式的开发很就像是它的名字一样。 它一次构建软件的一步,每个步骤下降到下一个较低的步骤,直到开发结束。

内置到瀑布模式开发方法的是软件开发生命周期(SDLC)。

同样的SDLC在几乎每种方法中都会出现。

在瀑布开发中,SDLC是顺序的。

事实上,你可以说,瀑布式开发只是一步一步地跟随SDLC,没有其他的。

你对SDLC熟悉吗?

是啊,你知道我的。

我熟悉SDLC。

它是什么?

它是一个从需求分析到软件设计,到实现,测试,部署,然后最终维护的软件开发过程。

第 5 段(可获 1.45 积分)

你的程序通过每个阶段,你只会向前走,永远不会后退。

阶段之间有一些重叠。

让我们简单地谈谈每个阶段,以便你可以熟悉SDLC。

需求分析

在此阶段,您将收集软件的所有要求。

应该怎么办? 它应该有什么功能?

它应该是什么样子?

它应该如何行为?

您可以通过与客户或利益相关者交谈,或者仅仅自己制作来收集这些信息,但是您需要在构建之前知道要构建的内容。 (虽然当你进入软件开发的世界,如果你还没有,你会很快发现这不是现实的情况。)

第 6 段(可获 1.53 积分)

软件设计

现在你知道你正在尝试构建的软件的要求,现在是时候弄清楚你将如何构建它。

在这个阶段,你将这些需求转化为系统的架构设计,低级算法和UML图(如果你喜欢),并且通常要决定如何构建系统和让系统工作。

软件设计的细节水平正在争论,但是一定程度的设计总是必要的。

在传统的瀑布方法中,您通常具有所谓的前期设计,这些意味着大部分细节刚被以非常低的水平规划出来。

第 7 段(可获 1.48 积分)

如果你总是向前走,从不后退,你有一个固定的时间表,设计一切前面似乎是有道理的,但在实际情况下,需求的变化,有这么多意想不到的情况,这很少奏效。

实施

好吧,现在是时候编码。

软件开发的这个阶段应该是关于编写代码的。

在这里,您将设计从最后阶段到实际工作代码。

我真的不认为有更多的需要说,在这里,所以……继续…

测试

啊,所以你有一个优美的代码,是优雅的设计,完美地实现,并像一千太阳闪耀。

第 8 段(可获 1.48 积分)

然后,一些油腻着头发的测试人员出现,并且通过展示你是如何偏离了需求和你那实际上并没有真正工作的代码来打破这一切。

这就是测试阶段。

这些测试人员一直在创建测试计划、编写测试用例。当他们第一次见到你在你小小的工位上享受的写着代码的时候,就开始为这一时刻而准备了。在他们心里,没有人应该这样的快乐。

现在,这些测试人员开始运行他们的测试用例,来寻找bug。在经过了几次讨论,玩过了几次小把戏之后,直到你尽可能的修复了bug并且所有人都同意了,你的工作才能继续前进。

第 9 段(可获 1.34 积分)

部署

现在是时候看看你的程序是否真的工作。

如果你有多个单独开发的组件,你把它们绑在一起,你可以称之为“集成”阶段,但无论如何,你必须部署该代码。 把它放在实际环境中。

这可能意味着将代码部署到服务器,然后紧张地翻转交换机,说:“我们活着。

这可能意味着制作金黄色的标准CD,你会发送给所有的客户。

今天,它可能意味着将您的应用程序上传到应用商店。

无论哪种方式,你现在都把软件 - 所有的希望和梦想 - 放在客户的手中。

第 10 段(可获 1.44 积分)

祝你好运。

我希望你真的修复了这些错误...

 

维护

哦,你以为当你把这个软件投入生产并发给你的客户时你已经完成了任务?

已经开始做下一个事情了?

不要那么快。 大多数项目最终在维护阶段比任何其他阶段更长。

一旦软件在运行中,你还需要支持它。

现在,您将修复客户发现的错误,添加新功能,并保持一切顺利运行。

只要软件仍在使用和支持,此阶段就会持续。

敏捷开发

敏捷开发真的在软件开发方面发生了巨大变化。

第 11 段(可获 1.41 积分)

在敏捷开发模式产生之前,无论承认与否,大多数开发项目使用的是瀑布开发模式。

我的意思是软件开发人员持续构建软件,从软件生命周期的一个阶段到另一个阶段。

虽然在敏捷开发方法形成之前,一些软件开发项目使用了迭代的方法,把整个软件生命周期分为较小的周期,这种理念在敏捷产生之前并没有正规化。

那敏捷到底是什么呢?

好吧,即使介绍了几年的敏捷,我们仍没有真正的了解。.

敏捷的概念有点模糊。你必须了解其历史来理解什么是敏捷。

第 12 段(可获 1.3 积分)

敏捷宣言

敏捷宣言起始于在美国犹他州的瓦萨奇山雪鸟滑雪胜地。

一群来自软件开发不同领域的人与行业领袖聚在一起,试图找寻在软件开发在各行业中的共同点。

团队成员原本有17名成员,他们在那个时候讨论了一些会影响软件开发的问题,并一致形成了所熟知的 敏捷宣言 ,  你在下文中将看到:

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。

第 13 段(可获 1.19 积分)

由此我们建立了如下价值观:

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

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

这是基于如下的12条准则:

我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

欣然面对需求变化,即使在开发后期也一样。善于掌控变化,帮助客户获得竞争优势。

第 14 段(可获 1.16 积分)

经常开发工作软件,从几个星期到几个月,优先考虑较短的时间。

商务人士和开发人员必须在整个项目中每天一起工作。

围绕积极的个人建立项目。

给他们所需要的环境和支持,并相信他们完成工作。

向开发团队传达信息和在开发团队内部传递信息的最有效和最有效的方法是面对面交谈。

工作软件是进步的主要衡量标准。

敏捷过程促进可持续发展。

第 15 段(可获 1.05 积分)

赞助商,开发人员和用户应该能够无限期地保持一个恒定的速度。

持续关注技术卓越和良好的设计增强了敏捷性。

简单 - 最大化未完成的工作量的艺术是至关重要的。

最好的架构,要求和设计来自自组织团队。

定期地,团队反思如何变得更有效,然后相应地调整和调整其行为。

我认为这些原则更好地说明了敏捷是什么,而不是宣言本身。

敏捷开发不是真正的方法论

第 16 段(可获 1.1 积分)

因此,正如你所看到的,敏捷并不是一个真正的方法论,它在一个很高的层次上定义了软件开发者该如何去工作, 很多其他的方法论都继承了它,而这也被认为是敏捷开发的性质。

敏捷认为软件应该是增量式的开发和交付的。并且需要接受这样的一个观点,需求是能够并且可以在软件开发过程中有变化的。

它还重新定义了一些软件开发团队成员之间的关系,通过评估面对面交流和自组织团队来去除繁重的文档和严格的协议。

第 17 段(可获 1.21 积分)

正如我所说的,一些开发者团队已经开始做了一些相关努力,并且实行了一些遵循某些敏捷原则的方法论,但在大多数情况下,这个世界上大部分人还是在使用传统的瀑布模式来开发软件。

瀑布模式的问题

在我们深入研究当前流行的敏捷方法之前,让我们花一点时间去讨论一下:为什么瀑布模式听起来很不错,但实际执行起来却没有想象中的那么好?其中一个最大的问题就是需求变更,或者说,需求变更一直都没有被处理直到项目到了晚期。

 

第 18 段(可获 1.4 积分)

如果你尝试使用瀑布模式来开发软件,并且试图在前期拿到所有的需求。那么突然而来的需求变更或者新需求对你来说并不是一个好的兆头。

如果你已经完全设计好了系统的架构但又必须改变其中的某些东西。你在实现它的过程中要么废掉一部分已经完成的工作并回滚,要么使劲跺下脚并勇敢的说No。

就是这样,无论是项目滑坡或者使你做了一些错误的事情使你的客户心生讨厌。

第 19 段(可获 1.33 积分)

作为一个软件开发人员,任何事情都不会发生变化想必是极好的。

如果我们能收集并执行所有的需求、计划、问题想必也是极好的。

但是,生活是不会这样继续的。

其实,敏捷是关于承认事实、接受现实,并且在这些约束上去构建软件开发的过程,而不是反对它。

这就是敏捷。

Scrum

现在让我们来谈谈一些流行的敏捷开发方法。

我并不打算覆盖到敏捷的每一部分,老实说,大多数团队声称他们使用了敏捷中的一些方法,但事实上并没有真的做到。

 

第 20 段(可获 1.38 积分)

他们只是冠了个名字而非真正的在实践中使用。

大部分团队所做的事情我会将他们归类为类敏捷开发方法。

那么,Scrum是从哪里被引入的呢?

Scrum 大概在1990年之前被 Ken Schwaber 和 Jeff Sutherland 几乎同时创建。在1995年,他们 在一个联合论文中定义了Scrum方法论,合并了他们的研究。

Scrum 是一个形式化和规定性的方法论。它在一个开发团队中定义了一些特殊的角色。它定义了一个软件开发的工作流,以及在每次迭代中应该开什么样的会议,或者说一个冲刺中。

第 21 段(可获 1.25 积分)

Scrum的角色

在Scrum中有三个主要角色。

首先,产品所有者充当客户的角色,并最终确定工作的优先级,以及与业务其他部门,其他利益相关者和客户进行沟通。

开发团队不仅编写代码,而且执行分析,设计,测试和与交付软件相关的所有其他任务。

最后,Scrum主人就像团队的教练一样,帮助消除任何妨碍团队,与产品所有者沟通,促进Scrum过程的障碍。

第 22 段(可获 1.31 积分)

Scrum如何工作

Scrum背后的基本思想是,软件开发被分解为更小的迭代,称为sprint,它有一定数量的工作,在该时间段内被锁定和完成。 然后,在每个冲刺结束时将结果递增地递送给客户。

需要为软件开发的所有功能都被放在一起成为所谓的产品积压。 (这些基本上就像系统的要求。)

优先处理产品积压,并且在每个冲刺期间,创建冲刺积压,其中在该冲刺期间拉动某一组产品积压项目以工作,这通常持续一或两周。

第 23 段(可获 1.51 积分)

在每个冲刺的开始,当所有的积压工作放入冲刺目标时,举行规划会议,并且当前团队估计完成积压工作的努力水平。

技术上,团队应该承诺在sprint期间完成所有这些积压,但我发现,在实践中很少发生。 (承诺很困难。)

每天都有一个快速的站立会议,称为Scrum,每个人都提供了一个真正快速的报告。

Scrum会议的想法是让每个人了解情况,消除任何可能减缓进度的障碍。

第 24 段(可获 1.24 积分)

Scrum会议每天在同一地点同时进行,每个团队成员回答三个问题:

  1. 你昨天做了什么帮助团队达到冲刺目标?
  2. 今天你会做什么,将帮助团队达到冲刺的目标?
  3. 是否有任何障碍阻止您或团队达到冲刺目标?

我发现对问题2要求个人承诺是非常有用的。

所以,我会改为“我今天承诺做什么,这将有助于团队达到冲刺的目标?

这种微妙的变化在我的经验中有很大的区别。

第 25 段(可获 1.39 积分)

在sprint期间,团队一起工作以完成该sprint中的所有积压项目,并且通常使用一个燃尽图来跟踪团队完成积压项目的进度和速度。

燃尽图跟踪剩余小时,故事点,难点,或者用于跟踪在冲刺中剩余的工作的任何描述方法。

当冲刺结束时,进行审查,其中在冲刺期间完成的功能向利益相关者展示。

最后,召开回顾会议,团队反思过去的冲刺,并在下一个冲刺中开发改进的想法。

第 26 段(可获 1.34 积分)

Scrum 的问题

当Scrum被正确的执行的时候,我发现对软件开发来说这是一个极其高效和有价值的方法论。

不幸的是,我发现事实上它并没有被执行的很严格,并且大多数的津贴被用于补偿失败或者尝试和游戏这个系统。

我曾写过很多关于在一般情况下我认为Scrum是如何失败的文章,因此在这里我不会详细的讨论这个问题,但是我曾经提到过,我认为这个问题是非常值得讨论的,并且我认为这是Scrum团队没有获得他们应该获得的成功的最大原因。

第 27 段(可获 1.34 积分)

承诺

作为多个团队的Scrum主管,教导了许多组织实施Scrum,我发现最容易杀死一个成功的Scrum实现的事情是缺乏承诺 - 无论是团队还是个人层面。

如果一切顺利,并根据计划,真的很容易把积压项目放入sprint并完成它们。

但实际承诺完成这些积压项目是一个困难的事情。

没有承诺的概念,问责制的标准下降,同时冲刺也失去意义,因为放入冲刺的工作只是一个白日梦,不可能实现。

第 28 段(可获 1.43 积分)

它非常像创建一个你每天待办事项的待办列表,每天都尽量让他们完成,但大多数日子没有完成列表。

列表本身开始变得没有意义,随着时间的推移,你开始怀疑为什么有它。

对自己和团队承诺你将花费99%的时间去完成任务会非常有效,因为那样你可以相信自己,你也被团队信任。

我可以多谈一些关于这个问题,但我想你明白这一点。

看板

虽然Scrum是一个相当正式和规范的方法 -——至少在工作流和组织上 ——但 看板不是。

第 29 段(可获 1.58 积分)

看板是类似的,但它是一个更宽松定义的方法,更多地基于原则而不是指令。

看板起源于丰田生产系统和精益制造。

最初看板是作为限制生产中制造工作的一种方式,可以提高效率和减少库存。

当应用于软件开发时,看板主要集中于所谓的看板

看板是一个简单的板,其中包含多个列,代表了工作流程在开发过程中的各个阶段。

 

第 30 段(可获 1.23 积分)

这里的想法是使一个项目上的所有工作都可见,并限制一次完成的工作总量(称为WIP或正在进行的工作),以便识别和减少瓶颈。

像Scrum一样,看板是基于自组织团队的想法,它是多学科的。

看板易于应用于现有的系统和过程,并且通过可见的看板显示通过这些系统的工作流程的形式化和可视化。

看板非常注重通过反馈循环持续改进的想法

第 31 段(可获 1.26 积分)

没有明确的软件开发团队使用看板的方式,所以这个过程会因团队而异。

通常,您可能希望团队拥有需要完成的积压项目或待办工作列表,并且该工作将优先。

然后,团队中的某人会拿起要完成的新工作,并将其添加到看板上。

当工作从一个阶段进展到另一个阶段时,工作将在看板上移动。

也许工作从分析和设计开始,然后进展到开发,然后移动到测试和最终部署,但是在过程中、其他方式或组织工作上可能有各种步骤。

第 32 段(可获 1.5 积分)

我一直都是看板法的忠实粉丝。

事实上,我在我的大多数工作中都会使用各种各样的看板法,也包括这本书。

但是我一直感觉这里应该有更多一点的关于看板法的具体结构。

前阵子,我写了我自己的正式版本的看板法理论,我叫它 Kanbanand.

目的就是创造更多的针对工作流和开发过程的具体结构和方案。

极限编程(XP)

在这一章里我们讨论的最后一个敏捷方法是我最喜欢的,因为它有高度的说明性,并且促进了软件开发的高度专业化和严谨性。

第 33 段(可获 1.46 积分)

极限编程,或者称之为XP,被Kent Beck创建于1996年。他在1999年出版了他的第一本 Extreme Programming Explained,详细的描述了极限编程。

XP当时提出了很多最佳实践,例如单元测试、测试驱动开发、面向对象编程以及高质量的客户关注,并将其提升到了一个称之为极端的水平。并因此而被命名为极限编程。

由于它的极端性和严谨性,虽然现在有一些团队还在使用它,但它从没有变得特别流行过。(到目前为止,最为常见的是Scrum或者Scrum的一个变种,我称之为Scrumbut)

第 34 段(可获 1.28 积分)

极限编程,类似其他的敏捷开发方法论,都认可变化和利用短开发周期或迭代来应对随时间推移而产生的需求变更和软件演化。

极限编程的开发进程以一组极其集中的纪律为中心。

极限编程者会列出他们需要做的工作,就像Scrum,然后分配各点的工作开始做。

当工作实际完成时,它开始测试。

验收测试定义了完成标准,工作项目必须通过测试才会被认为是完成的。

 

第 35 段(可获 1.19 积分)

在任何实际代码被编写前,一个明确定义了代码在各种情况下应该做什么的单元测试就被创建了,随后测试将会驱动代码的实际开发。

极限编程很大程度上依赖于结对编程,也就是两个开发者坐在一起,共同编写即将被创建所有的代码。

我们的目标一直都是设计与实现的功能尽量简单,专注于当前的需求而不是将来的需求。

这个想法是代码可以在出现更复杂的情况的时候去处理这些情况,而不是试图过早优化或者提供额外的灵活性,这通常会造成复杂性成本的增加。

第 36 段(可获 1.43 积分)

管理代码所有权和编码规范的概念对实施极限编程来说非常重要。

极限编程即便是如此规定性的要求,也没有开发者可以在项目中一直这样做。

你可以想象的到,极限编程受到了很多的批评,如果没有一个所有成员都致力于遵守它的原则和实践的团队,它实施起来是极其困难的。

在一个局外人看来,极限编程更像是一个编程邪教。

但我必须说我个人很喜欢极限编程,并且发现它在被正确实施的时候是极其高效的。

我总是会有一个极其困难的时期用来说服管理者和开发团队完全采用这个开发过程。

    

第 37 段(可获 1.44 积分)

其他方法和不用方法

让我们在这里坦陈相告:你工作的大多数软件开发团队自称遵循一些方法论,而实际上不是真正地遵循它,或假装不遵循任何正式的方法论。

我过去常常因此而心烦意乱。

我曾经站上演讲台,并向下面传达了Scrum信息的价值,或者实际而不是假装实现XP的好处。

有时我会问,“你使用什么方法来开发你的软件?”当我得到答案“我们没用任何方法,”我只想说shit。

第 38 段(可获 1.38 积分)

我所意识到的是,一种具体的方法不像具有某种可重复和可测量的可以演变和适应的过程那么重要

如果你的团队在实行Scrum和改进他们实行Scrum的工作,这是伟大的。

但是,如果你的团队从Scrum中获取一些东西,并从Kanban和XP中获取一些东西,或者做出自己的流程,只要有一些流程并且有效,它也是伟大的。

这是关键。 一个可重复和定义的流程。

所以,当你在学习方法时,我敦促你考虑最后几点。

第 39 段(可获 1.36 积分)

首先, 可重复过程比具体的方法更重要。

第二, 只是因为方法不列在这里并不意味着它不是软件开发团队使用一个有效的方法 。

这是一个很长的书,但一个简短的一章,而不是试图涵盖每一个存在的软件开发方法有每一直试图给你的方法,一个基本的了解,我觉得大多数的软件开发过程的今天,利用或重借。

第 40 段(可获 1.08 积分)

文章评论

CY2
苏州小浮云
不是说17年可译有大招的么,没看出来啊
CY2
兼职做忙不过来啊
苏州小浮云
原来可译也只不过是你的兼职啊,人才啊!