PMI-ACP認證是由美國項目管理協(xié)會（PMI）于2011年推出的一種敏捷項目管理認證。它是PMI針對敏捷實踐者的資格認證，同時也是敏捷項目管理的行業(yè)標準。該認證旨在評估從業(yè)者在敏捷方法、實踐和工具方面的知識和技能，以及在敏捷環(huán)境中管理項目的能力。通過PMI-ACP認證，可以證明個人在敏捷項目管理方面的專業(yè)能力和實踐經(jīng)驗。
大多數(shù)學(xué)計算機語言的人都會有過這樣的感受，過去一直認為編程和架構(gòu)是整個軟件生命周期里_了不起的部分，但實際工作后才會發(fā)現(xiàn)在商業(yè)產(chǎn)品里，需求分析才是一個商業(yè)軟件成功與否的關(guān)鍵。
放眼望去，在當今軟件工程領(lǐng)域出現(xiàn)的許多問題，諸如缺陷及資源運用不當，都源于需求的不清晰，甚至有軟件人戲稱：“需求變更乃萬惡之源”，一時也獲得了頗多響應(yīng)。時至如今，業(yè)務(wù)IT間需求分析過程中存在的問題主要有哪些？什么是敏捷需求分析？產(chǎn)品級和項目級需求有何異同？敏捷需求分析方法論中的五大關(guān)鍵點是什么？就以上熱點話題，雅各布森中國區(qū)總經(jīng)理吳穹分享了他的看法。
三大癥狀 兩份需求、合同式驗證、產(chǎn)品需求缺失成為了當前需求溝通的三大癥結(jié)。
兩份需求 ——用戶（業(yè)務(wù)）需求和軟件需求。用戶需求由不熟悉IT的業(yè)務(wù)人員完成，大多歸于天馬行空的意識流，基本上是想起什么寫什么。而軟件需求由IT人員編寫，經(jīng)過技術(shù)思維的過濾、梳理、增刪，包含進了算法、數(shù)據(jù)庫設(shè)計、架構(gòu)之類的技術(shù)專業(yè)詞匯，業(yè)務(wù)人員往往已不知文檔內(nèi)所云。
合同式驗證 ——業(yè)務(wù)人員和技術(shù)人員企圖在溝通后以合同形式將需求固化并且確定下來，而沒有充分考慮到軟件開發(fā)過程中可能出現(xiàn)的需求變更。
產(chǎn)品需求缺失 ——項目是片段，產(chǎn)品是總量，兩者的關(guān)系在于項目其實就是一個不斷完善產(chǎn)品的過程。由于國內(nèi)PMP（Project Management Professional）和項目管理流行，更多IT需求都是以項目形式存在，而往往忽視了產(chǎn)品需求的積累，導(dǎo)致_后的結(jié)果多是項目（需求）很多，但產(chǎn)品需求缺失。
項目級和產(chǎn)品級需求的具體區(qū)別，如果放在幾年或十多年前并不明顯 ，對于全新產(chǎn)品而言，項目（需求）=產(chǎn)品（需求）。隨著時間推移，兩者的區(qū)分逐步明朗，由于全新項目越來越少，更多的需求都是在維護和升級老的產(chǎn)品。
以咖啡機為例，從基本型升級到1.1版，或許是加入一個按鈕。此時和客戶溝通的時候就需要引導(dǎo)客戶想清楚，需要的是項目級還是產(chǎn)品級的需求，是做整個咖啡機的需求還是僅僅只是新添按鈕的需求。如果未來再做1.2版，繼續(xù)添按鈕，這時候的需求又該如何寫？新按鈕的需求，然后和以前的按鈕有些變化。如果不能明確兩種需求的差異，隨著項目需求的累積，到_后會發(fā)現(xiàn)所有的（需求）都是片段的，都是增量而缺乏一個總的全景。
事實上，業(yè)務(wù)IT需求造成如今的混亂狀況，CMMI（Capability Maturity Model Integration，能力成熟度模型集成）和國內(nèi)企業(yè)對CMMI的僵化理解可以說“功不可沒”。在對“兩份需求”的認識上，CMMI里有明確分項，用戶需求和軟件需求。但值得一提的是，其實里面并未明確要求是兩份文檔或由兩部分人來寫，而只是表示需求細化的兩個階段。遺憾的是，很多國內(nèi)CMMI認證企業(yè)也并沒有真正打算去了解它的內(nèi)涵，只是僵化地表現(xiàn)出自己是否有這樣的能力。
_近接觸到一些項目也出現(xiàn)了這樣的情形，大家先做了一份用戶需求，然后花費大量時間寫軟件需求，以滿足認證的需要，但到頭來軟件需求根本沒人看，大家都只是應(yīng)付，CMMI成為了擺設(shè)。
需求貫穿于軟件開發(fā)測試全過程 敏捷的_大貢獻在于它是對整個軟件工程的一次再認識。具體到敏捷需求分析領(lǐng)域，其實涉及到一個核心問題：是否承認（軟件）需求可以在一開始就搞清楚并確定下來？敏捷的答案是No！而在傳統(tǒng)瀑布式開發(fā)中，更多的是合同式驗證的情形，大多數(shù)客戶的思想基礎(chǔ)都是基于需求_初就能確定下來的。但事實上，這在當前階段基本屬于“不可能完成的任務(wù)”，不符合軟件開發(fā)本質(zhì)。在敏捷需求分析中，需求應(yīng)是貫穿于整個軟件生命周期全過程中并在其中不斷變更、迭代和完善。
敏捷需求分析認為，需求應(yīng)建立在以用例為中心的需求文檔體系，采取協(xié)作式而非合同式的溝通方式之上。具體可分為五個關(guān)鍵點：
用例；
協(xié)作；
迭代，即需求不是一次_終確定，而是先完成主要框架，再通過迭代逐步精化；
整個過程中以分析為支撐，做需求同時也在做分析，分析模型的輸出結(jié)果應(yīng)跟需求分開；
把用例分解到用戶故事，在整個軟件生命周期過程中來驅(qū)動開發(fā)和測試。
業(yè)務(wù)/技術(shù)溝通頻現(xiàn)“兩份需求” 同時還要考慮到的是，將兩份需求改為一份文檔，而不必死摳CMMI概念區(qū)分出用戶和軟件需求。首份需求稿將由SA（系統(tǒng)分析師）來牽頭完成，負責(zé)各方協(xié)調(diào)和溝通的工作。理想的情況下，整個團隊在項目開始前就應(yīng)搭建完畢，包括客戶、開發(fā)測試人員都參與的寫作和迭代，而不是以往的由技術(shù)人員對用戶進行里程碑式的教輔。通常來說，一個項目里一名SA同時對應(yīng)5~9名開發(fā)人員是比較合適的。
需求文檔化與敏捷的平衡點 至于用例和用戶故事。按照敏捷大師Martin博客中的說法，兩者都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而用戶故事的目的是把需求分解成可用于迭代計劃的單元。對應(yīng)到產(chǎn)品級和項目級文檔，用例是產(chǎn)品級，例如做咖啡機，不管有多少不同版本，有些核心功能是不改變的，這些都是產(chǎn)品級需求。而用戶故事則是項目級，屬于做完就扔的“拋棄型”。
進一步理解的話，用戶故事其實是一個或多個完整的業(yè)務(wù)場景，而用例是場景的抽象，一個用例里可以包含成百上千個場景。用戶故事是基于開發(fā)思想的，不光要考慮業(yè)務(wù)，還要考慮如何實現(xiàn)包括工作量大小、任務(wù)分配、項目風(fēng)險以及架構(gòu)風(fēng)險等多重因素。有人認為寫用戶故事是極簡單的事，但在吳穹看來，現(xiàn)在有很多人都還在用功能點套用用戶故事，顯得不倫不類，而沒有理解到用戶故事的精髓。
案例分析 以ATM取款為例，正常流程是插卡、取錢、把錢拿走。這個看似簡單的場景其實工作量很大，可以在整個流程中做一些必要的簡化。有人認為既然用戶故事是一個場景，那就把它變成一個場景步驟吧，于是就成了功能點。其實他們忽略了一點，用戶故事還是一個簡化了但還_完整業(yè)務(wù)價值的場景。ATM取款建立用戶故事會涉及哪些因素呢？取款是否需要輸入密碼？小額取款時能否取消密碼輸入的步驟？取錢后打印賬單，查詢余額等，在這里面哪些功能是風(fēng)險級別高的，哪些需要與銀行核心數(shù)據(jù)通信？這不僅涉及（功能）優(yōu)先級的問題，還可以根據(jù)原則簡化用戶故事。例如可以考慮做一個用戶故事，儲戶用不需驗密的卡，限額是一千塊，取幾百塊錢的時候，把去銀行驗證的過程取消掉。這種情形下很多時候都要考慮到賬戶的風(fēng)險情況，這些都需要多方溝通。類似的用戶故事簡化的情形有很多，但這時一定基于黑盒方式來做簡化。而在簡化的過程中，考慮如何實現(xiàn)如何合理調(diào)整工作量提高效率，這些都是找（用戶）故事的過程，也是一個白盒的過程。
你忍心就這樣宅在家里？剛過炎炎夏天，正是秋高氣爽的季節(jié)不如和家人朋友一起出門擁抱大自然負氧離子滿滿的新鮮空氣。不過還是要提醒大家由于國慶節(jié)人多，旅行健康安全還是要給予高度重視。
在實現(xiàn)上，除了強調(diào)快速交付或生命周期很短、業(yè)務(wù)模式高度可變的互聯(lián)網(wǎng)、網(wǎng)游等項目，可以采用純用例的模式，現(xiàn)階段讓（大型）企業(yè)IT項目全面接納需求完全無文檔化還是不現(xiàn)實的，更實際的解決辦法是在文檔化和敏捷需求分析之間找到一個平衡，一份需求用例加上用戶故事，然后驅(qū)動開發(fā)這種方式，目前看來，這是現(xiàn)階段更適合大型企業(yè)的敏捷需求實踐模式。
艾威國際網(wǎng)校
艾威天貓旗艦店
艾威官方微信
艾威網(wǎng)校官方微信
艾威官方視頻號
艾威知乎號
企業(yè)微信客服
TOGAF 10定義的5大類22小類利益相關(guān)者，企業(yè)架構(gòu)師如何與他們協(xié)同工作?
