[全程建模]元用例和需求与绩效之间的关系讨论

看了《随笔2：开发任务的分解过程》http://blog.csdn.net/CSDNATM/archive/2010/07/12/5730142.aspx后的评论内容，涉及到需求分解和获取，任务分配和绩效管理的内容。

slowgrace让我过来看看，上面这篇文字中提到的内容很多是常见内容，但是根源却不在撰写者的内容。下面进行一下我个人的观点描述：
1、“往往因为功能（任务）分解得不够细致而造成过程失控”
这段文字中的问题其实是因为需求没有做好的原因。关于最小分解单位可以对应于uc和us的方式，在我的定义中将之具体化为元uc/us的概念，也就是最小的不可分的操作，对应于用户业务过程中的一个最小的动作，比如从办公室拿文件送给领导看就分为两个最小动作，拿过去和看！
如果你非要说从桌上拿起来也是一个动作，但是要注意这个动作在软件系统中是不需要具体化的动作，软件系统中需要具体化的动作就是送到领导桌子上，然后是领导看，也就是领导点击打开，至于打开以后是否看了，谁也无法做主，只有领导本人知道，就类似于领导拿到了你送上来的文件，眼睛盯着，心里却在想着三顿晚饭去吃那一顿的问题，那你也没办法。
2、量化问题
这个问题建议去参考我的绩效管理模型，那里面给出了量化方法和操作过程。
任何事务在一定层面上都是可以量化的。当然到了再细分一层的层面可能就无法量化，比如原子物理学中原子核组成的量化，到了中子质子组成的时候却又出现了无法量化的问题，于是有了云概念的提出和解释，从而衍生了很多新的推理。
软件开发的工作量也是可以量化的，量化的基础就在于一定层面，而不是100%精确，其实100%这个词本身就不够精确，因为它只精确到了小数点后两位，如果非要较真地说精确，那就是100.00000%（这里有无穷多个0）。
3、“把模块和功能一一分解出来”
根据我这几年总结的东西来看，我认为软件项目的开发任务不是分解出来的，而是归纳出来的。
常规情况下说分解，是因为需求没有做到位的原因，大家都认为项目是一个整体，却没有反过来思考一下，其实项目是由众多需求组成而形成的，每个需求有自己的基础组成内容。
比如文中的例子：
““添加用户”还不能做为一个独立的项目，因为，添加时会用到查重、用户名的格式限制，所以，可以再次分解，这样分析出“查重”和“用户格式限制”这两个独立项目”
其实，这是多个uc或者us之间的相互连接的关系，也就是开发中的接口定义和重用问题。
这个问题如果只是从需求，从项目的层面往下看，的确会认为这个需求很大，但是，如果你是从细分角度来看整体，那就是一个积木组合或者方法/对象间调用关系，并不复杂。
如果用我的元用例的概念来看待，那就是多个元用例的重新组合问题，或者说就是元工作任务（最小工作任务）的重新组合。
这时候往往一切都能豁然开朗了。
4、任务的大小
其实任务的大小未必要限定到1个工作日这样的规模，因为在开发中有些元工作任务有可能十分复杂，因为这个功能对于你这个系统只需要一个返回值，而这个模块是另外一个组几十个人几个月的工作量。这里面就涉及到组间协调和配合的问题，一方面要看你团队的管理者的管理水平，另一方面也要看你们的协调和开发配合问题。
也可能这个很大功能的返回对于你们公司是没有技术力量开发的，那么购买组件或者成品就是最佳选择，如果你的领导这时候非要坚持自己开发，那必然带来整个项目的复杂化和细分的问题，这就只能具体问题具体分析了。
关于任务的大小规模，要根据元用例产生的基础原因来定义考虑，而不是随心所欲的认定或者讨论认定，当然元用例的规模也要进行讨论否则可能出现错误和偏差，但是这些内容的根源都在于需求你如何看待如何整理如何获取的问题，而不是其他。
在我新书的需求章节中提供了新的关于需求细分的方法，也曾经在我的blog中发布过。可以去看看。

补充：

loveisbug看后总结说：需求是归纳出来的，不是分解出来的。

分解出来的需求，往往是开发者根据自己经验给用户套上的需求，这样的需求往往是不准确的，因为有经验的开发人员经常习惯用已知的名词和名词的覆盖范围来覆盖当前用户的需求和想法，于是，就出现了需求中有些是用户不需要的，有些是用户需要修订的。而如果是按照我的方法归纳出来的，则绝不会出现这样的问题！