软件⼯程师的能⼒评估和职业发展
介绍:  个⼈软件流程,  职业发展，个⼈绩效的衡量和提⾼, 软件开发是科学, ⼯程, ⼿艺, 或是艺
术?
我们刚讲了软件⼯程, 它包括了什么呢?
软件⼯程包括了开发，运营, 维护软件的过程中有很多技术, 做法, 习惯, 和思想。软件⼯程把这些相关的技
术和过程统⼀到⼀个体系中, 叫 “软件开发流程”，软件开发流程的⽬的是为了提⾼软件开发, 运营, 维护的
效率；以及⽤户满意度, 可靠性，和软件的可维护性。
软件开发流程不光指团队的流程,  软件团队是由个⼈组成的。在团队的⼤流程中, 是每⼀个具体
的个⼈在做开发，测试，⽤户界⾯设计，管理，交流等⼯作。因此, 个⼈在软件团队中也有个⼈
的流程。
个⼈的劳动成果有序地组织起来, 就是团队的流程。这⾥说的“有序”, 并不是“⽆争论”,  在⼤部分
成功的软件团队模型中,  各个⾓⾊（开发, 测试, 项⽬管理等）考虑问题的出发点是有区别的, 不
同意见的冲突在所难免, ⼀个好的团队流程能把冲突的积极⽅⾯ (各⾃尽⼒把⾃⼰的⼯作做
好，说服别⼈) 释放出来, ⽽避免消极⽅⾯ (因为冲突⽽产⽣的消极，抵触情绪等)。
我们⽤⾜球作⼀个⽐喻:  ⾜球中有没有个⼈流程?  当然有,  职业球队对于运动员有很严格的要
求: 例如:
体能, 技术, 意识, ⽃志
具体技术有传接，盘带，射门, 定位球, 跑位, 等。⼀些特定的⾓⾊（守门员）还有独特的技术要
求。
⾜球的团队有没有流程? 当然有:
阵型, 配合, 临场应变
⾜球队有不少 “阵型” (442, 433, 451和它们的各种变体, 等等) 和打法 (南美，欧洲，技术，⼒
量, ⼩快灵, 抢逼围, 两翼齐飞,  全攻全守, 等等).
尽管有这么多理论,  ⾜球的每⼀次盘带, 传球,  跑动, 射门，扑救，都是单个运动员完成的。如
果单个运动员的技术, 体能不⾏,⽆论是什么阵型⽤处都不⼤，有些阵型反⽽会起反作⽤,  例
如, 让体⼒弱的球队去打全攻全守。
软件也是这样。
软件系统的绝⼤部分模块都是由个⼈开发或维护的。在软件⼯程的术语中, 我们把这些单个的成
员叫做 Individual Contributor (IC).
IC 在团队中的流程是怎么样的呢? 我们以开发⼈员为例:
•      理解问题或任务
•      提出多种解决办法并估计⼯作量
•      其中包括寻以前的解决⽅案，因为很多⼯作是重复性的 – 例如实现某些类似的web页
⾯。
•      与相关⾓⾊交流解决问题的提案, 决定最终⽅案
•      执⾏, 把想法变成实际中能⼯作的代码
•      修复缺陷,  对结果负责
每个⼈的⼯作质量直接影响最终软件的质量。
作为⼀个软件⼯程师, 你觉得⾃⼰表现如何? 有没有这样的体会:
看书的时候觉得“技⽌此⽿”，开发项⽬的时候才觉得实际情况和书上讲的都有⼀些出⼊，⼀些重要的细节书上没有提。我们很多⼈是边看asp的书, 边开发asp 的项⽬，这相当于⼀边看医学书⼀边动⼿术。。。
如果你是病⼈, 你希望你的医⽣是下⾯的那⼀种呢?
a)  刚刚在书上看到你的病例, 开⼑的过程中⾮常认真严谨, 时不时还要停下来翻书看看…
b)  富有创新意识, 开⼑时突然想到⼀个新技术, 新的⼑法,  然后马上在你⾝上试验…
c)  已经处理过很多类似的病例, 可以⼀边给你开⼑, ⼀边和护⼠聊天说昨天晚上放的《⾮诚勿扰》的花絮…
d)  此医⽣⽆正式⽂凭或医院, 但是号称有秘⽅, 可治百病。
事实上, 很多软件项⽬就是⽤ a) b) 这样的⽅法搞出来的。当然也有⼀些⼈⾛ d) 这条路。
如果我可以选择, 我要选 c) 那样的医⽣。
软件⼯程师的成长
⼀个游戏玩家, 如何成长呢?  在游戏中, 可以打怪, 挖宝, 买装备, 完成任务, 买卡换积分,  等等。。。
那⼀个刚⼊⾏的初级软件⼯程师如何成长呢?  我认为成长有下⾯⼏种:
1. 1.      知识:  对具体技术的掌握, 动⼿能⼒
例如: 对Java, C/C++/C#, 诊断/提⾼效能的技术,  对device driver, kernel debugger 的掌握；对于某⼀开发平台的掌握。
1. 2.      经验: 对问题领域的知识和经验的积累 (例如: 对于医疗⾏业的了解, 对于⾦融⾏业的了
解)。
第⼀点和第⼆点都可以在很多简历上看到, 也可以⽐较容易地检测出来。随着经验的增长, ⼀个⼯程师可以掌握更⼴泛，更深⼊的技术和问题领域的知识。
1. 3.      通⽤的软件设计思想,  软件⼯程思想的提⾼
这⼀⽅⾯就⽐较虚，什么是好的软件设计思想, 什么是好的软件⼯程思想? ⼀个⼯程师开了博客, 转发了很多别⼈的⽂章, 这算有思想么? 另⼀个⼯程师坚持任何设计都要画 UML 图, 这算有思想么?
1. 4.      职业技能 (区别于技术技能)
游戏开发工程师需要学什么职业技能包括: ⾃我管理的能⼒; 表达和交流的能⼒; 与⼈合作的能⼒; 把任务按质按量完成的执⾏⼒; 这些能⼒在IT ⾏业和其它⾏业都很重要。
如何衡量, 证明⾃⼰的能⼒?
问: 你是职业软件⼯程师么?
答: 是。
问: 你觉得你“职业”到哪⼀个程度?
答: 嗯, 我在⼀个能发⼯资的地⽅上班, 靠我的软件技术挣钱, 所以我想当职业。
问: 像职业篮球队员那样职业?
答: 差不多吧。
问: 职业篮球队员都有很详细的记录说明，例如，下⾯的⽹页说明了⼀个职业篮球队所有队员的详细情况:
出场次数, 场上时间, 命中率, 篮板, 助攻,  抢断,  盖帽,  失误,  犯规,  得分, 罚球命中率等。
作为⼀个职业软件⼯程师, 你有类似的数据说明你所有职业活动和成绩么?
答: 嗯…  唯⼀的数据是，我的 “上场时间”  还是挺长的, ⽽且经常加班。
什么样的数据能说明⼀个⼯程师的技术和能⼒呢? 衡量能⼒有哪些参数? 没有量化的指标, 就谈不上衡量和⽐较。我们还是看看搬砖的伙计们，关于⼯作量, 他们有:
·        有多少块砖？
·        要搬多远?
他们也有简单的指标衡量⼯作质量:
·        多快搬完?
·        搬的过程中损坏了多少块砖?
软件开发的⼯作量和质量怎么衡量呢? PSP认为有下列4 个因素:
a)      项⽬/任务有多⼤？
说明项⽬的⼤⼩, ⼀般⽤代码⾏数 (Line Of Code, LOC) 来表⽰；也可以⽤功能点 (function point) b)      花了多少时间?
可以⽤⼩时, 天，⽉，年来表⽰。⼀组⼈所花费的时间可以⽤ (⼈数*时间) 来表⽰，例如某项⽬花费了10个⼈·⽉。
c)      质量如何?
交付的代码中有多少缺陷?  交付有两个定义,
·        在 Code Complete “代码完成” 的时候, 交付给测试⼈员
·        交付到顾客那⾥去 (在软件交付的时候)。
可以⽤缺陷的数量来除以项⽬的⼤⼩。例如 5 bugs / KLOC，意味着每千⾏程序有5个缺陷。
也有⼈⽤试图⽤“re-work”来表⽰质量, 例如：这1000 ⾏代码, 从开始写到最后发布, ⼀共修改
了200 ⾏·次。另⼀组代码, 从开始写到最后发布, ⼀共修改了 50 ⾏·次。那我们做改得少的代码最初质量⾼ – 因为 re-work (返⼯) 的次数少。
笔者认为,  re-work 只是表明在软件开发过程中花费的时间，re-work 的多少并不和最终的质量成正⽐关系。软件开发过程很⼤程度上是⼀个探索和实验的过程, 不同的 re-work 能帮助⼯程师深⼊了解项⽬的各个难点, 尽早交付原型, 到最优解决⽅案，等等. 因此 re-work 是有价值的。当然, 如果⼀个程序员为了⼀个简单的问题⽽不断地re-work, 其⼯作效率就不是太⾼ – 这可以⽤时间花费来考虑。
d)      是否按时交付?
软件/任务是否按时交付？这个看似简单, 其实也有讲究。例如, 当我们衡量⼀个程序员在⼀段时间内的交付情况时, 我们是⽤简单的平均值呢, 还是⽤⽅差来表⽰? 考虑这个例⼦:
我们来看看下⾯两个程序员的⽐较 (Al 和Bob).  他们在两次项⽬中各⾃完成3 个任务。平均值显⽰,  Al 完
成任务的时间从10 天提⾼到了 7 天; Bob 从10 天提⾼到了 8 天.  看起来是 Al 更好?
1,2,310 days5, 10, 1510 day5, 10, 15
4,5,6            (3
7 days1, 9, 118 days7,8,9
months later)
Average = 7Average=8
StdDev=5.3StdDev=1
在第⼀轮的⼯作中,  Al 和Bob 都完成了3项估计为 10 天的⼯作, 都各⾃花了 5， 10， 15 天.
在三个⽉之后,  Al 和Bob 接受了另外三项任务,  Al 的估计都是 7 天, 他花了 1， 9， 11 天。平均是7天时间。  Bob 估计是8天, ⽤了 7， 8， 9 天时间.  从总⽤时来看, Al 的平均时间
⽐Bob 快⼀天, 似乎应该是稍稍优秀⼀些, 但是从标准⽅差(Standard Deviation) 来看, Al 的⽅
差是5.3，⽽Bob 是1.  显然Bob ⽐Al 的交付时间要稳定得多。在团队⼯作中, 稳定，⼀致的交付时间是衡量⼀个员⼯能⼒的重要⽅⾯。
杰克·韦尔奇也讲过:
Standard deviation is key to the quality of service, and key to build trust.
职业发展
⽼师问学⽣: 你学计算机最喜欢什么?
学⽣答:  写程序多爽啊。
问: 那⼯作以后怎么发展呢?
答: 有更多的时间写程序, ⽽且还有⼯资, 太爽了。
⼏种⽅法:
·        PSP
·        考级
·        Steve McConnell  Construx
·        Corporate Career Model
·        Pragmatic Approach
职业成长 – 考级之路:
基于笔者有限的经验, 此类考级有这样的好处:
·        国家认证, 有⼀定的权威性和通⽤性
·        任何⼈都可以参与
也有这样⼀些局限性:
·        是⼀种答题/评分为主要⽅式的考试形式，没有⾯对⾯的⼝试。
·        考试中每个⼈单独⾏动, 不能考量团队合作能⼒。
·
        要考虑到通⽤性和稳定性，考题内容相对滞后，部分内容相当滞后。
职业成长 – Personal Software Process
⼤家可能都听说过CMU 的CMM 团队成熟度模型,  这是⽤来衡量⼀个团队的能⼒。 CMU 的专家们针对软件⼯程师也有⼀套模型: 叫 Personal Software Process (PSP)
PSP 和任何其他⽅法论⼀样, 也不是⼀蹴⽽就的。下图显⽰了CMU  Personal Software Process 的各个版本的内容 (来源: CMU PSP⽹站)。红字标出了每个版本新增的内容:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。