[全程建模]元用例和需求與績效之間的關係討論

看了《隨筆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看後總結說：需求是歸納出來的，不是分解出來的。

分解出來的需求，往往是開發者根據自己經驗給使用者套上的需求，這樣的需求往往是不準確的，因為有經驗的開發人員經常習慣用已知的名詞和名詞的覆蓋範 圍來覆蓋當前使用者的需求和想法，於是，就出現了需求中有些是使用者不需要的，有些是使用者需要修訂的。而如果是按照我的方法歸納出來的，則絕不會出現這樣的問 題！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-667866/，如需轉載，請註明出處，否則將追究法律責任。