互聯網 - 大數據

普天之下莫非王土，貌似是真理。。。額。。淡定淡定，土也有肥與不肥之分。。哈哈。

灰常有趣，現在公司開發模式采用了敏捷開發之scurm方法，最初也是神密與憧憬還夾帶著疑問，嗯，是的，不了解則無法理解。于是就scurm進行中。。也許是太了解了就容易生厭，就好像夫妻有個什么七年之癢似的，我還沒7年就有點癢了。最初的神密沒了，疑問變成了反問，當然憧景還是有滴。

每當看到敏捷開發的文章都來一段《敏捷宣言》，立馬站直抬頭看天空，高喊：

個體與交互 重于設 計過程和工具      

可用的軟件 重于 完備的文檔      

客戶協作 重于 合同談判      

響應變化 重于 遵循計劃

然而念多了就會覺得喊口號容易，干事情真難。于是乎就從反過來的角度思考宣言，才發現這宣言也是狗屁不是啊。說的好聽點是廢話。哦，我是不是得罪大多數敏捷開發者了？？我才狗屁不是。。。對對，你們是狗屁，我不是。。哈哈

我們之所以會認可敏捷開發，一定程度上是因為之前的開發過程太糾結，無序的計劃，無盡

的任務和無盡的交流加上無盡的BUG。所以想尋求一種開發方法來解決，敏捷開發是一種很好的方法，他解決了什么呢？

1. 使用迭代來解決開發周期與目標的混亂
2. 使用合理的交流方式來促進問題的分析與解決
3. 有了好的迭代就如同有了可執行的計劃，所以交付制品也更加快速，安全
4. 提高了對個體的要求，一方面個體除了會完成任務外，還要會交流，交互，更重要是明白你不是一個人在戰斗（哈哈）
5. 領導放心了，因為他能看到任務在一個接一個的咔嚓掉。

除上面這些之外呢？也許有吧，哦，你會說：

完備文檔被好的制品替代了？

和客戶有交流了？

擁抱變化了？

老兄，這些問題你覺得哪一個開發方法不重視？如果不重視也不是開發方法的問題，而是具體執行人員的問題，這些問題即使使用了敏捷，你解決了嗎？？反問自己吧。

說了些打擊自己和他人的話，也要找找解決的方法。最近因為工作上的原因，所以就看了一些關于敏捷的資料，也切身的思考了實際開發中對敏捷的應用。也發現很多人都在分析敏捷開發在實際應用中存在的問題，也有提出了解決方法的人。我不是高手，但別人不能阻止我像高手那樣叼根煙。。。所以我也叼根煙。咳咳。。

Scurm的可謂是覆蓋面夠廣呀，真是做到了個體的交互，“客戶”的協作，響應變化。但是咱們拿出來分析一下：

個體的交互？

就是你和我交互了，我把可以說的隨便說一下，不想說的不說，交互的結果就是你知道了又怎么樣呢？

敏捷思想是希望能把需求也好、問題也好，拿出來溝通，但要讓開發人員把這些東西拿出來說還是要靠方法滴。Scrum約定了很多會，最值得提的還是站會吧，這個是每天都要做的事情，做的好提高效率，做的不好就是浪費時間。借用網上一個家伙提到的例子：

站立會議=審問？

我們自己想想，是不是這個樣子？所以我們這些當兵的就只好把可以說的隨便說說了，有問題？沒有，咱們沒問題。領導我保證完成任務。好吧，領導放心了。

我覺得吧，不能這樣，既然是站立會議就是要快，要有效。把大家一起聚集起來是討論問題的，領導也好、Master也好不要去問些無趣的問題，如果想要問問題就必須把每個開發任務都弄清楚，知道任務的關鍵點。

比如你問：HI，兄弟這個任務要搞定千萬級數據緩存問題耶？你現在用的什么方法呢？

被問的人說：我不知道耶，正在想。

那好了，這個問題效果來了，不需要再解釋了吧？

個體的交互，目的是交流溝通，把一些潛在問題消滅掉，而不是領導問進度，要充分相信自己共事的人，把問題分析清楚，不要把任務逼成潛在問題。

一個團隊不要把階層劃的太過份，很多問題不一定是老手才能解決，有時新手也能有更加出色的點子，解決方法更加獨特有效，要充分發揮團隊的作用。

做為Leader更是要把外界的壓力減到最低，讓團隊成員在執行任務時可以專心，不能因為自己壓力大，就讓成員也跟著無序，心急。否則要Leader干什么？同樣的，團隊成員也要負起自己的責任，把事情做好，有問題就要盡快交流。這樣Leader才能知曉，調配資源。最終目的就是把開會變成溝通，而不是碰頭，頭都碰爛了，最后發現啥也沒干。

“客戶”的協作，交互可用的制品？

之所以敏捷開發會強調客戶的作用，就是希望能讓客戶把問題充分描述，以保證開發的產品符合要求。在很多時候客戶的需求不一定是合理的，如果不告訴客戶，結果就是客戶和開發都成了SB，不要以為收到了客戶的錢就是成功。最后客戶SB的發現自己付的錢沒用時，會讓你吐的更多，這時你更SB。

敏捷開發就是希望把問題解決在需求階段，讓一個個迭代來與客戶交流，讓客戶了解制品，對產品產生概念，從而反饋到最真實的需求模型。好了，我們真的這么做了嗎？？？

很多時候，我們開發人員又如何能知道客戶真實的需求呢？需求背景描述？跟著現場人員討論？與客戶討論？都是方法，那最終體現是什么呢？怎么算能認賬？

敏捷不等于沒文檔，制品也不能代替文檔，與客戶交流就更加是了，說了一大堆，沒有個記錄，你敢說你交流的充分了？絕大多數時候，不寫文檔都是因為懶，然后敏捷說不需要完備的文檔，這下好了，直接就可以歡天喜地了，不用寫文檔咯。。自己問問自己是不是這樣？文檔真的不是DOC,PPT，文檔有很多形式，與客戶交流時可以用用例模型，界面原型工具，有時文檔就是一段話，甚至是一句話。比如：客戶希望把登錄按鈕默認為按回車。

文檔的目的是為了記錄、傳播、更加充分的討論，你一個人懂了不代表所有人懂了。把自己的工作做踏實點，把建模過程做起來。從源頭上提高交流的效率效果，文檔有很多，我比較推薦的方法是：建模。

UML建模是軟件開發領域的一種描述語言，他的好處是統一、規范、描述性強。從客戶開始就可以有需求建模，界面原型建模等。這個工作客戶如果沒有能力就讓需求分析人員做，讓客戶明白后再轉到開發。這種事情不存在增加工作量，和客戶交流總歸是要有文檔的，只不過是換種形式而已。

開發則更重要了，一個需求如何開發，一拍腦袋就這么干吧，拍腦袋的過程是在干什么呢？不就是在把需求分析成一個個的程序模型嗎？為什么不記錄下來呢？把分析的過程轉成一種可描述的語言，這不是更好？除了你自己之外，還可以上其他人閱讀。而且用模型工具也能一定程度上提高分析效果。同樣的，UML建模之后再與市場人員進行交流時就更加充分了，UML不僅僅是只有開發人員懂。市場、測試甚至很多客戶都具備這樣的能力。而且圖形化的描述，客戶也更能理解接受。

響應變化？

計劃趕不上變化，這大多數情況下就是事實。敏捷開發是想通過迭代及溝通來解決變化給項目的影響。然而更多的時候變化就是會影響到計劃，而且讓人很不爽又不得不干，理由很多，如：什么客戶就要這么干，那個時候必須要，云云。。。其實這個事情真的很急，但是急有什么用？

所以我對響應變化的理解是：把計劃做到容忍變化才是解決之道。通常公司有了績效考核后會對開發工作進行量化，好了，領導一看，反正一個月就這么多時間，給我排排滿。然后各個開發負責人就排排滿。迭代之初大家興高采烈的領了任務，估了任務時間，咔嚓。等到快要交付的時候，因為雞鴨魚的原因，狗沒吃到屎，我去。

Leader很深情的說：沒辦法，大家加加班吧，領導說了要做完，客戶有這個要求，弟兄們地球會因為我們的努力繼續轉的。然后與客戶打交道的同事用上吊來威脅你：兄弟，不做完，我就死在這了，我能不能活就看你了。看著辦吧！

怎么辦？我不入地獄，誰入？于是乎噼里啪啦，回了句：哥能行。

好了，若干時間后，BUG大爺出現了。。。。。。。。。。。。。。

呵呵。開個玩笑，計劃與變化，是個很難協調的話題。但是我一直認為一個計劃一定是可執行的，如果一個計劃只是一種形式，那肯定會有很多問題。變化也是相對于計劃才有的，對吧？那好就把計劃與變化劃分清楚，把什么是計劃什么是變化弄清楚。

迭代的目的就是把計劃做到可執行，把一個短周期內安排的事情做完，給客戶提交一個可信的制品。如果你的計劃總是有這種那種原因被打斷，一個迭代周期總是不讓別人爽，那么你自己也不用想爽。這就得說說Scrum的需求評估，通常在Scrum會議上任務是由成員估時并認領的，那么，這個估時準不準就會成為重要的因素。不準，是多了少了？不管是多是少都是不準。怎么樣才能準？如果到這時還不明白，那就繼續擁抱變化吧！

呵呵，其實很簡單，需求描述準確，開發人員理解準確，估時還會相差很大嗎？如果很大那就是人品的問題了。

對了，還有測試，測試一定要懂的。

總結一下：軟件開發是個系統工程，他涉及的人是方方面面，人涉及的多就會有交流問題，交流大家都知道很容易產生偏差，只有想辦法把偏差減少才能減少變化。前面聊的個體交互與客戶協作都是強調了內容的一致性，這才是敏捷開發帶給我們的。

不管是和團隊成員交互，還是與客戶交互，要形成一致的語言，只有語言一致了才能理解相互在說什么，干什么。