Ⅰ 如何做軟體項目管理
可以使用任務管理/項目管理軟體來做項目管理，優勢如下：
WorkLess可量化的任務協作軟體，通過積分來衡量每個任務的任務量、難度和完成質量，最終合理量化每個協作創造的價值是WorkLess的核心思想，詮釋了精準協作創造價值的理念。價格公道實在，適合中小企業或者成長型企業使用。
一、任務管理
1、任務分為四個優先順序，其中A優先順序的任務有時效性考核要求，如超時會根據扣分配置產生連帶（連帶上級）扣分；
2、一個任務的角色包括發布人、執行人、驗收人，其中執行人可以是多人，也可以在任務執行過程中指派新的執行人協作
3、預估任務量是最終驗收獲得積分的重要依據，發布任務時需要客觀評估該任務的任務量，並盡可能精準。
4、任務執行獲得的積分=日基礎分*難度系數*完成質量*任務量，其中難度系數、完成質量由驗收人根據溝通和經驗主觀評定
二、任務的量化評分
1、執行人需悔亮悄要對A類任務特別關注，A類任務超時扣分=扣分日基礎分*超時天數，並產生連帶扣分，扣分日基礎分和連帶層級可設置；
2、執行人交付任務時提交執行任務的耗時，耗時是單獨做該任務所花費的時間，不是時間流逝的長度。耗時是驗收人最終核准任務量的參考；
3、驗收人主觀評定難度系數和完成質量，並根據執行人提交的耗時和發布人填寫的預估任務量最終評定核准任務量，核准鍵大任務量應傾向預估任務量，適當參考執行人耗時，此後分數將自動計算出。
三、項目全局管理
1、項目進度的全局管控，清晰顯示項目包含的任務、動態、文檔、文件和進碧渣展；
2、在線創建項目文檔，多人協作編輯查看；
3、共享項目文檔，並進行動態管理
4、關鍵的項目討論留痕，提升參與者對項目的信息對稱程度
四、通過積分量化任務
積分是執行任務產生成果的量化體現，WorkLess提供積分管理工具，對任務、匯報等成果進行統計，形成積分排名，為團隊管理者提供數據依據。
Ⅱ 軟體項目管理的組織模式
軟體項目可以是一個單獨的開發項目，也可以與產品肢宏棚項目組成一個完整的軟體產品項目。如果是訂單開發，則成立軟體項目組即可；如果是產品開發，需成立軟體項目組和產品項目（負責市場調研和銷售），組成軟體產品項目組。公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟體產品項目組。
3.1、項目管理委員會項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：
（1）依照項目管理相關制度管理項目；
（2）監督項目管理相關制度的執行；
（3）對項目絕旅立項、項目撤消進行決策；
（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.
3.2、項目管理小組項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：
（1）草擬項目管理的各項制度；
（2）組織項目階段評審；
（3）保存項目過程中的相關文件和數據；
（4）為優化項目管理提出建議。
3.3、項目評審小組項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：
（1）對項目可行性報告進行評審；
（2）對市場計劃和階段報告進行評審；
（3）對開發計劃和階段報告進行評審；
（4）項目結束時，對項目總結報告進行評審。
3.4、軟體產品項目組軟體產品項目組對項目管理委員會負責，可下設軟體項目組和產品項目組。軟體項目組和產品項目組分別設開發經理和產品經歷則理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟體開發和市場調研及銷售工作。
Ⅲ 論述軟體項目管理過程中如何開展好配置管理工作
1、在軟體開發的過程中，從設計時就要參與；
2、根據軟體開發計劃，做好配置管理計劃；
3、根據項目人員分配情況，做好項目的許可權控制；
4、及時收集各配置項，確認提交；
5、做好需求變更控制，在項目過程中變更是無法避免，注意變更的回歸測試；
6、產品出入庫的版本要正確；
7、對配置庫做好備份。
Ⅳ 軟體項目管理的配置管理
是否需要進行配置管理與軟體的規模有關，軟體的規模越大，配置管理就顯得越重要。軟體配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟體變更的一種管理。配置管理的使用取決於項目規模和復雜性以及風險水平。
6.1、目前軟體開發中面臨的問題:在有限的時間、資金內，要滿足不斷增長的軟體產品質量要求；開發的環境日益復雜，代碼共享日益困難，需跨越的平台增多；程序的規模越來越大；軟體的重用性需要提高；軟體的維護越來越困難。
6.2、軟體配置管理應提供的功能:
在ISO9000.3中，對配置管理系統的功能作了如下描述：唯一地標識每個軟體項的首慎巧版本；標識共同構成一完整產品的特定版本的每一軟體項的版本；控制由兩個或多個獨立工作的人員同時對一給定軟體項的更新;按要求在一個或多個位置對復雜產品的更新進行協調；標識並跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由於更改請求或問題引起的。
6.3、版本管理軟體配置管理分為孝此版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：
建立項目；
重構任何者鍵修訂版的某一項或某一文件；
利用加鎖技術防止覆蓋； ?當增加一個修訂版時要求輸入變更描述；
提供比較任意兩個修訂版的使用工具；
採用增量存儲方式；
提供對修訂版歷史和鎖定狀態的報告功能；
提供歸並功能；
允許在任何時候重構任何版本；
許可權的設置；
晉升模型的建立；
提供各種報告。
Ⅳ 如何在軟體項目中實施軟體配置管理
1、配置管理員水平很重要。
2、領導要很重視（比如告訴他代碼需要控制不同的許可權，集中保存防止出現各種意外比如離職泄露啊，電腦壞了啊等等，與開發過程相關的就不用說了，他不關心的）。
3、項目經理要很重視，很多項目經理本身是技術出身，可羨告能管理跟的不是那麼上~.~。
4、項目成員有這樣的概念。
以上是前提。
開展配置管理工作的關鍵是讓公司內部的項目干係人的人感覺到配置管理工作在起作用。
最重要的手段：
針對不同的人進行不同層次的培訓。
1、對於老闆/總監/技術老大/項目老大等等所有項目的統籌負責人，可以做一些月度季度年度報表PPT什麼的告訴他你做了什麼。取得了什麼樣的效果。
2、對於項目經理們或者准項目經理們，做配置管理里關於流程方面的培訓（比如配置項管理、基線管理、變更管理、構建管理、版本管理、發布管理、審計管理、外部發布管理等）、然後就是一些配合不同開發模式（比如瀑布、螺旋、敏捷等）進行配置工具培訓、 比如分支開發、自動構建、持續集成等
3、對於普通開發測試等兄此明項目組成員，就是培訓各類工具的使用了比如svn/git/cc等，比如一些好的操作，版本對比、回退機制、代碼共享、同步開發等等。
至於配置管理過程的話，網上一大堆，隨便憑記憶總結下，可能不全：
1、從組織上定義標准流程規范制度等。這個規范制度是用來指導配置管理工作的總規范。包括具體的配置管理簡介、配置管理過程中涉及到的人的權責、然後就是配置管理實施的策略（比如計劃、配置項、基線、變更、發布、審計、報告、伺服器管理、配置工具說明、許可權管理總則、配置庫結構標准、庫備份啊、收尾工作比如移交轉產交付取消許可權刻盤保存等），可能還要定義一個內測版本、外測版本、正式版本號的附則。製作好所有的excel/word/ppt/txt模版。給領導審批通過就OK了。
2、項目開始就後按照組織定義的配置管理流程去做，不斷裁剪修改，不同規模的配置管理工作的需求是不同的，要考慮投入產出是否合理，與項目是否適配。
------------------------------------------
以上所有涉及到和領導扒檔相關的步奏，請考慮你在公司的實際地位和能力水平，有可能你的項目的配置管理工作沒有到這個高度，還只是初級階段，領導都不知道。一般來說成熟的軟體公司、規模比較大配置管理是單獨的。如果你只是某個項目的，沒有那麼高的地位那就只針對本項目的經理和普通成員來操作吧.......~.~
Ⅵ 如何構造軟體企業的配置管理方案
1.1什麼是配置管理
配置管理(ConfigurationManagement)是通過技術或行政手段對軟體產品及其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟體產品的演化過程，確保軟體開發者在軟體生命周期中各個階段都能得到精確的產品配置。
配置管理過程是對處於不斷演化、完善過程中的軟體產品的管理過程。其最終目標是實現軟體產品的完整性、一致性、可控性，使產品極大程度地與用戶需求相吻合。它通過控制、記錄、追蹤對軟體的修改和每個修改生成的軟體組成部件來實現對軟體產品的管理功能。
1.2配置管理在軟體開發過程和項目管理過程中的作用
隨著軟體系統的日益復雜化和用戶需求、軟體更新的頻繁化，配置管理逐漸成為軟體生命周期中的重要控制過程，在軟體開發過程中扮演著越來越來重要的角色。一個好的配置管理過程能覆蓋軟體開發和維護的各個方面，同時對軟體開過程的宏觀管理，即項目管理，也有重要的支持作用。良好的配置管理能使軟體開發過程有更好的可預測性，使軟體系統具有可重復性，使用戶和主管部門用軟體質量和開發小組有更強的信心。
軟體配置管理的最終目標是管理軟體產品。由於軟體產品是在用戶不斷變化的需求驅動下不斷變化，為了保證對產品有效地進行控制和追蹤，配置管理過程不能僅僅對靜態的、成形的產品進行管理，而必須對動態的、成長的產品進行管理。由此可見，配置管理同軟體開發過程緊密相關。配置管理必須畢殲緊扣軟體開發過程的各個環節：管理用戶所提出的需求，監控其實施，確保用戶需求最終落實到產品的各個版本中去，並在產品發行和用戶支持等方面提供幫助，響應用戶新的需求，推動新的開發周期。通過配置管理過程的控制，用戶對軟體產品的需求如同普通產品的訂單一樣，遵循一個嚴格的流程，經過一條受控的生產流水線，最後形成產品，發售給相應用戶。從另一個角度看，在產品開發的不同階段通常有不漏數衡同的任務，由不同的角色擔當，各個角色職責明確，涇渭分明，但同時又前後銜接，相互協調。好的配置管理過程有助於規范各個角色的行為，同時又為角色之間的任務傳遞提供無縫的接合，使整個開發團隊象一個交響樂隊一樣和諧而又錯雜地行進。
正因為配置管理過程直接連接產品開發過程、開發人員和最終產品，這些都是項目主管人員所關注的重點，因此配置管理系統在軟體項目管理中也起著重要。配置管理過程演化出的控制、報告功能可幫助項目經理更好地了解項目的進度、開發人員的負荷、工作效率和產品質量狀況、交付日期等信息。同時配置管理過程所規范的工作流程和明確的分工有利於管理者應付開發人員流動的困境，使新的成員可以快速實現任務交接，盡量減少因人員流動而造成的損失。
返做1.3配置管理方案的構成
配置管理過程對軟體開發有如此重要的影響，它的構造、實施過程也必定相當復雜。不藉助工具，純粹靠手工方式或只利用簡單的工具來實現配置管理是很難做到滿意程度的，而且其中的繁瑣龐雜最終必定讓管理者一愁莫展。因此，實現配置管理過程的通常做法是藉助於專業化的配置管理工具，結合開發組織的實際情況制訂出相應的配置管理規范，由開發人員在工作過程中依據規范，通過配置管理工具來實現。在這整個過程中，由配置管理工具負責那些非智能的、可自動化的管理過程，如身份角色驗證、修改軌跡記錄、版本控制等；由配置管理規范來控制那些需要開發人員用智力去判斷的因素，如需求合理性和優先順序判定、任務分工、產品的結構定義、版本發行方案確定等等。配置管理工具的採用和配置管理規范的制訂是緊密聯系的，二者構成了一個軟體開發機構的整體配置管理方案。這種方案是因組織的差異和配置管理工具的差異而變化的。構造一個配置管理方案涉及到軟體開發組織和開發過程的各個方面，是一個復雜的工程應該當作一個項目來做。本文試圖給出一個構造配置管理方案的基本策略和主要步驟。
2組建配置管理方案構造小組
構造或完善一個軟體開發組織的配置管理過程需要在構造初期花費較大的人力物力。這種工作一般是由一個臨時組成的軟體配置管理過程構造小組來完成。這個小組負責構造配置管理過程中的所有工作，包括了解本組織的現有開發、管理現狀，選擇配置管理工具，制訂配置管理規范，安排試驗項目的實施，溝通部門間關系，獲得管理者支持和開發人員的認同。
配置管理過程構造小組的成員應該包括：
小組負責人
其對整個構造過程負責。主要職責是協調與其它部門或與上級主管的關系，監督工作進程，協調小組內部關系。
技術支持專家
其負責在技術、設備方面為本組提供支持和服務，並負責本同其它部門就技術問題進行聯絡，如了解相關項目情況、開發環境、開發人員狀況等。
配置管理技術專家
其對配置管理過程的構造和配置管理工具十分熟悉。主要任務是指導配置管理過程的構造，幫助制訂配置管理規章，負責對開發人員進行配置管理工具的培訓。通常是配置管理工具提供商或專門的配置管理顧問機構的人員擔當此任。
配置管理系統用戶代表
他們是從將來要在實際的項目開發過程中使用該系統、遵照該過程的開發人員中挑選出來的。他們負責從構造初期了解配置管理系統和規程，根據開發經驗協助制訂、修改配置管理規程，並在試驗項目中擔任部分開發角色。這部分成員應包括軟體開發項目經理、設計人員、編碼、測試和構造、發布人員。
該項目小組成立後，將按後述步驟開展配置管理過程的構造工作。
3對目標機構進行了解、評估
「知已知彼，百戰不殆」。配置管理過程的構造過程也是如此，必須對相互作用的雙方都有較透徹的了解才能達到預期的效果。因此首先要做的事情是調查了解，既要了解目標機構（即將要採用該配置管理過程的軟體開發組織）的情況，又要了解配置管理工具的情況。
目標機構的調查評估工作由配置管理技術專家領導，配置管理系統用戶代表參與，提供基本信息，並由小組負責人協調，對相關部門人員進行深入調查獲得較全面的數據。
對目標機構的了解、評估應從這幾個方面入手：人員、技術、工作流程、現有項目和期望值。
3.1人員評估
人員評估的目的是了解目標機構的員工對現有配置管理過程的評價和對採用新工具、制訂新規范的態度，預測新的配置管理過程構造中的工作難點和可能遇到的阻力。調查的方麵包括：
該組織員工對引入新工具的反應，以前是否有過類似的償試。
該組織負責人對新工具、新流程的支持程度。
開發人員的素質、教育程度、溝通能力。
開發隊伍的穩定性。
該組織的溝通渠道是否通暢。
3.2技術評估
對目標機構技術方面的的調查、評估將直接導致對工具的選擇。要了解的信息有：
目標機構有哪些可用的計算資源。
在什麼軟硬體平台上進行開發。
是否存在資源瓶頸，是什麼。
現用什麼開發工具，用戶對該工具評價如何。
現用什麼網路環境。
使用什麼編程語言。
目標平台是否與開發平台一致。
代碼更新程度如何，新編代碼、重用代碼和歷史代碼各占什麼比例。
3.3現有流程評估
對目標組織現有工作流程的評估直接影響新的配置管理流程和規章的制訂。調查的方面是：
現有流程的成熟性、適用性和執行情況。
現有流程是否能進一步提高自動化程度。
現用什麼開發模型。
對分析、設計、編碼、測試、產品管理等過程是否有嚴格的成文規范，如何保證該規范的執行。
開發流程中的哪些質量控制信息被收集，如何使用。
3.4項目評估
配置管理系統對正在開發的產品、正在進行的項目有直接的影響，因此對即將納入管理的項目應有充分的了解。了解的方面有：
項目的平均工期（人月）。
項目的組織方式，是主程序員制還是開發小組制，按深度結構還是按廣度結構組織。
項目的產品規模（功能模塊數、源碼行數）。
項目開發支持狀況，是否有專門的開發環境、開發工具和配置管理等方面的支持人員。
3.5期望值評估
對目標機構的開發、管理人員對新系統的期望值的了解有利於對症下葯，解決其當前緊要問題，提高對新系統的信心。調查的方麵包括：
對當前本組織的生產率和產品質量的滿意程度，期望有怎樣的提高。
對現有流程的評價，現有流程中哪個環節希望改進或加強。
期望增減哪些文檔或規則。
期望等到什麼樣的通信交流方式，現有方式的優缺點是什麼。
期望收集哪些新的開發度量數據或簡化哪些數據。