在Scrum的方法里面，使用Sprint的一个方式，就是在构建产品的过程中，产品的设计和开发是逐步完善的，也就是说，产品并不是一次设计完成的，这里就有一个问题，Scrum是否适合于大多数的软件产品开发？相对于传统的方式，我们编码前是否需要一个完整的明确的代码的设计？
这里有两个例子可以考虑，如果我们要开发一个操作系统，或者是开发一个Office系列软件，我们能否使用敏捷开发的模式？
对于操作系统而言，Unix开发的哲学是最好的实践方法。
Unix开发哲学中其中一点是，做一件事情，把它做好，这意味着小但是精致的产品开发方法。尽管，从整体上看，操作系统是一个庞杂的系统，但是还是需要从小的部分做起。
记得Linux开发的故事里面，开发者开始做的就是一个磁盘驱动和一个process调度器，来看今天Linux的代码和那个时候相比，我相信，如果一个开发者对于这样一个产品有一个整体的深度的了解（技术上，思想上都具备开发这样产品的能力），那么，Scrum的开发方法是起作用的，作者只需要从小的部分着手，就可以建立起来这样一个系统。
至少看到这样一个事实，Unix和Linux的作者，开始都是一个人（或许Unix是两个人），然后逐步构建出来的。
相比而言，如果你让一群人来共同设计一个操作系统，然后再来编码，设计的过程同样体现的是作者对于产品的理解度，但是因为是整体设计，然后来编码实现，所以小而精的原则可能被打乱，而出现问题的几率会更多（看一下Windows 的 API，和 Unix 的System Call相比，感觉前者没有后者精致），设计是思想的体现，而思想是在开发中逐步完善的，一个人想要一步设计出来一个完善的产品，对于人，即便是对于一个团队而言也是不实际的。
对于Office系列软件，或者Adobe的图像编辑软件而言，我们似乎也有一种错觉，就是这样的庞大的产品，需要整体的设计才能够完成，我觉得并非如此。而Scrum会更加有效，同样可以借鉴Unix的开发哲学，正是有了小而精致的模块，才能构建一个出色的软件产品。
在实际的开发经验中，看到的，和自己所做的，都是在实践Scrum的方法，只是过去自己不这样去理解，而是一种错误的理解，开发者在开发之前希望能够得到某些功能的详细说明，从而可以实现，好比，我们需要在某个系统上来体现某个软件的特性，对于编码者而言，他熟悉这个系统的接口和具体细节，他需要把这种特性的实现变化成为具体的编码实现来考虑，这就是说，越接近编码实现的功能描述，越容易被编码者理解和接受。
所以，如果功能描述不完全，就会给编码者带来困惑和工作上的难度，这也就是过去不能够接受Scrum方法的原因所在，其实，真正的开发中，自己使用和体验一下Scrum的设计方法，就觉得是很好用的。
讨论我们是否需要一个系统的完整的设计的问题，还有一种情况存在，如果项目的规划者并不熟悉产品的技术实现的细节，对于他而言，是否一个完整的设计更有必要？
记得3年前，当我自己尝试写产品设计的文档的时候，我总是尝试描述更多的产品开发的意义所在，力图说明产品的每一个部分的设计都有其意义的存在，并且通过更多的创意来构建产品的特性，其目的无非是让人觉得这样的产品具有竞争力， 如果今天在回头看这些产品设计文档，会觉得，这些文档太过戏剧化，更像思想和理念。
这个时候，我对于技术的实现并没有实质的经验和能力，当我开始考虑其具体的产品的技术设计的时候，我就遇到了困难，难以继续下去。
我自以为我的描述已经细致的描述了产品的起源，背景以及我们需要些什么，但是对于开发而言，其实我所做的工作也就是做了第一步的工作，产品的简介。
至于，产品的模块是那些，产品的形象是什么，都没有涉及和定义。这样的产品文档，只是一个最初级的idea，连一个proposal都算不上，一个proposal需要idea，同时需要数据来支持你的观点，具有说服力。
所以，当我自己拿到这样的文档的时候，我想要动手来写这样一个产品，也是感到无从下手。
这里体现了一个问题，对于没有技术实现的背景的项目规划者而言，他同样需要了解最基本的产品的结构和功用所在，至少的，他需要以一个用户的角度来考虑这个系统的形象，从而构建出来在他的理解上的产品的样子。
然后，另一个有着经验的开发人员按照这种产品的样子来做产品的设计，这个时候的设计需要体现形象的具体，比如纸上的绘图或者数字化的绘图，从而项目的规划者能够看到体验，并在此基础上来改善。
当设计一旦确定之后，开发者就可以按照设计的要求构建编码需要的模块的设计，在这种情况下，是Scrum发生作用的时候，一个开发者在熟悉产品的开发结构的情况下，就可以通过以小的模块的构建来实现整体的方法来构建整个系统。
以youtube为例子：
我们需要一个用户能够分享，并且观看的视频平台。这可能是最初的idea。
对于开发者而言，他开始考虑用户应该如何使用这个平台，这样他可能构建出来：
我们需要一个用户的登录，注册的页面。
用户注册，登录之后能够开始上传自己的视频。
用户无需登录就可以看到所有的视频。
更多的：
我们需要用户能够发布私有的视频，并分享给自己的好友。
我们需要用户能够发布能够自定义密码的私有视频，并分享给好友。
我们需要在使用私有视频服务的用户的群体上收取费用。
对于编码者而言，可能会考试考虑功能的设计，那么对于Scrum而言，Sprint可能是这样描述的。
Sprint
Story ：给出一个页面的设计，从而能够涵盖以上的用户功能
Promise ： 设计以HTML的方式给出，需要可以符合目前流行的浏览器
Story ：给出基于现有设计页面的用户体验方式，包括页面的切换，以及使用何种方式与服务器沟通
Promise ： 设计以HTML的方式给出，需要能够体验现有的方式
然后按照定义的页面，以及体验方式，来做具体的设计。
到现在为止的讨论来看，一个开发团队需要多种技能的人，而Scrum的方法适合于软件产品的开发，而且比传统的开发方法在开发、编码和管理上更加有效，在实践中，也发现是这样的，现在如果让我做一个从来没有做过的软件产品，使用一种从来没有用过的语言，我不会感到束手无策，而是在自己能够掌握这些技能的前提下，有信心把它构建出来，因为认可了一个软件是从小部件／模块构建起来的逻辑，所以使用Scrum的方法就非常有效，软件编码就是一个演化的过程，最终形成一个用户满意的产品，这一点在实际的工作中也得到了证明。
