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

原文：Quick-Kill Project Management
譯文：

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

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

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

Andrew 和 Jennifer 是 “實(shí)用軟件項(xiàng)目管理（Applied Software Project Management）”一書的作者(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ì)中這些角色往往都是重合的）

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

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

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

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

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

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

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

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

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

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

    表1：       

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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