来到新公司,加入了一个功能非常庞大的系统开发团队中,无论是项目的组织架构还是项目的管理流程,都很规范,角色的划分也很清晰,需求分析工程师、开发工程师、测试工程师,各施其职各尽其责。
在原公司有将近一年的时间都是负责CMMI5流程改进,流程在国内项目中的推广很难,管理层的目光大多集中在利润,至于用怎样的流程开发,并不太在意,能快速完成任务满意客户就是硬道理。那一年,我们花了很多的时间和精力在通过CMMI5认证,我们最终也通过了,但CMMI5认证的通过也就意味在一片喜洋洋的宣传中宣布流程管理的结束。关于流程管理的一切,又回到了原点,悲哀。项目的时间很紧,资源不足,流程自然就靠边站了。我在那一年所积累下来的流程管理经验,让我对测试发生了很大的改观,可惜,我们的项目没有很好的利用。在离开原来的公司前,我写了一份长长的建议书,作为我离开公司的最后一次共享,不知那份建议现在能否给公司或部门或某个项目带来一点点的帮助呢?
新公司流程管理的规范和坚持,让我开了眼界。项目的开发流程,是标准的软件开发流程,需求分析和评审、系统设计和评审、开发实现和Code Review,测试设计和评审、测试进行和跟进,一切都进行得有条不紊。有一点让我印象特别深刻的是项目的开始,会有经验丰富的系统分析工程师与客户谈需求,需求谈完之后,会在公司内部与其他的需求分析工程师和Team Leader一起讨论需求的合理性,客户的需求中有哪些是合理的哪些是不合理的,内部讨论完之后再去跟客户谈。不像以前,被动地接受任何来自客户的合理或不合理的需求。
项目的日常工作开展也很有效。每周一个全体成员参加项目例会,总结过去一周的工作进度和遇到问题,安排新一周的工作内容和注意问题,刚进公司的时候这样的会议让我一下子就清晰了现在项目处于哪个阶段自己又需要做些什么。项目的管理划分成了几个不同的小组,每天一个Team Leader会议,跟踪当天的项目进度和问题。对于需求变更,由系统分析工程师先做设计和实现的评估,然后正儿八经地开需求变更会议,需求分析人员、开发人员、测试人员在一起讨论需求变更的来源、实现以及各人的任何安排和完成时间,当然这么重要的会议,自然少不了PM。这些,是我以前一直大力推广的,这里的管理理念与我不谋而合,让我开心了一把。
流程的规范管理,确保了软件在规
在原公司有将近一年的时间都是负责CMMI5流程改进,流程在国内项目中的推广很难,管理层的目光大多集中在利润,至于用怎样的流程开发,并不太在意,能快速完成任务满意客户就是硬道理。那一年,我们花了很多的时间和精力在通过CMMI5认证,我们最终也通过了,但CMMI5认证的通过也就意味在一片喜洋洋的宣传中宣布流程管理的结束。关于流程管理的一切,又回到了原点,悲哀。项目的时间很紧,资源不足,流程自然就靠边站了。我在那一年所积累下来的流程管理经验,让我对测试发生了很大的改观,可惜,我们的项目没有很好的利用。在离开原来的公司前,我写了一份长长的建议书,作为我离开公司的最后一次共享,不知那份建议现在能否给公司或部门或某个项目带来一点点的帮助呢?
新公司流程管理的规范和坚持,让我开了眼界。项目的开发流程,是标准的软件开发流程,需求分析和评审、系统设计和评审、开发实现和Code Review,测试设计和评审、测试进行和跟进,一切都进行得有条不紊。有一点让我印象特别深刻的是项目的开始,会有经验丰富的系统分析工程师与客户谈需求,需求谈完之后,会在公司内部与其他的需求分析工程师和Team Leader一起讨论需求的合理性,客户的需求中有哪些是合理的哪些是不合理的,内部讨论完之后再去跟客户谈。不像以前,被动地接受任何来自客户的合理或不合理的需求。
项目的日常工作开展也很有效。每周一个全体成员参加项目例会,总结过去一周的工作进度和遇到问题,安排新一周的工作内容和注意问题,刚进公司的时候这样的会议让我一下子就清晰了现在项目处于哪个阶段自己又需要做些什么。项目的管理划分成了几个不同的小组,每天一个Team Leader会议,跟踪当天的项目进度和问题。对于需求变更,由系统分析工程师先做设计和实现的评估,然后正儿八经地开需求变更会议,需求分析人员、开发人员、测试人员在一起讨论需求变更的来源、实现以及各人的任何安排和完成时间,当然这么重要的会议,自然少不了PM。这些,是我以前一直大力推广的,这里的管理理念与我不谋而合,让我开心了一把。
流程的规范管理,确保了软件在规