軟件開發(fā)管理建議

1、公司開發(fā)管理建議本文的目的1 希望工作氛圍有所改善2 希望工作效率得到提高回答如下問題1 為什么疲憊2 工作如何分工3 代碼版本控制4 工作環(huán)境文檔化5 新人的培訓與成長6 當前該怎么做為什么疲憊什么樣的工作容易疲憊？不是加班，有時加班往往帶來的不是疲憊，而是充實和成就感；導致疲憊的元兇是工作中的不確定性和瑣碎。不確定性源于自身能力與所做工作的差異，說白了就是不會；可是EDA行業(yè)到哪里找那么多會的人呢，優(yōu)秀人才大都在現(xiàn)有公司有一定地位，很難撬到，正確的做法是搞好分工，讓適當?shù)娜俗鲞m當?shù)氖?，這樣就不會面臨招人難的困境了，優(yōu)秀公司的人才都不是挖來的，而是自己培養(yǎng)起來的?，嵥樵从诜止さ慕徊婊蚴枪ぷ鞫?/p>

2、。工作瑣碎不僅僅是導致開發(fā)人員的疲憊，對產(chǎn)品質(zhì)量的影響很大，容易制造Bug，而新的Bug又導致工作更繁瑣，陷入惡性循環(huán)。我并不是反對壓力，對某些人來講，壓力是促進成長的催化劑，但新一代年輕人承受壓力的能力越來越差。最重要的是：如果我們能夠輕松的做完事情，何必選擇壓力呢。輕松代表了游刃有余，也暗示了我們能做更多的事情，如果已經(jīng)繃緊了，就沒有回旋余地了。工作的愉悅性是能留住人的重要砝碼。工作如何分工軟件開發(fā)的迭代流程是：需求分析，概要設計，詳細設計，編碼調(diào)試，測試維護。需求分析：不管做什么事，開頭都是最重要的，所以需求分析是最重要的，它貫穿整個開發(fā)流程，當工作進展到測試階段時，突然發(fā)現(xiàn)需求沒有弄清

3、楚，等于是整個工作從頭再來，這不光降低了工作效率，而且對于開發(fā)人員的情緒打擊很大。重要的事情自然要由重要的人來做，應當安排經(jīng)驗豐富能力強的人來做需求分析。新人考慮問題不周全，勢必增加返工的次數(shù)，對軟件質(zhì)量危害很大，而且還會干擾其他人的工作，進而影響到整個公司的效率。必須加強對需求的跟蹤，我們的需求零散的分布在Bug Tracer，文檔，Email里，對QA工作和工作交接都很不利。每一次需求變更會影響到整個軟件過程，所以在定義需求時要充分考慮，定義需求的工作自然也應該由經(jīng)驗豐富的人來做。概要設計：概要設計跟需求分析關聯(lián)很大，需求分析要做的工作就是理清需求，決定由哪些模塊協(xié)同完成，需求分析和概要設

4、計由一個人來做會更方便。概要設計包含了接口定義，一旦接口定下來，軟件的框架就確定了，從而約束了后面的風險。接口變更帶來的附加工作很多，接口制定的重要性是很明顯的，還是那句話：重要的事情由重要的人做。詳細設計/編碼調(diào)試：在接口定義下來之后，接下來就是實現(xiàn)了，詳細設計描述基本的實現(xiàn)算法和模塊的子結(jié)構(gòu)。概要設計的輸出就是詳細設計的需求，這個需求是開發(fā)人員容易理解的。詳細設計和編碼應該有一個人來完成，因為這兩部分結(jié)合緊密。詳細設計的目的：1 評審，概要設計人員和同行可以對詳細設計進行評審，以控制風險。2 維護，當需求發(fā)生變更，或有Bug，詳細設計可以給與指導。3 交接，在人事變動和工作變更時，有詳細設

5、計文檔可以方便的交接代碼。打鐵要趁熱，編碼之后要立即進行調(diào)試和測試，一些明顯的Bug應該在這個階段被發(fā)現(xiàn)。測試維護：測試的核心價值是發(fā)現(xiàn)Bug，是以寫CASE為主。對CASE的整理很重要，CASE和需求是相關的，有必要將CASE與需求點對應并編寫成文檔，方便查找，在后續(xù)的修改中，開發(fā)人員可以通過這個文檔找到相應CASE，對修改進行驗證。很多公司要求在需求確立后編寫測試計劃，這聽上去很完美，但如果需求總是變更，很多工作將被浪費，所以我建議在開發(fā)進入到一定階段的時候開始進行相關測試，因為這個時候需求相對穩(wěn)定，而且符合打鐵趁熱的觀念。寫到這兒，我對比一下兩種開發(fā)方法，從而說明上述軟件過程的必要性。當

6、前公司的開發(fā)模式有點類似于下圖：在這種模式里，每一項工作幾乎從頭至尾由一個人來完成。在這種模式下，人員之間的協(xié)同很少，高級員工和普通員工在工作性質(zhì)上沒有本質(zhì)差別，由于工作不一樣，高級員工不方便給與幫助，軟件的質(zhì)量由員工個人能力決定。由于能力差異，開發(fā)進度也很難控制。在這種開發(fā)模式里，看不到開發(fā)團隊的影子。而且，到哪里招能獨立開發(fā)的人員呢，招人難，用人難的問題突出。軟件規(guī)模受到限制， CMM認為，這種開發(fā)模式的人員極限是十幾個人，源笙這么些年來，開發(fā)人員規(guī)模一直在十人左右停步不前甚至萎縮，恐怕就是這個原因。當人員離職時，接手那一部分工作的人恐怕能做的就是祈禱別出問題了。因為從頭到尾只有他一個人知

7、道，他不需要寫文檔，所以沒有文檔留下來，他的代碼沒有人跟蹤，所以質(zhì)量如何根本不知道。我建議的開發(fā)模式圖如下：從上圖中可以看到，每一項工作都是由一個團隊協(xié)同完成的，開發(fā)人員根據(jù)能力資歷的不同在團隊中擔任不同的任務，高級員工和普通員工共同開發(fā)，高級員工可以方便的給與普通員工幫助，促進普通員工成長為高級員工，從而促進團隊成長。軟件的質(zhì)量由團隊的質(zhì)量決定。因為概要設計的輸出就是下一步的需求，所以這種模式不受軟件規(guī)模的限制，當軟件規(guī)模擴大時，可以想象成由子需求形成的一個個小項目逐級開發(fā)。越是高層的概要設計越重要，稱之為架構(gòu)師，微軟最重視的就是架構(gòu)師，據(jù)說微軟有一個架構(gòu)師擁有7部豪華跑車。用人問題得到解決

8、，高級員工把需求分析成開發(fā)需求，在高級員工的幫助下，普通員工可以完成開發(fā)，并在其中成長為高級員工，團隊得到成長。那是不是說，高級員工就不需要作編碼了呢，一些涉及流程控制，模塊間交互的代碼可以由高級員工掌握，這些模塊的開發(fā)模式看上去跟前一種一樣，從頭至尾都由一個人完成，但本質(zhì)是不同的，這屬于高級員工的多角色擔當，對于小型軟件是很普遍的。顯然，高級員工就是一個工作團隊的老大，一項工作是由高級員工帶領一個團隊完成的。代碼版本控制我們當前方式，所有人都往一個Branch里check in代碼，這會造成相互干擾，所以每天檢查regression成為一項繁重的工作。Regression每天都跑，服務器負擔

9、大，Regression的郵件從早到晚幾乎都沒有停過，而且大部分的是Fail的，而檢查這些Fail的工作量大部分是浪費的，因為很可能Fail只是一個人造成的。更好的做法是：開發(fā)人員在一個基準版本的基礎上開發(fā)，隔一段時間做一次整合，生成一個新的基準頒布，開發(fā)人員再更新基準版本，每次集成測試都建立在基準版本上。開發(fā)人員在開發(fā)過程中進行單元測試，保證集成單元的質(zhì)量?；鶞拾姹静皇穷l繁更新，Regression不需要天天跑，沒有更新就不需要跑，QA人員可以把精力用在寫CASE上。這樣，不管是單元測試還是集成測試，都遵循有更新就測試的原則，同意個CASE在同一個代碼上跑一次就行了。嚴格杜絕一個源文件多個人

10、寫的情況發(fā)生，一旦有人操作不當，對工作的干擾很大。事實上，采用上述的分工方式，也不會發(fā)生這種情況。這樣的話，我們需要如下幾個Branch：1 工作Branch，開發(fā)人員在這個Branch里開發(fā)，這個Branch不Make，只是用來保存所有的代碼歷史，不同開發(fā)人員擁有不同的源文件；除了自己擁有的文件外其他的文件可以從基準版本里Link過來或者直接復制在用戶目錄，因為基準版本不是頻繁變更的，所以每次基準版本變更時更新一次就可以了，這就杜絕了因為他人導致的編譯不通過的情況發(fā)生。與他人發(fā)生交互而要更新別人的代碼時，開發(fā)人員協(xié)同完成，這是可控制的。工作人員在開發(fā)時，要進行單元測試，保證單元內(nèi)部的軟件質(zhì)量

11、。2 集成Branch，集成時，由負責人統(tǒng)一將工作Branch中的Code更新到集成Branch中，這個工作沒有難度卻不容出錯，不建議新員工做，這時負責人還可以通過比較工具檢查代碼，對于較小的改動，很少的Coding Review工作非常有價值。集成Branch有了之后，由QA進行集成測試，開發(fā)人員在這個時間集中解決問題。3 集成Branch測試穩(wěn)定之后，生成新的基準版本，發(fā)布，通知所有開發(fā)人員更新基準版本。只有發(fā)生嚴重Bug才需要臨時更新基準版本。另外，使用Label而不是最新版本來獲取代碼，通過Label，可以在CVS里取得以往的所有版本。進行集成時，開發(fā)人員的代碼也是以Label的形式提

12、交的，當開發(fā)人員編碼完成，經(jīng)過充分測試，對代碼標一個Label，然后進入下一階段開發(fā)，集成時就取這個Label，這樣就不影響后續(xù)的開發(fā)，后續(xù)開發(fā)其實不用急于做，不妨等基準發(fā)布之后再做，因為這中間的改動可能性很大，一旦開發(fā)了新的，要進行代碼的差分修改，稍不留神，麻煩很大，欲速則不達。Label的重用作用是記住了歷史，當發(fā)生錯誤了，我們知道在哪個版本上錯了，利于Bug的復現(xiàn)和定位。有的Bug，一看最新的代碼不發(fā)生了，就不了了之了，其實還是被隱藏了。工作環(huán)境文檔化基本上每個公司都有類似的文檔，但質(zhì)量的差別就大了。這些文檔必須具備兩個條件：1 能夠方便的找到文檔的位置2 文檔中可以迅速查到想要的內(nèi)容內(nèi)

13、容當包括日常工作中相關的操作。包括公司服務器網(wǎng)絡配置，軟件位置，工具設置，基本命令。就這么多了。但在這兒我想鄭重地提一下使用中文文檔的事情。我們公司沒有看不懂中文的，而簡體繁體也可以通過Word方便的轉(zhuǎn)換，所以使用中文沒有什么障礙。民族主義和國際化企業(yè)是很虛的，不在此浪費唇舌了，我關注的是效率。首先，人的思維很奇妙，我們還不能做到用英文的方式思維和記憶，所以每一份英文文檔我們都必須先翻譯成中文意思，然后記憶。當記憶模糊需要重新看時，需要再次的翻譯，這就是為什么第二次看同一份英文文檔似曾相識感很弱，而中文文檔第二次看時速度會快很多，因為我們都是用中文來進行記憶和思維的。第二，大家的英文水平差異明

14、顯，幾乎是各說各的英文，造成很大的溝通障礙。用英文寫的人能表達幾成自己的想法，閱讀英文的人又能看懂幾成，兩個折扣一打，文檔溝通能力喪失殆盡。第三，從文字上來說，中文是二維的圖像文字，英文是一維的編碼文字，二維比一維能表達更多的信息，所以中文的閱讀速度是英文所不能比的，聯(lián)合國的每份文檔，中文的那份總是最短的?？梢灶A見，不遠的將來，中文才是通行世界的語言。我們在舍長取短啊。我可以推測，我們之所以選擇了一種錯誤的開發(fā)模式，很大原因是使用英文，因為文檔溝通的障礙，自然地拒絕了文檔，這就自然而然的促成了單人開發(fā)模式，因為這種模式需要最少的文檔。團隊開發(fā)是離不開文檔的。使用中文，是當下公司最容易做到，也是

15、對效率產(chǎn)生最大提高的方法。如果真有英文的必要，找個翻譯都是劃算的，還是分工問題。華為也是跨國公司，開發(fā)團隊不用英文。新人的培訓與成長對小公司，這是個大問題。當前公司分配給新人的工作多少有點趕鴨子上架的意味，這種揠苗助長的方式對新人沒有好處，有的干脆不堪壓力陣亡了，有的養(yǎng)成了做工作一知半解的習慣。開發(fā)人員必須獲得自己的核心，然后在這個基礎上往外擴展，才是健康的成長方式。對于一些告知性的知識，在入職時組織培訓，訓練一下基本操作，告訴他們哪里有文檔可以獲得幫助。新人成長的同時，還要達到解放老員工的目的，這樣才能在開發(fā)團隊體現(xiàn)出層次結(jié)構(gòu)來。一個很好的辦法是讓新人接手老員工開發(fā)的模塊，這個好處很多：1，

16、 讓新人在閱讀代碼中獲得常規(guī)的編程思想，優(yōu)秀的程序員都是讀代碼讀出來的；我們公司新來的幾個員工，讀的代碼很少，他們做事不能讓人放心的。2， 老員工能被解放出來，得到提升；3， 風險可控，新人的流動性強，不用擔心他留下一堆麻煩；4， 老員工方便對新人進行指導也許讀代碼對公司不能創(chuàng)造什么價值，但迫不及待的讓新人開發(fā)，更大的可能是創(chuàng)造負價值。培養(yǎng)出的人才才是公司的人才。新人在掌握一個模塊之后，就像有了一片自己的領地，以后的成長就少了很多迷茫。這樣，我們只要招合格的C語言工程師就可以了，不需要為額外的條件買單。當前該怎么做說了這么多，該從哪里入手呢，很多時候，事情總是容易越來越糟，本來夠忙的，又來了一堆事情，所以應該先從忙碌中削減工作，擠