中午有同事提出乙個問題，其實我覺得根本不值得一談。但很多人有爭議，在這裡簡單記錄，並闡述一下自己的觀點。
先看故事背景：
某tm 類似於 這類已經無效的需求，我們是否有必要不放到任何乙個版本裡面？因為即使關閉了，它也佔了乙個數，大家怎麼看？
某tm 檢視的時候，如果不乙個個點開，是不知道是否是無效的，無效的需求也混在有效需求裡面，雖然也有乙個狀態表明是無效的，但是多餘啊，--這個不就是坑嗎？這個才會增加管理難度的
某pm 統計的時候過濾掉就是了
某tm 如果是無效的，為什麼還要專門過濾它呢？新建乙個empty版本，無效的移動到那個版本裡。
某tm 有些浪費腦力哈，無效的根本就不應該被展示和被關注，應該淡出到考慮範圍之外。而不是要時刻提醒自己有乙個個的坑。
某pm 無效的及時關閉，還挖啥坑啊。不要增加管理難度嘛
……存在矛盾和問題。我們回頭看看，其實這裡討論的事情，都涉及到了什麼：需求管理、專案管理、專案度量、版本管理…
我給出的看法是：
首先，無效需求也是需求。只不過是在執行過程中才發現和前期預想的不一致，它和won't fix或者無法重現的bug類似，都是在專案前行過程當中經歷過的一些記錄；雖然最終的交付並非有效價值，但也包含了一段思考和分析在其中；
其次，無效需求也應當被統計。它是屬於某乙個版本下的產物，在專案結束時候，專案總結需要進行統計，和初期的專案計畫所提需求對應。
然後，empty版本沒什麼階段屬性，即使統計也應當基於一定時間一定版本週期內，脫離這兩點單獨建立empty版本統計無效需求是沒有實際意義的；
再者，從度量的角度，這些存在也是合理的，即使電信專案嚴謹一些要求 5個9，那麼也存在0.00001的瑕疵在其中。發布標準定的一般是實現80%，而無效需求存在於剩下的20%中。
越是創新型的專案，探索的越多，這種無效需求的可能性就越多。如果沒有經過失敗的嘗試，那麼就沒有最終的正確結果。
所以個人認為，這個問題沒有什麼爭議的必要。
現在大家都在倡導敏捷精益，倡導快速迭代，各種agile、xp、scrum、甚至還有「他爹的tdd開發模式」（test driven development），還有「他媽的***開發」( team meeting driven)，完了有些人連attd的全稱是什麼都不知道就開始大談atdd的好處，可見我們的manager們是多麼的浮躁，個個以為考了乙個pmp就可以了，隨便拍拍馬屁，這事就成了？而殊不知，正式如此，才導致了專案逐漸的走向死亡。
乙個專案的成功，離不開一行一行寫**和debug的「屌絲碼農」，和一次次搭環境嘗試各種不同場景下的執行狀況的「測試童鞋」們。他們才是支撐專案的最初原動力。當然架構師也功不可沒，乙個「大腦袋」的視野和高屋建瓴版的精妙設計決定這專案的定位。他們才是最可愛的人。他們才是專案的驅動力**，而絕對不是整天穿梭於各個會議室拿著喇叭催進度的managers。
我們不需要不懂技術的pm和tm。因為他們一人拿著底下三五個人的薪水，卻幹著一些拿著沒什麼真實意義的事情，還美其名曰「度量」，畫畫excel，喊喊口號，一天就過了，卻不幹多少實事。純粹是對專案成本的一種浪費。還不如用來給底層搞技術的碼農們來點加班飲料。呵呵，說的有點過了，就當作開玩笑罷了。
現在bdd和sbe也號稱比較火，這個不是什麼sb engineer，而分別是行為驅動開發、需求例項化。我想不論採取什麼模式，瀑布還是基礎模式，不論玩什麼開發方法學新花樣，cmmi也是基礎。萬變不離其宗，如果這二者都沒練熟，其他都是瞎扯。
從需求開發會議談起
今天專案組進行了乙個小時的需求討論，由於剛進入專案組不久，對系統了解不多，幾乎沒有發言一直在旁聽。此次會議得出一點心得 系統開發中最重要的就是解決方案的敲定，解決方案選擇對的話，就算沒有達到事半功倍的效果，開發人員開發起來也能輕鬆很多。怎麼才能產生乙個好的解決方案，這就與對系統 需求 技術的掌握程度...
由家裡網路故障談起
這些都需要慢慢研究了。ps，在位址列中輸入202.108.33.60並不能開啟sina的主頁，而是看到如下的反饋資訊 經過網上搜尋，發現這是因為為了安全考慮 防止惡意解析 有些 大部分 禁止通過ip直接訪問到 可以參考 後來在家裡用一台linux計算機ping 路由器能通，那麼有可能是windows...
需求工程 需求管理
需求以自然語言進行描述，應該以某種標識方案進行編號。幾種常見的需求標識和分類的技術 最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護...