敏捷软件开发

当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 敏捷软件开发

出版社:机械工业出版社
出版日期:2008
ISBN:9787111231660
作者:Alistair Cockburn
页数:388页

章节摘录

插图:

媒体关注与评论

“这是一本激动人心的书。作者以其丰富的实践经验,为我们提供了一部融合敏捷方法的力作。”——Tom Gilb,著名的软件工程和系统工程专家

内容概要

Dr. Cockburn was named in 2007 as one of "The All-Time Top 150 i-Technology Heroes". He is an internationally renowned project witchdoctor and IT strategist, a several-time winner of the Jolt & Productivity book awards. He is best known for describing Software development as a cooperative game, for co-authoring the Agile Development Manifesto, for defining Use Cases and for developing the Initial Response Technique massage form.

书籍目录

译者序第2版前言第1版前言第0章  不可知和不可说         0.1  和解析体验相关的问题          0.1.1  解析模式的冲突          0.1.2  检测解析模式          0.1.3  思考不准确的思想         0.2  沟通的不可能性          0.2.1  内部重新组织          0.2.2  触及共享体验          0.2.3  管理不完美的沟通         0.3  聆听的三个层次          0.3.1  三个层次和方法集          0.3.2  三个层次与本书          0.3.3  守-破-离         0.4  那么,明天我做什么        第0A章  不可知和不可说:演进         0A.1  沟通和共享的体验         0A.2  守-破-离        第1章  创造和沟通的合作博弈         1.1  软件和诗歌         1.2  软件与博弈          1.2.1  博弈的类型          1.2.2  软件与攀岩          1.2.3  创造和沟通的博弈          1.2.4  软件与工程化          1.2.5  软件与模型构建         1.3  再论合作博弈          1.3.1  程序员成为沟通专家          1.3.2  更快地博弈          1.3.3  标识物和道具          1.3.4  减少回报          1.3.5  对于首要目标的充分度          1.3.6  对于积淀的充分度          1.3.7  博弈中的博弈          1.3.8  开放源码开发         1.4  这对我意味着什么        第1A章  创造和沟通的合作博弈:演进         1A.1  沼泽游戏         1A.2  合作中的竞争         1A.3  其他领域的合作博弈         1A.4  软件工程的重建          1A.4.1  这一词汇从哪里来          1A.4.2  我们从哪里走错了          1A.4.3  重建软件工程          1A.4.4  技艺          1A.4.5  合作博弈          1A.4.6  精益制造          1A.4.7  重建后的软件工程          1A.4.8  其他工程化中的协作        第2章  个人         2.1  人是古怪的          2.1.1  寻找特征函数          2.1.2  古怪性格的元素          2.1.3  不可避免的多样性          2.1.4  技术的作用          2.1.5  相互冲突的共同点         2.2  克服失败模式          2.2.1  犯错误          2.2.2  宁可失败也要选择保守          2.2.3  创新而不研究          2.2.4  不能始终如一的习惯动物          2.2.5  使用纪律和容忍来应对         2.3  以一些更好的方式工作          2.3.1  具体化          2.3.2  实物          2.3.3  在某些东西的基础上进行修改          2.3.4  观察和聆听          2.3.5  支持专注和沟通          2.3.6  工作分配要与个性相匹配          2.3.7  天赋          2.3.8  奖励要能保留乐趣          2.3.9  组合奖励          2.3.10  反馈         2.4  利用成功模式          2.4.1  善于四处寻找          2.4.2  人们学习          2.4.3  可塑性          2.4.4  贡献和采取主动          2.4.5  组合成功模式          2.4.6  英雄也是普通人         2.5  明天我该做什么        第2A章  个人:演进         2A.1  策略平衡        第3章  团队的沟通与合作         3.1  信息的对流          3.1.1  延迟和机会损失成本          3.1.2  尔格-秒          3.1.3  渗透式沟通          3.1.4  穿堂风          3.1.5  信息辐射源          3.1.6  热空气理论的应用         3.2  跨越沟通的鸿沟          3.2.1  沟通的形态          3.2.2  去掉某些形态所产生的影响          3.2.3  利用各种形态          3.2.4  黏度与跨越空间的鸿沟         3.3  团队就是集体          3.3.1  友善和冲突          3.3.2  工作时间的公民意识          3.3.3  敌意的XP与友善的XP          3.3.4  使用胜利来建立“团队”          3.3.5  团队文化与亚文化         3.4  团队就是生态系统         3.5  我明天该做什么        第3A章  团队:演进         3A.1  一个修订后的办公室布局样本        第4章  方法集         4.1  一个交付软件的生态系统         4.2  方法集中的概念          4.2.1  结构术语          4.2.2  范围          4.2.3  概念术语          4.2.4  发布一个方法集         4.3  方法集的设计原则          4.3.1  常见设计错误          4.3.2  在方法集上成功的项目          4.3.3  与作者的相关性          4.3.4  七条原则         4.4  细看XP          4.4.1  XP简介          4.4.2  剖析XP          4.4.3  调整XP         4.5  到底为什么使用方法集          4.5.1  方法集解决什么问题          4.5.2  如何评估一个方法集         4.6  明天我应该做什么        第4A章  方法集:演进         4A.1  方法集与策略         4A.2  组织级的方法集         4A.3  过程就是循环         4A.4  更简单地描述方法集        第5章  敏捷与自适应         5.1  轻但足够          5.1.1  刚好足够          5.1.2  对于编制文档的建议         5.2  敏捷          5.2.1  最佳击球点          5.2.2  虚拟团队的麻烦         5.3  变得自适应          5.3.1  不厌其烦地进行反思          5.3.2  方法集成长技术          5.3.3  反思研讨会技术         5.4  明天我该做什么        第5A章  敏捷与自适应:演进         5A.1  对于寓意的误解          5A.1.1  迭代必须简短          5A.1.2  敏捷团队必须驻扎在一起          5A.1.3  敏捷团队不需要计划          5A.1.4  架构已死;重构是你全部所需要的          5A.1.5  我们不需要什么经理          5A.1.6  敏捷开发在纪律上要求很低          5A.1.7  敏捷只适合最优秀的开发人员          5A.1.8  敏捷是既老又新的、失败的、没有尝试过的         5A.2  敏捷方法集的演进          5A.2.1  XP第2版          5A.2.2  Scrum          5A.2.3  实用主义和无名的          5A.2.4  可预测、计划驱动和其他中心调整          5A.2.5  约束理论          5A.2.6  精益开发         5A.3  新的方法集话题          5A.3.1  敏捷项目管理          5A.3.2  测试          5A.3.3  用户体验设计          5A.3.4  规划管控、Burn图和系统工程          5A.3.5  用例和用户故事         5A.4  经久不绝的问题          5A.4.1  最佳击球点和下降          5A.4.2  固定价格、固定范围的合同          5A.4.3  敏捷、CMMI和ISO9001          5A.4.4  何时停止建模          5A.4.5  高科技/高接触的工具箱          5A.4.6  敏捷的中心          5A.4.7  你有多敏捷          5A.4.8  引入敏捷         5A.5  软件开发之外的敏捷          5A.5.1  项目组合管理          5A.5.2  客户关系          5A.5.3  合同          5A.5.4  将变更引入组织          5A.5.5  程序员读哈佛商业周刊          5A.5.6  建造房屋          5A.5.7  机场建设          5A.5.8  图书出版          5A.5.9  会议组织和敏捷模型的限制        第6章  Crystal方法集         6.1  对Crystal家族塑形          6.1.1  核心Crystal元素         6.2  Crystal Clear          6.2.1  Crystal Clear的简要描述          6.2.2  Crystal Clear的反思         6.3  Crystal Orange          6.3.1  Crystal Orange的简要描述          6.3.2  Crystal Orange的反思         6.4  Crystal Orange Web          6.4.1  Crystal Orange Web的简要描述          6.4.2  Crystal Orange Web的反思         6.5  明天我该做什么        第6A章  Crystal方法集:演进         6A.1  Crystal基因代码          6A.1.1  合作博弈的理念          6A.1.2  方法集的重点          6A.1.3  方法集设计原则          6A.1.4  高度成功的项目的7个特性          6A.1.5  技术与选择          6A.1.6  样本方法集设计         6A.2  Crystal Clear         6A.3  把Crystal Clear扩展到Yellow        附录A  敏捷软件开发宣言        附录Aa  敏捷软件开发宣言和相互依赖声明        附录B  Naur、Ehn、宫本武藏        附录Ba  Naur、Ehn、宫本武藏:演进        附录C  后记        参考文献

编辑推荐

《敏捷软件开发(原书第2版)》适合软件开发人员、管理人员、架构师等技术人员参考。

作者简介

本书提示了敏捷软件开发的真正内涵。全书以“软件是创造和沟通的合作博弈”为中心向读者展示一个看待软件开发的崭新视角。全书共13章,包括创造和沟通的合作博弈、个人、团队的沟通与合作、方法集、敏捷与自适应、以及Crystal方法集等内容。
本书适合软件开发人员、管理人员、架构师等技术人员参考。

图书封面


 敏捷软件开发下载 更多精彩书评



发布书评

 
 


精彩书评 (总计3条)

  •     个人和交互胜过过程和工具可工作的软件胜过全面的文档客户的协作胜过合同协商对于变更的响应胜过遵循计划频繁的交付可工作的软件欢迎变动的需求【很惭愧】业务人员和开发人员每天工作在一起【不是不想,...】使用有主动性的人来组建团队。给他们所需的环境和支持,信任他们能够完成工作【阿喀琉斯之踵】不断的追求技术上卓越和优秀的设计
  •     不知道是翻译问题,还是书的内容的确比较高深,初翻时,感觉不是一般的晦涩。比如将“博弈”的概念用在软件开发上,让我着实迷惘了一阵子,这个概念一般还是用在兵法谋略上的。本书提出的一个核心理念是:“软件开发是共同创建和沟通的过程”,因此本书的全部内容,都是基于如何创建和沟通来展开的。作者开头就阐明一个基本观点,沟通的不可能性。这意味着在传统软件开发过程中,我们以往靠严谨的结构化文档来进行充分沟通是严重不靠谱的。而失效的沟通技术,则会导致计划、设计、编程、测试及发布各环节衔接的问题,过程出现了问题,则以靠过程产生的软件自然也好不了。书中紧接着提出了解决的方式,这个答案里既有关于个人成功和失败习惯的方面,也有团队之间信息辐射的方面。作者认为,只要个人保持成功的习惯,并将整个团队放置在一起工作,就能达到良好沟通的目的。沟通只是软件开发的问题之一,问题之二是创建问题。这个问题实际上是由创建过程引起的,而创建过程又是由方法集来支持的。作者在讲解方法集的时候,充分印证着自己守破离的观点,即任何方法集都不是唯一正确的,所谓瀑布发和敏捷谁更正确其实是个伪命题,凡是纠结于这的同学,显然是并不了解方法集只是解决特定问题的过程集合这一基本事实。我对敏捷方法集的看法是,它其实将瀑布法中的顺序阶段,打包到几个迭代的过程中而已,当然在每个迭代过程中都会对顺序阶段做调整,比如将严格的顺序执行变化为并行执行等。我对书中的并行观点很倾佩,利用这个观点,我们很容易将自己的过程改造的更敏捷,而无需担心自己变成另一个先烈。因为书还没看完,所以不能完整的领略作者关于敏捷的所有核心要义,但我希望在今后的阅读中,能够明白如何通过人+方法集的方式,应用到软件产品的管理上,而不仅仅是软件产品的研发上。希望能通过领悟作者的精神,利用举一反三的技术,找到一个比较正确的答案来。出于对守破离的致敬,希望终有一天,我能将这本书付之一炬:)
  •     本书是一本非常好的学习敏捷开发方法的书。书中列举了大量的事实,详细的介绍了如何在软件开发过程中实现敏捷方法,作者对敏捷的一些感悟等等。如果对敏捷方法没有深刻的认识,可以在看过敏捷宣言以后,仔细研读这本书,作为对敏捷方法的入门。我在这里不想过多的来吹捧这本书的优点,我想谈一下就这本书透露出来的敏捷运动的不足。我第一次了解敏捷大约是在4年以前,最开始只是了解了敏捷宣言,后来又了解了敏捷的前身—XP。本来我对敏捷运动报着很大的希望,因为敏捷宣言里面提到了一些在传统软件开发方法中没有注意到的思想,这些思想是真的可以为软件开发方法带来革命。而事情发展到今天,这场革命在各种因素的综合作用下,事实上已经失败了。现在大多数人提到敏捷(包括很多资深的敏捷运动成员),都认为敏捷仅仅只是对传统软件开发方法的改良,而非革命,它仅仅只是把传统软件开发过程中好的元素综合起来了而已,而最开始,事实并非如此。虽然敏捷宣言最开始有12条,但是事实上其中只有三条是核心“我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意”“在整个项目开发期间,业务人员和开发人员必须天天都在一起工作”“即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势”。这3条意味着,和传统开发方法相比,敏捷开发方法是一种用户驱动的开发方法,它事实上是通过用户最快速度的使用,让用户明白计算机可以为他做什么,然后再由用户重组他对目标解决方案的设计。进而,为了快速的达到这一目标,其他的方法最大限度的加快了软件开发速度。从软件工程的发展趋势上来看,敏捷方法将原来用户和软件开发人员相对剥离的状况转变为一种紧密结合,将软件开发过程看做是双方之间的协作而非双方之间的买卖。是的,这本来是一个革命性的思想,这个思想甚至意味着全行业对软件需求认识上的改变。然而最终,什么变化都没有发生,敏捷打开了一扇大门,又最终把它关上了。现在任何一个组织都宣称自己是敏捷的,甚至连敏捷本来的死对头UP也宣称自己是敏捷的,就连敏捷自己,也在实践中逐渐迷失了自己最重要的特性,最终泯然众人了。拿IBM的Rational平台来说(09年《程序员》3月刊28页),其宣称自己是敏捷的,甚至宣称自己是大规模敏捷的,但是就其介绍,我们丝毫看不出这个敏捷和紧密结合用户的思想有什么关系,而此所谓的“敏捷方法”,事实上是通过提供统一平台,提高实现级别来实现的,这实质上是一种减小含混性的方法,而并非敏捷宣言的初衷。这本身是两种完全不同的思想,却在他们的介绍下被莫名其妙的混在了一起。敏捷运动为什么失败了?是因为在最初其革命性太强了。敏捷方法一出,号称颠覆了传统的所有软件开发方法,其宣称的不写文档也确实存在大量拥护者。但其方法本身只是一个从实践走过来的方法,其缺乏扎实的理论根基和与其配套的完整理论体系(比如一种更好的客户开发人员的交流方法等)。相比于早期的UML,先从图形化入手,提供一套便于传统软件开发方法上手的工具,进而逐步向UP甚至模型转换方向发展这种稳定的步伐,敏捷一出来就锋芒壁炉,结果在锋芒中迷失。甚至直到今天,敏捷方法也没有拿出一个靠得住的需求获取方法,而这可是最初12条宣言中最看家的本领。敏捷失败了,未来会怎么样?从软件工程发展的历史上来看,从最初的自己自足,到混乱型,到瀑布模型,到原型法,到迭代方法,敏捷方法等等,其本质沿着混乱,到流水线,到一次迭代,到多次迭代,到用户主导,将来必然会更加趋向于协同合作,而非独立自治。而在实现级别上,由最开始的机器码,到汇编,C,面向对象语言,动态语言,SOA,甚至未来可能到达的模型转化,其实现的级别越来越高。未来的软件开发方法,必然更加强调用户主导,快速响应,协同工作,甚至随需而变,而我们的精力必然随着实现级别的拔高,不断的向更高层次的目标转移,不断的去挖掘用户的潜在目标,形成完整的软件服务链。敏捷虽然失败了,但是下一次变革必然带来更强烈的交互协同,这个大趋势是不会变的,必然会存在着一天,用户和开发者将摆脱当前这种被动的交流状态,转变为相互主动的交流,共同完成对目标的优化。

精彩短评 (总计25条)

  •     不知道为什么买来的书印刷质量那么差。看封面还觉得可以,但是打开里面来,就不这么觉得叻。很粗糙的感觉!不开心!
  •     理论角度和协作方面来阐述agile的基本原则和方法 - 17th Jolt Award
  •     不愧是经典的著作,个人觉得非常不错。它从方法论的角度阐释了敏捷开发,对于一般项目管理也有一定的借鉴性。
  •     没有 《敏捷软件开发》清华大学出版的通俗易懂
  •     摘读了感兴趣的部分,国外大牛写这方面的书,不仅内容一流,可读性也是一流,比如把宫本武藏和软件开发扯到一块,再如拉上海德格尔和维特根斯坦所做的谈论,都可见出不一般处.
  •     敏捷软件开发必看读物。理论功底很深,例子翔实,跟作者的咨询背景有很大关系。全书信息量很大,读过之后感觉Alistair Cockburn总是说出了我的心声,此书应该每隔一段时间翻出来指导一下自己的实践。从此走上敏捷的道路!第二版的内容丰富更是让我对作者肃然起敬。
  •     大概浏览一下,没怎么细看,我的程度看着有些费劲,不如bob大叔的那本通俗易懂,可操作。
  •     书的思想值得学习,不管是在什么领域
  •     通过尽早和不断交付有价值的软件满足客户需要
  •     敏捷创始人解读敏捷开发。里面的方法很实用。
  •     不知道是翻译不好还是本来就是挺深奥的,或者说拗口的
  •     英文原版的不错,翻译版的读起来很不流畅,很蹩脚。
  •     书的质量不好,感觉是盗版的,而且边角还破损了
  •     一下午翻过的,没看太仔细,之前也对敏捷方法有了一些了解。 几个印象深刻的点: 1. 守,破,离—学习的三个阶段。守,遵循规则;破,比较相似的方法;离,忘记这些方法 2. 沟通就是触及共享的体验。我把它改为:沟通需要触及共享的体验。 3. 对你所做的事情和对你做事的方式进行反思。—宫本武藏 可以加上“任何”两个字 自己的话: 时刻相信当前最好的方案一直存在在自己的脑子里,就看你有没有足够的执行力和勇气。
  •     第一版译得比较好,可惜丢了。
  •     转行了,不读了。
  •     前半段很有水平啊,后半部看不太进去
  •     重点在于理解他所谓的思考密集与沟通密集。对具体方法的理解,当读到"所有方法集都是一种恐惧"时,剩下的几乎就几乎水到渠成了。(合作博弈还不如翻译成合作游戏呢,一看到维特根斯坦的"语言博弈"就气不打一处来。)
  •     相比一般的框架感觉有点奇怪,没怎么看的进去,先标记下吧
  •     质量看着还行,目前还没看,待看后在研究吧!
  •     对于中高级的计算机开发人员来说,这本书读后一定受益匪浅。
  •     系统介绍了敏捷开发的方法论,图书馆借用过,再买一本当藏书。
  •     相当好的书,也是我的敏捷入门书。从对人行为的理解来解释软件开发的过程。
  •     Cockburn关于敏捷的深度思考,看后受益匪浅。前段时间的毕设就从本书中汲取了不少养分。原书五星没的说,不过翻译不流畅,译本四星。
  •     我发现大家对这本书的打分都比较低,估计在意的都是书的质量问题!作者是敏捷开发的发起人之一,其理论知识相当深厚,如果这本书达不到这个高度,那你也没必要参阅敏捷软件开发了!不过这本理论性太强,看起来确实挺枯燥的,对于非常有经验或者对敏捷有一定深度的人可能是个好的进阶,... 阅读更多
 

外国儿童文学,篆刻,百科,生物科学,科普,初中通用,育儿亲子,美容护肤PDF图书下载,。 零度图书网 

零度图书网 @ 2024