《敏捷软件开发(原则、模式与实践)》前三章笔记

 《敏捷软件开发(原则、模式与实践)》
(美)Robert C.Martin 著
        邓辉 译
        孟岩 审

笔记

笔记摘录:Eleven

第一部分 敏捷开发

第1章 敏捷实践
    
    教堂尖顶上的风标,即使由钢铁制成,如果不懂得顺应风势的艺术,一样会被暴风立即摧毁。
                                                ——海因里希.海涅(1797-1856,德国诗人)

1 敏捷联盟宣言(The Manifesto of Agile Alliance)
我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法,通过这项工作,我们认为:
    个体和交互     胜过    过程和工具
    可以工作的软件 胜过    面面俱到的文档
    客户合作        胜过 合同谈判
    响应变化        胜过    遵循计划

1.1 个体和交互胜过过程和工具
    人是获得成功的最为重要的因素。
    一个优秀的团队成员未必就是一个一流的程序员,一个由平均水平程序员组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平程序员但是缺乏沟通和料流的团队更有可能获得成功。
    合适的工具对成功来说是重要的,但是其作用不可被过分夸大,敏捷方法建议从小的工具开始,尝试一个工具,直到发现它无法适用时才去更换它。例如:如果开始的时候没有迫切要求使用庞大的、高性能的数据库,那么就可以先使用文件来取代。  
    记住,团队的构建要比环境的构建重要得多。一个项目中,一个你该首先致力于构建团队,然后再让团队基于需要来配置环境。

1.2 可以工作的软件胜过面面俱到的文档
    没有文档的软件是一种灾难,然而过多的文档比没有文档更糟,会浪费时间和精力,如果文档和代码不能同步,文档会造成更多的代价和误导。
    对于团队来说,编写并维护一份系统原理和结构方面的文档将总是一个好主意,但是必须短小而且主题突出,“短小”的意思是说,最多有一二十页。“主题突出”是说应该仅论述系统的高层结构和概括的设计原理。
    在给新的团队成员传授知识方面,最好的两份文档是代码和团队。(代码是惟一没有二义性的信息源),在团队的头脑中,保存着时常变化的系统脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
    Martin文档第一定律(Martin's first law of document):直到迫切需要并且意义重大时,才编制文档。

1.3 客户合作胜过合同谈判
    成功的项目需要有序、频繁的客户反馈。作者认为小嗯木成功的关键在于和客户之间真诚的写作,并且合同指导了这种写作,而不是试图去规定项目范围的细节和固定成本下的进度。

1.4 响应变化胜过遵循计划
    响应变化的能力常常决定这一个软件项目的成败。当我们构建计划时,应该确保计划是灵活的并且易于适应商务和技术方面的变化。
    作者认为较好的做计划的策略是:为下两周做详细的计划,为下三个月做粗略的计划,再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务,粗略地了解一下以后三个月要实现的需求。至于系统一年后将要做什么,有一个模糊的想法就行了。(这样的计划仅仅支配了几周的时间,计划的其余部分仍然保持着灵活性)

2 原则
(1) 我们最有限要做的是通过尽早的、持续的交付有价值的软件来使客户满意
(2) 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
(3) 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
(4) 在整个项目开发期间,业务人员和开发人员必须每天都一起工作。
(5) 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持,并且信任他们能够完成工作。
    在敏捷项目中,人被认为是项目取得成功的最重要的因素。所有其他的因素——过程、环境、管理等——都被认为是次要的。当它们对于人有负面的影响时,就要对它们进行改变。
(6) 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
(7) 工作的软件是首要的进度度量标准。
(8) 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
(9) 不断地关注优秀的技能和良好的设计会增强敏捷能力。
(10) 简单——使未完成的工作最大化的艺术——是根本。
(11) 最好的架构、需求设计出自于组织的团队。
    对于敏捷团队来说,人物不是从外部分配给单个团队成员,而是分配给整个团队,然后再由团队来确定完成任务的最好方法。
(12) 每隔一段时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

3 结论
敏捷过程:SCRUM,CRYSTAL,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ADP),以及最重要的极限编程(eXtreme Programming,简称XP)。



第2章 极限编程概述

    作为开发人员,我们应该记住,XP并非惟一选择。
                                    ——Pete MaBreen

1 极限编程实践
极限编程(eXtreme Programming,简称XP)是敏捷方法中最著名的一个。它由一系列简单却互相以来的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

1.1 客户作为团队成员
    XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。在XP项目中,无论谁是客户,他们都是能够和团队一起工作的团队成员。
    最好的情况是客户和开发人员在同一个房间中工作,次一点的情况是客户和开发人员之间的距离在100米内,距离越大,客户就越难成为真正的团队成员,作者认为,如果确实无法和客户在一起工作,那么就去寻找能够在一起工作、愿意并能够代替真正客户的人。

1.2 用户素材
    为了进行项目计划,必须要知道和项目需求有关的内容,但是却无须知道得太多。对于做计划而言,了解需求只需要做到能够估算它的程度就足够了。
    需求的特定细节很可能会随实践而改变。因此,在离真正实现需求还很早的时候就去捕获该需求的特定细节,很可能会导致做无用功以及对需求不成熟的关注。
    用户素材(user stories,当然,在这里我更喜欢称其为用户故事)就是正在进行的关于需求谈话的助记符。它是一个计划工具,客户可以使用它并根据它的优先级和估算代价来安排实现该需求的实践。

1.3 短交付周期
    XP项目每两周交付一次可以工作的软件。每两周的迭代(interaction,也可成为成哦故你服周期或循环周期)都实现了涉众的一些需求,在每次迭代结束时会给涉众演示迭代生成的系统,以得到他们的反馈。
迭代计划:每次迭代通常耗时两周。是一次较小的交付,可能会被加入到产品中,也可能不会。它由客户根据开发人员确定的预算而选择一些用户素材组成。
        一旦迭代开始,客户就统一不再修改当次迭代中用户素材的定义和优先级别,迭代期间,开发人员可以自由地将用户素材分解成为任务(task),并根据最具技术和商务意义的顺序来开发这些任务。
发布计划:XP团队通常会创建一个计划来规划随后大约6次迭代的内容,也就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付,通常此次交付会被加入到产品中。
        发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用户素材组成。
        发布计划不是一成不变的,客户可以随时改变计划的内容,他可以取消用户素材,编写新的用户素材,或者改变用户素材的优先级别。(这里我个人认为并不是可以随时进行更改,而应当是说在未来2周也就是迭代计划中所用到的用户素材是不可以进行更改的,而之后的都是可以根据用户需要进行更改或者其他操作)

1.4 验收测试
    可以以客户指定的验收测试(Acceptance Tests)的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户素材之前或实现该用户素材的同时进行编写的。(可以看出,和一般的功能测试或者单元测试并不相同)
    验收测试使用能够让它们自动并且反复运行的某种脚本语言编写,这些测试共同来验证系统按照客户指定的行为运转。
    客户可以借助于QA来开发验收测试工具,并编写验收测试。
    一点通过一项验收测试,那么就加入到已通过的验收测试集中,并决不允许该测试再次失败。这个验收测试集每天会被多次运行,每当系统被创建时,都需要运行这个验收测试集,如果一项验收测试失败,那么系统创建宣告失败。因此,一项需求一旦被实现,就再不会遭到破坏。系统从一种工作状态变迁到另一种工作状态,期间,系统的不能工作状态时间决不允许超过几个小时。

1.5 结队编程
    所有产品(production)代码都是由结队的程序员使用同一台电脑共同完成的。结队人员中的一位控制键盘并输入代码,另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。两个人强烈地(intensely)进行着交互,他们都全身心地投入到软件的编写中。
    结队变成的代码是由两人共同设计、共同编写的,两人功劳均等。
    结队的关系每天至少改变一次,以便于每个程序员在一天中可以在两个不同的结队中工作。在一个迭代期间,每个团队成员应该和所有其他的团队成员在一起工作过,并且他们应该参与了本次迭代中所涉及的每项工作。
    这样可以促进知识在团队中的传播。
    Laurie Willianms和Nosek的研究表明,结队非但不会降低开发团队的效率,而且会大大减少缺陷率。

1.6 测试驱动的开发方法
    编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试,由于它要测试的功能还不存在,因此它会运行失败,然后,编写代码使测试通过。而且这样的方式非常利于重构。而且这样一种方式可以激发程序员去解除各个模块之间的耦合,这样能够独立地对它们进行测试。面向对象设计的原则在进行这种解除耦合方面具有巨大的帮助作用。

1.7 集体所有权
    结队编程中的每一对都具有拆出(check out)任何模块并对它进行改进的权力。没有程序员对任何一个特定的模块或技术单独负责,每个人都参与GUI方面的工作;每个人都参与中间件方面的工作;每个人都参与数据库方面的工作。没有人比其他人在一个模块或者技术上具有更多的权威。

1.8 持续集成
    XP团队每天会进行多次系统构建,他们会重新创建整个系统。

1.9 可持续的开发速度
    XP团队必须要以一种可持续的速度前进,必须要有意识地保持稳定、适中的速度。
    XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的惟一例外。如果发布目标就在眼前并且可以一蹴而就,则允许加班。

1.10 开放的工作空间
    密歇根大学的一项研究表明,在“充满积极讨论的屋子(war room)”里工作,生产率非但不会降低,反而会成倍地提高。

1.11 计划游戏
    计划游戏(planning game)的本质是划分业务人员和开发人员之间的职责。业务人员(客户)决定特性(feature)的重要性,开发人员决定实现一个特性所花费的代价。在每次发布和每次迭代的开始,开发人员基于在最近一次迭代或者最近一次发布中他们所完成的工作量,为客户提供一个预算。客户选择那些所需的成本合计起来不超过该预算的用户素材。

1.12 简单的设计
    XP团队使他们的设计尽可能地简单、具有表现力(expressive)。此外,他们仅仅关注于计划在本次迭代中要完成的用户素材。他们不会考虑那些未来的用户素材。这意味着XP团队的工作可能不会从基础结构开始,只有当出现一个用户素材迫切需要基础结构时,他们才会引入该基础结构。
三条XP知道原则(mantras):
(1) 考虑能工作的最简单的事情
(2) 你将不需要它
(3) 一次,并且只有一次

1.13 重构(refactoring)
    重构就是在不改变代码行为的前提下,对其进行一系列小的改造(transformation),旨在改进系统结构的实践活动。每个改造都是微不足道的,但是这些所有的改造迭加在一起,就形成了对系统设计和架构显著的改进。(也就是只要认为可以进行改进的地方,就必须毫不犹豫地去进行改进)
    每次重构进行完后,必须运行单元测试,保证重构没有造成任何破坏,然后再去做下一次重构。而且,重构是持续进行的。

1.14 隐喻
    隐喻(metaphore)是所有XP实践中最难理解的一个。隐喻是将整个系统联系在一起的全局视图,它是系统的未来景象,是它使所有单独模块的位置和外观(shape)变得明显直观。

2 结论
    极限变成是一组简单、具体的实践,这些实践结合在一起形成了一个敏捷开发过程。



第3章 计划

    当你能够度量你所说的,并且能够用数字去表达它时,就表示你了解了它;若你不能度量它,不能用数字去表达它,那么说明你的知识就是匮乏的、不能令人满意的。
                                                                                            ——凯尔文勋爵(英国物理学家),1883

1 初始探索
    在项目开始时,开发人员和客户会尽量确定出所有真正重要的用户素材。然而,他们不会试图去确定所有的用户素材。随着项目的进展,客户会不断编写新的用户素材。素材的编写会一直持续到项目完成。(这里应该主要是由于需求伴随着项目的进展发生着变化,因此才会这样的吧)
    开发人员共同对这些用户素材继续估算。估算是相对的,不是绝对的。我们在记录素材的卡片上写一些“点数”表示实现这个素材的相对时间,我们无法确定每个点数代表的时间,但是我们知道8个点的素材所需要的时间应该是4个点的两倍。
    任何过大的素材都应该被分解成小一点的部分,任何过小的素材都应该和其他小的素材进行合并。
    为知道用户素材的绝对大小,需要一个成为速度(velocity)的因子。
    伴随项目的进展,由于可以度量每次迭代中已经产正的用户素材点数,所以速度的度量会越来越准确。通常,去原型化一到两个用户素材来了解团队的速度就足够了,这样的一个原型化的过程成为探究(spike)。

2 发布计划
    用户素材实现顺序的选择不是单纯依据优先级进行的,一些重要的但是实现起来代价高昂的素材可能会被推迟实现,而会先去实现一些不那么重要的,但是代价要低廉得多的素材。此类选择属于商务(business)决策范畴。让业务人员来选定那些会给他们带来最大利益的素材。
    当开发速度变得准确的时候,可以对发布计划进行相应的调整。

3 迭代计划
    在选择用户素材的时候,觉不允许客户选择与当前开发速度不符的更多的素材。
    迭代期间用户素材的实现顺序属于技术决策范畴,开发人员采用最具技术意义的顺序来实现这些素材。
    和前面提到的一样,一旦迭代开始,客户就不能再改变该迭代期内需要实现的素材。
    即使没有完成所有的素材,迭代也要在先前指定的日期结束。开发人员会合计所有已经完成的素材的估算值,然后计算本次迭代的开发速度,这个速度会被用于下次迭代。规则很简单:每次迭代做计划时采用的开发速度就是前一次迭代中测算出的开发速度。

4 任务计划
    在新的迭代开始时,开发人员和客户共同制定计划。开发人员把素材分解成开发任务,一个人物就是一个开发人员能够在4-16个小时内实现的一些功能。
    每个开发人员都知道在最近一次迭代中完成的任务点数,这个数字可以作为下一次迭代中的个人预算。
    任务的选择一直到所有的任务都被分配出去,或者所有的开发人员都已经用完了他们的预算时为止。如果任务还没有分配完毕,那么会互相协商,开发人员将基于各自的特长交换相应的任务。如果还是有多余任务,那么就将考虑要求客户从本次迭代中去掉一些任务或者素材。如果所有的任务都已经被分配,并且开发人员仍然具有预算空间去完成更多的任务,那么他们将会向客户要求更多的素材。
    在迭代进行到一半的时候,团队必须召开会议查看所完成的素材(并非是任务,因为任务完成了一半,素材却都没有完成的情况,是毫无意义的)数量,应该是一半的素材都被完成,如果没有,那么团队应该设法重新分配没有完成的任务和职责,以保证在迭代结束时能够完成所有的素材。

5 迭代
    每次迭代结束时,会给客户演示客户演示当前可运行的程序。客户将会根据他们看到的反馈新的用户素材。

6 结论
    通过一次次迭代和发布,项目进入了一种可以预测的、舒适的开发节奏。
    使用敏捷方法并不意味着涉众就可以得到他们想要的。它不过意味着他们将能够控制着团队以最小的代价获得最大的商业价值。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页