系统架构与任务功能的分解

一、概述

                最近，看到一位同学整理开发计划，牵涉到一些任务分解上面。自然想起了之前架构分解的一些文章，同时也结合自己之前从事的岗位分析一下。

我们在面对一个庞杂的系统或是繁杂的任务时，有时总是感觉一座座大山在心头。最先想到的是愚公移山以及庖丁解牛。两者都是从一车或是一刀开始。

所以，分解使我们有能力解决这样的问题。

二、架构分解

                 最早看一本讲到架构实践的书籍，多阶段，多层次。但后来看到架构分解文章时，一下子有了醍醐灌顶之感。架构分解是在一个更高的层次上。之前人说过，架构吃掉需求，设计吃掉架构，开发吃掉设计。第一句总是不容易理解，现在感觉再自然而然不过了。架构也分类别的，比如我们常听说的业务架构，技术架构之类的。我们单单从技术架构的角度解释一下，我们在面对这些需求时，所提到的分解。

2.1、分解的维度

                业务域--- 》功能域---》技术域----》涉众域。螺旋上升。

                分解的原则也是我们在做系统设计时，一些常用的原则，比如高内聚、低耦合，抽象原则，稳定原则等。

                其次是讲到分解的粒度问题：没有统一的答案，也有一个原则是可指导设计开发。

2.2、分解的时机

                也是一个智者见智的问题。有人喜欢一开始就勾勒蓝图，也有人在出现问题时，调整。单我们也应该清楚什么样的需要事先做足功夫，什么样的又需要后续调整。这个也是根据系统架构重大需求影响面把握了。

三、任务功能分解

                 项目有项目计划，调研有调研计划。而作为其中一个环节，开发阶段也有开发计划。其实，和其他计划一样的道理，安排计划，就是安排有哪些事项，然后根据对应的所拥有的资源，填写上对应的日期。

                 我们先谈开发计划里面的任务怎么分解？

                 一般而言，开发计划也是项目里面一个阶段或是一个迭代阶段，既然是事项，那就用轻重缓急，功能实现也有难易划分，我们都可以依据一定的标准确定一个等级。然后根据相关性，将相同或是相似的划到同一个角色岗位的头上，这叫领取任务条。然后根据我们的评估以及与这个岗位角色人的交流，确定一个日期。后续就开始跟进调整了。

3.2、分解的维度

                 页面，如果没有页面的，根据系统功能点罗列。当然，里面还有牵涉到复杂度的评估，以及对负责完成此功能人的评估。

四、调和

                  既然架构分解中有一项是涉众域，那我们的系统功能分解也一样。架构分解中，采用的不同技术手段，以及功能开发中遇到各类技术障碍或是人为障碍，都需要保证顺利实施。调和就成了相关人相互接受的一种态度。