最近和大家一起討論了一些內(nèi)容管理方面的功能和設(shè)計，有些思考，和大家分享一下。
在討論內(nèi)容管理的功能需求時，我們常常會考慮某個功能各種各樣的情況，功能性、易用性、復(fù)雜的處理場景、異常的處理場景，這些無疑都是非常非常有價值的，一個系統(tǒng)做到最好的境界，從客戶角度來看，也就是這些功能了。
同時，我們也討論了很多軟件設(shè)計方面的一些內(nèi)容，考慮了很多靈活性、擴(kuò)展性方面的內(nèi)容，同時設(shè)計和功能也是緊密相連的，設(shè)計常常對功能的具體展現(xiàn)會有一定的影響。
那我們實(shí)際中遇到的困難是什么呢?針對上面我們討論的兩個方面，主要是兩個問題：
1)功能太多了，有時候是越想越多，如何選取合適的功能集合成為討論的焦點(diǎn);
2)還有就是設(shè)計的靈活性和擴(kuò)展性的把握，感覺好的設(shè)計，往往需要更多實(shí)現(xiàn)的時間，然后項(xiàng)目時間似乎又不允許。
在說明這兩個問題之前，我想有必要稍微說明一下軟件質(zhì)量的一些分類。
最近看一本書(Scrum and XP from the Trenches)，對軟件的質(zhì)量，劃分為內(nèi)部質(zhì)量(internal quality)和外部質(zhì)量(external quality)，外部質(zhì)量指的是從客戶角度可以看到的質(zhì)量，比如軟件的功能，易用性、性能等等;內(nèi)部質(zhì)量則是是從程序員角度來看的質(zhì)量，比如代碼的健壯性、可擴(kuò)展性、可維護(hù)性等等。外部質(zhì)量好的軟件，內(nèi)部質(zhì)量不一定好;但是內(nèi)部質(zhì)量不好的軟件，外部質(zhì)量一般很難好。很難想像，一個設(shè)計很糟糕，代碼質(zhì)量很糟糕的系統(tǒng)，功能、性能和易用性可以很好。內(nèi)部質(zhì)量就好比是外部質(zhì)量的基石，代碼的可維護(hù)性和擴(kuò)展性，直接影響了系統(tǒng)的功能的改進(jìn)和提升。
外部質(zhì)量和內(nèi)部質(zhì)量比較容易對于到功能和設(shè)計兩個問題上。
那么回過頭來看我們遇到的兩個問題，首先是功能的取舍問題。
我們Agile的團(tuán)隊(duì)討論，大家對于某個User Story，討論起來越談就越起勁，想出了好多好多的功能點(diǎn)，隨之也帶來了很多麻煩，比如說要實(shí)現(xiàn)的范圍好像太大了，似乎一下子工作量變得很大，隨著而來也有很多壓力，然后接著我們有時候也會不由自主的按照項(xiàng)目時間點(diǎn)，尋找一些“捷徑”，然后可能就逐步丟掉了或者少做了一些好的功能點(diǎn)，甚至?xí)D(zhuǎn)向?qū)崿F(xiàn)一些大家雖然覺得不怎么好但是滿足項(xiàng)目時間點(diǎn)的功能，這時大家都不免感到有些失落。
那我們可以怎么處理呢，可以稍微分析一下我們整理出來的功能點(diǎn)，我們會發(fā)現(xiàn)，情況也許不是我們想像的那么糟糕。我自己覺得有四個原則可以幫助我們?nèi)ゾ駬瘢?BR> <!--[if !supportLists]-->1)<!--[endif]-->功能優(yōu)先級
<!--[if !supportLists]-->2)<!--[endif]-->80/20法則
<!--[if !supportLists]-->3)<!--[endif]-->完整性
<!--[if !supportLists]-->4)<!--[endif]-->可持續(xù)性
1)優(yōu)先級
首先是我們可以按照優(yōu)先級來選擇功能點(diǎn)，這個是顯而易見的。重要的功能先做，次要的功能可以先放一放。特別是最基本的功能，比如客戶一定要的功能，沒有這個功能客戶就玩不轉(zhuǎn)了;比如內(nèi)容管理，如果內(nèi)容創(chuàng)建、修改和刪除，這些功能如果都沒有，那么系統(tǒng)都無法正常運(yùn)轉(zhuǎn)了，肯定是不行的了。
2)80/20法則
80/20法則，就是先選擇哪些客戶日常使用最需要用到的功能，比如說內(nèi)容處理的基本流程，有一些內(nèi)容同步的異常情況，實(shí)現(xiàn)起來是很復(fù)雜的，但是實(shí)際中遇到的可
項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~
http://opto-elec.com.cn/pmqhd/index.html
