* 這是我今天在美國(guó)著名的Dr.Dobb開(kāi)發(fā)網(wǎng)站上看到的一篇關(guān)注度很高（TOP5）的文章。我恰巧使用過(guò)文中講的（或類(lèi)似的）方法，而且效果不錯(cuò)，所以把它翻譯過(guò)來(lái)作為參考。

原文：Quick-Kill Project Management
譯文：

Quick-Kill 項(xiàng)目管理

作者：Andrew Stellman & Jennifer Greene     翻譯：tianxinet（胖猴）

怎樣進(jìn)行敏捷的(smart)軟件開(kāi)發(fā)，即使面對(duì)“不可能的”時(shí)間表

Andrew 和 Jennifer 是 “實(shí)用軟件項(xiàng)目管理（Applied Software Project Management）”一書(shū)的作者(O‘Reilly & Associates)。 在www.stellman-greene.com 可以聯(lián)系到他們。

（譯者注：文中l(wèi)ead developer、lead都可以認(rèn)為是team leader，因?yàn)樵谛⌒蛨F(tuán)隊(duì)中這些角色往往都是重合的）

    假如你是一個(gè)5人小組的lead developer，你在一個(gè)項(xiàng)目中工作了幾周，小組才剛剛上路。你的小組成員包括高級(jí)架構(gòu)師到剛剛走出校門(mén)的初級(jí)程序員。這時(shí)候你的上司把你叫到辦公室，告訴你高層主管剛剛在電話(huà)里訓(xùn)斥了他，他希望你的項(xiàng)目在昨天完成。而當(dāng)終于完成的時(shí)候，已經(jīng)超過(guò)許諾日期很長(zhǎng)時(shí)間了。用戶(hù)有一項(xiàng)工作要作，并且這個(gè)軟件是必須的。如果軟件不能工作，或不能工作的很好，你最好去更新你的簡(jiǎn)歷。

    這是你最后一次加入這種高壓力狀況的小組，這種項(xiàng)目是一場(chǎng)惡夢(mèng)。小組成員已陷于錯(cuò)誤的歧路很多天，你不得不扮演英雄，每個(gè)周末投入其中工作40小時(shí)去修正嚴(yán)重的設(shè)計(jì)問(wèn)題。和高級(jí)經(jīng)理開(kāi)冗長(zhǎng)的會(huì)議，頑固的bug好像永遠(yuǎn)不能搞定，經(jīng)常工作到深夜。當(dāng)小組終于交付了一些東西，用戶(hù)卻恨它。似乎用戶(hù)點(diǎn)擊每一個(gè)button都會(huì)有一個(gè)bug，而他們期望的特性卻從沒(méi)有在交付的軟件中出現(xiàn)。

Quick Kill
    許多小組發(fā)現(xiàn)他們每天都處于類(lèi)似的境況，lead developer面對(duì)嚴(yán)峻的考驗(yàn)。lead developer未必直接管理他的小組，但他負(fù)責(zé)把軟件“送出門(mén)去”，他受到小組的尊重，當(dāng)他作出一個(gè)決定，人們通常愿意追隨他。但lead developer的工組不是管理而是開(kāi)發(fā)，他需要花費(fèi)大多數(shù)時(shí)間設(shè)計(jì)方案、設(shè)計(jì)軟件、構(gòu)建代碼。

    Quick-kill項(xiàng)目管理由3個(gè)方法組成，這些方法讓lead能夠使他們的項(xiàng)目產(chǎn)物滿(mǎn)足老板的期望和用戶(hù)的需求：
        • 前景和范圍文檔（Vision and scope document）
        • 工作分解安排（Work breakdown structure,WBS）
        • 代碼復(fù)查（Code review） 

        *譯者注：WBS如果照詞面意思翻譯成“工作分解結(jié)構(gòu)”之類(lèi)的很別扭，結(jié)合文中對(duì)WBS的描述，翻譯成“工作分解安排”是合適的。

    這些方法中的每一個(gè)只需要少許時(shí)間來(lái)執(zhí)行，并且可以幫助小組避免一些最常見(jiàn)和代價(jià)高昂的項(xiàng)目缺陷。使用它們，leads能極大的增進(jìn)交付滿(mǎn)意軟件的幾率。

前景和范圍文檔(Vision and scope document): 6 小時(shí)
    如果一個(gè)小組不能真正理解所構(gòu)建軟件的“內(nèi)涵”(context)，他們很可能在整個(gè)項(xiàng)目過(guò)程中都作出糟糕的決定。這些糟糕的決定浪費(fèi)小組的寶貴時(shí)間去修正，如果沒(méi)修正，又會(huì)導(dǎo)致項(xiàng)目不能符合用戶(hù)的需要而損害小組和用戶(hù)的良好關(guān)系。（如果）對(duì)項(xiàng)目的真正范圍(scope)沒(méi)有很好理解，小組唯一能預(yù)見(jiàn)的事就是被人“在屁股后追”（urgency），他們脫離了試圖滿(mǎn)足的需求。程序員能夠看到自己的單個(gè)程序，但是脫離了大的構(gòu)想。這是導(dǎo)致項(xiàng)目延遲和失敗的最大單一原因。

    幸運(yùn)的是，有一個(gè)簡(jiǎn)單直接和容易執(zhí)行的經(jīng)驗(yàn)來(lái)幫助小組避免這些問(wèn)題――花不超過(guò)一天的時(shí)間寫(xiě)一份前景和范圍文檔，并幫助小組避免數(shù)周的改寫(xiě)和錯(cuò)誤的開(kāi)始。

    寫(xiě)一份前景和范圍文檔的第一步是和項(xiàng)目的干系人（stakeholders）交談。不幸的是，誰(shuí)是項(xiàng)目干系人不總是顯見(jiàn)的。Lead應(yīng)該找出最受項(xiàng)目影響的人――要么他打算使用軟件，要么軟件不開(kāi)發(fā)出來(lái)他就有麻煩。干系人通常樂(lè)于談他們的需要，這正是lead developer――和其他小組成員，如果可能的話(huà)――應(yīng)該和干系人談的。和每個(gè)干系人談不超過(guò)一個(gè)小時(shí)來(lái)獲取他們的需求。

    前景和范圍文檔應(yīng)該是簡(jiǎn)明的、不超過(guò)兩頁(yè)（見(jiàn)表1）。通過(guò)和干系人交談得到的所有信息應(yīng)該加到“問(wèn)題陳述”部分。

    表1：       

“項(xiàng)目背景”部分是項(xiàng)目要解決問(wèn)題的概要，應(yīng)該提供一份問(wèn)題的簡(jiǎn)明歷史記錄，和組織（注：用戶(hù)的組織）如何決定構(gòu)建軟件去處理它。這個(gè)部分應(yīng)該覆蓋這些原因：這些問(wèn)題為什么存在、組織的問(wèn)題歷史記錄、先前被采用來(lái)試圖解決這些問(wèn)題的項(xiàng)目、得出的開(kāi)始當(dāng)前項(xiàng)目的方法。

“干系人”部分是干系人的列表。每一個(gè)干系人可能提到名字、頭銜或角色（象支持組經(jīng)理、SCTO、高級(jí)經(jīng)理），每個(gè)干系人的需求用幾句話(huà)來(lái)描述。“用戶(hù)”部分是類(lèi)似的，包括用戶(hù)列表，與“干系人”一樣，每個(gè)用戶(hù)可能提到名字或角色;可是，如果有許多用戶(hù)，試圖給每個(gè)用戶(hù)命名（注：指角色命名）通常是效率較差的。每一個(gè)用戶(hù)的需求都要描述。

“用戶(hù)”和“干系人”的需求是這個(gè)文檔最重要的部分。除非小組理解驅(qū)動(dòng)項(xiàng)目的需求，否則可能導(dǎo)致他們?cè)趯?duì)干系人來(lái)說(shuō)不重要的問(wèn)題上浪費(fèi)時(shí)間。構(gòu)建解決這些錯(cuò)誤問(wèn)題地軟件是簡(jiǎn)單地，但是構(gòu)建適當(dāng)?shù)能浖奈ㄒ晦k法，是項(xiàng)目中的每一個(gè)人在項(xiàng)目開(kāi)始前理解軟件將為什么和怎樣被構(gòu)建，并達(dá)成一致。這是項(xiàng)目計(jì)劃的目標(biāo)。

“前景（vision）”部分提出軟件目標(biāo)的描述。所有的軟件都是為了滿(mǎn)足特定用戶(hù)和干系人的需求，小組必須識(shí)別需求并且寫(xiě)下“前景陳述”（描述需求怎樣被滿(mǎn)足）。“前景陳述”部分的目標(biāo)是描述項(xiàng)目被預(yù)期達(dá)到的（期望）。它應(yīng)該解釋項(xiàng)目的目的。應(yīng)該有一個(gè)非常有說(shuō)服力的理由：為什么花費(fèi)時(shí)間、金錢(qián)、資源在這個(gè)項(xiàng)目上。

功能規(guī)格列表包含一個(gè)“什么要做”和“不作什么”的簡(jiǎn)明列表。在撰寫(xiě)這部分前，小組應(yīng)該寫(xiě)出文檔的其他部分并且對(duì)他們要滿(mǎn)足的需求進(jìn)行開(kāi)放的討論。每個(gè)單一功能應(yīng)該解決“問(wèn)題陳述”部分的一個(gè)需求。小組常常提出一個(gè)好像明顯的，但不是真正解決需求的功能規(guī)格，這些功能規(guī)格應(yīng)該放在“將不會(huì)被開(kāi)發(fā)的功能規(guī)格”中描述。

工作分解安排(Work Breakdown Structure,WBS): 2 小時(shí)
    搞定了功能規(guī)格（features），開(kāi)始針對(duì)這個(gè)功能規(guī)格工作之前，lead應(yīng)該和小組一起提出對(duì)每一個(gè)功能規(guī)格的評(píng)估（estimate）列表。許多開(kāi)發(fā)者在評(píng)估時(shí)會(huì)遇到很多麻煩，幸運(yùn)的時(shí)有一些指導(dǎo)方針可以使評(píng)估過(guò)程簡(jiǎn)單可靠。

    評(píng)估是重要的，因?yàn)樗笮〗M成員從頭到尾考慮項(xiàng)目的每個(gè)方面。大多數(shù)程序員承認(rèn)有這種不安的感覺(jué)：伴隨著他們（原先）假定的任務(wù)的實(shí)現(xiàn)，原來(lái)（似乎）簡(jiǎn)單的問(wèn)題會(huì)變得越來(lái)越棘手。如果其他小組的成員依賴(lài)這些工作，它可能把整個(gè)項(xiàng)目拖入混亂。好的評(píng)估經(jīng)驗(yàn)可以避免經(jīng)常發(fā)生的災(zāi)難。評(píng)估一個(gè)項(xiàng)目要求小組預(yù)先給出完成項(xiàng)目的步驟，并且提出每一步需要幾天（或周，或小時(shí)），找出這些數(shù)字的唯一方法是整個(gè)小組坐下來(lái)考慮許多稍后在項(xiàng)目中可能被遺漏的細(xì)節(jié)。

    做評(píng)估的第一步是把項(xiàng)目分解成一個(gè)完成最終產(chǎn)品要做的任務(wù)列表。這個(gè)列表叫做“工作分解安排（work breakdown structure，WBS）”。有許多方法把一個(gè)項(xiàng)目分解成一個(gè)WBS。lead developer應(yīng)該把小組成員組織在一起開(kāi)會(huì)討論任務(wù)列表。

    一個(gè)有用的準(zhǔn)則是――任何項(xiàng)目都可以分解成10～20個(gè)任務(wù)。對(duì)于大項(xiàng)目來(lái)說(shuō)（比如航天飛機(jī)），任務(wù)是非常大的；對(duì)于小項(xiàng)目（象簡(jiǎn)單的計(jì)算器程序），這些任務(wù)很小。

    一旦小組成員就WBS達(dá)成一致，可以開(kāi)始討論每一個(gè)任務(wù)，以使他們能夠?qū)γ恳粋€(gè)任務(wù)提出評(píng)估。在項(xiàng)目的開(kāi)端，小組成員沒(méi)有做評(píng)估需要的所有信息；然而，他們需要提出數(shù)字。去處理這些不完善的信息，他們必須做一些關(guān)于待處理工作的假設(shè)（assumption）。通過(guò)做假設(shè)，小組成員能夠?yàn)楹竺婵赡芴砑拥男畔㈩A(yù)留位置，使評(píng)估更加精確。

    假設(shè)是評(píng)估的重要關(guān)鍵，如果兩個(gè)人對(duì)完成一個(gè)任務(wù)需要多長(zhǎng)時(shí)間有爭(zhēng)執(zhí)，很可能他們對(duì)產(chǎn)品和生產(chǎn)產(chǎn)品的策略做的假設(shè)不同。換句話(huà)說(shuō)，任何爭(zhēng)執(zhí)通常都是關(guān)于執(zhí)行這個(gè)任務(wù)需要什么，而不是完成任務(wù)所要做的努力。例如，為一個(gè)設(shè)置計(jì)算機(jī)時(shí)鐘的工具給出相同的前景和范圍文檔（vision and scope document），但是一個(gè)開(kāi)發(fā)者可能假設(shè)做一個(gè)命令行接口，另一個(gè)開(kāi)發(fā)者假設(shè)做一個(gè)結(jié)合系統(tǒng)控制面板的圖形界面。

    通過(guò)幫助另一個(gè)程序員討論這些假設(shè)，并且就他們的分歧達(dá)成臨時(shí)決議，lead能夠幫助他們就此任務(wù)達(dá)成一致評(píng)估。Lead應(yīng)該一個(gè)接一個(gè)地提出每一個(gè)任務(wù)，并且小組應(yīng)該決定每一個(gè)任務(wù)需要多長(zhǎng)時(shí)間。每次遇到爭(zhēng)執(zhí)，就意味著有遺漏的假設(shè)，Lead應(yīng)該與其他小組成員一道準(zhǔn)確地指出那些遺漏的假設(shè)是什么。當(dāng)這些假設(shè)被發(fā)現(xiàn)時(shí)，應(yīng)該記下來(lái)。當(dāng)討論過(guò)程和更多的假設(shè)被記下來(lái)，小組成員會(huì)對(duì)項(xiàng)目了解的更多，并且將要開(kāi)始就軟件怎樣被構(gòu)建做決定。這幫助小組就每一個(gè)任務(wù)的評(píng)估達(dá)成一致。

    最終WBS應(yīng)該由任務(wù)列表、每個(gè)任務(wù)的評(píng)估、任務(wù)的假設(shè)組成。提出WBS中10～20個(gè)任務(wù)的假設(shè)大概會(huì)用去小組1個(gè)小時(shí)的時(shí)間。創(chuàng)建WBS以及做評(píng)估的總時(shí)間大約2小時(shí)。這對(duì)于一個(gè)5人小組的基本評(píng)估應(yīng)該時(shí)足夠的。但是，如果是一個(gè)大項(xiàng)目，就需要把項(xiàng)目分成很多塊，然后每一塊用2小時(shí)去評(píng)估。

代碼復(fù)查（Code Reviews）: 每次復(fù)查2.5 小時(shí)
    在一次代碼復(fù)查中，小組檢查一個(gè)代碼樣本并且修正它的任何缺陷(defect)。一個(gè)缺陷是一個(gè)不能象程序員想要的那樣運(yùn)行的代碼塊，或者可以改進(jìn)的代碼塊（比如讓它更易讀或提高它的性能）。

    執(zhí)行代碼復(fù)查是一個(gè)幫助小組構(gòu)建更好軟件的有效方法。除了幫助小組發(fā)現(xiàn)并修正bug外，代碼復(fù)查對(duì)于程序員進(jìn)行被復(fù)查代碼的交叉培訓(xùn)(cross-training)以及幫助初級(jí)開(kāi)發(fā)者學(xué)習(xí)新的編程技術(shù)是有益的。最重要的是，當(dāng)開(kāi)發(fā)者知道隨后有人要閱讀的時(shí)候會(huì)趨向于寫(xiě)更好的代碼。

    代碼復(fù)查的第一個(gè)任務(wù)是選擇檢查的代碼樣本。復(fù)查每一行代碼是不可能的，因此程序員要選擇哪一部分的代碼需要復(fù)查。如果復(fù)查的代碼選擇的正確，代碼復(fù)查會(huì)是有效的。多數(shù)項(xiàng)目中，大量缺陷集中在相對(duì)小部分的代碼中。如果代碼選擇的好，那么復(fù)查能幫助小組揪出缺陷，輕易地節(jié)省遠(yuǎn)比復(fù)查花費(fèi)的時(shí)間更多的時(shí)間，如果這些缺陷留在軟件中，稍后會(huì)需要更多的時(shí)間來(lái)追蹤和修正。

    對(duì)于lead developer來(lái)說(shuō)選擇正確的代碼樣本并不困難。好的復(fù)查候選代碼可能實(shí)現(xiàn)一個(gè)棘手的算法、使用一個(gè)難弄的API或者對(duì)象接口、需要特殊的專(zhuān)門(mén)技術(shù)去維護(hù)、或者可能使用了一個(gè)新的編程技術(shù)。這對(duì)于在一個(gè)軟件中任何缺陷都將導(dǎo)致災(zāi)難的高風(fēng)險(xiǎn)部分選擇代碼樣本是特別有用的――不僅僅是因?yàn)槟切┐a可能有更多的缺陷，還因?yàn)楦嗳藭?huì)沿著這條線索去維護(hù)軟件。當(dāng)有大范圍的修補(bǔ)時(shí)，引入缺陷的風(fēng)險(xiǎn)很高。

    準(zhǔn)備復(fù)查時(shí)，lead分發(fā)代碼的打印稿（帶有行標(biāo)號(hào)）給每一個(gè)小組成員。小組成員分別花費(fèi)半小時(shí)通讀（如果可能并執(zhí)行）代碼樣本一次，他們盡量指出代碼是否真的在干作者想讓它干的事。他們應(yīng)該查找準(zhǔn)確性、可維護(hù)性、可靠性、可控性、安全、可擴(kuò)展性、復(fù)用性、效率問(wèn)題。這些問(wèn)題的任何一個(gè)都應(yīng)該被看作是一個(gè)缺陷。每一個(gè)小組成員盡可能多的發(fā)現(xiàn)缺陷，并在打印稿上做標(biāo)記。

    準(zhǔn)備完后，team leader把大家集中起來(lái)開(kāi)復(fù)查會(huì)議。代碼復(fù)查開(kāi)始是由lead developer（大聲地）閱讀一段代碼樣本。他不是逐字閱讀代碼，而是做一個(gè)該代碼塊的簡(jiǎn)明描述。如果任何人（包括lead）不能理解這些代碼在干什么或不同意給出的闡述，代碼作者要解釋這些代碼應(yīng)該完成什么，有時(shí)一個(gè)小組成員能夠提出一個(gè)更好的、更加清楚的方法來(lái)完成同樣的事情；通常只是大概說(shuō)明這些代碼的用途。

    然后小組成員應(yīng)該討論代碼中發(fā)現(xiàn)的任何缺陷，這時(shí)lead必須扮演會(huì)議的仲裁者。如果任何人發(fā)現(xiàn)一個(gè)缺陷，lead應(yīng)該判斷小組是否能夠提出一個(gè)辦法修正它，如果判斷能，小組應(yīng)該提出解決辦法；如果判斷不能，把它作為未決問(wèn)題以便隨后修正。另外，lead向包含復(fù)查記錄(log)的表格中添加一行，每個(gè)發(fā)現(xiàn)的缺陷在這個(gè)表格中都有對(duì)應(yīng)的行，每行列出包含缺陷的代碼行號(hào)、鑒別人、以及一個(gè)怎樣解決缺陷的描述（或者標(biāo)記該問(wèn)題為未決的）。在記錄(log)的頂部，lead應(yīng)該記下會(huì)議召開(kāi)的時(shí)間以及復(fù)查的是哪一段代碼。

    復(fù)查會(huì)議應(yīng)該不超過(guò)2小時(shí)。如果持續(xù)時(shí)間超過(guò)2小時(shí)，那么將來(lái)應(yīng)該選擇一個(gè)更短的代碼樣本來(lái)復(fù)查。會(huì)議結(jié)束后，lead應(yīng)該把記錄mail給小組成員，并且指定代碼負(fù)責(zé)人修正缺陷。一旦缺陷被修正，lead應(yīng)該復(fù)查更新的代碼并確認(rèn)代碼被正確的修正。