少。又比如內(nèi)容創(chuàng)建流程的易用性，這個用戶使用頻率是非常高的，那么怎么優(yōu)化內(nèi)容創(chuàng)建的用戶體驗，這個功能點優(yōu)先級也就是很高的，然而它的代價可能不會特別高。
3）完整性
要特別注意是功能點的完整性，比如說內(nèi)容異常流程的處理，假設(shè)因為項目時間，先不實現(xiàn)了，那么也不是說完全不處理異常了，還是要做到有一定完整性，即使是簡單的實現(xiàn)也是需要的（比如說記錄日志以供人工查詢），但是這個簡單實現(xiàn)是代價最小的，而且是以后可以很快去替代的。
4）可持續(xù)性
功能點的實現(xiàn)選擇，要考慮的還有可持續(xù)性的問題，就是功能點是可以不斷去疊加來完善的，而不是說不斷的推翻后重新實現(xiàn)一把，這個是差別很大的。比如說內(nèi)容創(chuàng)建功能，現(xiàn)在對于異常的處理我們暫時不實現(xiàn)，這個是沒有問題的；但是如果下次要實現(xiàn)異常處理的時候，就要把現(xiàn)在內(nèi)容創(chuàng)建的流程的功能描述推翻重來，這個可持續(xù)性就有問題了，因為這個意味著以前的功能全部都會被推翻，很可能是以前的實現(xiàn)都白費了，這就是功能點設(shè)計的的不可持續(xù)性了。功能點設(shè)計一定要有持續(xù)性，如果是這樣子，系統(tǒng)的功能就能夠越做越強。
所以我們可以把每一個的User Story的各個功能點想的更加完善，這個是很好的，剩下的只是如何取舍的了，所謂取舍，只是階段性的舍棄和選擇罷了。所以在討論過程中，不要因為功能的增強，范圍的擴大而讓我們感到害怕和困惑，把他們記錄下來，就是很好的逐步改進系統(tǒng)的武器，我們只要運用上面的一些原則，就能夠讓我們做的更好。
下來再談?wù)勗O(shè)計的問題。
在Head First Object-Oriented Design的書中，定義Good Design就是Flexible Design。而The Art of Agile Software Development一書中，定義Good Design為“A good software design minimizes the time required to create, modify and maintain the software while achieving acceptable runtime performance.”就是軟件的可維護性。所以Agile Design強調(diào)的功能，基本上都是從如何不斷改進軟件的可維護性和可擴展性而努力的，只有軟件具備了良好的可維護性和可擴展性，那么軟件能夠很好的不斷疊加功能，軟件才具有旺盛的生命力。
我們實際中面向的問題呢？其實還是很簡單，就是好的設(shè)計和項目時間的沖突，好的設(shè)計是需要時間考慮的，也是需要時間來實現(xiàn)的（雖然不是絕對，有時候好的設(shè)計會節(jié)省更多的工作量）。
對于第一個問題，于項目時間的沖突，這個可以回到前面開始談的內(nèi)部質(zhì)量和外部質(zhì)量的問題，前面對于功能（外部質(zhì)量）的問題，我們已經(jīng)談了取舍的方法，那么，內(nèi)部質(zhì)量（設(shè)計），是不是也可以取舍呢？在“Scrum and XP from the Trenches”書里面，作者自己是這么認為的：
Internal quality, however, is not up for discussion. It is the team’s responsibility to maintain the system’s quality under all circumstances and this is simply not negotiable. Ever.
在這上面我是持一樣的觀點的。
然而我們的問題依然存在。和項目時間的沖突如何平衡呢？我想可以考慮兩個原則：
<!--[if !supportLists]-->1） <!--[endif]-->足夠好（First Right）
<!--[if
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
