PMP考點彙總—敏捷專案管理(二)

許多專案的成功,依賴於透過需求工作流、需求分析、和需求可追溯性的管理,在需求層面上進行整體的專案規劃和控制。

在 Scrum 中,使用者需求被解析成 Epic 和 Story,置於 Product Backlog 中進行管理。Epic 和 Story 並沒有統一的劃分標準,一般可認為 Epic(史詩)是有一系列相互聯絡的 Story(故事)組成的故事集。實踐中,我們可以把系統模組識別為 Epic,再從 Epic 中解析出足夠細緻的 User Story。或者說,我們用 Epic 來描述需求範圍,用 Story 來定義需求明細。

3.1 需求分析

敏捷開發中許多活動都是全員參與而非專人參與,需求分析同樣也可以是全員參與的一個活動。需求分析是在需求理解的基礎上進行的,全員參與有助於及時發現團隊成員對同一個需求理解不一致的問題,可以在很大程度上避免缺陷的引入。另外,也有助於規避人力風險。比如,一個需求的開發者突然需要請假,其他開發者可以馬上頂替他,因為其他人也參與了其負責開發的需求的分析。此外,全員參與需求分析也有助於全體成員的能力的提升。然而通常多數的開發人員和測試人員他們的能力和經驗不足以勝任需求分析工作。這意味著全員參與的需求分析活動需要一個扮演導師角色的人帶領大家去進行有效的需求分析,Product Owner 需要承擔起這個責任,Scrum Master 可以為 Product Owner 如何勝任敏捷開發中的需求指導和 管理工作提供指導和協助。使用者需求由 3 個要素組成:需求描述、需求優先順序和故事點(工作量)。

3.1.1 What or How

需要強調:需求分析是為了準確地描述問題,而非尋求如何解決問題。

從問題解決的角度來看,要解決一個問題首先要弄清楚的是問題究竟是什麼。軟體開發活動就是要把需求轉化為程式碼,這是一個怎麼(How)解決問題的過程。而需求分析的目的是,在動手開發前先搞清楚使用者到底想要什麼(What)。開發人員在需求分析時往往易犯的一個問題是急於考慮“怎麼”的問題,而這是設計開發活動所要解決的問題。

PMP考點彙總—敏捷專案管理(二)

3.1.2 需求描述:完整、合理、一致和相容

敏捷提倡客戶價值導向,應當從客戶價值角度描述,就是描述客戶想要什麼,而不是描述技術層面如何實現。典型的需求描述格式為:

作為 XX(角色,Who),我希望……(系統能夠實現什麼功能,What),以便……(達成某業務目標,Why)。

例如,一個 User Story 描述如下:

作為內容管理員,我希望我能對使用者投遞的稿件進行稽核和編輯,以避免釋出不合適的內容。

一個 Epic 概要描述如下:

指揮中心提出建設領導交辦模組,以處理領導批示的錄入、稽核、交辦、跟蹤和反饋。

3W 法是從 3 個維度描述需求的:需求所有者、需求陳訴和需求背景。其中:

1。 需求所有者明確需求由誰提出、或由誰使用;

2。 需求陳述告訴我們系統要做什麼,它反映了客戶所要的功能;

3。 需求背景告訴我們系統為什麼要做某件事,它反映了客戶的業務需要。

結合一個需求的這三個方面,有助於分析需求的合理性。對於不合理的需求應該及時拒絕,否則不僅浪費了團隊資源,系統上線後還可能給利益相關方帶來損失。

瞭解一個需求的背景對於理解和分析一個需求來說至關重要。因為需求背景不僅有助於理解需求,也有助於對需求進行進一步分析。比如,行動網路中的廣告可能要求內容的個性化定製,即讓每個使用者看到最適合他的廣告,這些廣告的內容因受眾的年齡、性別等個人資訊而異。顯然,系統需要先查詢使用者個人資訊然後再根據個人資訊去查詢廣告內容。針對這樣一個需求,我們可能會提出這樣一個問題:如果使用者個人資訊查詢失敗,系統是否還需返回廣告內容呢?而需求陳述中並沒有提及這點。考慮需求背景可以幫助我們自行找到這類需求完整性問題的答案——根據個人資訊獲取定製的廣告其目的是更好地定位潛在消費者,若無法獲取使用者個人資訊,則返回適宜大眾閱讀的廣告也無妨。

此外,描述需求還要考慮需求的一致性和相容性:

一致性:對需求的描述和理解應當在需求提出方和敏捷團隊之間達成一致。如果需求提出方提出需求變更,那麼至少要經過 產品負責人(Product Owner,PO) 評估、修改需求描述,並向需求提出方確認。

相容性:迭代開發中,當前迭代往往涉及對前面迭代中已經實現的需求的變更,而在此次變更之前該需求可能已經經歷若干次變更了。這種情況下,特別需要關注這些變更間的相容性。因為前些迭代中實現的這個需求可能已經上線執行,需求變更應當考慮到它對線上的系統可能帶來的相容性問題。否則,新的迭代釋出的版本若與線上的版本不相容,很可能給客戶帶來損失。

3.1.3 確定需求的優先順序

在敏捷專案中,對需求進行優先順序排序是個非常重要的活動,貫穿專案始終,每個迭代中都需要不斷的進行需求優先順序評估、使用者故事梳理等活動。對很多敏捷團隊而言,一提到需求優先順序排序,首先想到的就是產品負責人(PO)的責任。而對產品負責人來說,第一反應就是根據具體的商業價值(business value - 也稱業務價值)來確定優先順序。業務價值如何定義、如何評估和測量?其中包含哪些考慮因素?

價值,往往不僅僅純粹是經濟價值,能創造利潤或節省開支固然是非常重要的因素,但對成本、風險甚至學習新知識方面的考慮也至關重要。所以,確定優先順序時通常會從 5 個方面考慮:

經濟價值

所需成本

學習和獲取知識的重要性和數量

風險

客戶需要

在其中,如何考慮風險,以及風險和價值之間的關係來排定優先順序是一個難點。獨立的只考慮追求價值或迴避風險而進行優先順序排序,都會帶來問題。一般 PO 都會選擇採用風險-價值矩陣來評估需求優先順序,優先完成相對高價值-高風險的需求,高價值-低風險的需求次之,低價值-低風險的需求再次之,而儘可能推遲甚至避免開發低價值-高風險的需求。

在此基礎上,基於對知識學習和風險的考慮和客戶的實際需要,產品負責人也可以結合團隊的評估來進行調整。針對風險-價值矩陣,還需要持續監督,因為價值和風險隨著專案進行是會動態變化的。

3.1.4 估算 Story Point

無論是團隊研發一款產品或者開發某一個專案,我們都需要回答“我們大概什麼時間能夠完成?”, 或者到某一個時間點,我們能夠做到什麼程度, 因此和傳統的開發模式一樣,我們在工作開始之前需要對我們需要做的事情進行工作量的估算。

對工作量的估算應當以 User Story 為基礎,Epic 的整體工作量體現在分解得到的 Story 的工作量的總和以及整合成本上。

使用者故事的工作量以故事點(Story Point)來衡量。對工作量應當估算大小,而不是估算時間週期,使用相對估算,而不是絕對估算。在專案中,可以預設一個基準故事,例如,把實現使用者認證頁面的故事點定為 1,以後每個使用者故事都相對於“使用者認證頁面”這一故事來衡量工作量。

頂部