越来越多的软件开发组织开始努力赶上CMM这趟马车,但是其中大多数最后又还是从这架马车上摔了下去。如果希望从你的软件过程改进活动得到零回报,请遵守以下秘诀:
1. 花费大量的金钱和时间用于过程评估、咨询服务和各种形形色色的CMM培训班;
2. 按照咨询顾问们开给你的软件文档模板,制定一大堆你想得到想不到的过程规范,然后告诉程序员们必须一个不漏地马上开始实施;
3. 接受你的高层领导的指示:“照着CMM说的去做!”;
4. 你辛辛苦苦的收集一大堆数据,而程序员们的工作方式依然照旧。
1 何谓过程改进
过程改进的要义可以用一句话概括:对于效果良好的项目实践要推广应用,对于问题较多的项目实践要变更调整。这就需要对于过去项目的成功之处和不足地方进行如实的内省和仔细的分析。过程改进最大的动机应该是通过改善软件开发和管理的方式来打到企业的某个业务目标。CMM可以作为一个框架来引导你的过程改进活动,但是你的目标却不是简单的满足这个模型的要求。
2 过程改进周期
图1说明了一个完整的SPI生命周期。首先,定义你期望达到的业务目标;然后,通过过程评估了解当前过程的问题,以及实施过程改进的可能结果。有了在评估中获得的对本组织现状的深入了解,以及业界的最佳实践知识(CMM),你可以设定一个现实可达到的改进目标。下一步,选择可以解决当前过程不足的合适的最佳实践,可以是这些最佳实践的一个很小的子集,来接近改进目标的最后实现。确定一到两个项目作为新过程的试点,在取得成功后可以适当调整然后全面推广。
如果对新工作方式的实施作一定计划,无疑能够大大增加成功的可能性。最困难的部分就是实际开始实施一个行动计划,如果这部分工作被忽略了,那么一切努力都相当于白费。新的过程要发挥作用需要一些时间,你应该耐心观察改进行动所针对的问题是否得到了解决或者症状得到了缓解。用定量数据来表示过程改进带来的好处,总是比主观的认识要更有说服力。
如果这一次改进活动成功了,那么再继续这个过程改进的循环,开始解决下一个最紧迫的需求。记住,过程改进没有终点,而是一个不断延续的旅程。
3 集中精力于那些让你头痛的部分
人们日常工作方式中那些让他们头痛和感到麻烦的部分,是促使他们改变现状最强的动机。我在这里指的并不是外部的和假想的痛苦,而是有些时候我们在目前的工作方法里所感觉体会到的实实在在的“痛苦”。许诺一个更美好的将来,可以是鼓励人们作出变更的一个方法。但是,也许更有效的方式是指出他们现在正处于危险之中。
评估可以帮助揭示那些让你感到头痛的部分真正原因所在,也可以揭示项目潜在的巨大风险。评估的形式可以不拘一格,既可以是一个简单的“头脑风暴”会议,所有的小组成员都参与讨论究竟什么阻碍了生产率和质量提高;也可以是一个半正式的邀请外部的咨询顾问参与的评价;还可以是一个严格的参照CMM标准的正式评审。当然,正式的评审需要一定资金投入,但是可以参照一个业界统一的标准对企业当前实际作出彻底的全面评价。
根据我的经验,过程评估很少揭示出特别出人意料的问题。很多开发团队可能已经意识到了他们的问题所在,外部的咨询公司所作出的评估只是使这个问题得到正式的确认。因为,作为外部的第三方,可以置身事外于这个组织的遗留问题、人际纠纷和许多“特殊人物”。评估让你直面那些尴尬的问题情势,而绝对不应该是提供一个对过往问题进行刻意挑剔或者归罪某人的讲坛。
执行评估的另一层作用,就是显示管理层对于过程改进的一种决心和承诺。切记要按照评估所发现的问题和提出的建议进行改进,否则不但对于企业投入评估的金钱和精力是一种损失,而且也在团队成员们的心中失去了信任。这些在评估中花费心血的人们,会认为管理层对于变革实际上并没有严肃对待。
评估经常是确认了一大堆的改进机会,而你不可能一口全部吃下。“聚焦”就是过程改进中要注意的关键之处,因为,设计一个更好的过程并且将其变为团队工作方式的一部分,所花费的时间往往超过你的设想。我曾经遇到一个20人的开发团队,他们雄心勃勃,企图同时在七个领域实施改进活动,虽然精神可嘉,但是收效甚微。
过程改进的目标,应该用所期望的业务成效的术语来叙述。举个例子,目标不应该写成“制定软件构建版本递增规程”,而应该写成“减少从开发阶段传递到系统测试阶段的不正确的构建版本”。SPI的活动其自身并不是目的,而是达到某个目标的方式手段。项目经理应该清楚明白的说明,如果改进活动成功,那么期望开发团队成员的行为方式会有怎样的改变。
从优先级比较高的那些目标中,一开始仅仅选择两到三个实施改进。如果你很快的完成了这几个目标,很好;再从评估报告中选取下两个目标继续改进。每次步子不要迈得太大,不要在刚刚起步时尝试太多事情。大型开发组织可以一次在多个项目中同时进行若干领域的改进,但是,对于每个单独的项目仍然应该一次集中精力做好一件事。
4 沟通极端重要
当要求人们变更他们熟悉的工作方式,他们通常感到不情愿,因为对于熟悉的方式(哪怕效率不高),人们总是能感觉到某种舒适,而对于未知总是感到不安。同时,对于过程改进可能带来的一些额外的程序化的工作量,人们也普遍担心这会影响到创造性的发挥和软件的按时发布。但是,这种担心经常是不现实的。团队成员也许会有一种挫折感,因为哪怕他们已经尽了最大努力,评估结果仍然表明过程有不足之处。客户会认为过程改进活动给他们平添了不少障碍,使他们的需求不容易达到程序员。
要解决上述问题,沟通应该贯穿于过程改进的全过程。应该明确的说明当前过程的不足之处所造成的代价:包括不断推迟的进度表、功能的缺失、经常性的超时工作,超额的产品支持费用、客户的不满意、和士气的低下等;应该给那些怀疑论者们细致的解释过程改进对于个人、团队、公司和客户的好处;有人可能会担心变更接踵而至、疲于应付,应该强调新的过程是经过深思熟虑选择的,是团队成员共同创建的,也是循序渐进、逐步推广应用的;应该积极寻找那些愿意尝试新的过程和新的文档模板的支持者,提供反馈,为成功的变革奠定基础;应该公开的表扬对于每个成功的过程变更作出贡献的人员,来传达一个信息:建设性的参与过程改进活动是企业所期许的;应该仔细分析不成功的过程变更,查明为什么无法坚持定义的过程,最后不得不改变目标。
过程改进的一个关键的运作原则是,“平缓而持续的施加压力,尽一切努力来应用”。应该保持过程改进的目标和状态始终清晰,强调改进目标与企业的业务目标是如何统一的。应该在小组会议上留出时间来检查改进活动的进展,阶段性的向管理层报告改进工作取得的成功以获得他们的支持。
我们经常看到,有的开发团队在年初对过程改进工作满腔激情,而在整个一年中却不再提及,直到年底开始检查是否达到当时定下的目标,结果当然是失败。对大多数团队成员而言,具体的开发工作总是比投入过程改进更加重要。项目经理应该经常提醒和强调,过程改进工作是重要的和有价值的。
5 要有和过程改进相应的组织机构设置
认真对待过程改进的企业,通常设置一个三层的组织架构来确保过程改进工作的成功。不同的企业可能要根据实际情况作出调整,总的原则是不必过于复杂,够用就行。”够用“的标准是,有形的改进活动可以被有效的识别、启动和实施。管理层决策委员会(MSC),设定过程改进的方向,优先级和保证改进活动所需资源。它某些时候会为每个改进领域制定一个”过程负责人“,保证改进目标的达到和团队的稳定性。一般来说,管理层决策委员会的成员包括企业的高级经理(首席执行官或技术总监),过程改进经理,各改进领域的过程负责人,部分慎重选择的项目经理和部门经理。管理层的各个级别积极参与到MSC中,表明组织对于改进工作的重视态度。
MSC的职责包括:
(1)设定过程改进领域的优先级;
(2)为特定改进领域的工作组建立章程;
(3)监控改进活动与状态;
(4)及时评估以完成的改进活动的影响;
文章来源于领测软件测试网 https://www.ltesting.net/