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

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

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

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

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

5、3. 交接，在人事變動(dòng)和工作變更時(shí)，有詳細(xì)設(shè)計(jì)文檔可以方便的交接代碼。打鐵要趁熱，編碼之后要立即進(jìn)行調(diào)試和測(cè)試， 一些明顯的Bug應(yīng)該在這個(gè)階段被發(fā)現(xiàn)。測(cè)試維護(hù)：測(cè)試的核心價(jià)值是發(fā)現(xiàn) Bug,是以寫CASE為主。對(duì)CASE的整理很重要，CASE和需求是相關(guān)的，有必要將 CASE與需求點(diǎn)對(duì)應(yīng)并編寫成 文檔，方便查找，在后續(xù)的修改中，開發(fā)人員可以通過這個(gè)文檔找到相應(yīng)CASE對(duì)修改進(jìn)行驗(yàn)證。很多公司要求在需求確立后編寫測(cè)試計(jì)劃，這聽上去很完美，但如果需求總是變更， 很多工作將被浪費(fèi)，所以我建議在開發(fā)進(jìn)入到一定階段的時(shí)候開始進(jìn)行相關(guān)測(cè)試，因?yàn)檫@個(gè)時(shí)候需求相對(duì)穩(wěn)定，而且符合打鐵趁熱的觀念。寫到這兒，我對(duì)

6、比一下兩種開發(fā)方法，從而說明上述軟件過程的必要性。當(dāng)前公司的開發(fā)模式有點(diǎn)類似于下圖:不同在團(tuán)隊(duì)中擔(dān)任不同的任務(wù)，高級(jí)員工和普通員工共同開發(fā)，高級(jí)員工可以方便的給與普在這種模式里，每一項(xiàng)工作幾乎從頭至尾由一個(gè)人來完成。在這種模式下，人員之間的協(xié)同很少，高級(jí)員工和普通員工在工作性質(zhì)上沒有本質(zhì)差別，由于工作不一樣，高級(jí)員工不方便給與幫助，軟件的質(zhì)量由員工個(gè)人能力決定。由于能力差異，開發(fā)進(jìn)度也很難控制。在這種開發(fā)模式里，看不到開發(fā)團(tuán)隊(duì)的影子。而且，到哪里招能獨(dú)立開發(fā)的人員呢，招人難， 用人難的問題突出。軟件規(guī)模受到限制，CMM認(rèn)為，這種開發(fā)模式的人員極限是十幾個(gè)人，源笙這么些年來，開發(fā)人員規(guī)模一直在十

7、人左右停步不前甚至萎縮，恐怕就是這個(gè)原因。當(dāng)人員離職時(shí)，接手那一部分工作的人恐怕能做的就是祈禱別出問題了。因?yàn)閺念^到尾只有他一個(gè)人知道， 他不需要寫文檔，所以沒有文檔留下來，他的代碼沒有人跟蹤，所以質(zhì)量如何根本不知道。我建議的開發(fā)模式圖如下:工作1工作2工作3從上圖中可以看到,每一項(xiàng)工作都是由一個(gè)團(tuán)隊(duì)協(xié)同完成的，開發(fā)人員根據(jù)能力資歷的通員工幫助，促進(jìn)普通員工成長(zhǎng)為高級(jí)員工，從而促進(jìn)團(tuán)隊(duì)成長(zhǎng)。軟件的質(zhì)量由團(tuán)隊(duì)的質(zhì)量決定。因?yàn)楦乓O(shè)計(jì)的輸出就是下一步的需求，所以這種模式不受軟件規(guī)模的限制，當(dāng)軟件規(guī)模擴(kuò)大時(shí)，可以想象成由子需求形成的一個(gè)個(gè)小項(xiàng)目逐級(jí)開發(fā)。越是高層的概要設(shè)計(jì)越重要，稱之為架構(gòu)師，微軟最

8、重視的就是架構(gòu)師，據(jù)說微軟有一個(gè)架構(gòu)師擁有7部豪華跑車。用人問題得到解決，高級(jí)員工把需求分析成開發(fā)需求，在高級(jí)員工的幫助下，普通員工可以完成開發(fā)，并在其中成長(zhǎng)為高級(jí)員工，團(tuán)隊(duì)得到成長(zhǎng)。那是不是說，高級(jí)員工就不需要作編碼了呢，一些涉及流程控制， 模塊間交互的代碼可以由高級(jí)員工掌握，這些模塊的開發(fā)模式看上去跟前一種一樣，從頭至尾都由一個(gè)人完成， 但本質(zhì)是不同的，這屬于高級(jí)員工的多角色擔(dān)當(dāng)，對(duì)于小型軟件是很普遍的。顯然，高級(jí)員工就是一個(gè)工作團(tuán)隊(duì)的老大，一項(xiàng)工作是由高級(jí)員工帶領(lǐng)一個(gè)團(tuán)隊(duì)完成的。代碼版本控制我們當(dāng)前方式，所有人都往一個(gè)Branch里check in代碼，這會(huì)造成相互干擾，所以每天檢查re

9、gression 成為一項(xiàng)繁重的工作。Regression每天都跑，服務(wù)器負(fù)擔(dān)大，Regression 的郵件從早到晚幾乎都沒有停過，而且大部分的是 Fail的，而檢查這些Fail的工作量大部分是浪費(fèi)的，因?yàn)楹芸赡蹻ail只是一個(gè)人造成的。更好的做法是：開發(fā)人員在一個(gè)基準(zhǔn)版本的基礎(chǔ)上開發(fā)，隔一段時(shí)間做一次整合，生成一個(gè)新的基準(zhǔn)頒布，開發(fā)人員再更新基準(zhǔn)版本，每次集成測(cè)試都建立在基準(zhǔn)版本上。開發(fā)人員在開發(fā)過程中進(jìn)行單元測(cè)試，保證集成單元的質(zhì)量。基準(zhǔn)版本不是頻繁更新，Regression不需要天天跑，沒有更新就不需要跑，QA人員可以把精力用在寫 CASE上。這樣，不管是單元測(cè)試還是集成測(cè)試，都遵循有

10、更新就測(cè)試的原則，同意個(gè)CASE在同一個(gè)代碼上跑一次就行了。嚴(yán)格杜絕一個(gè)源文件多個(gè)人寫的情況發(fā)生，一旦有人操作不當(dāng)，對(duì)工作的干擾很大。事實(shí)上，采用上述的分工方式，也不會(huì)發(fā)生這種情況。這樣的話，我們需要如下幾個(gè)Branch :1. 工作Branch ,開發(fā)人員在這個(gè) Branch里開發(fā)，這個(gè) Branch不Make,只是用來保存所有的代碼歷史，不同開發(fā)人員擁有不同的源文件；除了自己擁有的文件外其他的文件可以從基準(zhǔn)版本里L(fēng)ink過來或者直接復(fù)制在用戶目錄， 因?yàn)榛鶞?zhǔn)版本不是頻繁變更的，所以每次基準(zhǔn)版本變更時(shí)更新一次就可以了，這就杜絕 了因?yàn)樗藢?dǎo)致的編譯不通過的情況發(fā)生。與他人發(fā)生交互而要更新別人

11、的代 碼時(shí)，開發(fā)人員協(xié)同完成，這是可控制的。工作人員在開發(fā)時(shí)，要進(jìn)行單元測(cè) 試，保證單元內(nèi)部的軟件質(zhì)量。2. 集成Branch,集成時(shí)，由負(fù)責(zé)人統(tǒng)一將工作 Branch中的Code更新到集成 Branch 中，這個(gè)工作沒有難度卻不容出錯(cuò)，不建議新員工做，這時(shí)負(fù)責(zé)人還可以通過比較工具檢查代碼，對(duì)于較小的改動(dòng)，很少的Coding Review工作非常有價(jià)值。集成Bran ch有了之后，由QA進(jìn)行集成測(cè)試，開發(fā)人員在這個(gè)時(shí)間集中解決問 題。3. 集成Bran ch測(cè)試穩(wěn)定之后，生成新的基準(zhǔn)版本，發(fā)布，通知所有開發(fā)人員更新基準(zhǔn)版本。只有發(fā)生嚴(yán)重Bug才需要臨時(shí)更新基準(zhǔn)版本。另外，使用Label而不是最

12、新版本來獲取代碼，通過Label，可以在CVS里取得以往的所有版本。進(jìn)行集成時(shí)，開發(fā)人員的代碼也是以Label的形式提交的，當(dāng)開發(fā)人員編碼完成，經(jīng)過充分測(cè)試，對(duì)代碼標(biāo)一個(gè)Label，然后進(jìn)入下一階段開發(fā)，集成時(shí)就取這個(gè)Label，這樣就不影響后續(xù)的開發(fā)，后續(xù)開發(fā)其實(shí)不用急于做，不妨等基準(zhǔn)發(fā)布之后再做，因?yàn)檫@中間的改動(dòng)可能性很大，一旦開發(fā)了新的，要進(jìn)行代碼的差分修改，稍不留神，麻煩很大，欲速 則不達(dá)。Label的重用作用是記住了歷史，當(dāng)發(fā)生錯(cuò)誤了，我們知道在哪個(gè)版本上錯(cuò)了，利 于Bug的復(fù)現(xiàn)和定位。有的 Bug, 看最新的代碼不發(fā)生了，就不了了之了，其實(shí)還是被隱 藏了。工作環(huán)境文檔化基本上每個(gè)公

13、司都有類似的文檔，但質(zhì)量的差別就大了。這些文檔必須具備兩個(gè)條件：1. 能夠方便的找到文檔的位置2. 文檔中可以迅速查到想要的內(nèi)容內(nèi)容當(dāng)包括日常工作中相關(guān)的操作。包括公司服務(wù)器網(wǎng)絡(luò)配置，軟件位置，工具設(shè)置， 基本命令。就這么多了。但在這兒我想鄭重地提一下使用中文文檔的事情。我們公司沒有看不懂中文的，而簡(jiǎn)體繁體也可以通過Word方便的轉(zhuǎn)換，所以使用中文沒有什么障礙。民族主義和國際化企業(yè)是很虛的，不在此浪費(fèi)唇舌了，我關(guān)注的是效率。首先，人的思維很奇妙，我們還不能做到用英文的方式思維和記憶，所以每一份英文文檔我們都必須先翻譯成中文意思，然后記憶。當(dāng)記憶模糊需要重新看時(shí)，需要再次的翻譯， 這就是為什么第

14、二次看同一份英文文檔似曾相識(shí)感很弱，而中文文檔第二次看時(shí)速度會(huì)快很多，因?yàn)槲覀兌际怯弥形膩磉M(jìn)行記憶和思維的。第二，大家的英文水平差異明顯，幾乎是各說各的英文，造成很大的溝通障礙。用英文寫的人能表達(dá)幾成自己的想法，閱讀英文的人又能看懂幾成，兩個(gè)折扣一打，文檔溝通能力喪失殆盡。第三，從文字上來說，中文是二維的圖像文字，英文是一維的編碼文字，二維比一維能 表達(dá)更多的信息，所以中文的閱讀速度是英文所不能比的，聯(lián)合國的每份文檔，中文的那份總是最短的?？梢灶A(yù)見，不遠(yuǎn)的將來，中文才是通行世界的語言。我們?cè)谏衢L(zhǎng)取短啊。我可以推測(cè)，我們之所以選擇了一種錯(cuò)誤的開發(fā)模式， 很大原因是使用英文， 因?yàn)槲臋n 溝通的障礙

15、，自然地拒絕了文檔， 這就自然而然的促成了單人開發(fā)模式， 因?yàn)檫@種模式需要 最少的文檔。團(tuán)隊(duì)開發(fā)是離不開文檔的。使用中文，是當(dāng)下公司最容易做到，也是對(duì)效率產(chǎn)生最大提高的方法。如果真有英文的必要，找個(gè)翻譯都是劃算的，還是分工問題。華為也是跨國公司，開發(fā)團(tuán)隊(duì)不用英文。新人的培訓(xùn)與成長(zhǎng)對(duì)小公司，這是個(gè)大問題。當(dāng)前公司分配給新人的工作多少有點(diǎn)趕鴨子上架的意味，這種揠苗助長(zhǎng)的方式對(duì)新人沒有好處，有的干脆不堪壓力陣亡了， 有的養(yǎng)成了做工作一知半解的習(xí)慣。開發(fā)人員必須獲得自己的核心，然后在這個(gè)基礎(chǔ)上往外擴(kuò)展，才是健康的成長(zhǎng)方式。對(duì)于一些告知性的知識(shí)，在入職時(shí)組織培訓(xùn)，訓(xùn)練一下基本操作，告訴他們哪里有文檔 可

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