I used to despise software testing, because I was very ignorant at that time and was just an ordinary Chinese programmer. This was also the mentality of most programmers at that time. At that time, Chinese programmers were most concerned about "programming is the last word".
Today, I love software testing, including software testing tools, methods, theories, and techniques. Because I have deeply realized the importance and fun of software testing in my three years of testing work. At this point, I have jumped out of the "little programmer" circle and looked at the work of software testing from the larger perspective of software systems engineering.
For a long time I have been confused by the following questions, some of which are still only superficial, and, the more testing projects I do and the more testing books I read, the more I feel that I understand software testing. the more superficial. Because I feel more and more the infinite breadth and depth of software testing, it is as wide as the ocean and as deep as the universe. Why do software testing? What is the future of software testing? Who is more important for software testing tools and ideas? What is the highest state of software testing?
Software testing is an important activity to ensure software quality and an indispensable link in software project implementation. The direct purpose of software testing is to find defects in software. This is the validity of the test.
All software defects before the end of the software project are mainly the responsibility of the software developers, because the software defects come from the programming of the programmers. Software defects after the end of a software project are mainly the responsibility of software testers, because software testers do not find hidden bugs in testing before software release. But this is not absolute, because a software project is a systematic project, and software quality involves multiple departments and personnel, as well as requirements analysis, design, coding and other links and processes. Software testing can only prove that the software has defects, and cannot guarantee that the software is error-free.
Software testing is not a panacea, because it is impossible to find all software defects, and the functionality and performance of the software are not determined by testing. This is the limitation of the test.
At present, software testing is mainly based on manual testing. Although there are many automatic testing tools, the breadth and depth of practical applications still have great potential, and automation will have a lot of room for development! .
The point of view of software-driven development illustrates the relationship between testing and programming. Testing should run through the entire life cycle of software development, and programming is only a part of software development. But often people attach great importance to software programming and regard testing as an auxiliary link after programming. This is typical putting the cart before the horse. The defect management process of software testing is very important. The quality of the reported software defects should be verified by others, so that the responsibility is clear and the method is simple and feasible.
Software testing technology continues to improve, but overall, domestic testing is not enough, but it has developed rapidly. Almost two years ago, there were very few books on software testing in domestic computer bookstores, but now they are dazzling and colorful.
Software testing is a career that can be entered quickly, and the threshold is not high, but don't think that anyone can do software testing well. Because will do and do well are two concepts. Software testers preferably have software development experience and a knowledge of software engineering. This is the basis for improving software testing capabilities. For students who have just graduated, if they want to be engaged in software development in the future, then it may be more beneficial for future programming to engage in testing for a period of time. For programmers with many years of programming experience, it is easier to improve their skills if they change their professions to do testing. Software testing is not an isolated activity or process, it requires the participation and communication of development and marketing personnel, and the active cooperation and communication of software quality assurance personnel SQA.
Software testing technology is constantly improving. Compared with specific testing techniques, mastering the core ideas of testing is more important than specific techniques! The highest state of testing is to use the simplest and most effective testing techniques to find software defects to the greatest extent!
It should be admitted that the status and treatment of domestic software testing engineers are still very low, and many testers have an impetuous mentality (I even feel There is always a fickle bubble throughout the software industry). How to change this situation should be a long process. When the entire IT industry truly regards customers as gods, when software quality becomes the decisive factor for the survival and development of the enterprise, and when the testing work of software test engineers brings greater economic benefits to software companies, software test engineers will receive Due respect!
Software development is a complex, creative, collaborative game. As a game, it naturally has fun, so programmers will never tire of it and keep going. First, this joy comes from a joy of creating things. Second, the joy comes from a sense of satisfaction in developing something useful to others. Third, happiness comes from the charming charm brought by seeing with your own eyes the software running according to your own pre-envisioned effects during the development process. Fourth, happiness comes from the joy of continuous learning in the development process. Finally, happiness comes from the development process, we can be like poets, just rely on our own imagination to build our own castle. The joy of programming is that it not only satisfies our inner desire to create, but it also awakens the emotions within everyone. Unfortunately, as a game it also has a distressing side: first, distress comes from the pursuit of perfectionism. Second, distress comes from always having others set goals, provide resources, and provide information. Third, the distress comes from finding trivial bugs, but it is a tedious and repetitive activity. Fourth, people usually hope to converge faster towards the end of a project, however, the closer it is to completion, the slower the convergence. Finally, the distress comes from the danger of being outdated when a product is released after a lot of hard work. As software developers, we have no choice but to adapt to them and face each day with pain and joy. Only 25% of the information from the leader is known and correctly understood by the subordinates, the feedback information from the bottom to the top does not exceed 10%, and the information exchanged on an equal basis can reach more than 90%. Equality creates trust, and trust enhances communication. Effective and appropriate exchange of ideas can have a beneficial and positive impact on an organization's climate and productivity. Satisfying customers and communicating with them face to face is the key to winning the market. ——Quoted from "Management Wisdom"
管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：
第一、风险识别：
从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。
第二、风险分析：
对风险出现的可能性和潜在的危害性进行量化分析。
第三、应急计划：
如果识别出的风险真的出现，你将采取的应急措施。
第四、风险缓解：
为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。
第五、持续的监控：
跟踪需要管理的风险，寻找风险出现的迹象。
项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：
第一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。其次、它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。
第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
第三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。
第四、规约崩溃
这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。
第五、低效率
对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。
正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。
精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。
——引自《最后期限》
Today, I love software testing, including software testing tools, methods, theories, and techniques. Because I have deeply realized the importance and fun of software testing in my three years of testing work. At this point, I have jumped out of the "little programmer" circle and looked at the work of software testing from the larger perspective of software systems engineering.
For a long time I have been confused by the following questions, some of which are still only superficial, and, the more testing projects I do and the more testing books I read, the more I feel that I understand software testing. the more superficial. Because I feel more and more the infinite breadth and depth of software testing, it is as wide as the ocean and as deep as the universe. Why do software testing? What is the future of software testing? Who is more important for software testing tools and ideas? What is the highest state of software testing?
Software testing is an important activity to ensure software quality and an indispensable link in software project implementation. The direct purpose of software testing is to find defects in software. This is the validity of the test.
All software defects before the end of the software project are mainly the responsibility of the software developers, because the software defects come from the programming of the programmers. Software defects after the end of a software project are mainly the responsibility of software testers, because software testers do not find hidden bugs in testing before software release. But this is not absolute, because a software project is a systematic project, and software quality involves multiple departments and personnel, as well as requirements analysis, design, coding and other links and processes. Software testing can only prove that the software has defects, and cannot guarantee that the software is error-free.
Software testing is not a panacea, because it is impossible to find all software defects, and the functionality and performance of the software are not determined by testing. This is the limitation of the test.
At present, software testing is mainly based on manual testing. Although there are many automatic testing tools, the breadth and depth of practical applications still have great potential, and automation will have a lot of room for development! .
The point of view of software-driven development illustrates the relationship between testing and programming. Testing should run through the entire life cycle of software development, and programming is only a part of software development. But often people attach great importance to software programming and regard testing as an auxiliary link after programming. This is typical putting the cart before the horse. The defect management process of software testing is very important. The quality of the reported software defects should be verified by others, so that the responsibility is clear and the method is simple and feasible.
Software testing technology continues to improve, but overall, domestic testing is not enough, but it has developed rapidly. Almost two years ago, there were very few books on software testing in domestic computer bookstores, but now they are dazzling and colorful.
Software testing is a career that can be entered quickly, and the threshold is not high, but don't think that anyone can do software testing well. Because will do and do well are two concepts. Software testers preferably have software development experience and a knowledge of software engineering. This is the basis for improving software testing capabilities. For students who have just graduated, if they want to be engaged in software development in the future, then it may be more beneficial for future programming to engage in testing for a period of time. For programmers with many years of programming experience, it is easier to improve their skills if they change their professions to do testing. Software testing is not an isolated activity or process, it requires the participation and communication of development and marketing personnel, and the active cooperation and communication of software quality assurance personnel SQA.
Software testing technology is constantly improving. Compared with specific testing techniques, mastering the core ideas of testing is more important than specific techniques! The highest state of testing is to use the simplest and most effective testing techniques to find software defects to the greatest extent!
It should be admitted that the status and treatment of domestic software testing engineers are still very low, and many testers have an impetuous mentality (I even feel There is always a fickle bubble throughout the software industry). How to change this situation should be a long process. When the entire IT industry truly regards customers as gods, when software quality becomes the decisive factor for the survival and development of the enterprise, and when the testing work of software test engineers brings greater economic benefits to software companies, software test engineers will receive Due respect!
Software development is a complex, creative, collaborative game. As a game, it naturally has fun, so programmers will never tire of it and keep going. First, this joy comes from a joy of creating things. Second, the joy comes from a sense of satisfaction in developing something useful to others. Third, happiness comes from the charming charm brought by seeing with your own eyes the software running according to your own pre-envisioned effects during the development process. Fourth, happiness comes from the joy of continuous learning in the development process. Finally, happiness comes from the development process, we can be like poets, just rely on our own imagination to build our own castle. The joy of programming is that it not only satisfies our inner desire to create, but it also awakens the emotions within everyone. Unfortunately, as a game it also has a distressing side: first, distress comes from the pursuit of perfectionism. Second, distress comes from always having others set goals, provide resources, and provide information. Third, the distress comes from finding trivial bugs, but it is a tedious and repetitive activity. Fourth, people usually hope to converge faster towards the end of a project, however, the closer it is to completion, the slower the convergence. Finally, the distress comes from the danger of being outdated when a product is released after a lot of hard work. As software developers, we have no choice but to adapt to them and face each day with pain and joy. Only 25% of the information from the leader is known and correctly understood by the subordinates, the feedback information from the bottom to the top does not exceed 10%, and the information exchanged on an equal basis can reach more than 90%. Equality creates trust, and trust enhances communication. Effective and appropriate exchange of ideas can have a beneficial and positive impact on an organization's climate and productivity. Satisfying customers and communicating with them face to face is the key to winning the market. ——Quoted from "Management Wisdom"
管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：
第一、风险识别：
从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。
第二、风险分析：
对风险出现的可能性和潜在的危害性进行量化分析。
第三、应急计划：
如果识别出的风险真的出现，你将采取的应急措施。
第四、风险缓解：
为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。
第五、持续的监控：
跟踪需要管理的风险，寻找风险出现的迹象。
项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：
第一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。其次、它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。
第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
第三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。
第四、规约崩溃
这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。
第五、低效率
对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。
正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。
精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。
——引自《最后期限》
企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益 。
需要免费的软件测试资料的加QQ：1784335504