[軟體工程]敏捷開發與常規開發的需求過程差別的原因，我寫的書和評價

老師，線上嗎?

青潤  15:02:40

在。

北京-FireSpider 男  15:03:33

老師，敏捷開發的需求過程好像和常規的需求過程不太一樣！？

青潤  15:03:50

沒有什麼不一樣的，敏捷開發也只是一種開發過程形式。

需求也有各種不同的採集形式，不能認為你所熟悉的就是常規需求過程，實際上需求的獲取本身就是多種多樣的。

北京-FireSpider 男  15:05:32

敏捷的使用者故事，從表述上來看，更像是使用者零散提出來的需求，不具有整體型，無法做整體的需求分析。

青潤  15:06:00

其實，實際的專案中的需求，使用者也是零散提出來的，不要太關注形式，要關注需求內在的聯絡。

北京-FireSpider 男  15:06:09

哦

青潤  15:07:14

只不過就在於使用者是否坐在一起給你提出需求而已。

敏捷只是把這種提出需求的形式更靈活化了。

實際上在十多年前我做的電信mss系統調研中，我們也是分成兩個組分別在集團公司和各省公司進行需求調研採集，在集團公司這邊，我也是一個一個使用者進行詢問，經過多次往復確認的過程採集下來的。

北京-FireSpider 男  15:07:12

需求的這一系列過程，在敏捷開發中也是一樣的做法？

青潤  15:08:11

從一個一個使用者存在和出現的隨機性上可以看到，這其實也是零散的，在外表上並不是系統化的，唯一可以控制的系統化需求的表現在內在，也就是說，所有的需求都是與你調研的業務相關的，而無關的業務都會被你所忽視或者放棄。

每一個單獨的需求的全過程看起來，也都是一樣的做法，最多是順序有些不同。

北京-FireSpider 男  15:08:52

哦，是這樣。

青潤  15:09:02

當你到了元用例層面進行需求處理和開發的時候，就會發現，其實都是一樣的。

北京-FireSpider 男  15:09:34

我沒執行過敏捷開發，在開發之前的需求階段通常是一次性獲取需求，然後如果使用者有變化的化，再做需求變更。

青潤  15:09:52

而很多隻懂得追逐潮流和本本主義者往往強調其個性，而忽視其內在的聯絡和本質。

所以，很多所謂極端的敏捷開發者，刻意強調自己的特立獨行和與眾不同，實際上是很荒謬的做法和言論。

北京-FireSpider 男  15:09:56

但開發的過程，通常是類似敏捷的。

嗯，確實是。

青潤  15:11:18

一次性獲取需求在新的使用者環境下往往不大可能。

注意拆分出來，注意條理性，注意分階段的獲取，注意使用者深層次需求的挖掘，這些往往比一次性獲取需求可以得到更完善的需求資訊。

而一次性獲取的時候，使用者因為個人原因或者某些因素會遺忘一些需求的細節，或者描述不清楚一些內容，開發者也會因為自己的想象去假設一些需求的內容和細節，於是就會造成需求的實現與使用者所需之間的差異。

結果，系統後期的變更就會非常多。

系統開發的延期就不可避免了。

北京-FireSpider 男  15:11:58

是的，通常系統在開發出來之後，會發生很多需求變更，導致軟體出現較大的重構。

這個時候是最痛苦的，畢竟軟體已經做了，再改動，很困難的。

青潤  15:12:30

實際上系統中後期的變更也都是需求的再次調研和採集過程，而很多專案的乙方為了讓甲方不會因此感覺到自己的系統開發能力不足，就用各種藉口來遮掩這樣的問題出現，實際上結果就是欲蓋彌彰，卻又不得不如此。

北京-FireSpider 男  15:12:45

將變化儘量控制在前期，我覺得搞系統原型是最好的辦法。

是的，系統做得死，是無力應付變化的根本原因。

北京-FireSpider 男  15:13:50

系統能夠較容易應付變化，系統就得要做得更加靈活，這確實需要在平臺層面下功夫。

青潤  15:14:03

只能說把可以找尋到的變化儘量控制在前期，另外在開發過程中隨時準備應對變化。

這個不僅僅在xp，在up和其他過程中也都有介紹。

北京-FireSpider 男  15:19:45

老師，如何控制需求範圍？有的時候，客戶漫天瞎提需求。

青潤  15:20:42

關於控制需求的問題在我曾經的培訓中提到過幾種方法。

1、關係處理

2、技術影響

3、使用者信任

4、實際討論

5、明確責任

青潤  15:21:42

大體上這幾個方面，不一定完善。

總之，我一般是在使用者那裡樹立很好的技術形象，使用者對我的信任，我提出對需求的異議的時候，使用者會非常相信認同，並配合我進行相應的風險處理和思考解決方法。

青潤  15:23:03

如果你做不到，那往往是被使用者牽引著到處走，因為你無法讓使用者信任你。

那就是使用者說什麼你做什麼了。

北京-FireSpider 男  15:24:23

是的，和客戶的關係得處，處好了，怎麼都好說，處不好，很難開展工作。

我還記得02年在搞大興安嶺資源局的專案，那個專案我們在需求上犯了很多錯誤。

青潤  15:25:08

不是單純處得好，而是要讓使用者對你這個人或者對負責技術溝通的人的技術和經驗的信任。

北京-FireSpider 男  15:27:43

1、為對客戶業務進行仔細深入的研究，兩週的調研，僅僅是拿回來一大堆單據（這個我沒參與，我是之後到這個公司的）和一份簡單的科室業務與單據的關係描述。開發人員面對一堆單據和描述文件，無從下手，只是推著做，做到哪兒算到哪兒。結果哪給客戶一看，全盤否定，沒有幾個是他們要的。

得出結論：需求階段沒有調研到客戶真正想要的東西。

倒是拿來一大堆垃圾需求。

青潤  15:30:13

嗯。這種現象很常見。

北京-FireSpider 男  15:30:16

2、客戶一看這樣不行，要求我們現場開發，我們到業務科室，一邊看著他們工作一邊開發。但是每個科室都“只見樹木，不見森林”，到科室間資料互動時，再次遇到問題。

青潤  15:30:30

需求人員其實不懂得什麼是需求，也不懂得如何進行需求提取，於是就只能拿回來很多東西。

北京-FireSpider 男  15:31:53

09年我到這個公司，好很多，因為這個公司在石油石化行業打拼很多年了，行業基礎好，需求調研人員很專業，這種問題很少出了。

但是需求人員也重來沒有用UML建模，更很少搞介面原型。

青潤  15:32:38

嗯。

北京-FireSpider 男  15:33:02

所以也會有些問題，不過很少。這可能主要是靠公司的積累對客戶需求的覆蓋和引導，以及需求調研人員的經驗。

可以說，直到目前，包括我本人在內，也從未用UML真正做過需求調研。不過我在用UML，但是隻是用於自己整理思路。

青潤  15:34:26

用好了uml是不錯的，但是很多往往用不好，其實，哪怕只能部分用好也能對需求起到很好的引導作用。

北京-FireSpider 男  15:34:30

嗯

UML是好東西，不過我用的也是前期引導思路，後期上了編碼，就是編碼引導思路了。

青潤  15:35:12

我的書中有例子，2002年電信mss系統的初始UML需求是何等的混亂，那張uml圖業內很多朋友看過後都很震驚。

我過去處理後的分層結構圖一下子一切都明晰了。

北京-FireSpider 男  15:35:29

哦，有一張圖，很大的，是吧？

在42頁。

北京-FireSpider 男  15:38:41

老師，我覺得UML可能就像我說得作法比較現實：用於前期引導思路、後期重構時的思路梳理。真正開發起來，還是得靠程式碼去引導思路。

 安全提示：如果聊天中有涉及財產的操作，請一定先核實好友身份。傳送驗證問題或點選舉報

青潤  15:38:49

我忘記在哪一頁了，那張圖還是刪掉了十多個用例後的，否則根本擺不下。

實際上，從設計引導程式碼，會是最好的解決辦法。

程式設計師習慣於從程式碼思考，往往取之片面，容易形成精巧的小業務系統，卻無法處理大而複雜的綜合性系統。

青潤  15:40:20

uml給了一種更好的從整體視角到區域性視角的系統設計視角，讓我們可以從設計著眼，而不是從程式碼層向上看。

北京-FireSpider 男  15:40:32

北京-FireSpider 男  15:41:59

這是一個手持終端通訊臺的前期設計，我用UML梳理思路，等到編碼開始後，我就再也沒有更新這個圖。因為，程式碼可以引導思路了。

青潤  15:42:26

呵呵，如果你能從設計引導思路，那時候，你會看到另一片更好的天地。

北京-FireSpider 男  15:43:07

但，我不清楚，如果這個設計給別人用，會事什麼樣子。因為我發現底下人搞開發，你得給他指得非常明白才行。所以這種粗略的設計，他們恐怕無法去做。

青潤  15:44:29

你把我書中設計到程式碼的章節都看懂了，應該能明白。

北京-FireSpider 男  15:45:06

嗯，我正在細看，也是一邊看，一邊用UML的方式把書中的內容量化出來。

北京-FireSpider 男  15:46:34

這是我做的量化，呵呵。

青潤  15:46:43

我用了9年的時間寫的東西，裡面沒有垃圾和任何無用的資訊，不要疏漏任何一點。

如果為了賺錢，我就不會用9年來寫一本書了，也不會寫得這麼薄，隨便扔點java基礎和uml基礎，都可以翻一倍以上的容量。

呵呵，沒事，任何嘗試都是有價值的，我不怕別人做得更好。

北京-FireSpider 男  15:47:45

嗯，老師，您的書確實是經驗的積累，很實用。現在很多計算機書籍跟實踐脫軌，導致無法應用的，不在少數。真正體現出實用價值的確實很少。

北京-FireSpider 男 15:49:12

多謝老師耐心指點。