作为一名从事应用软件开发多年的IT老兵,我从个人编程、开发小软件,到组织开发各类应用系统,经历了不少的软件工程模型、开发过程方法、组织级成熟度模型、管理体系等等。近几年敏捷开发成为热门,各种新鲜名词和套路层出不穷。
回顾多年的开发经历,发现很多东西在不断变化,但也有一些东西保持不变,而且各自有各自的适用场合。现将相关观点归纳如下,与大家探讨:
1、不变的是工程过程,变化的是管理过程。
软件开发活动可归为两大类,一类是工程类活动,一类是管理类活动。工程类活动是指直接制造产品的活动,受产品生产工艺约束,是产品制造中的“硬逻辑”。管理类活动是指其他辅助性活动,用于保障工程类活动高效实施,可根据实际条件灵活掌握,是生产过程中的“软逻辑”。在软件开发中也存在这两种不同的活动——具有硬逻辑特征的软件工程活动和具有软逻辑特征的软件开发管理活动。虽然现在有各种开发方法,但核心的工程过程并没有变化,仍然是基本的瀑布式软件工程过程。
2、需求、设计、编码、测试、发布。
无论开发方法、项目规模或开发人数,上述过程始终有效,是应用软件开发中的“硬逻辑”。但在具体实施过程的管理方式上,可以千差万别:
A、按照上述过程稳步前行,即“瀑布式”方法(瀑布式工程过程并不等同于瀑布式管理过程,必须加以区分);
B、先快速实现一个原型系统,然后导出正式需求,再按照上述过程实现,即“原型法”;
C、将整体需求分成多个部分,反复使用上述过程,每次只实现一部分目标功能,形成“快速迭代”;
D、细分需求,促进技术、业务等相关人员沟通,加速迭代,缩短开发周期,提升应用开发的响应速度,即“敏捷”;
纵观这些年来软件开发方法的变化,软件产品的制造工艺并没有根本改变,变化更多是在制造过程的组织管理方式上寻求新的出路,以适应快速响应的要求。
不同的开发管理模式下,开发过程的组织方式也应有所不同。传统的瀑布式开发管理过程适合采用软件工厂的管理方式,而敏捷方法则适应软件工作室的组织方式。
对于CMMI,作为一个组织级的模型,是许多专家经验教训的结晶,具有很高的参考价值。在这个模型中,试图识别并建立各方面工作的关键点和联系。但它没有给出具体操作要求,这是实施者需要解决的问题。有些企业实施CMMI后遇到困难,问题不在于CMMI本身,而是在于实施环节,没有掌握CMMI的实质,没有根据实际条件灵活运用,机械照搬他人的“成功模板”导致难受。正确的做法是将CMMI模型看作组织级能力中的“硬逻辑”,然后根据实际情况设计相应的“软逻辑”,因地制宜制定制度流程,推动“硬逻辑”的实现。在这些软逻辑中,可以根据需要采用不同的管理方式。
从这个角度来说,不妨考虑在类似CMMI的组织级模型中运用“敏捷”的管理思路和方法,也许会有意想不到的收获。
无论是“传统”的瀑布方法还是“现代”的敏捷方法,目标只有一个,就是以最优效率完成软件开发任务。没有必要为了敏捷而敏捷,而是应该掌握敏捷的思想、方法、技巧,灵活运用。作为软件开发的管理者,在具体的软件开发项目中,始终抓住软件工程过程的基本规律,结合实际条件,灵活运用不同的管理方式。
版权说明:
1、特别声明:以上文章内容仅代表作者本人观点,不代表建米软件观点或立场。
2、免责声明:本内容来自互联网相关创作者,不代表建米软件的观点和立场。
3、文章版权:版权属于原作者所有,如有侵权、违规,可直接反馈本站,我们将立即删除。删除联系电话:400-8352-114
添加专属销售顾问
扫码获取一对一服务