杭州app開發經驗總結
2018-08-13

軟件開發是一個發展很快的行業,杭州app開發的市場日新月異,作為一名程序員需要具備開放的心智,以應對不同的環境下不同的開發模式。提出有用的軟件開發方法并不容易。困難不在于定義它們,而是說服別人遵循。本文作者從《人類簡史:從動物到上帝》一書中透過現象看本質,解析初創團隊到大規模團隊的軟件開發模式不同之處,分享其 20 年的軟件開發經驗。


智人和集體創作模式

最近我閱讀了 Yuval Harari 的《人類簡史:從動物到上帝》一書。這本書的基本論點是:人類需要“集體創作”,因此我們可以在多于 150 人的情況下進行合作,我們的大腦足以應付。集體創作針對那些無法在現實世界中看見和摸到的事物。諸如宗教、民族主義、自由民主或波普爾哲學。雖然這些事物不存在,但是當我們像他們一樣行事時,我們很容易忘記他們并不存在。


IT 行業的集體創作模式


1. 瀑布模型


這促使我聯想到當今一些關于軟件工程領域的事情,它們困擾著我。20 年前當我投身軟件行業時,瀑布模型占據統治地位。我加入了一個約 400 人的咨詢公司,他們在著手項目之前會寫很長的軟件規格說明書,這些規格非常細致,精確到每一個 Java 類和屬性。這些規范寫好之后會提交給客戶,但是有時候并不知道具體是誰和客戶確定的需求并且書寫了這些規范。之后開發人員就按照這個規范開始開發、交付,直至收到項目款項。然后皆大歡喜,其樂融融。


但是實際上大多數時候都會出現另一種情況:客戶抱怨規范與交付不符,并且交付的產品往往與規范不一致,因為在項目進行的過程中,很多“事情”發生了變化。換句話說,瀑布模型是一個“集體小說”,給了我們足夠的穩定性和一致性來合作,我們按照事先定好的規范把產品開發出來并得到報酬。


這個咨詢公司在我加入后不久就倒閉了,無疾而終。


2. 初創公司的一段經歷


之后我以第 39 號員工的身份加入了另一家軟件公司,公司的開發工作量很大并且沒有使用瀑布模型。事實上,公司內部根本沒有任何的項目文檔,需求和規范都是通過電話確認。設計、原型和產品開發很難區分。我感覺這樣的情形混亂不堪,完全和我學到的軟件工程理念相違背。但是沒有更多時間思考應對方法,因為公司項目很多,開發任務繁重,這樣的開發狀態就這樣一成不變地繼續。


事實是,我們公司小到甚至不需要命名一個集體小說。項目需求和相關細節可以保留在我們的腦海里,如果你需要幫助直接在辦公室喊一聲就行?;{是這樣的: 



當然,這是集體小說,我們只是沒有為其命名:我們永遠不會有任務說明。我們不需要人力資源或企業的溝通。我們只雇用最好的員工。


隨著我們公司規模的逐漸壯大,有客戶開始詢問我們的軟件開發方法和規范。我肯定不能說我們的開發方法就是寫代碼。更不能告訴客戶我們有現成的使用 C 語言開發的服務器程序,它運行速度很快,針對不同項目我只需花費一周左右對其做簡單的調整即可完成開發工作。


事實上有一種叫做“快速應用程序開發”(RAD)的東西強調了原型設計。我們告訴客戶我們做了RAD,他們似乎很高興。聽起來感覺我們很專業,但說實話,我不知道我們當中是否有人真正理解或者閱讀過它。


作為“集體小說”模式它是有效果的,仿佛客戶在監視我們的開發。


很快,我們公司的規模翻了一番,從狹窄的小辦公室搬到了一個更大的場所,辦公桌更加寬敞,樓層更多。因此你不能在辦公室喊出你的問題了。團隊變得更大,一些名為“項目經理”的人開始出現,他們談論“規范”并且收集“需求”。我們試圖從零開始重寫整個平臺,但是失敗了。


是的,我們好像又回到了瀑布模型的開發模式,但是又有所不同,因為工作周期越來越短,但是因為客戶不斷變化的需求而產生的爭議依然存在。到底是不是瀑布模型呢?我們也不太清楚。


3. 敏捷


我首次聽到“敏捷”一詞大概是在 2003 年。但是,實際上我并沒有深入了解它。我對敏捷的了解源于網上的零散介紹,以及客戶和敏捷擁護者談論的只言片語。當我咨詢那些聲稱自己對敏捷很了解的人時,不同人的解釋和理解好像出入很大。實際上那些深諳敏捷模式的開發者在向非敏捷客戶發布軟件時依然充滿壓力。因此,我們繼續依照傳統的規格書進行軟件開發,也會使用少量的敏捷術語。比如,會議被稱為“scrum”,但是其他的情況卻與之前的情形并無太大差異。


作為一個集體小說它是有效的,因為在我們編寫軟件時,它使我們保持和客戶以及項目經理的溝通。此后,我曾在一家擁有 700 人的公司工作,目前在一家擁有 10 萬名員工的公司工作,但模式基本相同。你不相信嗎?我不會排斥這些開發模式,因為排斥是無意義的。即使軟件開始模式不存在,也會有其他的模式被發明出來,因為我們需要借助這些模式進行有效地合作。有了這些開發模式才能擴大軟件開發規模。敏捷模型對于員工流動性大的公司來說非常有用,并且這不是巧合。


《人類簡史》一書中有許多有趣的論點,其中之一是:由于這些集體小說不能充分地解釋世界,往往相互沖突,文化的有趣部分在于感受到這種緊張局勢。幽默通常源于這些緊張局勢。


“對于心智最高級的考驗是能夠同時持有兩個相反的想法,仍然正常運轉,互不干擾?!? -- F. Scott Fitzgerald


當在一個小團隊之外使用敏捷時,我不知道其他人是怎樣,我個人反正是感覺非常緊張的。當一個我從未見過的并且對我的工作一無所知的人提議我刪掉我的任務計劃(這些任務是外部決定且沒有商量余地的)時,我除了苦笑還能干嘛?


當你的控制權在每一個環節都有人否決時如何保持敏捷?基礎設施、審計、安全、財務規劃、財務結構都有助于快速提供有意義的產品迭代的能力。這里的客戶是誰呢?我們很絕望: 


當我看到這樣的代表敏捷的圖表時,我只能用我與同事分享的黑色幽默來回應:像在教堂后面咯咯笑的小孩。 


在一個規模較小且運作良好的團隊中,敏捷的理念會忽略,剩下的是(當它很好的時候)一個相互信任的團隊、對自己的試驗的開放、可以找到協議和解決方案的清晰的結構(正式或非正式)以及有效的合作。谷歌最近對其進行了闡述。



換種方式闡述


你可能會認為答案是提出一種更好的新方法,而不是像我們曾經嘗試過的: 



這不是那么容易,就像書里說的那樣:


“講一個好故事并不容易,杭州app開發也充滿困難。困難不在于講故事,而是說服所有人都相信這個故事。許多歷史都圍繞著這個問題展開:如何說服數百萬的人相信神、國家或者有限責任公司?然而,當它成功的時候,它給了 人類巨大的力量,因為它使數百萬的陌生人能夠合作,努力實現共同的目標。如果我們只能談論一些以及存在的事情,比如河流、樹木和獅子,那么設想一下創造國家、宗教或者法律制度將是何其艱難?!?/p>


換句話說也就是:


“提出有用的軟件開發方法并不容易。困難不在于定義它們,而是說服別人遵循。軟件開發的大部分歷史都圍繞著這個問題:人們如何說服工程師們相信有關需求收集、用例點、燃盡圖或grooming?然而,當其被采用時,它會給組織帶來巨大的力量,因為它使分布式團隊能夠合作并努力實現交付。如果我們只能談論具體的技術細節,設想一下想要創建 Microsoft、Google或IBM 這樣的公司何其艱難?!?/p>


無論如何,世界都需要更多的開發方式。這是一些聰明人都沒有想過的。 



總結


我并不介意 Lean、敏捷還是瀑布模型,事實上不論怎樣我們都需要一些共同的意識形態來進行大規模合作來進行杭州app的開發。他們都不邪惡,選擇他們也不像選擇社會主義或者種族主義。無論你選擇哪一個都和現實世界無關,但如果你期待完美那么或許會失望。如果觀察未說出或未公開的集體小說時,你會發現生活被其充斥。你的意見是很重要的,我不得不引用來自《人類簡史》一書中關于我們與小麥的關系的經典選段:


“人類的身體早期并沒有進化來方便種植小麥。而是用來攀爬果樹并追逐動物,無法鋤地和搬水。人類通過利用脊椎、膝蓋、脖子而生存。從事古代骨骼研究人員表明,人類向農業的過渡帶來了許多疾病,如腰椎間盤突出、關節炎和疝氣。此外,農業任務要求人類付出更多的時間,人們被迫永久定居在麥田旁邊。這完全改變了他們的生活方式。我們沒有馴化小麥,而是它馴化了我們。 “馴化”這個詞來自拉丁語的domus,這意味著“房子”。誰住在房子里?不是小麥,而是人類。


也許不是我們在指導代碼,而是代碼指導了我們。誰是增長代碼妥協的原因和邏輯?不是代碼,而是人類。


代碼指導人類進步,從而使得杭州app開發一步一步前進。


文章由 zwischenzugs《我的20年軟件開發經驗總結改編》