背景
至今,我在Motorola網絡部工作超過了5年,所在的產品線也是采用統一軟件開發過程和敏捷思想(但不是SCRUM)來組織軟件開發活動的,但這5年多的工作經歷從未引起我象微博上對于SCRUM話題的激烈討論這樣的思考。原因之一可能是,公司的流程已經很成熟了且形成了一種文化,不論怎樣的新人進入公司,都只需按照流程按步就班的工作就行了。另外,公司的開發流程并不包含象SCRUM所要求的形式化內容,使得我在工作中沒有機會體會和思考各種行為的利與弊。
與周圍的同事相比,我自認為自己的工作質量和效率都很突出,這歸功于我所掌握的知識、工具、方法和形成的思想。這四大塊內容也是將要出版的《專業嵌入式軟件開發 — 全面走向高質高效編程》一書的骨架。然而,最近微博上對于SCRUM的討論使我意識到,我的焦點更多地放在了工程師身上,而忽視了從組織的角度思考如何高質高效地從事軟件開發工作。即使這樣,我仍持這樣一種觀點:不論是怎樣的開發方法,一定要最終從基層工程師身上找到著力點,因為軟件產品的最終質量是他們“碼”出來的。一個方法論是否真的有效,得看方法論能多大程度地幫助工程師高效地開發出高質代碼,且該方法論被工程師所接受。注意,是“幫助”他們而不是“規范”他們。
對于SCRUM我還是一個門外漢(注:Motorola網絡部被NSN收購后也要求使用SCRUM,希望到時能寫些文章與大家分享所得與體會),但這并不妨礙我思考從事高質高效軟件開發我們到底需要什么。
SCRUM是銀彈嗎?絕對不是,因為她只是一個很粗的開發流程框架,仍無法消除開發活動中的人為因素(但可以減緩)。如果SCRUM不是銀彈,那將SCRUM引入到團隊中時我們應如何本地化呢?
模型
縱觀軟件行業開發方法論的發展,大多關注于開發過程。這一點從瀑布模型、統一軟件開發過程、CMMI和現在的敏捷軟件開發方法無一例外。開發工程化的思想深深地影響著軟件行業對開發方法論的探討,但業內也以意識到了軟件開發不只是工程,它更包含個體心理、行為等難以工程化的內容。在這里,我想拋磚引玉地提出自己的一個能力模型,來幫助思考我們到底需要什么、走向哪。該模型存在抽象與具體兩大層次。讓我們先從抽象模型開始,如圖1所示。圖1
從面象對象的角度來看,抽象模型是基類,而具體模型則是其派生類。高質高效的軟件開發工作需要涉及多個部門的各種崗位,各崗位的能力模型應在抽象模型的基礎上進行具體化。為了便于理解,圖2所示了我所認為的軟件開發部門的能力模型。
圖2
意義
引入這一能力模型的意義在于:
1) 讓我始終牢記實現高質高效的軟件開發是所有活動的根本目的。
2) 幫助我們在探索軟件開發方法論的道路上時刻關注我們需要什么,并以此了解軟件開發方法論解決了什么問題,哪些問題又是開發方法論不能解決的。
3)為人力資源管理提供一定的框架。引導組織思考:我們需要招聘什么樣的人?人員培養的著力點是什么?
結束語
這個模型是我花了不到一天的時間想出來的,所以一定很粗糙。個人認為,這個模型不應只是一種文字游戲的玩法,更應包含一定的實證研究。比如,模型中的關鍵要素又是什么?各要素的比重是多少?但無論如何,我希望這樣的模型不會讓我們在諸如SCRUM這樣的探討中迷失軟件開發活動的本原,這是我寫這篇文章的根本出發點。
最后,歡迎讀者提出自己的見解和參與討論。我的微博是@杭州李云(新浪)或@杭州李云(51CTO)。
Q&A
1. 軟件設計是質量之本,為什么在軟件開發工程師模型中沒有體現?
答:設計能力應體現在工程師的抽象與概括能力上,這兩者在模型中已涵蓋。
2. 在軟件開發工程師模型中為什么沒有體現建模的重要性?
答:建模應是軟件架構師的工作內容。建模在模型中可分解為“抽象 + 概括 + 工具”,它其實是設計的一種表達形式。