軟體開發管理流程的困惑——為什麼最後開發的一堆東西都成了無用的代碼堆積？
我是一名軟體開發者，從事了系統維護，軟體開發的整個流程，讓我來搭建伺服器出方案，實施，軟體系統架構，等等都沒問題，但是現在遇到的問題令人難以理解，想諮詢下大牛們大家是怎麼做的給晚輩些指點，也對中國的iT專業化共同努力。
問題是這樣的：1.軟體開發過程中總有時候是東西開發了再改，有的是上面的拍腦門的想法，怎麼避免如此的問題，最後開發的一堆東西都成了無用的代碼堆積；2.開發中設計，開發應該是怎樣的配合和模式，現在感覺為了趕工就沒有設計，就是簡單的想想就開始了，那麼怎麼評估一個項目的時間和效益對應的成本問題，大部分都是趕時間捨去了設計時間，最後的後果是非常痛苦的修改和更新；3.在開發或者修改更新的時候總會遇到這樣的問題，A修改的東西吧B的給改啦，或者很久之後A改的東西影響到了系統的其他功能，怎麼避免這些問題；4.思考這些年的IT經歷能感覺到有以下辭彙的重要性，需求，設計，開發，測試，修改，發布。但是怎麼進行配合組合，讓工作中盡量少的出現人為的非專業性帶來的並發性問題，延誤開發問題是我想不明白的，希望看到的大牛不要吝惜筆墨，多多分享讓我們每個人看到的都有所收穫這不是公司利益問題，是大家針對這些問題進行的討論和總結，是我們大家的智慧；
如果您回復了無論長短，對您表示感謝^_^
3.在開發或者修改更新的時候總會遇到這樣的問題，A修改的東西吧B的給改啦，或者很久之後A改的東西影響到了系統的其他功能，怎麼避免這些問題；
這種現象在日常的軟體開發中很普遍，我把這種現象叫作葫瓢現象——「按下葫蘆，起了瓢」。
目前軟體工程、敏捷開發解決這個問題比較徹底的辦法，主要是儘早發現，通過頻繁的回歸測試（包括自動與人工），以及建立和維護高覆蓋率的測試安全網。這樣一旦由於某些人修改某些代碼，導致引入新的 bugs 或破壞原有的系統功能，可以在第一時間儘早發現和排除。
要盡量減少葫瓢現象的發生，自動回歸測試與高質量的測試集是必不可少的。
1.軟體開發過程中總有時候是東西開發了再改，有的是上面的拍腦門的想法，怎麼避免如此的問題，最後開發的一堆東西都成了無用的代碼堆積；
這個問題的根源在於需求。什麼東西決定了你們開發的軟體、代碼有用還是無用？這是由用戶決定的。符合了用戶、干係人（Stakeholders）的需求，具有業務價值（business value）的代碼就是有用的，反之則無用。
軟體開發過程中經常會出現需求變更、代碼修改，這在一定範圍和程度內是正常的，因為複雜的系統開發必然都存在著一定的不確定型（Uncertainty），正是因為許多內容（包括需求和設計）的不確定，才需要我們去研究（research）、探索（explore）和試錯（trial and error），這正是軟體研發（RD）的本義。所以，由人類思考活動為主要活動的軟體開發本質上不是一個高度確定的製造、生產過程，絕大多數軟體開發不是汽車、服裝、皮鞋業的生產過程，也不是程序員打字，這些過程基本都是線性、確定的。
那麼，怎樣才能避免最後開發出來的代碼成為無用的東西，盡量減少開發過程中的浪費？
現代軟體工程與敏捷開發有一個最佳實踐與答案，就是迭代開發（Iterative development），也叫迭代遞增式開發（IID）。
把軟體開發項目分解成若干時間片，例如 2 周為 1 個迭代。每個迭代（每 2 周或每個月）都要對開發中的軟體進行全面的測試，最關鍵的是獲得反饋（feedbacks）：要對當前的開發成果進行質量評審（review）和運行演示（demo），尤其要讓軟體的最終用戶或用戶代表對系統的需求和設計進行確認，給出評價和意見，以便開發團隊在隨後的開發過程中及時進行調整和優化。讓軟體的用戶來回答你們開發的東西是有用還是無用，這才是根本、徹底的辦法。如果是領導、決策者拍腦門的想法，通過迭代開發的評審、運行和演示，就能儘早發現，避免無效的需求。
這種現代的迭代開發模式比傳統的瀑布模式風險要小很多，能最大程度上避免軟體開發過程中的浪費和差錯。
。。。好好學學軟體工程，你這屬於不合格的作坊式開發
沒有不會謝的花
沒有不會退的浪沒有不會暗的光你在煩惱什麼啊沒有不會淡的疤
沒有不會好的傷沒有不會停下來的絕望你在猶豫什麼啊題主，來這裡看看：
1 需求分析-軟體產品的利益相關者
2 你的項目延期過嗎3 代碼複審看什麼4 阿超的故事-第一輯以上內容摘自 @李旭 的回答中推薦鄒欣的軟體工程書：構建之法，此為多看版。
我們先來看看這位朋友的體會：
在微軟實習學到感觸最深的事情是什麼？ - 微軟（Microsoft）這位微軟實習生頗有感觸的事情是：現在，國內一些高校中有遠見的老師已經開始採用《構建之法》作為教材，來看看廣州商學院這兩位大三同學的閱讀筆記：《構建之法》的筆記微軟對coding的要求很高，入職第一天，實習生要首先閱讀coding guideline，裡面詳細描述了coding要遵守的規範，從變數命名，tab幾個空格，到最後code check in之前的review都很清楚。 我們開發的網站因為是內部使用的，所以沒有這麼嚴格遵守要求，但mentor一再囑咐coding的要求，復用，層次化設計，類和介面的設計，都要認真細緻的思考後進行，和上學時隨便寫有太大的區別。
在微軟工作過的 @Andy Pan ，先後也在騰訊微信產品部門及如今相當hot的大疆公司擔任團隊leader，他讀了《構建之法》，寫了這樣的書評：100倍速度前的慢動作 (評論: 構建之法)什麼意思呢？他說——在讀此書之前，我一直以為當一個團隊確定了負責一個項目之後，他們的成員不會再有所修改，會對所負責的項目負責到底。但實際上，軟體團隊是會流動的。為什麼要有人員的流動呢？是出現了現有團隊解決不了的技術困難，需要新技術新知識的支持，還是現有團隊身擔多職，需要人手幫忙？另外，不止是軟體程序會有bug，團隊也會有bug。處理好bug是創造「足夠好」的軟體的基礎，但在校園學習過程中，我們常常會忽視bug，甚至把它留在最後處理。
英雄所見略同。百度工程師牛堯在這篇題為相見恨晚-目前為止看過的最好的軟體工程書籍 的書評中寫道：看了鄒老師的《構建之法》，往日在微軟學習的紮實的方法學一幕一幕回來，裡面也加入了很多鄒老師在研發互聯網產品對微軟傳統方法的反思和互聯網方法的實戰經驗。我把幾本書送給微信的幾位核心開發，反饋也是，如果新同事有這樣紮實的訓練，更能夠適應微信高靈活性的開發。
和曾經微軟的一名開發同事現在小米公司的一名核心員工聊天，我問他，你在微軟和小米都做了開發，兩者的區別是什麼？回答：把微軟方法的速度提高一百倍就是小米的方法。
因此，對於學徒，在實戰之前，先認真學習拆解動作，免得將來到實戰場基礎不行速度上不去被淘汰，或者速度上去了基礎不紮實打成王八拳誤傷了自己。
隨著這本書及其授課模式在高校的推進，我相信再過 3-5 年，新生代的學生軟體研發的整體水平一定會有大幅度提升。
按照這本書的模式訓練新人和進行人才培養絕對可以事半功倍。若湊巧有位應聘的同學在大學經歷過這樣的授課模式，而且成績優異，絕對值得直接收了，至少可以讓你省掉半年的新人培養成本。
另推薦多篇來自不同IT公司的工程師或項目經理的書評_
水面下的冰山——讀《構建之法》 (評論: 構建之法)/丁香園工程師《構建之法》----迷你版的《代碼大全》 (評論: 構建之法)/廣州的一位工程師構建軟體工程的進階之道 (評論: 構建之法)/清華同方資深項目經理
以獨特的視角來看軟體工程--讀《構建之法：現代軟體工程》/中興通訊軟體工程師軟體需要嚴肅對待，謹慎修改 (評論: 構建之法)/嵌入式開發工程師===試讀及更多介紹請參看這裡。
鄒欣在Build To Win - 構建之法 - 知乎專欄中說：由雞，豬，和鸚鵡組成的團隊怎麼贏？ 要創新，但創新有規律么？如何平衡種種矛盾，走出一條理性的，不要拚命加班的道路，還能得到合適的回報? 這是我看到的所有軟體工程教科書沒有講的，也是我想在《構建之法》這本書裡面探討的。
我把這段話發給七牛的許式偉，他果然對《構建之法》產生了興趣，因為他也不提倡靠加拚命加班才能做好項目和產品，但他們團隊又尚未擺脫不得不經常加班的困境。
鄒欣最近在廣州致遠電子做了一次講座，講座文字實錄匯總在此：
鄒欣講座：現代軟體工程--構建之法下面是去現場聽過講座的 @劉鑫 聽了講座之後寫的專欄：鄒欣老師《構建之法》講座廣州（一）人才選拔 - 前路迢迢 - 知乎專欄鄒欣老師《構建之法》廣州講座（二）前夜 - 前路迢迢 - 知乎專欄
鄒欣老師《構建之法》廣州講座（三）啟動問題 - 前路迢迢 - 知乎專欄你沒有說你從事的是產品型開發，還是項目型開發，我就產品型說點點自己的看法。
1、關於需求變更。 開始寫代碼前，必須有需求文檔，我建議這個文檔由開發來寫，需求的原始文檔甚至可以不要，只要開發能懂就行。開發處於需求和測試之間，只有開發寫的文檔，三方才能都看的懂。這個文檔不要被各種格式所困擾，目的只有一個，三方認同。 有了文檔，還是不要動代碼。必須有一個三方確認的過程，請大家不要遺漏測試，測試在一開始就介入，對項目進程有莫大的好處。確認不應該只是個觀看文檔的過程，對一些重要的功能點，最好三方一起碰頭討論確定，否則，就文本層面，各人的理解差別可能很大。（就我個人習慣，會把各個功能點的複雜重要程度，以A、B、C、D來編號區分，方便之後的交流）如果是項目型的產品，文檔還必須由客戶簽字確認，客戶簽字的文檔尤其注意UI的描述。 最後，必須規定一個需求變更的流程。需求變更的原因應該附在原文檔後面（不要改原始文檔），我們一般是通過論壇回帖的方式在處理，需求、開發和測試都必須簽字確認。進入測試階段後，應該有一個Dead Date，超過這天，即使是錯的，也堅決不能修改。正常一個項目下來，有20%的需求變更是正常的。 當然，最麻煩的是領導拍腦袋。作為技術負責人，必須要敢於說不，領導敢半路加東西，你們就要敢瘋狂加時間，多弄幾次他們就知難而退了。我見過很多傻乎乎的程序員，領導一說什麼，他們就說簡單啊，分分鐘，也不徵求需求和測試的意見，就開始亂改一氣。其實這樣做領導會更不重視技術，更會亂來。2、開發的內部配合
如果有了上述了流程和文檔，在開發之前，各個程序員的分工和大概的工作安排應該已經出來了。精確到每個工作日應該不成問題，建議Leader都先做個這個任務安排，不精確到每天，有時候進度不好控制，特別是需要協同的地方。團隊不要太大，超過5個開發的團隊，就一定要拆分，國內開發的Leader一般都承擔著重要的開發任務，不可能有精力管理超過5個人的團隊。條件允許的話，最好空出幾個人掠陣，不要分配太多任務給他們，他們專門做代碼Review。
代碼Review是很重要的，建議每個團隊每周都有一次集體的Review，其實不用準備什麼，弄個投影儀，把大家正在開發的代碼投影出來就可以。代碼Review有一定的套路，我建議只為了一個目的：降低代碼複雜度。「複雜度」是個可以量化的指標，有興趣的朋友可以找一下相關書籍看看。 A改的代碼影響了B，這種情況很難避免，但應該控制在比較小的範圍內。如果某些人經常出這種事情，那就把他貶去做很獨立簡單的東西，比如報表。加強開發的自測，可以制定相應的績效考核，比如交給測試的產品質量標準，不能主要流程走不通，不能出英文提示等等，這時候不能手軟，說多了沒用，錢才是硬道理。 最近流行結對編程什麼的，在國內應該實行不下去的，但是可以結對Review，弄些連帶責任的績效考核。至於單元測試，對代碼的架構要求很高，做不動就算了。3、關於測試
測試在國內軟體行業的地位低下，這非常糟糕。建議一個測試團隊起碼能有個把兩個白盒測試的，有個把兩個精通各種測試工具的，有個把兩個能做效率測試的。有些團隊甚至連專職的測試都沒有，這就非常堪憂了。 建議開發階段，測試就要介入，完成一個功能能用，就應該馬上交給測試，但開發階段，主動權和話語權還在開發這邊。進入測試階段後，所有功能應該全部完成，這裡應該也有個明確的日期，測試階段應該由測試完全掌握主動權，有些錯誤開發可能會認為是測試吹毛求疵，那也必須尊重測試的工作。 其實不少錯誤開發改不動，或者不能重現，或者得不償失，這些類型的錯誤可以延期不改，但也應該有一個嚴格的流程，起碼不應該是隨便一個開發人員都可以跟測試說什麼什麼不改。想到哪裡寫到哪裡，寫不動了，也沒有整理一下，見笑。我對你提出的問題看法如下：1、需求的問題不能光看錶象，更不能聽風就是雨，比方用戶說要一個報表，那你至少要問清楚用戶要這報表幹什麼？用戶所關注的數據是哪些？如果這些都不清楚的話，那不是用戶說報表太簡單不實用，就是說報表太複雜操作不方便。在需求的收集中，如果涉及到專業的行業知識，則更需要請相關專業人士做好業務的指點，這點非常重要，因為這往往會影響到系統與系統的交互或後期功能的擴展。另外，需求必須經過嚴格的評審，因為很多研發人員認為很有用的功能，其實用戶根本不用或極少使用，你所說的無用的代碼堆砌應該就是類似這種情況。2、關於開發的設計，我的建議是要極簡，什麼叫極簡，就是以滿足需求為根本目標，切忌過度設計和閉門造車，在設計過程中不要受到市場或同行的影響，因為需求是無止境的，如果需求的基線已經確認，那原則上應該儘快按需求定義出具產品原型請用戶試用，儘快體現出自己產品的亮點和優勢以引導客戶，根據客戶的意戶和實際的情況，進行分析後再有計劃的優化和完善產品。所謂的改改改，最大的問題是公司的開發設計及市場人員的思維局限。打個簡單的比方，當年諾基亞盛行的時候，哪個手機製造商能按用戶的需求設計出蘋果手機？軟體設計中有一個重要目標是如何創新和體現產品優勢，要從服從客服變為引導客戶，進而引導市場。在軟體產品領域，要麼你跟著別人的產品改改改，要麼別人跟著你的產品改改改。當然這一點對於銷售人員、實施人員的要求會比較高。3、關於開發過程中程序員互改代碼的問題，可以考慮每周進行組內人員的REVIEW，一個小組的人數建議在4到5人左右，負責1至2個產品的更新維護和一個新產品的開發。但代碼的REVIEW受到參與人員編程水平及個人喜好、工作態度、情緒等主觀因素的影響，所以代碼REVIEW要有，但必要的測試也要做，數據的度量和收集更是必不可少，對於代碼質量一直沒有提高的人員，要考慮將其調至一個更適合他的技術或非技術崗位。另外，如果項目不是很龐大的話，盡量劃分好模塊或功能界線，盡量避免程序員之間相互修改代碼的情況出現。4、各項工作的組合及配合，關鍵在於是否有合適且明確的流程及審核，還有必須做好過程改進，比如某產品在需求階段，一開始需求及設計人員的思路是明確的，產品的理念也是明確的，但等銷售人員參與進來後，一會說張三的產品怎麼好，一會說李四的產品怎麼好。但是銷售人員往往忽略了一個問題，就是張三或李四的產品是否解決了用戶的問題，用戶在使用這些產品時是否有不適的地方，或者說我們的產品能否能超越當前市場上的產品，這才是產品設計應該關注的點。一個手機製造商抄蘋果抄的再象，也是不可能超越蘋果的。所以上述的案例就是典型的非設計需求人員引導開發的案例。所以各項工作的組合及協作，在每個階段都要明確參與的人員是否合適，排除不必要的干擾，由適合的人做適合的事，要抓好評審工作，簡單點說，抓頭抓尾，中間卡里程碑。
你採用自底向上的開發就不會有垃圾代碼了
強烈推薦鄒欣的軟體工程書，很通俗易懂，看完你就沒這些疑問了。
0. tech lead，架構師必須寫代碼
1. 結對編程2. 測試驅動開發3. code review4. 功能測試5. 持續集成6. 自動化測試認真在項目中引入以上實踐並思考為什麼需要這些實踐。 但是最重要的是，你需要一個「懂行」的領導或客戶推薦閱讀：