原創(chuàng)2020-10-15小艾老師

ACP敏捷項(xiàng)目管理認(rèn)證知識(shí)體系考證須知證書含金量培訓(xùn)大綱 3分鐘小視頻我要提問(wèn)

PMI-ACP認(rèn)證是由美國(guó)項(xiàng)目管理協(xié)會(huì)（PMI）于2011年推出的一種敏捷項(xiàng)目管理認(rèn)證。它是PMI針對(duì)敏捷實(shí)踐者的資格認(rèn)證，同時(shí)也是敏捷項(xiàng)目管理的行業(yè)標(biāo)準(zhǔn)。該認(rèn)證旨在評(píng)估從業(yè)者在敏捷方法、實(shí)踐和工具方面的知識(shí)和技能，以及在敏捷環(huán)境中管理項(xiàng)目的能力。通過(guò)PMI-ACP認(rèn)證，可以證明個(gè)人在敏捷項(xiàng)目管理方面的專業(yè)能力和實(shí)踐經(jīng)驗(yàn)。

中文名ACP敏捷項(xiàng)目管理認(rèn)證
英文名Agile Certified Practitioner
英文簡(jiǎn)稱ACP
頒證機(jī)構(gòu)PMI（美國(guó)項(xiàng)目管理協(xié)會(huì)）
證書類別敏捷
同類認(rèn)證Scrum Master、ITIL4 HVIT、DevOps

大多數(shù)學(xué)計(jì)算機(jī)語(yǔ)言的人都會(huì)有過(guò)這樣的感受，過(guò)去一直認(rèn)為編程和架構(gòu)是整個(gè)軟件生命周期里_了不起的部分，但實(shí)際工作后才會(huì)發(fā)現(xiàn)在商業(yè)產(chǎn)品里，需求分析才是一個(gè)商業(yè)軟件成功與否的關(guān)鍵。

放眼望去，在當(dāng)今軟件工程領(lǐng)域出現(xiàn)的許多問(wèn)題，諸如缺陷及資源運(yùn)用不當(dāng)，都源于需求的不清晰，甚至有軟件人戲稱：“需求變更乃萬(wàn)惡之源”，一時(shí)也獲得了頗多響應(yīng)。時(shí)至如今，業(yè)務(wù)IT間需求分析過(guò)程中存在的問(wèn)題主要有哪些？什么是敏捷需求分析？產(chǎn)品級(jí)和項(xiàng)目級(jí)需求有何異同？敏捷需求分析方法論中的五大關(guān)鍵點(diǎn)是什么？就以上熱點(diǎn)話題，雅各布森中國(guó)區(qū)總經(jīng)理吳穹分享了他的看法。

三大癥狀

兩份需求、合同式驗(yàn)證、產(chǎn)品需求缺失成為了當(dāng)前需求溝通的三大癥結(jié)。

兩份需求——用戶（業(yè)務(wù)）需求和軟件需求。用戶需求由不熟悉IT的業(yè)務(wù)人員完成，大多歸于天馬行空的意識(shí)流，基本上是想起什么寫什么。而軟件需求由IT人員編寫，經(jīng)過(guò)技術(shù)思維的過(guò)濾、梳理、增刪，包含進(jìn)了算法、數(shù)據(jù)庫(kù)設(shè)計(jì)、架構(gòu)之類的技術(shù)專業(yè)詞匯，業(yè)務(wù)人員往往已不知文檔內(nèi)所云。

合同式驗(yàn)證——業(yè)務(wù)人員和技術(shù)人員企圖在溝通后以合同形式將需求固化并且確定下來(lái)，而沒(méi)有充分考慮到軟件開(kāi)發(fā)過(guò)程中可能出現(xiàn)的需求變更。

產(chǎn)品需求缺失——項(xiàng)目是片段，產(chǎn)品是總量，兩者的關(guān)系在于項(xiàng)目其實(shí)就是一個(gè)不斷完善產(chǎn)品的過(guò)程。由于國(guó)內(nèi)PMP（Project Management Professional）和項(xiàng)目管理流行，更多IT需求都是以項(xiàng)目形式存在，而往往忽視了產(chǎn)品需求的積累，導(dǎo)致_后的結(jié)果多是項(xiàng)目（需求）很多，但產(chǎn)品需求缺失。

項(xiàng)目級(jí)和產(chǎn)品級(jí)需求的具體區(qū)別，如果放在幾年或十多年前并不明顯，對(duì)于全新產(chǎn)品而言，項(xiàng)目（需求）=產(chǎn)品（需求）。隨著時(shí)間推移，兩者的區(qū)分逐步明朗，由于全新項(xiàng)目越來(lái)越少，更多的需求都是在維護(hù)和升級(jí)老的產(chǎn)品。

以咖啡機(jī)為例，從基本型升級(jí)到1.1版，或許是加入一個(gè)按鈕。此時(shí)和客戶溝通的時(shí)候就需要引導(dǎo)客戶想清楚，需要的是項(xiàng)目級(jí)還是產(chǎn)品級(jí)的需求，是做整個(gè)咖啡機(jī)的需求還是僅僅只是新添按鈕的需求。如果未來(lái)再做1.2版，繼續(xù)添按鈕，這時(shí)候的需求又該如何寫？新按鈕的需求，然后和以前的按鈕有些變化。如果不能明確兩種需求的差異，隨著項(xiàng)目需求的累積，到_后會(huì)發(fā)現(xiàn)所有的（需求）都是片段的，都是增量而缺乏一個(gè)總的全景。

事實(shí)上，業(yè)務(wù)IT需求造成如今的混亂狀況，CMMI（Capability Maturity Model Integration，能力成熟度模型集成）和國(guó)內(nèi)企業(yè)對(duì)CMMI的僵化理解可以說(shuō)“功不可沒(méi)”。在對(duì)“兩份需求”的認(rèn)識(shí)上，CMMI里有明確分項(xiàng)，用戶需求和軟件需求。但值得一提的是，其實(shí)里面并未明確要求是兩份文檔或由兩部分人來(lái)寫，而只是表示需求細(xì)化的兩個(gè)階段。遺憾的是，很多國(guó)內(nèi)CMMI認(rèn)證企業(yè)也并沒(méi)有真正打算去了解它的內(nèi)涵，只是僵化地表現(xiàn)出自己是否有這樣的能力。

_近接觸到一些項(xiàng)目也出現(xiàn)了這樣的情形，大家先做了一份用戶需求，然后花費(fèi)大量時(shí)間寫軟件需求，以滿足認(rèn)證的需要，但到頭來(lái)軟件需求根本沒(méi)人看，大家都只是應(yīng)付，CMMI成為了擺設(shè)。

需求貫穿于軟件開(kāi)發(fā)測(cè)試全過(guò)程

敏捷的_大貢獻(xiàn)在于它是對(duì)整個(gè)軟件工程的一次再認(rèn)識(shí)。具體到敏捷需求分析領(lǐng)域，其實(shí)涉及到一個(gè)核心問(wèn)題：是否承認(rèn)（軟件）需求可以在一開(kāi)始就搞清楚并確定下來(lái)？敏捷的答案是No！而在傳統(tǒng)瀑布式開(kāi)發(fā)中，更多的是合同式驗(yàn)證的情形，大多數(shù)客戶的思想基礎(chǔ)都是基于需求_初就能確定下來(lái)的。但事實(shí)上，這在當(dāng)前階段基本屬于“不可能完成的任務(wù)”，不符合軟件開(kāi)發(fā)本質(zhì)。在敏捷需求分析中，需求應(yīng)是貫穿于整個(gè)軟件生命周期全過(guò)程中并在其中不斷變更、迭代和完善。

敏捷需求分析認(rèn)為，需求應(yīng)建立在以用例為中心的需求文檔體系，采取協(xié)作式而非合同式的溝通方式之上。具體可分為五個(gè)關(guān)鍵點(diǎn)：

用例；

協(xié)作；

迭代，即需求不是一次_終確定，而是先完成主要框架，再通過(guò)迭代逐步精化；

整個(gè)過(guò)程中以分析為支撐，做需求同時(shí)也在做分析，分析模型的輸出結(jié)果應(yīng)跟需求分開(kāi)；

把用例分解到用戶故事，在整個(gè)軟件生命周期過(guò)程中來(lái)驅(qū)動(dòng)開(kāi)發(fā)和測(cè)試。

業(yè)務(wù)/技術(shù)溝通頻現(xiàn)“兩份需求”

同時(shí)還要考慮到的是，將兩份需求改為一份文檔，而不必死摳CMMI概念區(qū)分出用戶和軟件需求。首份需求稿將由SA（系統(tǒng)分析師）來(lái)牽頭完成，負(fù)責(zé)各方協(xié)調(diào)和溝通的工作。理想的情況下，整個(gè)團(tuán)隊(duì)在項(xiàng)目開(kāi)始前就應(yīng)搭建完畢，包括客戶、開(kāi)發(fā)測(cè)試人員都參與的寫作和迭代，而不是以往的由技術(shù)人員對(duì)用戶進(jìn)行里程碑式的教輔。通常來(lái)說(shuō)，一個(gè)項(xiàng)目里一名SA同時(shí)對(duì)應(yīng)5~9名開(kāi)發(fā)人員是比較合適的。

需求文檔化與敏捷的平衡點(diǎn)

至于用例和用戶故事。按照敏捷大師Martin博客中的說(shuō)法，兩者都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而用戶故事的目的是把需求分解成可用于迭代計(jì)劃的單元。對(duì)應(yīng)到產(chǎn)品級(jí)和項(xiàng)目級(jí)文檔，用例是產(chǎn)品級(jí)，例如做咖啡機(jī)，不管有多少不同版本，有些核心功能是不改變的，這些都是產(chǎn)品級(jí)需求。而用戶故事則是項(xiàng)目級(jí)，屬于做完就扔的“拋棄型”。

進(jìn)一步理解的話，用戶故事其實(shí)是一個(gè)或多個(gè)完整的業(yè)務(wù)場(chǎng)景，而用例是場(chǎng)景的抽象，一個(gè)用例里可以包含成百上千個(gè)場(chǎng)景。用戶故事是基于開(kāi)發(fā)思想的，不光要考慮業(yè)務(wù)，還要考慮如何實(shí)現(xiàn)包括工作量大小、任務(wù)分配、項(xiàng)目風(fēng)險(xiǎn)以及架構(gòu)風(fēng)險(xiǎn)等多重因素。有人認(rèn)為寫用戶故事是極簡(jiǎn)單的事，但在吳穹看來(lái)，現(xiàn)在有很多人都還在用功能點(diǎn)套用用戶故事，顯得不倫不類，而沒(méi)有理解到用戶故事的精髓。

案例分析

以ATM取款為例，正常流程是插卡、取錢、把錢拿走。這個(gè)看似簡(jiǎn)單的場(chǎng)景其實(shí)工作量很大，可以在整個(gè)流程中做一些必要的簡(jiǎn)化。有人認(rèn)為既然用戶故事是一個(gè)場(chǎng)景，那就把它變成一個(gè)場(chǎng)景步驟吧，于是就成了功能點(diǎn)。其實(shí)他們忽略了一點(diǎn)，用戶故事還是一個(gè)簡(jiǎn)化了但還_完整業(yè)務(wù)價(jià)值的場(chǎng)景。ATM取款建立用戶故事會(huì)涉及哪些因素呢？取款是否需要輸入密碼？小額取款時(shí)能否取消密碼輸入的步驟？取錢后打印賬單，查詢余額等，在這里面哪些功能是風(fēng)險(xiǎn)級(jí)別高的，哪些需要與銀行核心數(shù)據(jù)通信？這不僅涉及（功能）優(yōu)先級(jí)的問(wèn)題，還可以根據(jù)原則簡(jiǎn)化用戶故事。例如可以考慮做一個(gè)用戶故事，儲(chǔ)戶用不需驗(yàn)密的卡，限額是一千塊，取幾百塊錢的時(shí)候，把去銀行驗(yàn)證的過(guò)程取消掉。這種情形下很多時(shí)候都要考慮到賬戶的風(fēng)險(xiǎn)情況，這些都需要多方溝通。類似的用戶故事簡(jiǎn)化的情形有很多，但這時(shí)一定基于黑盒方式來(lái)做簡(jiǎn)化。而在簡(jiǎn)化的過(guò)程中，考慮如何實(shí)現(xiàn)如何合理調(diào)整工作量提高效率，這些都是找（用戶）故事的過(guò)程，也是一個(gè)白盒的過(guò)程。

你忍心就這樣宅在家里？剛過(guò)炎炎夏天，正是秋高氣爽的季節(jié)不如和家人朋友一起出門擁抱大自然負(fù)氧離子滿滿的新鮮空氣。不過(guò)還是要提醒大家由于國(guó)慶節(jié)人多，旅行健康安全還是要給予高度重視。

在實(shí)現(xiàn)上，除了強(qiáng)調(diào)快速交付或生命周期很短、業(yè)務(wù)模式高度可變的互聯(lián)網(wǎng)、網(wǎng)游等項(xiàng)目，可以采用純用例的模式，現(xiàn)階段讓（大型）企業(yè)IT項(xiàng)目全面接納需求完全無(wú)文檔化還是不現(xiàn)實(shí)的，更實(shí)際的解決辦法是在文檔化和敏捷需求分析之間找到一個(gè)平衡，一份需求用例加上用戶故事，然后驅(qū)動(dòng)開(kāi)發(fā)這種方式，目前看來(lái)，這是現(xiàn)階段更適合大型企業(yè)的敏捷需求實(shí)踐模式。

贊