关于项目分析的理论模型

这个图画得超级难看，但我只想把自己的意思说明白，所以越简单越好，画得难看反而不会将注意力放在上面。

好长时间以来，对于一个项目或者说一个解决方案到底具体怎么做，我一直没找到一个合适的思路。敏捷算是一个不错的方法，但是和我说的又不是一回事。我的关注点在于如何让整件事及其成果简单，简单到绝大部分的人都能理解，简单到每个人参与到这件事中后都能非常简单的清晰自己所做的事情是什么以及处在一个整体的什么节点上。要达到这个目的，必须要对整件事做一个透彻的分析，并建立起模型，这样才能对其他人解释。其他人对整件事的理解就基于这个模型。

这不是一件简单的事情，因为再简单的一件事里面也有很多因素的配合，就像一棵树的成长，最起码包括土地和阳光（空气什么的就先不牵涉了，只是为了举个例子，简单点就好），它俩搭配好了，树才能在符合搭配点的地方生长。所以，我觉得，大道至简，道法自然，对事情的分析应该也这样。

首先，要分析好基础因素（比如土地和阳光），这个因素都有自己的运转法则（水往低处流，水能渗透到土中去，阳光只能直射等等这些原则），之后根据这些基础因素的法则搭配需要的点，比如树可以生长的点，然后就可以在这种树（按照需求完成一定的功能）了。

这些基础因素的法则，在系统里面，都要自己去定义了，具体按照什么原则去定义，这就关系到哲学、个人的世界观价值观等等东东了。

这样做的好处怎么体现呢？首先基本因素的定义，这个需要根据一定的原则去定义，而这个原则可以是确定的、简单的，有了这个原则，基本要素就可以确定外部轮廓，也就是与外部的接口，使用该基本要素就可以与基本要素内部的演化隔离开来。如果这样推演开来，这个方案或者整件事情就可以被完美的分解成貌分神合的各个部分。

这个道理现在在软件解决方案中最常见到的应该是界面中的控件系统。每个控件提供一定的接口供外部调用，每个控件内部实现其相应的功能。但是这一思想在一个大型的系统中很难得到完美的实现，这对个人的能力要求太高，通常很难分清哪些是基础要素，基础要素间的分界点又在哪里。敏捷采用了一种渐进的方式，不断的对当前的情况进行分析，持续的提炼基础要素，并加深对基础要素的认识以及重新定义基础要素，这不失为一个可行性很高的方案。但是不可避免的，因为对基础要素的不断的修改，整个系统也要做相应的修改，迭代过程会浪费很多的精力，这个就是敏捷最大的缺点了。