知行合一： 实现价值驱动的敏捷和精益开发 - (EPUB全文下载)

文件大小：0.32 mb。
文件格式：epub 格式。
书籍内容：

知行合一： 实现价值驱动的敏捷和精益开发
第1章 从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式
第2章 敏捷开发方法——摸着石头过河的智慧
第二部分 建立以Scrum为框架的软件开发管理体系
第4章 布好自己的局——确定Scrum中的角色、文档和活动
第6章 把握好敏捷的度——敏捷工程及质量控制实践
第三部分 CMMI框架下的敏捷实施
第7章 盲人摸象——关于敏捷和CMMI的错误偏见
第8章 建立敏捷的保护网——CMMI架构下的敏捷实施
第四部分 新一代精益软件工程
第9章 敏捷不是解决软件开发问题的银弹
第10章 软件开发的新模式——新一代精益软件工程
参考文献
欢迎来到异步社区！
第1章 　从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式
北大西洋公约组织的科技委员会在1968年10月组织了一次会议，在那次会议上，出现了“软件工程”这个词。50位来自11个国家的软件用户、软件生产者和高校从事软件教学的教授一起讨论了下列一些软件工程中碰到的突出问题。
随着数据系统不断渗透到现代社会日常活动中，如何保证这些系统的可靠性成了一个日益突出的问题。
大的软件项目的进度及特性需求难以控制。
软件工程师的再教育。
软件的定价是否要和硬件分开。
除了第4个问题外（今天软件的价格常常已经超过了硬件的价格），其他3个问题在今天依然是让我们头痛的问题。随着互联网变成公众生活中不可缺少的部分，软件系统的应用比当年多出了百倍，而质量成本依然是软件项目的杀手。软件产品的需求比以往更加难于控制，需求蔓延（requirement creep）是软件开发中最常见的风险之一。IT行业技术变化之快远超其他行业，学习新的技术、方法是软件工程师常态工作的一部分。
根据这些问题，在这次会议上首次提出了“软件危机”的问题。会后不久，Winston Royce（1970）博士根据制造业的实践，提出了一个至今依然影响软件业的开发模式—瀑布式软件开发生命周期，希望能够借鉴其他行业的经验，解决软件开发中的问题。但40多年后，危机并没有消失，依然威胁着软件公司的生存发展。
近20年来，越来越多的软件工程实践者开始了深层次的反思：问题出在哪里？解决问题的方向又在哪里？在反思的同时，一些有勇气的软件工作者开始了新的探索。他们在软件开发过程中，尝试了新的实践，并不断总结交流，形成了我们今天看到的敏捷宣言、敏捷原则、敏捷实践以及敏捷方法与传统方法结合的实践。今天我们比以往任何时候都更接近找到解决软件危机之匙。
我们首先审视下列4个问题。
（1）什么是成功的项目？项目中的决策应该由什么来驱动？
（2）Royce博士提出的瀑布开发模式真的适用于复杂软件产品开发吗？
（3）复杂软件项目的特点是什么？
（4）根据复杂软件项目特点，我们需要建立一个什么样的开发模式？
通过对这4个问题的讨论，希望读者能意识到为什么“先知后行”的传统开发模式会让我们在原地踏步，很难走出软件危机的圈子。走出瀑布模式，拥抱“知行合一”的敏捷方法才可能是解决软件危机的正确思路。在这里我虽然借用了王阳明的核心理念，但要表达的意思远远没有达到王阳明先生表达的深度。在本书中，“先知后行”指的是确定了实现目标要走的路再开始行动，也就是在项目前期，确定产品范围、实施方法后，才开始软件开发活动。“知行合一”指的是明确了愿景后，尽管我们不完全清楚到达目标的路径，但我们先往前走，边走边看边调整，在开发中学习、总结、调整、提高，逐步实现客户需要的产品。
1.1　重新审视项目成功的标准
在预算范围内，按期向客户提交需求范围要求的产品是长期以来IT企业判定项目成功以否的标准。这个著名的项目管理铁三角（需求范围、成本、进度）直到今天仍定义着大部分软件项目的实施目标。多年来我一直觉得这个铁三角有一个致命问题：它们到底是项目追求的终极目标，还是项目实施的约束条件？项目的价值似乎没有在这3个度量指标中明确体现。
我看到很多项目为实现不合理的进度目标辛苦努力，其他很多重要的东西被忽略，特别是没有关注项目要获取的价值，似乎价值这个东西随着进度目标的完成自然就会实现。也有些项目沉迷于具体的需求项，而看不见这些需求项到底给用户带来什么价值。一个令软件业同行不得不面对的事实是超过50%的软件产品功能基本没有被用户使用过，换句话说，对软件项目团队辛辛苦苦实现的一半以上的功能，客户并无兴趣使用，它们没有给用户带来什么价值。这就应了一句老话：每条需求都有成本，但并不是每条需求都有价值。推想一下，又有多少没有完成的项目，因为追求一些没有价值的需求，导致了过多延期和预算超支，使得企业只能放弃它们。
1.1.1　传统的三要素不一定能客观度量项目的成功与否
图1-1定义了传统项目管理铁三角：需求范围（特性、功能）、成本（资源、预算）和进度（时间）。成功的项目应该依据客户需求（范围），在不超出预算的前提下，按时提交项目。
“传统铁三角”定义的项目成功三要素有两个重要隐含假设。
项目定义的需求范围真正反映了客户的真实需要，通过使用这些需求功能，用户可以实现其价值目标。
项目计划是正确的，实际和计划不符意味着错误。
在这两个假设下，和计划不符的都会被视为问题，项目管理工作就是消灭计划的偏差。让我们认真思考一下上面的假设，它真的总是正确吗？按时完成，没有超出预算提交了需求范围的功能，一定就意味着项目是成功的吗？如果这3个目标没有实现，项目就一定是个失败的项目吗？
图1-1　项目管理“传统铁三角”
请你回顾一下以前你们公司发布的产品，在这3个目标方面都做得好的产品中，有多少卖得好，为公司带来了价值？有多少用户并不买账，产品并未对扩大市场占有率有任何正面贡献？而在没有按时完成，没有实现所有项目计划阶段定的需求范围，预算有超出的项目中，有没有卖得好、客户喜欢的产品？这其中有没有为公司带来新的机会的项目？
我们看几个例子。如果微软的Vista符合这3个要求，你能认为这是个成功的项目吗？如果你用过这个系统的话，相信你的体 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。