一个软件项目的团队中不仅需要软件编码人员,还需要很多非编码人员的配合。 在GJB5000A/CMMI中,软件开发的过程就不仅有工程类过程,同时也离不开项目管理类过程以及支持类过程。而这些管理类过程和支持类过程通常都不需要专业的编码人员来负责,非编码人员也一样能够承担测量分析、配置管理等的工作。 非编码人员承担的工作有两类,一种是辅助软件开发的工作,一种是确认软件开发需求的工作。 前面所说的项目管理、测量分析、配置管理以及质量保证、决策分析、风险管理等工作,都属于辅助软件开发的一类工作。这类工作不需要有专业的编码知识也能够承担,但它却能解决编码知识不能解决的诸多问题。 毕竟软件开发可不只是写几行代码的事儿,要满足项目所有利益相关方的需求,需要协调、处理的问题很多很多。比如:
比如在军用软件开发的单位里的系统设计人员就是这样的人。 他们在项目中的作用更是举足轻重。如果他们给出了不正确的需求,而这个错误直到系统联试的时候才发现,那对开发人员来说就是一场灾难。 系统设计人员同时还承担着对软件进行验收的工作。因为他们对需求最熟悉,他们对软件是否满足需求应该更有发言权。 如果是某个研究课题需要开发的软件,那么软件团队中可能还会有一些不懂代码的纯粹的研究人员、科学家、数学家、统计分析学家,他们会给软件开发人员提供需求,开发人员要配合研究人员不断地明确需求,直到最终把这个满足课题要求的软件产品做出来。 对于后面这类非编码人员,我们总会有这样的一个野望:让每个人都成为一种半自治的编码人员/研究人员。即懂需求的人也会编码,会编码的人也懂业务。如果省去了和不懂软件的人沟通需求的这个一节,那么软件的开发会不会更加高效? 这正是: 软件团队成分多,不会编码又如何 支持管理多重要,需求验收要有我 参考文献:程序之美系列:团队之美、项目管理之美,Andrew Stellman,Jennifer Greene,Scott Berkun,机械工业出版社 |
|