<ruby id="rxdll"></ruby><strike id="rxdll"></strike>

    <rp id="rxdll"></rp>
      <del id="rxdll"><meter id="rxdll"></meter></del>
      <pre id="rxdll"><font id="rxdll"></font></pre>
        <pre id="rxdll"></pre>
      <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

      <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
      <i id="rxdll"><dfn id="rxdll"></dfn></i>
      <font id="rxdll"><meter id="rxdll"></meter></font>

        <mark id="rxdll"><dfn id="rxdll"></dfn></mark>
        • 軟件測試技術
        • 軟件測試博客
        • 軟件測試視頻
        • 開源軟件測試技術
        • 軟件測試論壇
        • 軟件測試沙龍
        • 軟件測試資料下載
        • 軟件測試雜志
        • 軟件測試人才招聘
          暫時沒有公告

        字號: | 推薦給好友 上一篇 | 下一篇

        異議《淺析軟件項目管理中的10個誤區》

        發布: 2008-9-02 10:13 | 作者: 不詳 | 來源: 測試時代采編 | 查看: 46次 | 進入軟件測試論壇討論

        領測軟件測試網
        關鍵字:軟件項目管理 誤區

         7月3日天極網登載了一篇題為《淺析軟件項目管理中的10個誤區》(以下簡稱《誤區》)文章,閱后對作者的觀點有些異見,在此提出希共同交流。

          筆者大體認同的觀點是:[誤區5]中關于白盒法測試可由程序員擔當--因為程序員對程序的設計思路最熟悉,對可能引發錯誤的地方最為清楚,所以他們能制作出最快、最準的測試用例,所以由程序員完成部分"白盒法"測試是可行的、于提高效率/質量有益的;[誤區8]中項目經理不一定是所有項目成員中薪水最高的--如果項目經理只執行管理性質的工作,對項目不形成建設性成果,在項目組中,除了文秘人員外,項目經理的薪資甚至可以是最低的。

          作者所謂的誤區3是:軟件程序主要由代碼組成,因此編碼階段是整個軟件項目的最重要的階段,應該給與大量的時間,并且集中主要的資源。--意即編碼并不是主要的工作,分析、設計與測試才是主要工作,并提出了一個"資源的合理分配比例":項目論證、風險評估階段3% ,項目需求分析階段8%,系統總體/詳細設計階段45%,編碼階段10%,系統測試階段34%。

          一般都看得到,軟件程序由代碼組成,代碼是軟件的實體。沒有代碼,再多、再完善的分析、設計、測試都是空洞/無意義的。在一定的技術水平條件下,系統中要編寫的代碼量是客觀性質的,是硬性的工作量,不會因設計的不同而有太大的區別--除非一個外行、生手才可能堆砌大量冗余代碼。分析、設計、測試則是可主觀控制的,是柔性的工作量。好比收割一畝麥田,工作量是確定的--一畝麥田,工作方法是可以多樣的,如一個人干、十個人干、用鐮刀、用收割機;為完成該工作,也需要分析設計:如根據麥田的形狀設計收割路線,以減少行走的距離,工作時休息幾次、在何處休息,以使勞動者保持最佳舒適狀態等等;為完成該麥田的收割,分析、設計的比重可以很小,小到可以為1%,總的工作量就是101%,工作的過程可能是勞動者苦一點、累一點;分析、設計的比重也可以很大,大到10000%,總的工作量就變為10100%,工作的有效成績同樣是完成一畝麥田的收割,只是工作的過程可能是勞動者感覺非常舒服。軟件開發也是一樣。同樣的系統,其代碼工作量是確定的,假設為100個人月。公司甲的開發方式中,資源分配比例是:論證1%、分析5%、設計9、編碼70%、測試15%,公司甲對該項目的總開發成本是:100個人月/70%=約為143個人月。公司乙的開發方式中,資源分配比例是:論證3%、分析8%、設計45、編碼10%、測試34%,公司乙對該項目的總開發成本是:100個人月/10%=約1000個人月。如果是競標項目,顯然公司甲更有獲勝機會;如果是公司自身的項目,則公司甲的特點為:速度更快、成本更低,公司乙的特點為:工作流程更清晰、員工工作強度更低。實際中系統開發各部分的資源分配比例應如何,并無先天的規則,主要根據企業自身資金實力、企業文化、企業形象、員工福利待遇、及市場競爭等來定,特別地,不一定投入的成本越大,系統就能做得越好!

          作者所謂的誤區6是:軟件項目管理只是相關技術部門的事情,與公司其他部門無關。意即軟件項目管理需要提高公司的整體參與意識,需要公司各個部門協同作戰。殊不知道,公司設立專門的項目管理團隊,就是為了能盡可能由該團隊獨立地解決掉項目過程中的各種問題,不要仍然象沒有獨立管理團隊時一樣,碰到一個問題時動不動就吆五喝六,把公司各部門的人都攪動起來,影響/牽制公司的全局工作。一個優秀的項目管理者,只有在非常必要時,才會去請求其他部門的協助--他首先會盡可能在項目團隊內解決問題。

          作者所謂的誤區7是:在開發進度滯后的情況下,可以聘請更多的程序員加入到開發團隊中,通過增加人力資源來趕上進度。意即項目進行過程中,新人的加入不一定是有益的,可能會"好心好意做壞事",因為引導新人融入團隊需要花費開發團隊許多時間和精力,很有可能使項目進度更慢。其實作者的這一觀點筆者也是認同的,只是作者文章前后的說法有點自相矛盾。作者貶見的是"作坊式"的軟件管理,褒見的是"軟件工廠式"管理、軟件工程方法。按照軟件工程規范來進行項目管理,各種文檔、流程必然是相當規范的,而且軟件工程化的主要目的之一也是要使項目不依賴于個人、能持續進行,即如此,新人加入時、融入團隊時自然不應該存在什么困難!作者的矛盾,大概是理論與實際無法統一帶來的尷尬。

          作者所謂的誤區8是:技術骨干應該成為項目的項目經理。意即在"軟件作坊"時代,這是一種普遍使用而且效果不錯的方法;而在"軟件工廠"時代,這種方法卻帶來各種問題,有時甚至直接導致項目失敗。軟件項目不同于建筑項目,建筑項目中,絕大部分工作都是明確的,可明確分配給工人去做的,建筑項目管理中主要的問題是組織、領導、協調的問題,它確實不必需要建筑技術專才來管理;而軟件項目中,大部分工作是不能簡單描述清楚的,也不是簡單地分配下去了就能被完成的,首先工作任務如何劃分就需要技術能手才能作出,每一個任務可安排給團隊中誰來做,也需要技術能手才能把握得準確,雖然不是必須的,但用技術骨干擔當項目經理,更能保證項目組的工作效率、更能保證項目的成功。單從項目組效率上講,技術骨干型項目經理帶領的團隊能保證90%以上的效率,而非技術型項目經理帶領的團隊大約只能保證40%--60%的效率。因為項目管理中還有不少人際交流上的問題,所以為技術骨干型項目經理配一個善于協調的助手/秘書,則更是一種黃金組合。
        以上僅為筆者的一些淺見,歡迎指教。

        延伸閱讀

        文章來源于領測軟件測試網 http://www.k11sc111.com/

        TAG: 淺析 軟件 誤區 項目管理 異議


        關于領測軟件測試網 | 領測軟件測試網合作伙伴 | 廣告服務 | 投稿指南 | 聯系我們 | 網站地圖 | 友情鏈接
        版權所有(C) 2003-2010 TestAge(領測軟件測試網)|領測國際科技(北京)有限公司|軟件測試工程師培訓網 All Rights Reserved
        北京市海淀區中關村南大街9號北京理工科技大廈1402室 京ICP備10010545號-5
        技術支持和業務聯系:info@testage.com.cn 電話:010-51297073

        軟件測試 | 領測國際ISTQBISTQB官網TMMiTMMi認證國際軟件測試工程師認證領測軟件測試網

        国产女主播精品_国产片婬乱18一级毛片视频_国产午夜激无码av毛片不卡_国产精品欧美久久久天天影院
          <ruby id="rxdll"></ruby><strike id="rxdll"></strike>

          <rp id="rxdll"></rp>
            <del id="rxdll"><meter id="rxdll"></meter></del>
            <pre id="rxdll"><font id="rxdll"></font></pre>
              <pre id="rxdll"></pre>
            <p id="rxdll"><thead id="rxdll"></thead></p><dl id="rxdll"><progress id="rxdll"><form id="rxdll"></form></progress></dl>

            <ol id="rxdll"><thead id="rxdll"><track id="rxdll"></track></thead></ol>
            <i id="rxdll"><dfn id="rxdll"></dfn></i>
            <font id="rxdll"><meter id="rxdll"></meter></font>

              <mark id="rxdll"><dfn id="rxdll"></dfn></mark>