随笔2：开发任务的分解过程

    在软件开发中，往往因为功能（任务）分解得不够细致而造成过程失控，可能因为功能的反复修改或遇到原来没有预见的技术难点而造成进度延迟，更有可能要推倒重来。在开发过程中，往往是公司交给一个项目组某个项目，只要求几个月完成；项目组分配到某个开发人员手里，只明确到某个人需要完成哪些模块，比如用户管理模块、邮件发送模块等。对公司为说，项目成了最小的分解单位，对开发人员来说，模块是最小分解单位。一个模块如果需要1000行代码，7个工作日，一个人在没有任何工具的支持下，一般不太可能知道具体的细节流程，无法知道会遇到什么样的技术或流程风险。

    软件开发中，十个人有九个人认为开发任务是不可量化的，只能质化，所以会出现以测试驱动开发这样的开发模式，量化，成了很难逾越的鸿沟。其实，我们平时所说能量化的东西，一般是指可以数出数目的个数，比如水果，除了可以数个儿外，还可以称重量，像软件开发这种即数不出又称不出的，理所当然就不能量化了。

    咨询行业曾经是我梦想进入的行业，可惜这个行为像软件业一样，在国外很吃香（门槛很高），在国内成了民工，包括三大咨询公司之一的麦肯锡在中国也上演滑铁卢。咨询行业和软件行业一样，他们的咨询顾问和开发人员的工作也是不容易量化的，不过，麦肯锡的顾问工作任务却是细化到每一个步骤，咨询的内容细化到每一个过程，这种无尽细化的工作方式，应该也适合软件开发，这种任务细化的分析方法叫MECE。

    MECE是麦肯锡的第一个女咨询顾问巴巴拉·明托（Barbara Minto）在金字塔原理（The Minto Pyramid Principle）中提出的一个很重要的原则，全称是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。MECE分析法主要是把一个工作项目分解为若干个更细的工作任务的方法。在项目分解的时候，必须保证项目的完整性与独立性，分解后的子项目总和是=1，如果出现>1则说明分解有重叠部份，如果<1，则说明有遗漏。

    在软件开发过程中，我们也可以把模块和功能一一分解出来，根据MECE分析法，在分析问题的时候，从解决方案的最高层次开始，设定解决方案的维度，然后列出每个维度中所有的项目。当确定每个项目都可以做为一个独立的项目来解决的时候，就可以寻求项目的解决办法，如果某个项目还无法做为一个独立的模块来解决，那么必须继续分解。至于说到什么样的程序才算是一个独立的项目呢，比如，用户管理这个项目，因为包含有添加、修改、删除、查询等功能，而且这些功能又可以做为一个独立的小项目，所以“用户管理”不能做为一个独立的项目，分析的粒度如果到此为止，那么，负责“用户管理”这个项目的开发人可能就不知道他需要实现多少个功能，删除需要吗？查询需要吗？如果不能确定，就会造成进度失控。既然“用户管理”还不能做为一个独立的项目，那么我们继续分解，比如分解出“添加用户”这个项目，“添加用户”还不能做为一个独立的项目，因为，添加时会用到查重、用户名的格式限制，所以，可以再次分解，这样分析出“查重”和“用户格式限制”这两个独立项目，以查重为例，它只涉及到“以用户名为关键词来查询某个用户是否存在”，这样，就可以确定查询的对象实体、查询的关键词和需要的结果。

    如果我们把一个整体的项目分解成若干个这样的完全独立的小项目，在开发人员拿到开发任务的时候，就是一个一个的小项目，每个小项目清晰的描述了在什么条件下需要什么样的结果，而且这些小项目的耗时一般不会超过1个工作日，开发人员可以自由的安排每天完成哪几个小项目，质检人员也清楚需要检查哪些小项目，大家都非常清楚各自需要做什么，和做过什么，哪里出现了问题。这样，开发人员就不需要纠缠于复杂的逻辑业务，不需要承担因模块复杂而带来的风险，他们可以安心的考虑使用什么样的技术实现这些小项目的功能。

 

   PS：写完了，总觉得还不够完善，思路和流程不够多明朗，有点雾里看花的味道，蛙蛤蛤！明天再改改