高質高效軟件開發組織能力模型

背景

至今，我在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. 在軟件開發工程師模型中爲何沒有體現建模的重要性？

答：建模應是軟件架構師的工做內容。建模在模型中可分解爲「抽象 + 歸納 + 工具」，它實際上是設計的一種表達形式。