如何让敏捷软着陆?

当前,敏捷已经成为了2018的热词,执行敏捷研发模式的项目多数都是从瀑布模型转型过来的,瀑布模型是一套根深蒂固的传统流程,如果硬着陆的话,很容易折翼。笔者在各类项目敏捷实施过程中,总结了一些接地气、可操作的经验,思考如何让敏捷软着陆,给大家提供参考。

0
55
  1.  因地制宜

纵观目前正在实施的敏捷实践,成功案例有一个共同的特点,就是“因地制宜”。敏捷实践有很多种,看板站会、持续集成、单一主干、测试前移、影响地图、测试驱动、结对编程、Scrum、故事地图等等,在敏捷的实施中没有所谓的最佳实践,只有更合适,更有效的实践。团队在透彻理解敏捷理念的基础上,能够结合自己的项目情况灵活应用敏捷,才是真正的敏捷。
案例一:A项目已成功引入业务人员参与,打通了敏捷的前端,达到从市场需求到研发过程的“业技融合”的状态。
案例二:B项目与测试部门合作,将测试环节前移,用TDD优化代码设计,提高代码可测试性,同时“测研结对”促进交付速率的提升。
案例三:C项目需求分批次下达,团队上下对Scrum敏捷框架有一致的见解,项目在开发侧开展Scrum实践,推进项目追求卓越的技术、良好的设计、高效的沟通。
案例四:D项目建设的系统需求稳定,属于核心类系统,使用传统瀑布式研发方法相当顺畅,应遵从实际继续沿用传统模式,可借鉴敏捷思想中的看板、站会等管理实践,促进沟通与协作。

天底下没有同样的一片叶子,因为每个项目都有独特的实际情况,所以敏捷的引入点不尽相同,要实现敏捷在自己项目软着陆,必须“因地制宜”的制定适合的策略。“削足适履”反而会“南辕北辙”。

2.  问题驱动

敏捷并不是万能的,不能听说别人用了敏捷之后,效率提高了百分之多少,成本降低了百分之几等等,就盲目地去追赶这股“敏捷风”。
不同的业务条线,项目情况各异,还是应该由问题驱动、对症下药,先收集当前的研发模式有哪些问题,分析一下,到底是人的问题、技术的问题、还是流程的问题,如果真的是流程问题,那就再看,是需要全盘替换,还是仅仅吸取敏捷里的若干特色工具或方法即可。举两个案例。
案例一:某系统在建设过程中,项目经理面临项目规模大、项目进度把控难、团队沟通不顺畅的问题。如果项目全盘引入Scrum的全套流程,前期就需要投入大成本在学习和磨合上,同时交付也会下降,这是项目团队无法容忍的结果。项目组从最迫切的沟通问题出发,先期引入了Scrum的“看板”和“每日站会”,让整个项目进度变得直观透明,同时让沟通更及时快捷,其他流程保持不动,这种对于项目组成员来说,学习成本最低,基本不会影响交付。项目组在实施一段时间后,反馈的确解决了他们的实际问题。

案例二:项目人员技能参差不齐,初级人员总是成为交付的瓶颈,项目组希望引入敏捷来提升交付速度。首先,项目组对敏捷的概念认识是有误区的,敏捷≠快速交付,它强调对需求的快速响应能力,敏捷不是一颗灵丹妙药,吃了就可以日行八百里。其次,敏捷团队,强调的是自组织,自管理,对每个人的要求都相对较高,但是从实际角度出发,不可能每个敏捷团队的人员配比都是高级人员,所以建议在初期组建时,以老带新,慢慢来,通过若干个迭代的打磨和成长,让整个团队都能达到自组织和自管理的“理想”状态。
所以敏捷的引入,一定要切合实际要解决什么问题,而不要为了敏捷而敏捷。

3.  基本要求

来点实在的,笔者不得不说一些基本的硬件要求,那就是首先要有一块板子。哈哈,不开玩笑,说的是真的,下面的几点搭建了最基础的着陆跑道,为着手尝试敏捷的项目提供参考:

  • 看板一开始最好是物理看板,不需要追求漂亮完整,只追求简单。
  • 物理看板的话,需要白板纸、木纹胶带、各种颜色和形状的便签。
  • 指定专人关注看板改进,把握三个核心:可视化价值流、显示化流程规则、控制在制品数量。
  • 改进看板,改进不一定是成功的,但是提出改进是职责。思考流程是否顺畅,内容是否上板。
  • 建立每日站会习惯,每天固定时间固定地点,设立奖惩制度推进每日站会,促进团队沟通协调,及时暴露问题。
  • 所有要求和规则显示化。
  • 三个角色,Scrum Master(SM)、Product Owner(PO)、Team。SM需要有较高的软技能,对技术要求不高。可以由有能力、熟知Scrum人轮流担任。PO对技术要求比较强,熟知需求,负责产品价值最大化。Team包括团队中的设计、实现、管理人员,负责实现产品需求。

敏捷源于多种实践方法,大家都在不断的尝试、实践、发展敏捷研发方法和技术,并引入工具探索实践。综上,在团队对敏捷思想达成共识,“因地制宜”制定适合自己的敏捷实施策略,从“问题驱动”来思考敏捷切入点,同时建立敏捷实施的基本规则,后续根据每个迭代总结回顾,优化流程,践行Scrum的核心理念:持续改进。

- leansoftx.com -

发表评论

请输入评论内容
姓名