为了敏捷,你愿意变更管理方式吗?

实施GJB5000A的组织,有很多人都认为严格按照GJB5000A体系的要求开发软件,管理成本太过高昂,他们本来都恨不得把一个软件开发人员当作几个人来用,高昂的管理成本让他们无法接受。所以,有些过程就成了形式。当敏捷出现在他们面前的时候,自然会让他们眼前一亮。那么敏捷对于这些实施GJB5000A的组织来说,真的是救命稻草吗?

敏捷诞生的土壤是商业公司,追求的是以最小的价值去满足客户的需求,从而为公司获取最大的利益。在商业公司中,可以为了达到这一目的采取更灵活的管理方式。所以,敏捷的团队是自管理的团队,敏捷的团队负责人是服务型的领导。

而那些实施GJB5000A的组织会为了引入敏捷而改变它熟悉的管理方式吗?

  • 自管理

敏捷团队是自管理团队。一方面,每个团队成员都是极度自律的,都会按照约定的迭代计划、团队章程和开发准则完成自己的任务;另一方面,技术上的决策也是由团队自行决定的。

而在绝大多数实施GJB5000A的组织中,软件开发本来是没有项目的,为了完成GJB5000A体系的要求而成立的软件项目,在组织架构中几乎不会出现。软件项目负责人与原来的软件开发人员并不多大区别(除了增加很多本来不需要的项目管理工作量),他依然要听系统负责人的招呼,要听部门领导的命令。所谓的自管理,也许他可以约束自己按照编码规范来操作,他也不会去按部就班地完成那些额外的管理工作(因为根本就没人在意);技术决策,他也只会按照系统的要求来做,想要自己做决策,分分钟会被人劈头盖脸训一顿。

不能自管理的团队还是敏捷团队吗?

  • 服务型管理

敏捷团队的管理者是服务型的管理。他引导敏捷团队按照敏捷的方式完成项目的目标,他倾听团队的困难,及时清除对团队的阻碍。

而在绝大多数实施GJB5000A的组织中,管理者的权力是巨大的。有些领导的服务意识是没有的,他们只会享受凌驾于团队之上的权威性,不管是不是自己擅长的专业,都可以对团队进行指导。他们喜欢按照自己的管辖范围中任务的紧迫程度来安排团队成员工作,不管团队成员所在的当前项目进展如何。这种家长式的管理,常常会让团队成员失去工作的积极性,你怎么说我就怎么做,团队成员的自管理也就烟消云散了。

所以,在实施GJB5000A的组织里,软件开发人员没有什么决策权,他们只能听众领导的安排,遇事就要请领导做指示,这样的管理环境下,即使引入了敏捷,它能存活下去吗?

这正是:

若想敏捷能存活,管理方式要灵活

凡事都要找领导,敏捷只能成玩笑

作者简介:王小双,长期从事GJB5000推广、实施、评价、改进的工作,创建《软件工程之思》微信公众号,一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。

为了敏捷,你愿意变更管理方式吗?》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/3495.html