* 這是我今天在美國著(zhù)名的Dr.Dobb開(kāi)發(fā)網(wǎng)站上看到的一篇關(guān)注度很高（TOP5）的文章。我恰巧使用過(guò)文中講的（或類(lèi)似的）方法，而且效果不錯，所以把它翻譯過(guò)來(lái)作為參考。
原文：Quick-Kill Project Management
譯文：
Quick-Kill 項目管理
作者：Andrew Stellman & Jennifer Greene 翻譯：tianxinet（胖猴）
怎樣進(jìn)行敏捷的(smart)軟件開(kāi)發(fā)，即使面對“不可能的”時(shí)間表
Andrew 和 Jennifer 是 “實(shí)用軟件項目管理（Applied Software Project Management）”一書(shū)的作者(O‘Reilly & Associates)。 在www.stellman-greene.com 可以聯(lián)系到他們。
（譯者注：文中lead developer、lead都可以認為是team leader，因為在小型團隊中這些角色往往都是重合的）
假如你是一個(gè)5人小組的lead developer，你在一個(gè)項目中工作了幾周，小組才剛剛上路。你的小組成員包括高級架構師到剛剛走出校門(mén)的初級程序員。這時(shí)候你的上司把你叫到辦公室，告訴你高層主管剛剛在電話(huà)里訓斥了他，他希望你的項目在昨天完成。而當終于完成的時(shí)候，已經(jīng)超過(guò)許諾日期很長(cháng)時(shí)間了。用戶(hù)有一項工作要作，并且這個(gè)軟件是必須的。如果軟件不能工作，或不能工作的很好，你最好去更新你的簡(jiǎn)歷。
這是你最后一次加入這種高壓力狀況的小組，這種項目是一場(chǎng)惡夢(mèng)。小組成員已陷于錯誤的歧路很多天，你不得不扮演英雄，每個(gè)周末投入其中工作40小時(shí)去修正嚴重的設計問(wèn)題。和高級經(jīng)理開(kāi)冗長(cháng)的會(huì )議，頑固的bug好像永遠不能搞定，經(jīng)常工作到深夜。當小組終于交付了一些東西，用戶(hù)卻恨它。似乎用戶(hù)點(diǎn)擊每一個(gè)button都會(huì )有一個(gè)bug，而他們期望的特性卻從沒(méi)有在交付的軟件中出現。
Quick Kill
許多小組發(fā)現他們每天都處于類(lèi)似的境況，lead developer面對嚴峻的考驗。lead developer未必直接管理他的小組，但他負責把軟件“送出門(mén)去”，他受到小組的尊重，當他作出一個(gè)決定，人們通常愿意追隨他。但lead developer的工組不是管理而是開(kāi)發(fā)，他需要花費大多數時(shí)間設計方案、設計軟件、構建代碼。
Quick-kill項目管理由3個(gè)方法組成，這些方法讓lead能夠使他們的項目產(chǎn)物滿(mǎn)足老板的期望和用戶(hù)的需求：
• 前景和范圍文檔（Vision and scope document）
• 工作分解安排（Work breakdown structure,WBS）
• 代碼復查（Code review）
*譯者注：WBS如果照詞面意思翻譯成“工作分解結構”之類(lèi)的很別扭，結合文中對WBS的描述，翻譯成“工作分解安排”是合適的。
這些方法中的每一個(gè)只需要少許時(shí)間來(lái)執行，并且可以幫助小組避免一些最常見(jiàn)和代價(jià)高昂的項目缺陷。使用它們，leads能極大的增進(jìn)交付滿(mǎn)意軟件的幾率。
前景和范圍文檔(Vision and scope document): 6 小時(shí)
如果一個(gè)小組不能真正理解所構建軟件的“內涵”(context)，他們很可能在整個(gè)項目過(guò)程中都作出糟糕的決定。這些糟糕的決定浪費小組的寶貴時(shí)間去修正，如果沒(méi)修正，又會(huì )導致項目不能符合用戶(hù)的需要而損害小組和用戶(hù)的良好關(guān)系。（如果）對項目的真正范圍(scope)沒(méi)有很好理解，小組唯一能預見(jiàn)的事就是被人“在屁股后追”（urgency），他們脫離了試圖滿(mǎn)足的需求。程序員能夠看到自己的單個(gè)程序，但是脫離了大的構想。這是導致項目延遲和失敗的最大單一原因。
幸運的是，有一個(gè)簡(jiǎn)單直接和容易執行的經(jīng)驗來(lái)幫助小組避免這些問(wèn)題――花不超過(guò)一天的時(shí)間寫(xiě)一份前景和范圍文檔，并幫助小組避免數周的改寫(xiě)和錯誤的開(kāi)始。
寫(xiě)一份前景和范圍文檔的第一步是和項目的干系人（stakeholders）交談。不幸的是，誰(shuí)是項目干系人不總是顯見(jiàn)的。Lead應該找出最受項目影響的人――要么他打算使用軟件，要么軟件不開(kāi)發(fā)出來(lái)他就有麻煩。干系人通常樂(lè )于談他們的需要，這正是lead developer――和其他小組成員，如果可能的話(huà)――應該和干系人談的。和每個(gè)干系人談不超過(guò)一個(gè)小時(shí)來(lái)獲取他們的需求。
前景和范圍文檔應該是簡(jiǎn)明的、不超過(guò)兩頁(yè)（見(jiàn)表1）。通過(guò)和干系人交談得到的所有信息應該加到“問(wèn)題陳述”部分。
表1：
| 1. 問(wèn)題陳述 |
| a. 項目背景 |
| b. 干系人 |
| c. 用戶(hù) |
| 2. 方案前景（Vision） |
| a. 前景陳述 |
| b. 功能規格(Features)列表 |
| c. 將不會(huì )被開(kāi)發(fā)的功能規格（Features） |
表 1: 前景和范圍文檔概要
“項目背景”部分是項目要解決問(wèn)題的概要，應該提供一份問(wèn)題的簡(jiǎn)明歷史記錄，和組織（注：用戶(hù)的組織）如何決定構建軟件去處理它。這個(gè)部分應該覆蓋這些原因：這些問(wèn)題為什么存在、組織的問(wèn)題歷史記錄、先前被采用來(lái)試圖解決這些問(wèn)題的項目、得出的開(kāi)始當前項目的方法。
“干系人”部分是干系人的列表。每一個(gè)干系人可能提到名字、頭銜或角色（象支持組經(jīng)理、SCTO、高級經(jīng)理），每個(gè)干系人的需求用幾句話(huà)來(lái)描述。“用戶(hù)”部分是類(lèi)似的，包括用戶(hù)列表，與“干系人”一樣，每個(gè)用戶(hù)可能提到名字或角色;可是，如果有許多用戶(hù)，試圖給每個(gè)用戶(hù)命名（注：指角色命名）通常是效率較差的。每一個(gè)用戶(hù)的需求都要描述。
“用戶(hù)”和“干系人”的需求是這個(gè)文檔最重要的部分。除非小組理解驅動(dòng)項目的需求，否則可能導致他們在對干系人來(lái)說(shuō)不重要的問(wèn)題上浪費時(shí)間。構建解決這些錯誤問(wèn)題地軟件是簡(jiǎn)單地，但是構建適當的軟件的唯一辦法，是項目中的每一個(gè)人在項目開(kāi)始前理解軟件將為什么和怎樣被構建，并達成一致。這是項目計劃的目標。
“前景（vision）”部分提出軟件目標的描述。所有的軟件都是為了滿(mǎn)足特定用戶(hù)和干系人的需求，小組必須識別需求并且寫(xiě)下“前景陳述”（描述需求怎樣被滿(mǎn)足）。“前景陳述”部分的目標是描述項目被預期達到的（期望）。它應該解釋項目的目的。應該有一個(gè)非常有說(shuō)服力的理由：為什么花費時(shí)間、金錢(qián)、資源在這個(gè)項目上。
功能規格列表包含一個(gè)“什么要做”和“不作什么”的簡(jiǎn)明列表。在撰寫(xiě)這部分前，小組應該寫(xiě)出文檔的其他部分并且對他們要滿(mǎn)足的需求進(jìn)行開(kāi)放的討論。每個(gè)單一功能應該解決“問(wèn)題陳述”部分的一個(gè)需求。小組常常提出一個(gè)好像明顯的，但不是真正解決需求的功能規格，這些功能規格應該放在“將不會(huì )被開(kāi)發(fā)的功能規格”中描述。
工作分解安排(Work Breakdown Structure,WBS): 2 小時(shí)
搞定了功能規格（features），開(kāi)始針對這個(gè)功能規格工作之前，lead應該和小組一起提出對每一個(gè)功能規格的評估（estimate）列表。許多開(kāi)發(fā)者在評估時(shí)會(huì )遇到很多麻煩，幸運的時(shí)有一些指導方針可以使評估過(guò)程簡(jiǎn)單可靠。
評估是重要的，因為它要求小組成員從頭到尾考慮項目的每個(gè)方面。大多數程序員承認有這種不安的感覺(jué)：伴隨著(zhù)他們（原先）假定的任務(wù)的實(shí)現，原來(lái)（似乎）簡(jiǎn)單的問(wèn)題會(huì )變得越來(lái)越棘手。如果其他小組的成員依賴(lài)這些工作，它可能把整個(gè)項目拖入混亂。好的評估經(jīng)驗可以避免經(jīng)常發(fā)生的災難。評估一個(gè)項目要求小組預先給出完成項目的步驟，并且提出每一步需要幾天（或周，或小時(shí)），找出這些數字的唯一方法是整個(gè)小組坐下來(lái)考慮許多稍后在項目中可能被遺漏的細節。
做評估的第一步是把項目分解成一個(gè)完成最終產(chǎn)品要做的任務(wù)列表。這個(gè)列表叫做“工作分解安排（work breakdown structure，WBS）”。有許多方法把一個(gè)項目分解成一個(gè)WBS。lead developer應該把小組成員組織在一起開(kāi)會(huì )討論任務(wù)列表。
一個(gè)有用的準則是――任何項目都可以分解成10～20個(gè)任務(wù)。對于大項目來(lái)說(shuō)（比如航天飛機），任務(wù)是非常大的；對于小項目（象簡(jiǎn)單的計算器程序），這些任務(wù)很小。
一旦小組成員就WBS達成一致，可以開(kāi)始討論每一個(gè)任務(wù)，以使他們能夠對每一個(gè)任務(wù)提出評估。在項目的開(kāi)端，小組成員沒(méi)有做評估需要的所有信息；然而，他們需要提出數字。去處理這些不完善的信息，他們必須做一些關(guān)于待處理工作的假設（assumption）。通過(guò)做假設，小組成員能夠為后面可能添加的信息預留位置，使評估更加精確。
假設是評估的重要關(guān)鍵，如果兩個(gè)人對完成一個(gè)任務(wù)需要多長(cháng)時(shí)間有爭執，很可能他們對產(chǎn)品和生產(chǎn)產(chǎn)品的策略做的假設不同。換句話(huà)說(shuō)，任何爭執通常都是關(guān)于執行這個(gè)任務(wù)需要什么，而不是完成任務(wù)所要做的努力。例如，為一個(gè)設置計算機時(shí)鐘的工具給出相同的前景和范圍文檔（vision and scope document），但是一個(gè)開(kāi)發(fā)者可能假設做一個(gè)命令行接口，另一個(gè)開(kāi)發(fā)者假設做一個(gè)結合系統控制面板的圖形界面。
通過(guò)幫助另一個(gè)程序員討論這些假設，并且就他們的分歧達成臨時(shí)決議，lead能夠幫助他們就此任務(wù)達成一致評估。Lead應該一個(gè)接一個(gè)地提出每一個(gè)任務(wù)，并且小組應該決定每一個(gè)任務(wù)需要多長(cháng)時(shí)間。每次遇到爭執，就意味著(zhù)有遺漏的假設，Lead應該與其他小組成員一道準確地指出那些遺漏的假設是什么。當這些假設被發(fā)現時(shí)，應該記下來(lái)。當討論過(guò)程和更多的假設被記下來(lái)，小組成員會(huì )對項目了解的更多，并且將要開(kāi)始就軟件怎樣被構建做決定。這幫助小組就每一個(gè)任務(wù)的評估達成一致。
最終WBS應該由任務(wù)列表、每個(gè)任務(wù)的評估、任務(wù)的假設組成。提出WBS中10～20個(gè)任務(wù)的假設大概會(huì )用去小組1個(gè)小時(shí)的時(shí)間。創(chuàng )建WBS以及做評估的總時(shí)間大約2小時(shí)。這對于一個(gè)5人小組的基本評估應該時(shí)足夠的。但是，如果是一個(gè)大項目，就需要把項目分成很多塊，然后每一塊用2小時(shí)去評估。
代碼復查（Code Reviews）: 每次復查2.5 小時(shí)
在一次代碼復查中，小組檢查一個(gè)代碼樣本并且修正它的任何缺陷(defect)。一個(gè)缺陷是一個(gè)不能象程序員想要的那樣運行的代碼塊，或者可以改進(jìn)的代碼塊（比如讓它更易讀或提高它的性能）。
執行代碼復查是一個(gè)幫助小組構建更好軟件的有效方法。除了幫助小組發(fā)現并修正bug外，代碼復查對于程序員進(jìn)行被復查代碼的交叉培訓(cross-training)以及幫助初級開(kāi)發(fā)者學(xué)習新的編程技術(shù)是有益的。最重要的是，當開(kāi)發(fā)者知道隨后有人要閱讀的時(shí)候會(huì )趨向于寫(xiě)更好的代碼。
代碼復查的第一個(gè)任務(wù)是選擇檢查的代碼樣本。復查每一行代碼是不可能的，因此程序員要選擇哪一部分的代碼需要復查。如果復查的代碼選擇的正確，代碼復查會(huì )是有效的。多數項目中，大量缺陷集中在相對小部分的代碼中。如果代碼選擇的好，那么復查能幫助小組揪出缺陷，輕易地節省遠比復查花費的時(shí)間更多的時(shí)間，如果這些缺陷留在軟件中，稍后會(huì )需要更多的時(shí)間來(lái)追蹤和修正。
對于lead developer來(lái)說(shuō)選擇正確的代碼樣本并不困難。好的復查候選代碼可能實(shí)現一個(gè)棘手的算法、使用一個(gè)難弄的API或者對象接口、需要特殊的專(zhuān)門(mén)技術(shù)去維護、或者可能使用了一個(gè)新的編程技術(shù)。這對于在一個(gè)軟件中任何缺陷都將導致災難的高風(fēng)險部分選擇代碼樣本是特別有用的――不僅僅是因為那些代碼可能有更多的缺陷，還因為更多人會(huì )沿著(zhù)這條線(xiàn)索去維護軟件。當有大范圍的修補時(shí)，引入缺陷的風(fēng)險很高。
準備復查時(shí)，lead分發(fā)代碼的打印稿（帶有行標號）給每一個(gè)小組成員。小組成員分別花費半小時(shí)通讀（如果可能并執行）代碼樣本一次，他們盡量指出代碼是否真的在干作者想讓它干的事。他們應該查找準確性、可維護性、可靠性、可控性、安全、可擴展性、復用性、效率問(wèn)題。這些問(wèn)題的任何一個(gè)都應該被看作是一個(gè)缺陷。每一個(gè)小組成員盡可能多的發(fā)現缺陷，并在打印稿上做標記。
準備完后，team leader把大家集中起來(lái)開(kāi)復查會(huì )議。代碼復查開(kāi)始是由lead developer（大聲地）閱讀一段代碼樣本。他不是逐字閱讀代碼，而是做一個(gè)該代碼塊的簡(jiǎn)明描述。如果任何人（包括lead）不能理解這些代碼在干什么或不同意給出的闡述，代碼作者要解釋這些代碼應該完成什么，有時(shí)一個(gè)小組成員能夠提出一個(gè)更好的、更加清楚的方法來(lái)完成同樣的事情；通常只是大概說(shuō)明這些代碼的用途。
然后小組成員應該討論代碼中發(fā)現的任何缺陷，這時(shí)lead必須扮演會(huì )議的仲裁者。如果任何人發(fā)現一個(gè)缺陷，lead應該判斷小組是否能夠提出一個(gè)辦法修正它，如果判斷能，小組應該提出解決辦法；如果判斷不能，把它作為未決問(wèn)題以便隨后修正。另外，lead向包含復查記錄(log)的表格中添加一行，每個(gè)發(fā)現的缺陷在這個(gè)表格中都有對應的行，每行列出包含缺陷的代碼行號、鑒別人、以及一個(gè)怎樣解決缺陷的描述（或者標記該問(wèn)題為未決的）。在記錄(log)的頂部，lead應該記下會(huì )議召開(kāi)的時(shí)間以及復查的是哪一段代碼。
復查會(huì )議應該不超過(guò)2小時(shí)。如果持續時(shí)間超過(guò)2小時(shí)，那么將來(lái)應該選擇一個(gè)更短的代碼樣本來(lái)復查。會(huì )議結束后，lead應該把記錄mail給小組成員，并且指定代碼負責人修正缺陷。一旦缺陷被修正，lead應該復查更新的代碼并確認代碼被正確的修正。
聯(lián)系客服
