高质高效软件开发组织能力模型

原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。
http://blog.csdn.net/hzliyun/article/details/7078896。

背景

至今，我在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. 在软件开发工程师模型中为什么没有体现建模的重要性？

答：建模应是软件架构师的工作内容。建模在模型中可分解为“抽象 + 概括 + 工具”，它其实是设计的一种表达形式。 

本文出自 “李云” 博客，请务必保留此出处 http://blog.csdn.net/hzliyun/article/details/7078896。