软件项目成功之道pdf/txt下载_在线阅读全文

编辑推荐

　　根除项目延期之痼疾！
　　打开软件项目成功之门！
　　经验宝贵，篇幅精练，讲解透彻！

内容简介

　　如何成功地开发并交付软件，是许多软件企业面临的难题。本书由专业开发人员编写，汇集大量实用性建议及成功的项目团队需要用到的工具和技术，通过42个技巧全面概括了软件开放的方方面面，为开发人员指明了最适用的方法。本书还给出了大量软件开发实践，供读者认真思考并将其中涉及的具体概念转化为自己的所得。
　　就像其他Pragmatic图书一样，本书作者不仅无私分享了自己多年的软件开发经验，而且将枯燥乏味的软件开发过程描写得趣味横生，相信本书会对你的软件研发工作有所启迪，从而改变一些思维定式和研发模式。

作者简介

　　Jared R. Richardson是一名开发人员、演说家、作家和独立顾问，是由开发人员逐步成长为研发经理的。他有着十多年丰富的工作经验，擅长使用非定制技术来解决疑难问题。他领导着SAS软件研究所的一个开发和测试团队，负责带领整个公司提高了测试自动化的使用。

William A. Gwaltney Jr.有着二十多年软件开发经验，在网络、通信、知识表达及基于网络的计划调度方面都很有造诣。他在SAS软件研究所从事测试自动化方面的工作。

目　　录

第1 章　绪论　　
　1.1 习惯性优秀　　
　1.2 务实观点　　
　1.3 路线图　　
　1.4 继续前进　　
　1.5 怎样读这本书　　
第2 章工具和基础设施　　
　1 在沙箱中开发　　
　2 管理资产　　
　3 建立构建脚本　　
　4 自动构建　　
　5 跟踪问题　　
　6 跟踪特性　　
　7 使用自动化测试框架　　

第1 章　绪论　　 
　1.1 习惯性优秀　　 
　1.2 务实观点　　 
　1.3 路线图　　 
　1.4 继续前进　　 
　1.5 怎样读这本书　　 
第2 章 工具和基础设施　　 
　1 在沙箱中开发　　 
　2 管理资产　　 
　3 建立构建脚本　　 
　4 自动构建　　 
　5 跟踪问题　　 
　6 跟踪特性　　 
　7 使用自动化测试框架　　 
　8 选择工具　　 
　9 何时结束试验　　 
第3 章 实用项目技术　　 
　10 按照任务清单工作　　 
　11 技术领导人　　 
　12 每天都要协调和沟通　　 
　13 审查所有代码　　 
　14 发送代码变更通知　　 
　15 大汇总　　 
第4 章 曳光弹开发　　 
第5 章 常见问题及解决办法　　 
　16 救命！我继承了遗留代码　　 
　17 测试不可测试的代码　　 
　18 特性不断破坏　　 
　19 测试？我们早就不用了　　 
　20 不过我这里没问题！　　 
　21 集成代码很痛苦　　 
　22 不能可靠地构建产品　　 
　23 客户不满意　　 
　24 有一个另类的开发人员　　 
　25 你的经理不满意　　 
　26 团队不能很好地合作　　 
　27 在根本问题上无法得到“认可” 　　 
　28 新实践没有帮助　　 
　29 没有自动测试　　 
　30 我们只是低级别开发人员，没有人指导我们　　 
　31 我们在一个“死亡之旅”项目中　　 
　32 特性不断蔓延　　 
　33 我们永远也完不了　　 
附录A 技巧汇总　　　　 
附录B 源代码管理　　 
附录C 脚本构建工具　　 
附录D 持续集成系统　　 
附录E 问题跟踪软件　　 
附录F 开发方法　　 
附录G 测试框架　　 
附录H 建议阅读书目

显示全部信息

媒体评论

　　我想大多数人都应该读这本书。虽然它主要是写给技术主管看的，不过所有开发人员都能从中受益。如果掌握了本书思想，我相信项目经理们都能获益匪浅。我深深地沉醉在本书中：读着它能让你身心愉悦，内容的框架和组织结构更是让人印象深刻。极力推荐！”
　　——技术作家Harry Newton，news@UK

　　 “如果你只满足于做一个平庸的开发人员，那么这本书*不适合你！”

　　 ——读者评论

在线试读部分章节

如果我们坚持不懈，那么，优秀就不再是一种行为，而成为一个习惯。
亚里士多德
绪　　论
如今，很多软件开发人员都很困惑。他们夜以继日、废寝忘食地工作，可是他们的团队还是无法顺利地完成项目。不是他们的努力不够，也不是愿望不强烈：团队里的每一个人都希望能干净利落地把项目搞定，不过大家都不知道如何共同努力完成工作。你很难有时间坐下来静心读点东西，做些试验，得出哪些做法可行以及如何在你的工作室合理运用。大多数人都太忙于手头的工作，而无暇顾及这种研究。
本书就这样应运而生。这本书汇集了大量基本而实用的建议，这些建议已经在这个领域的多个项目以及大小公司中得到充分证明。我们的亲眼所见和亲身经历可以证明这些方法确实可行。我们不同于那些只在公司出出进进几个星期就离开的顾问，而是天天都在这些公司全力工作。我们并不只是提出一些听起来不错的想法，就匆匆转向下一个预约项目。如果这些想法没有效果，我们还会留在公司查看为什么会失败，哪里出了问题。另一方面，我们必须等到情况好转，工作能够顺利进行下去。
我们介绍的想法有些是从一些众所周知的软件方法中得来的，我们会尽量指明它们的出处。另外一些想法则是我们用热血、汗水和泪水“凝结”而成的。我们尝试过很多工具、技术和最佳实践，如果可行就会将其保留；如果失败，就会断然地放弃。在这里你几乎看不到我们通过盲目摸索得来的一手经验（尽管这是好东西）。相反，我们会“站在巨人的肩上”，精选出这个行业最睿智的思想，把它们转化为你将看到的文字。
如今，50%~70%的软件开发团队并没有使用那些基本的、众所周知的软件实践（[Cus03]）。很多情况下，这并不是因为他们不知道要做什么，而是因为他们不清楚该如何立即开始运用这些实践。我们会告诉你如何向管理层推销这些想法，给出能够让你迅速上手的明确的实用步骤，然后指出要注意哪些警告信号以免脱离正轨。
本书由“一线”开发人员倾力编写。这本书凝聚了我们在不同公司的实践中得出的经验（从初创的小型公司，到全世界最大的私营软件公司），而不是刻板的理论。这是一个不依赖具体方法论的指南，更注重如何让项目顺利完成。
我们努力使这本书沿袭PragmaticBookshelf图书一贯秉承的风格：实用、简洁，轻松阅读。希望能将这一风格发扬光大。
1.1　习惯性优秀

如果我们坚持不懈，那么，优秀就不再是一种行为，而成为一个习惯。 
 亚里士多德 
绪　　论 
如今，很多软件开发人员都很困惑。他们夜以继日、废寝忘食地工作，可是他们的团队还是无法顺利地完成项目。不是他们的努力不够，也不是愿望不强烈：团队里的每一个人都希望能干净利落地把项目搞定，不过大家都不知道如何共同努力完成工作。你很难有时间坐下来静心读点东西，做些试验，得出哪些做法可行以及如何在你的工作室合理运用。大多数人都太忙于手头的工作，而无暇顾及这种研究。

本书就这样应运而生。这本书汇集了大量基本而实用的建议，这些建议已经在这个领域的多个项目以及大小公司中得到充分证明。我们的亲眼所见和亲身经历可以证明这些方法确实可行。我们不同于那些只在公司出出进进几个星期就离开的顾问，而是天天都在这些公司全力工作。我们并不只是提出一些听起来不错的想法，就匆匆转向下一个预约项目。如果这些想法没有效果，我们还会留在公司查看为什么会失败，哪里出了问题。另一方面，我们必须等到情况好转，工作能够顺利进行下去。

我们介绍的想法有些是从一些众所周知的软件方法中得来的，我们会尽量指明它们的出处。另外一些想法则是我们用热血、汗水和泪水“凝结”而成的。我们尝试过很多工具、技术和最佳实践，如果可行就会将其保留；如果失败，就会断然地放弃。在这里你几乎看不到我们通过盲目摸索得来的一手经验（尽管这是好东西）。相反，我们会“站在巨人的肩上”，精选出这个行业最睿智的思想，把它们转化为你将看到的文字。

如今，50%~70%的软件开发团队并没有使用那些基本的、众所周知的软件实践（[Cus03]）。很多情况下，这并不是因为他们不知道要做什么，而是因为他们不清楚该如何立即开始运用这些实践。我们会告诉你如何向管理层推销这些想法，给出能够让你迅速上手的明确的实用步骤，然后指出要注意哪些警告信号以免脱离正轨。

本书由“一线”开发人员倾力编写。这本书凝聚了我们在不同公司的实践中得出的经验（从初创的小型公司，到全世界最大的私营软件公司），而不是刻板的理论。这是一个不依赖具体方法论的指南，更注重如何让项目顺利完成。

我们努力使这本书沿袭Pragmatic
Bookshelf图书一贯秉承的风格：实用、简洁，轻松阅读。希望能将这一风格发扬光大。 
1.1　习惯性优秀 
为什么这里要引用亚里士多德的名言？“如果我们坚持不懈，那么，优秀就不再是一种行为，而成为一个习惯。”能够生产出一个或一些不错的产品算不上优秀。优秀体现在我们每天所做的点点滴滴，也就是我们的习惯。一流的产品只不过是好习惯的副产品。

把这句名言应用到我们自己身上（包括工作和个人生活中），要求我们能够认识到生活实际上只是习惯的副产品，因此最好审慎地选择我们的习惯。大多数人会毫无计划地草率陷入当前的工作模式而不能自拔，这有很多原因：也许你原先就是这么学的，或者这是你的老板一贯的做法，诸如此类。但是，我们确实能做得更好。

要有意识地搜寻好习惯，并把它们加到你的日常生活当中。 
可以做个小实验。找一种要研究的开发方法，挑选一个看上去对你来说不错的习惯（而且这个习惯可以单独运用）。实际使用一个星期。如果你喜欢，而且看来有好处，就继续用上一个月。不断实践这个新习惯，把它变成为你生活模式中很自然的一部分，然后再选择另一个新习惯重新开始这个过程。如同你一砖一瓦地建造地基那样，一次一个新习惯重复这个过程，你就正在为优秀奠定坚实的基础。有时有些做法并不适用于你的环境，请大胆舍弃这些方法，也不要因为某个实践很有名或者很流行就勉强地把它保留下来。要走你自己的路，根据自身情况做出正确的选择。

“我们的每一天怎样度过，一生就会怎样度过”。 既然如此，就必须仔细考虑如何度过我们的每一天。 
  
不要偶然地养成某些习惯，要有意识地主动选择习惯。 
1.2　务实观点 
这本书并不是一个学术著作，单纯地分析为什么有些做法可行或者有些做法不可行，也不会简单地罗列一堆实践和方法供你选择。 
相反，这本书会提供现实的软件项目中比较有用的方法。我们会先引入一个新工具或实践，具体加以运用，弄明白它是否可行。接下来，会把那些可行的工具保留在我们的软件开发工具箱中，并“随身携带”。最终看来，我们所做的确实很奏效！希望这些工具和实践也适用于你。

我们参与过很多小型初创公司的工作，这些小公司条件有限，并不是某种方法“正确”就能够加以使用——他们无法做到如此“奢侈”。我们所处的环境要求我们找出能够立即投入使用的解决问题之道。我们也在较大规模的公司工作过，这些公司拥有丰富的资源和技术。但我们发现，大公司也不会因为某个工具很优秀或者某个专家很推崇就使用这个工具。他们想要的是能够快速而经济地解决当务之急的方案。所以我们会有取舍地挑选合适的习惯，最终建立一个足够通用可以移植，并且仍能有效地解决具体问题的工具箱。这本书汇集了我们使用过的很多好习惯，它们也会对你的工作室产生深远影响——结果可能是惊人的。

为了便于说明，下面来讲一个有关两个软件工作室的“双室记”故事（因为篡改了《双城记》的名字，在此向查尔斯?狄更斯致歉）。 
第一个工作室简直一团糟。他们购买了非常昂贵的源代码管理软件，但是从来没有安装过。结果，他们甚至把原本打算向潜在客户展示的演示版的源代码都弄丢了。没有人能确定产品中应当包含哪些特性，但不管怎样，整个开发团队还在兢兢业业地工作着。开发出的代码很不稳定，每5分钟左右就会崩溃一次（经常还会在关键时刻出问题，比如说在现场演示过程中）。这种混乱严重影响了大家的士气：公司例会的气氛经常急转直下，演变成一场场争吵。有些开发人员成天躲在自己的办公室里，以躲避这种场面。总之，这实在是一个糟糕的工作环境。所有人都知道存在严重的问题，但是没有人能解决。

第二个工作室情况就好多了。开发人员的人数与第一个工作室相当，他们在分头同时开发三项主要产品。这些项目的代码都放在一个源代码管理系统中，只要代码有变更，就会自动重新构建并测试。整个团队每天召开例会，尽管简短，但非常专业而有效。每个项目都有一个主计划，因此每个开发人员都知道要完成哪些功能。他们遵循采石工人的信条：尽管我们只是采石头，但脑海中必须想象着最终建造出的宏伟教堂[HT00]。也就是说，每个人都能在一个更大的框架范围内充分施展他们的专业技能和才华。他们会按时交付问题最少的产品，这些产品都经过精心设计，因此很稳定。

最让人惊讶的是，这两家公司实际上是同一个工作室，这两种状态相隔不超过6个月，区别仅是之前没有应用这本书中的原则，而后来将这些原则充分加以运用。（你应该已经猜到了，对不对？）情况好转之后，CEO说我们引入了一种“卓越的气氛”，他“甚至没有认出这个地方”。这是我们最近参与工作的一家公司，就像书中为你展示的一样，我们为他们应用了这本书中的原则。这种巨变也是促使我们写这本书的一个原因。

我们发现了这些方法，并将其应用于各种规模的公司，从只有4个人的小型初创公司到全世界最大的私营软件公司SAS。坦率地说，这些原则居然能适用于各种规模的公司，让我们也感到惊讶。

可以认为这些理念是得出优秀产品的基础。如果你愿意在前期投入时间建立这么一个很好的基础，在余下的产品生命周期中就会大有收获。当然，如果充分采用这些实践，启动一个项目就会容易得多。就像一幢房子毁坏的地基，有些方面可能很容易修补，而有些则是更深层次结构上的问题，需要下很大功夫才能修复。

目前你的项目可能正在进行当中，但什么时候开始采用好习惯都不晚。你可以把这些想法引入到一个现有的项目中，很快就能有所收获，我们会在最后一章全面介绍有关方法。

1.3　路线图 
我们把想法整理为三部分：基础设施、技术和过程（见图1-1）。这些方面会直接影响你的团队能否始终如一地交付客户想要的产品。 
  
图1-1　如何构建优秀的产品 
1.3.1　基础设施 
在第2章中，我们会介绍一些软件工具，它们能使你和团队更加轻松地完成工作。例如，一个好的源代码管理系统可以保证项目的“重中之重”（即源代码）安全可靠。自动构建系统可以根据需要随时随地提供可重复的构建。我们还会讨论如何跟踪记录bug报告和特性要求，以及向全世界发布你开发的产品的那一刻还可能会出现什么其他问题。最后，我们还会介绍一个很好的自动化测试框架，可以让你放心代码确实在老老实实地工作。
1.3.2　技术 
在第3章中，我们将介绍你和你的团队每天可以使用的一些具体实践，做到“更巧地工作，而不是更玩命地工作”。我们会介绍如何在团队中引入一位“技术领导人”，使你与外部世界隔离，只得到你需要知道的信息。你可以使用“任务清单”来组织自己以及整个团队的工作，保证团队不脱离正轨。你的团队是不是沟通不畅？是不是不知道谁在做什么？如果是这样，就应当开始召开“每日例会”，保证所有人都达成共识，同时借机采纳团队成员的想法。简短的“代码审查”有助于利用同事的专长，还可以与别人分享你的才能。一旦审查结束，就要利用“代码变更通知”向团队的其他人员展示你做了哪些工作。

1.3.3　过程 
如果一本关于软件开发的书没有展示作者最钟爱的开发方法，就谈不上完整，这本书也不例外。所以我们特别增加了一章，取名为“曳光弹开发”（Tracer
Bullet
Development）。使用曳光弹开发方法时，可以创建一个端到端的工作系统，其中大部分组件都是中空的对象，然后填入缺少的部分，使它成为一个真正实用的系统。这对于分解大型项目并让团队并行完成各部分工作很有好处，而且利于自动测试。

1.3.4　常见问题及解决办法 
最后我们会指出一些可能出现的常见问题（和危险信号），并给出实战建议，告诉你如何利用我们在书中介绍的工具、技术和过程来解决这些问题。这里的很多问题我们自己就曾遇到过。有些当时解决了，有些则是事后才知道该怎么办（毕竟，人们经常是事后诸葛亮……）。希望我们的经历能避免你重蹈覆辙，不会犯我们犯过的错误。

1.3.5　哪些内容没有谈到 
人员配备和需求收集不在我们的讨论范围内。好的人才是项目中最重要的部分，他们的作用胜过工具、技术和过程。不过，组织和维持一个优秀的团队是一个值得单独用一本书（甚至一系列书！）去探讨的话题。我们不打算讨论这个方面，而会重点讨论如何充分利用并且进一步发展团队已有的技能。

类似地，了解产品需求也是一个需要深入研究的主题。收集需求有很多方法，从简单的便条卡片，到需要许多检查和平衡的复杂系统。这个主题仅用一章根本无法说明白，我们并不打算去解决这个难题，而是选择了另一种做法，给出一些足够灵活的想法来处理不断变化的需求，而不论需求是从哪里得来的。本书中的想法适用于各种项目，包括需求从不改变的项目，也包括需求不断变化的项目。所以不论你是利用一堆3×5的小卡片了解需求，还是根据一个10
000页的庞大合同分析需求，都可以使用这些想法。 
我们尽量保证讨论的适用面足够广，以便在任何工作室利用任何技术都可以采用这些想法。正是由于这个原因，我们没有特设章节来讨论安装技术或代码优化工具。

1.4　继续前进 
对于这里给出的理念和习惯，希望你能本着它们的内在精神（也就是务实地）加以使用。先阅读，然后动手尝试。根据你的环境，保留那些适用的想法，其他的断然舍弃。

读完每一节后要停下来，想想你是否正在采用刚刚读到的方法。如果没有，那么请读一读“如何起步？”；如果确实采用了这种想法，那么可以读一读“我做得对吗？”或者“警告信号”来确认一切正常。

1.5　怎样读这本书 
如何学习这本书取决于你在项目中承担的角色。很自然，如果是一个开发人员或测试人员，那么你学习这本书的角度肯定与你的团队领导人有所不同，但不论你是什么角色，都能从这本书中收获很多。

1.5.1　开发人员或测试人员 
如果你是一线从业人员（或程序实现人员），那么可以从头到尾读完这本书。每一节都包含一些实用的想法，不论是普通员工还是团队领导人，都可以在每天的工作中使用这些想法。有些开发人员由于不是团队领导，往往会跳过强调团队的章节，这其实很不好。大多数团队环境都是由团队成员的诉求或者他们的直接经历造就的。要把你自己放在一个更高的位置上，知道哪些工具、技术和过程会为你的工作室带来正面影响，并且能为你的每个提议给出充分的理由。我们经常听到开发人员因为某个工具或技术展开争辩，因为“那才是正确的做法”。管理层绝对不会被这种争辩所左右，实际上，争来争去可能还会适得其反。提出一个想法之前，一定要明确了解它对团队有什么好处。

看看这样两个提议，一个是：“我们需要Acme Code
Systems的一个源代码管理系统，因为这个系统很不错，所有人都在用。这是一个最佳实践！”另一个提议是：“我们应该有一个源代码管理系统，有了它我们可以访问以前的版本、撤销特定的代码变更，还允许开发人员安全地处理并行代码树。这是保障公司开发投资最容易的办法。Acme
Code
Systems提供了一个不错的产品，我们应该了解一下。Joe和我已经用了几个月，确实对我们的工作效率有很大改善。它会在以下这些方面对我们提供帮助……”在这两个提议中，哪一个更能让你接受呢？

1.5.2　项目团队领导人 
可以用这本书对团队的环境和工作流做一个审查。（你已经在不时地做这个工作了，对不对？）请利用这个机会重新检查你的团队是如何工作的。有没有一组基本工具可以满足你的基本需求？团队的技术能不能构建可靠的产品，培养可靠的开发人员？有没有一个明确定义的简洁的过程？

审查你的团队如何工作时，一定要考虑每一项的关联性。有没有用到一些原先合适但现在已经失效的工具或实践？ 
你听说过这样一个故事吗？一位女士烧火腿时总是先切掉三分之一。有人问她为什么这么做，她说她妈妈总是这么烧火腿。而她妈妈也说她的妈妈一直是这么做的。最后问到她的外祖母时，老人家说她年轻时家里的锅不够大，没办法放下整只火腿，所以她总是先切掉后面一段，时间长了就养成了习惯。

一定要保证你的习惯是根据当前的需求形成的，而不是因为去年的项目就是这么做或者只是因为“老奶奶式”的怪癖。 
确保你的团队可以得到当前需要的工具、技术和过程。要了解哪些可行以及为什么可行，这是有效地指导团队的唯一途径。我们会在每一节介绍一些技巧，帮助你着手实践，还会给出一些警告信号，提示存在问题以防完全失控。

1.5.3　经理（或当事客户） 
更高管理层只需询问正确的信息，就能对团队如何工作产生很大影响。这本书会告诉你团队应当使用哪些重要工具，以及你应询问哪些类型的问题。例如，如果你要求得到上一个版本的修正清单，实际上就是在说你希望这个信息得到跟踪。读每一小节时，找出要求团队领导人提交的可交付产品（deliverables），这会引导他们的工作不脱离你希望的方向。不过，一定要审慎地提出要求，你肯定不希望你的要求导致团队毫无意义地瞎忙，而希望通过精心设计的要求做出正确的引导。

因为你不必完成开发人员的日常工作，所以可能会跳过“如何起步？”小节，不过你肯定想了解每个主题是什么以及为什么那样做。 
1.5.4　个人组成团队 
这本书中几乎每一个理念都经过团队成员、整个团队以及经理的实际运用。团队成员通常是第一个使用这些实践、证实其价值，然后与团队分享的人。我们自己反复做过这个工作，也见过其他人做过，你也同样可以。有人就这样做过，下面听听他们的故事。

CafePress.com敏捷支持系统的快速发展 
Dominique Plante和Justin McCarthy 
去年年初我们开始在CafePress.com工作，那时管理层对于采用敏捷实践可谓热情万丈，不过要想信心十足地做出改变，开发环境还缺乏必需的基本支持系统。

“Enter the Create and
Buy”项目——这是CafePress核心产品的一个扩展，允许客户轻松地设计和购买定制的商品（如T恤、杯子等）。这个项目首次尝试除了Web表示层外还引入一个明确的业务和持久存储层。业务和持久存储层大部分都设计为先行测试，使用NUnit框架来编写开发测试。同时，我们引入了NAnt，为Web层中使用的类完成可重复的编译和部署。接下来，我们利用CruiseControl.NET基于Subversion代码存储库的每次签入完成持续集成（即编译和运行测试）。最后，委托Chicken
Little（一个规模很小但高度可见且可听的工作站）运行CCTray来提供构建状态通知。 
Subversion、CruiseControl.NET、NAnt和NUnit之间的互操作性帮助我们建立了一个友好的协作环境，而不再频频出现有争议的供应商分析或购买决策。另外，这些支持系统都是由开发人员主动提出的，而不是在管理层要求之下被迫接受的。

由于我们完成了这些自动化，团队开始壮大，很多新的团队成员促进了我们的测试套件和项目自动化工具的成熟过程。最新的升级包括100%脚本开发环境的创建以及自动化测试环境部署，不过回头来看，最常使用的目标仍然是nant
test。 
在这些工具出现之前，我们每天的沟通主要是向大家广播构建失败问题或API变更通知。现在CruiseControl.NET会处理我们的“伙伴构建”，开发人员了解并履行承诺，会保证构建不被破坏。任何人都不愿意由于一个错误的代码签入而导致工作中断。有了这些支持系统，我们的交流很自然地转向软件设计和实现，而不再为如何消除环境方面的问题而困扰。

我们前期的所有努力没有白费，在此帮助下，代码经过测试并即时交付，而且每次Chicken
Little发出“叫声”通知变更时，我们原来的投入就会产生回报！ 
我们认为这才是改变的最佳方式。我们从来不拒绝经理引入改变，但是我们发现最好而且最可行的改变还是来自于一线人员。具体做事的人应该更了解需要解决哪些具体问题。

所以我们认为，不论你是经理、开发人员、测试人员还是技术领导人，都请“使用这本书”。找出你的工作室（或你个人的工作）中缺少的环节，看看这本书是如何让你现在的生活更轻松的。
  
小乔爱问…… 
 什么是敏捷? 
敏捷（agility）是指软件团队能够很快适应不断变化的条件的能力。这有时意味着要重新设计以适应变化的需求，有时则意味着快速应对新的bug或迅速采用新的技术。总之，敏捷团队更关注结果而不是形式。关于敏捷软件的更多信息可以参考<a>http://www.agilemanifesto.org/</a>。

下面这段话是从这个网站摘录的，对敏捷观点做了很好的总结。 
“我们正在提出更好的软件开发方法，我们自己在使用，同时还帮助其他人使用。通过这些工作，我们意识到： 
? 个体及互动比过程与工具更有价值 
? 可用的软件比冗长的文档更有价值 
? 客户协作比合同谈判更有价值 
? 对变化的响应比遵循计划更有价值 
也就是说，我们认可上述右边事项的价值，但我们更加重视左边的事项。”

显示全部信息

软件项目成功之道下载

软件项目成功之道

发布书评

相关图书推荐