400-888-5228

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 MasterITIL4 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)品。

五個(gè)敏捷需求分析的關(guān)鍵因素 -- 第1張

以咖啡機(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ò)程。

五個(gè)敏捷需求分析的關(guān)鍵因素 -- 第3張

你忍心就這樣宅在家里?剛過(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í)踐模式。

發(fā)表回復(fù)

您的電子郵箱地址不會(huì)被公開(kāi)。 必填項(xiàng)已用*標(biāo)注

  • 2024-09-26 20:00
    職場(chǎng)故事:從戰(zhàn)略規(guī)劃到項(xiàng)目管理交付
  • 2024-10-10 20:00
    解決方案評(píng)價(jià):評(píng)估解決方案的高效績(jī)效工具
  • 2024-10-15 20:00
    研發(fā)績(jī)效管理:組織戰(zhàn)略如何解碼到績(jī)效指標(biāo)?組織績(jī)效與個(gè)人績(jī)效管理
  • 2024-10-17 20:00
    科學(xué)的降本增效
  • 2024-10-22 20:00
    職場(chǎng)故事:“煉金術(shù)”與數(shù)字的交響曲:一位化學(xué)研發(fā)工程師的職業(yè)升級(jí)之旅
  • 2024-10-24 20:00
    助力財(cái)務(wù)運(yùn)營(yíng)自動(dòng)化:機(jī)器人流程自動(dòng)化(RPA)技術(shù)的實(shí)際應(yīng)用
  • 2024-10-29 20:00
    職場(chǎng)故事:從在日工作的經(jīng)驗(yàn)教訓(xùn)談職場(chǎng)需要的技能
  • 2024-10-30 20:00
    嚴(yán)謹(jǐn)求實(shí):安全評(píng)估和測(cè)試
  • 2024-10-31 20:00
    什么是數(shù)據(jù)標(biāo)準(zhǔn)?如何制定數(shù)據(jù)標(biāo)準(zhǔn)?這份指南送上
  • 更多直播講座
    小艾老師還在安排中…
查看全部 >

掃碼一鍵預(yù)約全部

查看更多 > 查看更多 >

數(shù)字化轉(zhuǎn)型8大核心認(rèn)證

  1. PMP項(xiàng)目管理認(rèn)證

    聽(tīng)
    艾威最近一期班: 針對(duì)2025年03月考試
  2. CBAP業(yè)務(wù)分析認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-11-23
  3. CBPP流程管理認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-12-07
  4. ITIL4 IT管理認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-10-26
  5. TOGAF企業(yè)架構(gòu)認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-11-02
  6. CDMP數(shù)據(jù)管理認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-11-23
  7. CISA信息安全審計(jì)師認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-12-01
  8. CISSP信息安全專家認(rèn)證

    聽(tīng)
    艾威最近一期班·開(kāi)課時(shí)間: 2024-11-16
近期課程安排