这篇文章是写给致力于推广Scrum的项目经理们的，我的很多客户都问过我这样的问题：他们用了Scrum一段时间了，发Scrum确实是个好东西，能够有效的提高团队的生产力，鼓舞团队士气，降低外界对团队的干扰，以及卜啦卜啦卜啦一大堆的好处，但是老板们，尤其是那些非软件开发出身的老板们，却对Scrum仍然无动于衷，得不到老板的支持，推行Scrum举步维艰，想要说服老板，却又不知道如何去打动他们，Scrum中也丝毫没有说老板们在Scrum中能获得啥东西，那么Scrum对于老板的意义到底何在呢？
近几年来，敏捷作为一种很实用、上手快、轻量级的方法，被越来越多的开发团队所采用。然而，在很多大团队中，敏捷方法的实施带来了包括在人员管理、工作计划、沟通和文档记录等诸多问题。
在敏捷测试中也有测试活动乃至专职的测试人员，但其活动内容和目标是有显著差异的。 一般在传统开发团队中，产品经理（或销售）为范围或称之为需求负责，项目经理和开发组为进度负责，测试组为质量负责，部门经理为成本负责，结果就是当四者发生矛盾时，会有四个部门各自站在自己的立场上，从而导致沟通不畅或或博弈成分超过合作。
敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product Backlog中挑选迭代周期准备开发的意向表（Willing List）进行总体介绍，然后分配到Sprint研发过程中。以Scrum为代表的纯敏捷方法，认为首先不需要对需求做分析，因为需求一直在变。所以提出了Story的概念，认为需求就该是对需求的一种类似讲故事的方式来表达的，这样便于让原始客户比较清晰的对需求进行表达，同样开发和测试也会逐渐以客户的需求思维来思考自己的工作。使得大家都能在需求的层面上，进行大脑思维。
在我拿到计算机科学博士学位的时候，我已经从事软件工作一段时间了。从最初的程序员做起，随着经验的积累，开始逐渐管理软件团队和软件项目。后来我成立了自己的软件公司，并领导这个公司成为应用生命周期管理领域的行业领先者。
当团队处于分布式协同工作时，沟通是最大的问题，也是我们需要尽最大努力去改进的区域。
规范点驱动开发（Specification Driven Development，简称SpecDD）是一种全新的软件开发概念性框架，它贯穿于应用生命周期管理（Application Lifecycle Management，简称ALM）的各个阶段，支持各种成熟开发模型，旨在帮助开发团队提高项目质量，促进软件项目成功。
SpecDD是基于一个基础理论以及在此基础理论上的一系列原则创造出来的。这个基础理论已经为实践所证明所以任何人都无法进行更改，而这些原则正是它的最佳实践并且作为骨架来设计详细的框架。
