軟件項目管理面試題范圍、時間，成本，這三項中哪些是可以由客戶控制的？范圍、時間、成本，是項目管理中常說的三角關系。任何一方改變都可能牽扯到其他兩方的變動。項目管理的本質，就是在保證質量的前提下，尋求這三者之間的最佳平衡。因為客戶是需求方和投資方，客戶有權對這三者進行控制，當然客戶主要控制范圍，即提出他們的需求——項目要實現的功能特性，其次，客戶也非常關心能交付的時間和所付出的成本。在滿足客戶的需求情況下，可以在時間、成本上和客戶進行交流、談判。從項目管理的角度看，最好固定其中一項，其他兩項可以根據實際狀況來調節保證項目質量。誰該對項目中所要付出的一切做出估算？誰有權設置最后期限？項目成功是團隊協作的結果。在對項目進行估算的時候，需要由參與項目各個環節的人進行符合實際的估算，最后匯總起來進行綜合分析計算，獲得項目總的估算結果。項目的最后期限設置除了客戶定死最后交付時間，其他的情況都是根據項目的進度估算結果而進行符合實際的計劃得出的。減少交付的次數，或是減少每個每個交付中的工作量，你喜歡哪種做法？根據項目的類型和項目進行中的實際情況來決定，如果項目是規模比較大，時間長的，那么就應增加交付次數或者減少每個每個交付中的工作量，以便及時考察項目進展，保證項目進度。例如，一個項目按計劃進行到第一個里程碑發現項目進度明顯落后，而下一個檢查點（也就是交付的工作量）距離還很長管理層需要及時了解其進展，那么交付的次數的就要根據現在的時間狀況來增加。反過來，如果這個項目的進度非常好，甚至超前，而下一個檢查點（也就是交付的工作量）距離還很短，我們就可以減少交付次數。在傳統的軟件項目中，開發周期比較長，往往減少交付的次數，更好地控制質量；而現在，有一部分公司比較傾向于敏捷方法，喜歡減少每個交付中的工作量，交付周期只有幾周時間（最短的周期，可能是一周），擁抱變化，更好地、更及時地滿足用戶的需求。而對互聯網上的web應用軟件開發，“減少每個每個交付中的工作量”是一個比較好的策略，力求及時獲得用戶的反饋，將用戶的需求及時融入新的版本，及時發布出去，贏得競爭市場。例如，在我新書《軟件工程導論》中專門有一節討論“永遠的Beta”的軟件工程思想。你喜歡用哪種圖來跟蹤項目進度？還是要根據項目的特點來決定，具體項目具體對待，當然，有時也不能由自己決定，而是取決于公司已有的工具和習慣。對于復雜、規模大的項目，可能要借助甘特圖和網絡圖來分析和跟蹤進度。簡單、規模小的項目根據進度報告百分比和表格跟蹤就可以了。迭代和增量的區別在哪里？軟件開發不是一躇而就，其過程猶如雕琢一件工藝品，由無形到有形、由粗到細，很難一次就能開發出功能完善、強大的一個版本，而往往是分階段進行，一個版本接一個版本的發布出去。軟件開發分階段可以通過兩種模型來描述，即增量模型和迭代模型。增量模型描述軟件產品的不同階段是按產品所具有的功能進行劃分，先開發主要功能或用戶最需要功能，然后，隨著時間推進，不斷增加新的輔助功能或次要功能，最終開發出一個強大的、功能完善的、高質量的、穩定的產品。迭代模型描述軟件產品的不同階段是按產品深度或細化的程度來劃分，先將產品的整個框架都建立起來，在系統的初期，已經具有用戶所需求的全部功能。然后，隨著時間推進，不斷細化已有的功能或完善已有功能，這個過程好像是一個迭代的過程。最終的目標是一致的，也是為了實現一個強大的、功能完善的、高質量的、穩定的產品。舉一個例子：假設現在要開發A，B，C，D四個大的業務功能，每個功能都需要開發兩周的時間.則對于增量方法而言可以將四個功能分為兩次增量來完成，第一個增量完成A，B功能，第二次增量完成C，D功能；而對于迭代開發來將則是分兩次迭代來開發，第一次迭代完成A，B，C，D四個基本業務功能但不含復雜的業務邏輯，而第二個功能再逐漸細化補充完整相關的業務邏輯.在第一個月過去后采用增量開始時候A，B全部開發完成而C，D還一點都沒有動；而采用迭代開發的時候A，B，C，D四個的基礎功能都已經完成.試著解釋一下風險管理中用到的實踐。風險該如何管理？風險管理的實踐很多，包括頭腦風暴、風險列表(checklist)等。例如，人們常采用十大風險清單：在項目進行中，不時地更新和處理項目當前風險最高的前十項風險，以保證項目不脫離主軌道。因為項目中的風險大大小小會很多。十大風險清單就是抓住重要的風險及時處理，而又關系的小風險可能也就隨之消失。從這里可以看出，風險也是動態的，需要經常地、及時地評估當前的風險，例如每周或每兩周進行一次風險評估。風險管理就是通過風險的識別、預測、估算和衡量、選擇有效的方法和手段，對風險進行預防、避免、降低或者轉移的管理過程。你喜歡任務分解還是滾動式計劃？根據項目特點來定，一般會選用任務分解的計劃，責任清楚，可控性更強。滾動式計劃的靈活性比較強，適應性比較好，但容易引起大家對計劃不夠重視，計劃能力降低，或者可控性會差些。有時會將這兩種方法結合起來使用。你需要哪些東西幫助你判斷項目是否符合時間要求，在預算范圍內運作？前提是這個項目的進度計劃和成本計劃是符合項目實際情況并不斷隨著項目的時間發展而滾動更新的。確保收集的進度和花費的成本就真實可靠的。在此時項目的范圍沒有影響到時間和成本的規劃。那么就可以根據項目時間與計劃的內容進行對比來判斷項目符合時間要求，在預算范圍內運作。常用的方法有基線對比法和掙值法。DSDM、Prince2、Scrum，這三者之間有哪些區別？動態系統開發方法(DynamicSystemDevelopmentmethod，DSDM)是眾多敏捷開發方法中的一種，它倡導以業務為核心，快速而有效地進行系統開發。該方法的詳細內容，可以參考：DSDM業務中心框架開發方法(第二版)。這種方法主要是在英國應用比較廣泛。一般來說，敏捷方法適合于規模比較小、變化比較快(需求不夠穩定)的項目，而對大規模軟件，特別是在關鍵性、可靠性、安全性方面有很高要求的開發項目，則不適合。當然，可以在某些項目小組內實施；也是可以的。敏捷開發的方法很多，包括下面所說的Scrum、自適應軟件開發(AdaptiveSoftwareDevelopment，ASD)、Crystal方法和特性驅動開發(Feature-DrivenDevelopment，FDD)，可以參考《敏捷軟件開發生態系統》。PRINCE2(PRojectsINControlledEnvironments2)為項目管理提供了一種結構化的方法，這種方法最早是在1989年由英國政府計算機和電信中心（。CTA）開發的，作為英國政府IT項目管理的標準。PRINCE2如今日益流行，是英國項目管理的標準，它為管理項目提供清晰界定工作框架，介紹如何協調項目中的人和活動、如何設計和監督項目以及在項目發生變更的情況下如何調整的流程。每一個流程都詳細標出關鍵的輸入、輸出和具體目標及要執行的活動，這為計劃偏差提供了自發的控制。這種方法把項目劃分為多個管理階段，保證讓所有資源得到有效的控制。依靠嚴格的監控，項目在控制和組織的方式下得到執行。Scrum是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發。Scrum在英語的意思是橄欖球里的爭球。Scrum是一個包括了一系列實踐和預定義角色的過程骨架，其主要角色包括同項目經理類似的Scrum主管角色一一負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。在每一次沖刺（一般為15到30天周期），開發團隊創建可用的、可隨時推出的軟件一個增量（小版本）。每一個沖刺所要實現的特性來自產品訂單（productbacklog），產品訂單是按照優先級排列的工作需求。在沖刺的過程中，沒有人能夠變更沖刺訂單（sprintbacklog），這意味著在一個沖刺中需求是被凍結的。管理Scrum過程有很多實施方法，從白板上的即時貼到軟件包。Scrum最大的好處是它非常容易學習，而且應用Scrum不需要太多的投入。方法的應用，同樣由項目規模、業務特點（需求是否穩定）等決定，而且還受企業文化、流程和領導意識等決定。如果需求穩定、項目規模比較大或周期比較長，一般會選用PRINCE2，相反，可能會選擇DSDM或Scrum，后兩者沒有本質區別，只是具有不同的最佳實踐。正如有人評論，國內對Scrum還比較熟悉，對DSDM、PRINCE2等不夠熟悉，應用不多。而業界最熟悉的是CMMI、RUP（IBMRationalUnifyProcess統一過程）、XP（敏捷方法的極限編程extremeProgramming）和MSF（MicrosoftSolutionFramework，微軟公司軟件開發解決方案框架），可參考：軟件開發過程（CMMI/RUP/XP/MSF）是與非10.如果客戶想要的東西太多，你在范圍和時間上怎樣跟他達成一致呢？首先要向客戶說明，如果在某個時間內去做不可能完成的工作，其結果必然是質量得不到保證，或者所化的成本過大。應該沒有客戶想做賠本的生意，每個客戶都會重視質量，而不愿意損害自己的利益。然后，和客戶一起，按需求重