分享

浅谈跨国软硬件结合项目的敏捷开发管理实践

 七七在路上 2016-04-06





敏捷开发在软件开发领域越来越受到欢迎。它的优点显而易见:灵活定义需求、所见即所得、迭代的开发和测试、软件任何时候都在可用状态、资源利用高效、提高软件质量等等。但是,是否所有的软件项目或者团队都适合使用敏捷开发模型呢?答案显然是否定的。


今天和大家分享一个案例,背景是:公司高层对之前的软件质量和资源使用效率不甚满意,想推行敏捷开发模型。项目的性质是软硬件协同项目,即软件产品的很多功能需要在硬件产品上面验证和运行。


老板在某个软件版本启动会议上宣布即将采取敏捷模型,项目经理开始挠头皮,因为项目的干系人对于敏捷开发的概念不甚了解。开发团队还算是好的,因为有很多外雇员工在之前的项目中曾经接触过敏捷开发。这个苦了测试和商务团队,敏捷开发对于他们来说纯粹是一个“新潮”的概念。不要说敏捷开发,就是软件开发瀑布模型也是做了几个发布以后才慢慢熟悉起来的。


老板宣布意味着这个版本必须要使用敏捷模型,行也得行,不行也得行。更要命的是,质量不能含糊软件发布以后,客户的投诉不能上升,并且还要看到显著的下降;资源不能含糊不可以使用更多的资源,不可以有更多的加班。否则老板使用敏捷开发的目的就没有达到!这个难题如何破解。


千丝万缕中,我们发觉对于这个项目和这个团队来说,首先要做的是沟通计划。因为主要干系人对于如何实施敏捷开发还没有一致意见!


沟通计划和管理

沟通计划主要包括:
1.
敏捷开发模型介绍。 很多概念比如sprintbacklog等等对于测试团队来说都是全新的。市场部、售后服务部等干系人对于这些概念更是闻所未闻。这里要指出,当时的沟通计划虽然提到了sprintbacklog的概念,但是没有定义清楚timebox。导致后来项目的实施碰到了不小的争执。在“进度定义和管理”中详细说明。
2.
敏捷开发角色定义。Scrum Master, product owner, team member的职责和责任要定义清楚。Product owner必须在SPRINT评审之前非常明确自己要干什么



有了沟通计划,项目实施会顺畅很多。但“跨国”、“软硬件协同”等性质还是在实施过程中碰到了诸多的实际问题。本文从范围、进度、质量等方面做一些分享。


范围定义和管理

1.
需求说明书如何集成到流程中
正宗的敏捷开发应该是不需要需求说明书就可以开工的。敏捷开发的宗旨之一就是去掉繁冗的文档审批流程,让用户和开发人员直接接触并定义出一个短时期的可交付成果。双方都认可就行了,甚至不需要一个文档和签字流程。但事实是,第一,没有这样自我严格控制的开发人员。第二,需求没有清楚到两个人一拍即合。有的需求是隐形的,比如性能要求,你不规定我就不做。第三,用户不是某一个特定客户,不可能把用户直接请过来。在这个项目中,“用户”主要是市场部的代表和售后服务部门的代表。结合项目的实际,我们做了一个妥协:项目需求说明书还是需要的,在进入每个SPRINT之前必须定义清楚本SPRINT需要完成的工作,并且有各方(开发、测试、干系人)管理团队的签字认可。和以前的区别是,不需要在项目一开始定义所有SPRINT的需求,因为三个月后的事情现在还说不清楚。这个也算是一个进步吧。不过,需求的讨论变得频繁了,以前每半年(一个版本)一次,现在每个月一次(SPRINT)。




进度定义和管理

1.
SCRUM 会议
敏捷开发中的SRUM会议每天都要做。这个跨国项目,有中美各方参与。如果定义SCRUM会议的参与方和时间呢?大家都不想晚上过多开会。如果每天SCRUM加上所有的干系人,显然晚上的会议是无法避免的。由于这个项目的开发团队和大部分的测试团队都在中国,我们定义中国的白天每天早上九点准时SCRUM,这个会议美国团队是选择性参加即想参加并且有时间就来,没时间不方便可以不来。会议纪要每天都发,如果美国团队有意见可以通过电子邮件沟通。每周五上午的SCRUM约定为全球都要参与。美国团队至少每周一次,主要讨论的议题是重要的话题,比如timebox的关闭、是否有重大缺陷导致无法继续测试等等。
SCRUM会议还有一个重要任务就是重新安排资源。由于每天跟进,SCRUM MASTER很好的掌控实际进度,他有权限微调各个部分的资源,做到最优分配,削峰平谷。以满足老板的第一个期望(节约资源)


2.
Timebox的结束
在沟通管理中提到了,Timebox的关闭一开始没有定义清楚。于是有了一场争论。在某个SPRINT中,开发团队由于技术原因,定义的某个BACKLOG工作项无法完成。测试团队以这个SPRINT没有完成为由,拒绝继续测试。而当时项目的整体进度上测试就是关键路径。一天都不能耽搁,停工一天就意味着项目的延宕。软硬件结合项目,结束日期是死的。如果延宕,就意味着硬件的出货要延宕,对于项目来说,就是“死”!开发团队认为Timebox结束了就结束了,即使有东西没有完工,也应该进入下一个SPRINT。没有完工的东西顺延到下一个SPRINT,并且调整下一个SPRINT的范围定义,即可以少做一些功能。最终,进过漫长和艰苦的讨论,测试才同意继续测试。但是这个争论原本不必要,只要双方在项目前期做了约定即可。


质量定义和管理



1.
质量度量标准
对于本项目,质量度量标准定为总得缺陷数和缺陷生命周期以及缺陷曲线形态。因为范围定义更加确切,所以从管理层期望更少的缺陷和更及时的修复。总缺陷数不必解释,生命周期代表一个缺陷从发现到修复的时间周期,敏捷开发的周期应该更短。传统的模型中缺陷数形态有一个上升期和一个下降期,像一座小山。敏捷开发的模型期望缺陷是以一个相对均匀的速度被发现并被修复。道理很简单,做多少,测多少,完成多少。不是一股脑先做,再测,修复,完成。


2.
发现缺陷曲线异常的应对措施
SCRUM MASTER需要监控缺陷曲线。一旦发现缺陷有上升势头,并且持续3天以上,SCRUM会议上他就会逐个定义缺陷的应对措施,并限期修改。把项目从做新需求转向到专注修复目前的缺陷。这种及时的调整保证项目的质量始终在一个可控的范围。总缺陷数的下降,意味着在测试方法不变的情况下,将有更少的缺陷流入到用户手中。这样将显著提高项目的满意度。完成管理层的第二个目标(提高质量)。


综上,以上的一些考虑和实践保证了“跨国”、“软硬件协同”项目初步实施了敏捷开发并且满足了管理层的一些基本考虑。在以后的工作中需要不断总结和交流,把一些深层次的问题予以解决。(比如团队的士气、自我激励、流水线形态的开发知人善任等等)

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多