成功項目管理的秘密

1、.：.；勝利工程管理的1. 定義工程勝利的規(guī)范 在工程的開場，要保證風(fēng)險承當(dāng)者對于他們?nèi)绾闻袆e工程能否勝利有一致的認(rèn)識。經(jīng)常，滿足一個預(yù)定義的進(jìn)度安排是獨一明顯的勝利要素，但是一定還有其它的要素存在，比如：添加市場占有率，獲得指定的銷售量或銷售額，獲得特定用戶稱心程度，淘汰一個高維護(hù)需求的遺留系統(tǒng)，獲得一個特定的事務(wù)處置量并保證正確性。 2. 識別工程的驅(qū)動、約束和自在程度 每個工程都需求平衡它的功能性，人員，預(yù)算，進(jìn)度和質(zhì)量目的。我們把以上五個工程方面中的每一個方面，要么定義成一個約束，他必需在這個約束中進(jìn)展操作，要么定義成與工程勝利對應(yīng)的驅(qū)動，或者定義成通向勝利的自在程度，他可以在一個規(guī)定

2、的范圍內(nèi)調(diào)整。相關(guān)的詳細(xì)信息，請參照我的Creating a Software Engineering CultureDorset House, 1996中的第二章。 3. 定義產(chǎn)品發(fā)布規(guī)范 在工程早期，要決議用什么規(guī)范來確定產(chǎn)品能否預(yù)備好發(fā)布了。他可以把發(fā)布規(guī)范基于：還存在有多少個高優(yōu)先級的缺陷，性能度量，特定功能完全可操作，或其它方面闡明工程曾經(jīng)到達(dá)了它的目的。不論他選擇了什么規(guī)范，都應(yīng)該是可實現(xiàn)的、可丈量的、文檔化的，并且與他的客戶指的“質(zhì)量一致。 4. 溝通承諾 雖然有承諾不能夠事件的壓力，從不作一個他知道他不能保證的承諾。和客戶和管理人員溝通哪些可以實踐獲得時，要有好的信譽。他的任何

3、以前工程的數(shù)據(jù)會協(xié)助 他作壓服的論據(jù)，雖然這對于不講道理的人來說沒有任何真正的防御作用。 5. 寫一個方案 有些人以為，花時間寫方案還不如花時間寫代碼，但是我不這么以為。困難的部分不是寫方案。困難的部分是作這個方案-思索，溝通，權(quán)衡，交流，提問并且傾聽。他用來分析處理問題需求破費的時間，會減少工程以后會帶給他的不測。 6. 把義務(wù)分解成英寸大小的小圓石 英寸大小的小圓石是減少了的里程碑。把大義務(wù)分解成多個小義務(wù)，協(xié)助 他更加準(zhǔn)確的估計它們，暴顯露在其它情況下他能夠沒有想到的任務(wù)活動，并且保證更加準(zhǔn)確、細(xì)密的形狀跟蹤。 7. 為通用的大義務(wù)開發(fā)方案任務(wù)表 假設(shè)他的組經(jīng)常承當(dāng)某種特定的通用義務(wù)，照

4、實現(xiàn)一個新的對象類，他需求為這些義務(wù)開發(fā)一個活動檢查列表和方案任務(wù)表。每個檢查列表應(yīng)該包括這個大義務(wù)能夠需求的一切步驟。這些檢查列表和任務(wù)表將協(xié)助 小組成員確定和評價與他/她必需處置的大義務(wù)的每個實例相關(guān)的任務(wù)量。 8. 方案中，在質(zhì)量控制活動后應(yīng)該有修正任務(wù) 幾乎一切的質(zhì)量控制活動，如測試和技術(shù)評審，都會發(fā)現(xiàn)缺陷或其它提高的能夠。他的工程進(jìn)度或任務(wù)細(xì)分構(gòu)造，應(yīng)該把每次質(zhì)量控制活動后的修正，作為一個單獨的義務(wù)包括進(jìn)去。假設(shè)他現(xiàn)實上不用作任何的修正，很好，他曾經(jīng)走在了本義務(wù)的方案前面。但是不要去指望它。 9. 為過程改良安排時間 他的小組成員曾經(jīng)淹沒在他們當(dāng)前的工程中，但是假設(shè)他想把他的組提升到

5、一個更高的軟件工程才干程度，他就必需投資一些時間在過程改良上。從他的工程進(jìn)度中留出一些時間，由于軟件工程活動應(yīng)該包括做可以協(xié)助 他下一個工程更加勝利的過程改良。不要把他工程成員可以利用的時間100的投入到工程義務(wù)中，然后詫異于為什么他們在自動提高方面沒有任何進(jìn)展。 10. 管理工程的風(fēng)險 假設(shè)他不去識別和控制風(fēng)險，那么它們會控制他。在工程方案時花一些時間集體討論能夠的風(fēng)險要素，評價它們的潛在危害，并且決議他如何減輕或預(yù)防它們。要一個軟件風(fēng)險管理的簡要的指南，參見我的文章“Know Your Enemy: Software Risk ManagementOct. 1998。 11. 根據(jù)任務(wù)方案

6、而不是日歷來作估計 人們通常以日歷時間作估計，但是我傾向于估計與義務(wù)相關(guān)聯(lián)的任務(wù)方案以人時為單位的數(shù)量，然后把任務(wù)方案轉(zhuǎn)換為日歷時間的估計。這個轉(zhuǎn)換基于每天我有多少有效的小時破費在工程義務(wù)上，我能夠碰到的任何打斷或突發(fā)調(diào)整懇求，會議，和一切其它會讓時間消逝的地方。 12. 不要為人員安排超越他們80的時間 跟蹤他的組員每周實踐破費在工程指定任務(wù)的平均小時數(shù)，真實會讓人吃驚。與我們被要求做的許多活動相關(guān)的義務(wù)切換的開銷，顯著地降低了我們的任務(wù)效率。不要只是由于有人在一項特定任務(wù)上每周破費10小時，就去假設(shè)他或她可以馬上做4個這種義務(wù)，假設(shè)他或她可以處置完3個義務(wù)，他就很僥幸了。 13. 將培訓(xùn)時

7、間放到方案中 確定他的組員每年在培訓(xùn)上破費多少時間，并把它從組員任務(wù)在指定工程義務(wù)上的可用時間中減去。他能夠在平均值中早曾經(jīng)減去了休假時間、生病時間和其它的時間，對于培訓(xùn)時間也要同樣的處置。 14. 記錄他的估算和他是如何到達(dá)估算的 當(dāng)他預(yù)備估算他的任務(wù)時，把它們記錄下來，并且記錄他是如何完成每個義務(wù)的。了解創(chuàng)建估算所用的假設(shè)和方法，可以使它們在必要的時候更容易防護(hù)和調(diào)整，而且它將協(xié)助 他改善他的估算過程。 15. 記錄估算并且運用估算工具 有很多商業(yè)工具可以協(xié)助 他估算整個工程。根據(jù)它們真實工程閱歷的宏大數(shù)據(jù)庫，這些工具可以給他一個能夠的進(jìn)度和人員分配安排選擇。它們同樣可以協(xié)助 他防止進(jìn)入“

8、不能夠區(qū)域，即產(chǎn)品大小，小組大小和進(jìn)度安排組合起來沒有知工程勝利的情況。Software Productivity Centre(spc.ca)公司的Estimate Pro是可以一試的好工具。 16. 遵守學(xué)習(xí)曲線 假設(shè)他在工程中第一次嘗試新的過程，工具或技術(shù)，他必需認(rèn)可付出短期內(nèi)消費力降低的代價。不要期望在新軟件工程方法的第一次嘗試中就獲得驚人的效益，在進(jìn)度安排中思索不可防止的學(xué)習(xí)曲線。 17. 思索不測緩沖 事情不會象他工程方案的一樣準(zhǔn)確的進(jìn)展，所以他的預(yù)算和進(jìn)度安排應(yīng)該在主要階段后面包括一些不測的緩沖，以順應(yīng)無法預(yù)料的事件。不幸的是，他的管理者或客戶能夠把這些緩沖作為填料，而不是明智的

9、成認(rèn)現(xiàn)實確實如此。指明一些以前工程不愉快的不測，來闡明他的深謀遠(yuǎn)慮。 18. 記錄實踐情況與估算情況 假設(shè)他不記錄破費在每項義務(wù)上的實踐任務(wù)時間，并和他的估算作比較，他將永遠(yuǎn)不能提高他的估算才干。他的估算將永遠(yuǎn)是猜測。 19. 只需當(dāng)義務(wù)100%完成時，才以為該義務(wù)完成 運用英寸大小的小圓石的一個益處是，他可以區(qū)分每個小義務(wù)要么完成了，要么沒有完成，這比估計一個大義務(wù)在某個時候完成了多少百分比要真實的多。不要讓人們只入不舍他們義務(wù)的完成形狀；運用明確的規(guī)范來判別一個步驟能否真正的完成了。 20. 公開、公正地跟蹤工程形狀 創(chuàng)建一個良好的風(fēng)氣，讓工程成員對準(zhǔn)確地報告工程的形狀感到平安。努力讓工程

10、在準(zhǔn)確的、基于數(shù)據(jù)的現(xiàn)實根底上運轉(zhuǎn)，而不是從由于害怕報告壞音訊而產(chǎn)生的令人誤解的樂觀主義。運用工程形狀信息在必要的時候進(jìn)展糾正操作，并且在條件允許時進(jìn)展表揚。 這些提示不能保證他的勝利，但是它們將協(xié)助 他在他的工程上獲得一個堅實的把手，并且保證他做了一切他可以做的事來讓工程在這個瘋狂的世界上勝利。 Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no job training. Some

11、times you must rely on coaching and survival tips from people who have already done their tour of duty in the project management trenches. Here are 20 such tips for success, which Ive learned from both well-managed and challenged projects. Keep these suggestions in mind during your next project, rec

12、ognizing that none of them is a silver bullet for your project management problems.Laying the GroundworkTip #1: Define project success criteria. At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too

13、 often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Some examples are increasing market share, reaching a specified sales volume or revenue, achieving specific customer satisfaction measures, retiring a high-maintenance legacy system, and ach

14、ieving a particular transaction processing volume and correctness.Tip #2: Identify project drivers, constraints, and degrees of freedom. Every project needs to balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a cons

15、traint within which you must operate, a driver aligned with project success, or a degree of freedom that you can adjust within some stated bounds to succeed. For more details about this, see Chapter 2 of my Creating a Software Engineering Culture (Dorset House, 1996).Tip #3: Define product release c

16、riteria. Early in the project, decide what criteria will determine whether or not the product is ready for release. You might base release criteria on the number of high-priority defects still open, performance measurements, specific functionality being fully operational, or other indicators that th

17、e project has met its goals. Whatever criteria you choose should be realistic, measurable, documented, and aligned with what quality means to your customers.Tip #4: Negotiate commitments. Despite pressure to promise the impossible, never make a commitment you know you cant keep. Engage in good-faith

18、 negotiations with customers and managers about what is realistically achievable. Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against unreasonable people.Planning the WorkTip #5: Write a plan. Some people believe the time spent

19、writing a plan could be better spent writing code, but I dont agree. The hard part isnt writing the plan. The hard part is actually doing the planningthinking, negotiating, balancing, talking, asking, and listening. The time you spend analyzing what it will take to solve the problem will reduce the

20、number of surprises you have to cope with later in the project.Tip #6: Decompose tasks to inch-pebble granularity. Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of othe

21、rwise, and permits more accurate, fine-grained status tracking.Tip #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets for these tasks. Each check

22、list should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle.Tip #8: Plan to do rework after a quality control activity. Almost all qua

23、lity control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you dont actually have to do any rework, great; youre a

24、head of schedule on that task. But dont count on it.Tip #9: Plan time for process improvement. Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, youll have to invest some time in proce

25、ss improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Dont allocate 100% of your team members available time to project tasks and then wonder why they dont ma

26、ke any progress on the improvement initiatives.Tip #10: Manage project risks. If you dont identify and control risks , they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them.

27、 For a concise tutorial on software risk management, see my article Know Your Enemy: Software Risk Management (Oct. 1998).Estimating the ProjectTip #11: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time, but I prefer to estimate the amount of e

28、ffort (in labor-hours) associated with a task, then translate the effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other pl

29、aces into which time disappears.Tip #12: Dont schedule people for more than 80%of their time. Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all

30、asked to do reduces our effectiveness significantly. Dont assume that just because someone spends 10 hours per week on a particular activity, he or she can do four of them at once; youll be lucky if he or she can handle three.Tip #13: Build training time into the schedule. Determine how much time yo

31、ur team members typically spend on training activities annually, and subtract that from the time available for them to be assigned to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.Tip #14: Record

32、estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary, and it will help y

33、ou improve your estimation process.Tip #15: Use estimation tools. Many commercial tools are available to help you estimate entire projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. Theyll also help

34、 you stay out of the impossible region, combinations of product size, team size, and schedule where no known project has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre (spc.ca).Tip #16: Respect the learning curve. If youre trying new processes, tools, or te

35、chnologies for the first time on this project, recognize that you will pay a price in terms of a short-term productivity loss. Dont expect to get the fabulous benefits of new software engineering approaches on the first try, so build extra time into the schedule to account for the inevitable learnin

36、g curve.Tip #17: Plan contingency buffers. Things never go precisely as you plan on a project, so your budget and schedule should include some contingency buffers at the end of major phases to accommodate the unforeseen. Unfortunately, your manager or customer may view these buffers as padding, rather than the sensible acknowledgement of reality that they are. Point to unpleasant surprises on previous projects as a rationale for your foresight.Tracking Your Progr