Quick-Kill 項目管理

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

原文：[url=http://www.ddj.com/dept/architect/189401902]Quick-Kill Project Management[/url]

譯文：

[b][size=18]Quick-Kill 項目管理[/size][/b]

作者：Andrew Stellman & Jennifer Greene 翻譯：tianxinet（胖猴）－－最近致力於研究、介紹一些“最佳實踐”

[color=red][b]怎樣進行敏捷的(smart)軟件開發，即使面對“不可能的”時間表？[/b][/color]

[i]Andrew和Jennifer 是 “實用軟件項目管理（Applied Software Project Management）”的作者(O'Reilly & Associates)。 在www.stellman-greene.com 可以聯繫到他們。[/i]

（譯者注：文中lead developer、lead都可以認爲是team leader，因爲在小型團隊中這些角色往往都是重合的，但也可以根據不同情況各安其位）

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

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

[b]Quick Kill[/b]
許多小組發現他們每天都處於類似的境況，lead developer面對嚴峻的考驗。lead developer未必直接管理他的小組，但他負責把軟件“送出門去”，他受到小組的尊重，當他作出一個決定，人們通常願意追隨他。但lead developer的工組不是管理而是開發，他需要花費大多數時間設計方案、設計軟件、構建代碼。

Quick-kil項目管理由3個方法組成，這些方法讓lead能夠使他們的項目產物滿足老闆的期望和用戶的需求：
• 前景和範圍文檔（Vision and scope document）
• 工作分解安排（Work breakdown structure,WBS）
• 代碼複查（Code review）

這些方法中的每一個只需要少許時間來執行，並且可以幫助小組避免一些最常見和代價高昂的項目缺陷。使用它們，leads能極大的增進交付滿意軟件的機率。

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

幸運的是，有一個簡單直接和容易執行的經驗來幫助小組避免這些問題――花不超過一天的時間寫一份前景和範圍文檔，並幫助小組避免數週的改寫和錯誤的開始。

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

前景和範圍文檔應該是簡明的、不超過兩頁（見下表）。通過和干係人交談得到的所有信息應該加到“問題陳述”部分。

1. 問題陳述
a. 項目背景
b. 干係人
c. 用戶
2. 方案前景（Vision）
a. 前景陳述
b. 功能規格(Features)列表
c. 將不會被開發的功能規格（Features）

（此處省略對此文檔撰寫的一些說明，見原文）
[quote]補上這段說明的原文：
Table 1: Vision and scope document outline.

The Project Background section is a summary of the problem that the project solves. It should provide a brief history of the problem and an explanation of how the organization justified the decision to build software to address it. This section should cover the reasons why the problem exists, the organization's history with this problem, any previous projects that were undertaken to try to address it, and the way that the decision to begin this project was reached.


The Stakeholders section is a bulleted list of the stakeholders. Each stakeholder may be referred to by name, title, or role ("support group manager," "SCTO," "senior manager"). The needs of each stakeholder are described in a few sentences. The Users section is similar, containing a bulleted list of the users. As with the stakeholders, each user can either be referred to by name or role ("support rep," "call quality auditor," "home web site user"); however, if there are many users, it is usually inefficient to try to name each one. The needs of each user are described.


The needs of the users and stakeholders are the most important part of this document. Unless the team understands the needs that drive the project, they may end up with a narrow focus, causing them to waste time addressing problems that are of little importance to the stakeholders. It's easy to build great software that solves the wrong problems, but the only way to build the appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. That's the purpose of project planning.


The "vision" part of the vision and scope document refers to a description of the goal of the software. All software is built to fulfill needs of certain users and stakeholders. The team must identify those needs and write down a Vision Statement (a general statement describing how those needs will be filled). The goal of the Vision Statement section is to describe what the project is expected to accomplish. It should explain the purpose of the projects. This should be a compelling reason, a solid justification for spending time, money, and resources on the project.


The List of Features and Features That Will Not Be Developed sections contain a concise list of exactly what will and won't be built. Before writing these sections, the team should write the rest of the document and have an open discussion of the needs that they are trying to fill. Every single feature in each list should be built to address a specific need listed in the Problem Statement section. Often the team comes up with a feature that seems obvious, but that turns out not to really address a need. Features like this should be described in the Features That Will Not Be Developed section.
[/quote]


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

評估是重要的，因爲它要求小組成員從頭到尾考慮項目的每個方面。大多數程序員承認有這種不安的感覺：伴隨着他們（原先）假定的任務的實現，原來（似乎）簡單的問題會變得越來越棘手。如果其他小組的成員依賴這些工作，它可能把整個項目拖入混亂。好的評估經驗可以避免經常發生的災難。評估一個項目要求小組預先給出完成項目的步驟，並且提出每一步需要幾天（或周，或小時），找出這些數字的唯一方法是整個小組坐下來考慮許多稍後在項目中可能被遺漏的細節。

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

一個有用的準則是――任何項目都可以分解成10～20個任務。對於大項目來說（比如航天飛機），任務是非常大的；對於小項目（象簡單的計算器程序），這些任務很小。

一旦小組成員就WBS達成一致，可以開始討論每一個任務，以使他們能夠對每一個任務提出評估。在項目的開端，小組成員沒有做評估需要的所有信息；然而，他們需要提出數字。去處理這些不完善的信息，他們必須做一些關於待處理工作的假設（assumption）。通過做假設，小組成員能夠爲後面可能添加的信息預留位置，使評估更加精確。

假設是評估的重要關鍵，如果兩個人對完成一個任務需要多長時間有爭執，很可能他們對產品和生產產品的策略做的假設不同。換句話說，任何爭執通常都是關於執行這個任務需要什麼，而不是完成任務所要做的努力。例如，爲一個設置計算機時鐘的工具給出相同的前景和範圍文檔（vision and scope document），但是一個開發者可能假設做一個命令行接口，另一個開發者假設做一個結合系統控制面板的圖形界面。

通過幫助另一個程序員討論這些假設，並且就他們的分歧達成臨時決議，lead能夠幫助他們就此任務達成一致評估。Lead應該一個接一個地提出每一個任務，並且小組應該決定每一個任務需要多長時間。每次遇到爭執，就意味着有遺漏的假設，Lead應該與其他小組成員一道準確地指出那些遺漏的假設是什麼。當這些假設被發現時，應該記下來。當討論過程和更多的假設被記下來，小組成員會對項目瞭解的更多，並且將要開始就軟件怎樣被構建做決定。這幫助小組就每一個任務的評估達成一致。

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

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

執行代碼複查是一個幫助小組構建更好軟件的有效方法。除了幫助小組發現並修正bug外，代碼複查對於程序員進行被複查代碼的交叉培訓(cross-training)以及幫助初級開發者學習新的編程技術是有益的。最重要的是，當開發者知道隨後有人要閱讀的時候會趨向於寫更好的代碼。

代碼複查的第一個任務是選擇檢查的代碼樣本。複查每一行代碼是不可能的，因此程序員要選擇哪一部分的代碼需要複查。如果複查的代碼選擇的正確，代碼複查會是有效的。多數項目中，大量缺陷集中在相對小部分的代碼中。如果代碼選擇的好，那麼複查能幫助小組揪出缺陷，輕易地節省遠比複查花費的時間更多的時間，如果這些缺陷留在軟件中，稍後會需要更多的時間來追蹤和修正。

對於lead developer來說選擇正確的代碼樣本並不困難。好的複查候選代碼可能實現一個棘手的算法、使用一個難弄的API或者對象接口、需要特殊的專門技術去維護、或者可能使用了一個新的編程技術。這對於在一個軟件中任何缺陷都將導致災難的高風險部分選擇代碼樣本是特別有用的――不僅僅是因爲那些代碼可能有更多的缺陷，還因爲更多人會沿着這條線索去維護軟件。當有大範圍的修補時，引入缺陷的風險很高。

準備複查時，lead分發代碼的打印稿（帶有行標號）給每一個小組成員。小組成員分別花費半小時通讀（如果可能並執行）代碼樣本一次，他們儘量指出代碼是否真的在幹作者想讓它乾的事。他們應該查找準確性、可維護性、可靠性、可控性、安全、可擴展性、複用性、效率問題。這些問題的任何一個都應該被看作是一個缺陷。每一個小組成員儘可能多的發現缺陷，並在打印稿上做標記。

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

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

複查會議應該不超過2小時。如果持續時間超過2小時，那麼將來應該選擇一個更短的代碼樣本來複查。會議結束後，lead應該把記錄mail給小組成員，並且指定代碼負責人修正缺陷。一旦缺陷被修正，lead應該複查更新的代碼並確認代碼被正確的修正。