如何解決軟件研發(fā)團(tuán)隊(duì)管理的問(wèn)題(完整版)
【正文】 題?？偠灾浖邪l(fā)需要文檔（但文檔的形式可以是多種多樣的，用Word寫的文字式的文件是文檔，用Visio畫的UML圖也是文檔，保存在Quality Center中的測(cè)試用例也是文檔），同時(shí)我們只需寫夠用的文檔。在實(shí)踐中，我們可以按以下方法做，在實(shí)現(xiàn)SCRUM的同時(shí)，符合審核和評(píng)估的要求： 制作格式良好的、被細(xì)化的、被保存的和能跟蹤的Backlog。但是，它們的宗旨是一致的，即：構(gòu)建高質(zhì)量的產(chǎn)品。 設(shè)計(jì)思想和代碼只有一個(gè)人了解，此人一旦離職，無(wú)人知道其細(xì)節(jié)。另外，某段提交的代碼出問(wèn)題，提交者和審查者都要一起來(lái)解決出現(xiàn)的問(wèn)題，以最大限度避免審查過(guò)程敷衍了事。 “花合理時(shí)間抓出大多數(shù)Bug”要好過(guò)“窮盡一生抓出所有Bug”。有些老產(chǎn)品，舊代碼，可能沒有或者沒有那么多的單元測(cè)試。從接手人心理的角度看，重構(gòu)還有一個(gè)好的副作用，就是代碼重構(gòu)之后，接手人覺得那些原來(lái)的“爛”代碼被修改成為自己引以自豪的新成就。敏捷開發(fā)中有關(guān)于如何估算生產(chǎn)率的方法。”原來(lái)如此。 有些開發(fā)人員水平相對(duì)不高，如何保證他們的代碼質(zhì)量？ 從這樣一個(gè)問(wèn)題開始，在隨后的交談中，又引出他一連串在軟件研發(fā)管理中的遇到的問(wèn)題，包括：我把我的“套路”再此絮叨絮叨。對(duì)于產(chǎn)品的交付時(shí)間或項(xiàng)目的完成時(shí)間，往往由高級(jí)管理層根據(jù)市場(chǎng)情況決策和確定。這說(shuō)明什么？排除接手人個(gè)人水平的因素，這說(shuō)明舊代碼可讀性、可擴(kuò)展性比較差。3. 重構(gòu)會(huì)造成回退，怎樣避免？重構(gòu)確實(shí)很容易造成回退（Regression）。扮演“程序公敵”，縱容你心智中比較促狹的那一部分，積極思考如何破壞代碼。首先，我們采用的Code Review有2種形式，一是Overtheshoulder，也就是2個(gè)人座在一起，一個(gè)人講，另一個(gè)人審查。5. 軟件研發(fā)到底需不需要文檔？軟件研發(fā)需要文檔的起原可能有2種，一是比較原始的，需要文檔是為了當(dāng)開發(fā)人員離職后，企業(yè)需要接手的人能根據(jù)文檔了解他所接手的代碼或模塊的設(shè)計(jì)。接觸過(guò)敏捷開發(fā)的人都知道《敏捷宣言》中的“可以工作的軟件勝于面面俱到的文檔”。SCRUM之類的敏捷方法也被引入過(guò)那些已通過(guò)CMMI5級(jí)評(píng)估的組織。團(tuán)隊(duì)對(duì)“完成”的定義(Definition of “Done”)可以很容易轉(zhuǎn)變?yōu)橐环輽z查列表。當(dāng)然這里會(huì)牽扯到績(jī)效評(píng)定的問(wèn)題，比如：提供幫助的人會(huì)覺得，他的幫助無(wú)助于自己績(jī)效評(píng)定的提高，為什么要提供幫助。我們的經(jīng)驗(yàn)是，在每年大約3月份為每個(gè)工程師制定整個(gè)年度的目標(biāo)，每個(gè)人的目標(biāo)包括產(chǎn)品上的，技術(shù)上的，個(gè)人能力上的等4到5項(xiàng)。團(tuán)隊(duì)還為了配合其實(shí)現(xiàn)目標(biāo)，組織Tech Talk的活動(dòng)，供大家分享每個(gè)人的學(xué)習(xí)成果。4級(jí)管理類是Manager/Senior Manager，技術(shù)類是Principal/Senior Principal。6級(jí)是Executive Management）。8. 如何提高開發(fā)人員的主觀能
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1