大多數學計算機語言的人都會有過這樣的感受，過去一直認為程式設計和架構是整個軟體生命週期裡最了不起的部分，但實際工作後才會發現在商業產品裡，需求分析才是乙個商業軟體成功與否的關鍵。
放眼望去，在當今軟體工程領域出現的許多問題，諸如缺陷及資源運用不當，都源於需求的不清晰，甚至有軟體人戲稱：「需求變更乃萬惡之源」，一時也獲得了頗多響應。時至如今，業務it間需求分析過程中存在的問題主要有哪些？什麼是敏捷需求分析？產品級和專案級需求有何異同？敏捷需求分析方**中的五大關鍵點是什麼？就以上熱點話題，雅各布森中國區總經理吳穹分享了他的看法。
三大症狀
在吳穹看來，兩份需求、合同式驗證、產品需求缺失成為了當前需求溝通的三大癥結。
兩份需求——使用者（業務）需求和軟體需求。使用者需求由不熟悉it的業務人員完成，大多歸於天馬行空的意識流，基本上是想起什麼寫什麼。而軟體需求由it人員編寫，經過技術思維的過濾、梳理、增刪，包含進了演算法、資料庫設計、架構之類的技術專業詞彙，業務人員往往已不知文件內所雲。
合同式驗證——業務人員和技術人員企圖在溝通後以合同形式將需求固化並且確定下來，而沒有充分考慮到軟體開發過程中可能出現的需求變更。
產品需求缺失——專案是片段，產品是總量，兩者的關係在於專案其實就是乙個不斷完善產品的過程。由於國內pmp（projectmanagement professional）和專案管理流行，更多it需求都是以專案形式存在，而往往忽視了產品需求的積累，導致最後的結果多是專案（需求）很多，但產品需求缺失。
專案級和產品級需求的具體區別，如果放在幾年或十多年前並不明顯，對於全新產品而言，專案（需求）=產品（需求）。隨著時間推移，兩者的區分逐步明朗，由於全新專案越來越少，更多的需求都是在維護和公升級老的產品。以咖啡機為例，從基本型公升級到1.1版，或許是加入乙個按鈕。此時和客戶溝通的時候就需要引導客戶想清楚，需要的是專案級還是產品級的需求，是做整個咖啡機的需求還是僅僅只是新添按鈕的需求。如果未來再做1.2版，繼續添按鈕，這時候的需求又該如何寫？新按鈕的需求，然後和以前的按鈕有些變化。如果不能明確兩種需求的差異，隨著專案需求的累積，到最後會發現所有的（需求）都是片段的，都是增量而缺乏乙個總的全景。
事實上，業務it需求造成如今的混亂狀況，cmmi（capability maturity model integration，能力成熟度模型整合）和國內企業對cmmi的僵化理解可以說「功不可沒」。在對「兩份需求」的認識上，cmmi裡有明確分項，使用者需求和軟體需求。但值得一提的是，其實裡面並未明確要求是兩份文件或由兩部分人來寫，而只是表示需求細化的兩個階段。遺憾的是，很多國內cmmi認證企業也並沒有真正打算去了解它的內涵，只是僵化地表現出自己是否有這樣的能力。
最近接觸到一些專案也出現了這樣的情形，大家先做了乙份使用者需求，然後花費大量時間寫軟體需求，以滿足認證的需要，但到頭來軟體需求根本沒人看，大家都只是應付，cmmi成為了擺設。
需求貫穿於軟體開發測試全過程
在吳穹看來，敏捷的最大貢獻在於它是對整個軟體工程的一次再認識。具體到敏捷需求分析領域，其實涉及到乙個核心問題：是否承認（軟體）需求可以在一開始就搞清楚並確定下來？敏捷的答案是no！而在傳統瀑布式開發中，更多的是合同式驗證的情形，大多數客戶的思想基礎都是基於需求最初就能確定下來的。但事實上，這在當前階段基本屬於「不可能完成的任務」，不符合軟體開發本質。在敏捷需求分析中，需求應是貫穿於整個軟體生命週期全過程中並在其中不斷變更、迭代和完善。
敏捷需求分析認為，需求應建立在以用例為中心的需求文件體系，採取協作式而非合同式的溝通方式之上。具體可分為五個關鍵點：
用例；
協作；
迭代，即需求不是一次最終確定，而是先完成主要框架，再通過迭代逐步精化；
整個過程中以分析為支撐，做需求同時也在做分析，分析模型的輸出結果應跟需求分開；
把用例分解到使用者故事，在整個軟體生命週期過程中來驅動開發和測試。
業務/技術溝通頻現「兩份需求」
同時還要考慮到的是，將兩份需求改為乙份文件，而不必死摳cmmi概念區分出使用者和軟體需求。首份需求稿將由sa（系統分析師）來牽頭完成，負責各方協調和溝通的工作。理想的情況下，整個團隊在專案開始前就應搭建完畢，包括客戶、開發測試人員都參與的寫作和迭代，而不是以往的由技術人員對使用者進行里程碑式的教輔。通常來說，乙個專案裡一名sa同時對應5~9名開發人員是比較合適的。
需求文件化與敏捷的平衡點
至於用例和使用者故事。按照敏捷大師martin部落格中的說法，兩者都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而使用者故事的目的是把需求分解成可用於迭代計畫的單元。對應到產品級和專案級文件，用例是產品級，例如做咖啡機，不管有多少不同版本，有些核心功能是不改變的，這些都是產品級需求。而使用者故事則是專案級，屬於做完就扔的「拋棄型」。
進一步理解的話，使用者故事其實是乙個或多個完整的業務場景，而用例是場景的抽象，乙個用例裡可以包含成百上千個場景。使用者故事是基於開發思想的，不光要考慮業務，還要考慮如何實現包括工作量大小、任務分配、專案風險以及架構風險等多重因素。有人認為寫使用者故事是極簡單的事，但在吳穹看來，現在有很多人都還在用功能點套用使用者故事，顯得不倫不類，而沒有理解到使用者故事的精髓。
以atm取款為例，正常流程是插卡、取錢、把錢拿走。這個看似簡單的場景其實工作量很大，可以在整個流程中做一些必要的簡化。有人認為既然使用者故事是乙個場景，那就把它變成乙個場景步驟吧，於是就成了功能點。其實他們忽略了一點，使用者故事還是乙個簡化了但還保證完整業務價值的場景。atm取款建立使用者故事會涉及哪些因素呢？取款是否需要輸入密碼？小額取款時能否取消密碼輸入的步驟？取錢後列印賬單，查詢餘額等，在這裡面哪些功能是風險級別高的，哪些需要與銀行核心資料通訊？這不僅涉及（功能）優先順序的問題，還可以根據原則簡化使用者故事。例如可以考慮做乙個使用者故事，儲戶用不需驗密的卡，限額是一千塊，取幾百塊錢的時候，把去銀行驗證的過程取消掉。這種情形下很多時候都要考慮到賬戶的風險情況，這些都需要多方溝通。類似的使用者故事簡化的情形有很多，但這時一定基於黑盒方式來做簡化。而在簡化的過程中，考慮如何實現如何合理調整工作量提高效率，這些都是找（使用者）故事的過程，也是乙個白盒的過程。
在實現上，除了強調快速交付或生命週期很短、業務模式高度可變的網際網路、網遊等專案，可以採用純用例的模式，現階段讓（大型）企業it專案全面接納需求完全無文件化還是不現實的，更實際的解決辦法是在文件化和敏捷需求分析之間找到乙個平衡，乙份需求用例加上使用者故事，然後驅動開發這種方式，目前看來，這是現階段更適合大型企業的敏捷需求實踐模式。
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...