小步快跑,敏捷开发的精髓!

这篇具有很好参考价值的文章主要介绍了小步快跑,敏捷开发的精髓!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

每日站会,两周一迭代,有自己的“Scrum Master”,就是敏捷实践?No!

具备敏捷之形的团队有很多,但是,真正掌握敏捷精髓的,却并不多见。这是因为,敏捷方法属于simple but not easy(简单但并不好做)。结合我这么多年的体会来看,与其说敏捷是一场研发方式的变革,不如说是一场思维方式的变革。

今天,结合我在某试点团队中深度实践敏捷的经历,来跟你分享一下,我对敏捷精神的理解,以及在敏捷应用过程中的实施建议。

1 为何引入敏捷?

敏捷特点:小即是美(Small is beautiful)。小而美体现:

  • 人:拆分成小规模(5~7人)、跨职能的小团队
  • 事:拆分成一系列小而具体的交付物,按优先级排序,增量交付
  • 时间:拆分成固定大小的短迭代(1~4周),在每个迭代结束后,对可工作的产出进行演示

小团队在小块时间,做出小块东西,周期性集成组装。为何当时考虑引入敏捷?要从第一个版本发布讲起。

新业务第一个版本,原本预计在春节前发布。我们基于WBS做完整项目计划,2月进行模块开发,然后用一个月的时间来做发布前的联调、功能及性能测试。

开发联调开始前,一切都理想。我们有自认为完备计划,有周会、周报和各种文档,还有任务系统的监控报表。种种途径获取的信息,都告诉我们,一切正常!

直到某天开始代码集成,准备测试,“嘭!”各种意外超出想象,项目越来越不可控:

  • 集成联调比我们想像得要更复杂
  • 性能稳定性调优花了更多的时间
  • 一名主程离职
  • 赶上过年,要放长假
  • 测试人员是新人,还在熟悉业务
  • ……

所有因素加在一起,把这个项目拖入了完全失控深渊,一直到38节才正式提交给用户……

最初引入敏捷就是想 发布周期更短。

2 痛点一:发布时间不可控(快速增量交付)

考虑项目实际背景,把迭代周期定一月。每月都和内部客户一起做Sprint计划及Review演示。这给我们带来哪些改进呢?

  • 提早集成与测试

    让问题及时暴露,更快反馈应对

  • 及时规避风险

    意外仍会有,但大多数情况,可在Sprint内部消化,避免更大影响

  • 快速响应变化

    在Sprint1演示会后,我们收到新客户提的紧急需求,立即做相应调整。若按之前模式,这时,可能很多事情我们都只做了一半,想调头不容易。短周期让我们能灵活调整方向,每个Sprint都是潜在可交付的产品

Sprint3后,我们临时安排个小Sprint,以快速将“潜在可交付”变为“真正可交付”。我们发现,在每个周期内,能真正把事做完,跟最终用户一起分享阶段性成果,对团队来说,也是很好的激励。

这时,发布周期的问题已基本解决,交付灵活性高很多,客户也更满意。

这能叫Scrum团队了吗?

3 痛点二:摆脱“接力综合征”(从对抗走向协作)

经观察总结,团队各角色协作方式仍存在一些问题。我把这叫“接力综合征”。虽交付周期变成月/次,但大家却仍在按过去方式工作。

3.1 宁愿选择等待

每人都等上环节的人把东西弄好送到自己面前,才开始工作。

“需求文档还没理清楚,急啥?”

“接口设计文档还没确认,怎么做啊?”

传统项目管理中这很正常。但这些空转时间不能给产品带来直接价值。

3.2 角色间泾渭分明

都觉得只要把份内事做完就行。如:

  • 开发把工作做完,也不管做得效果,心想:“反正要丢给测试,先撤了,出问题再说。”
  • 测试测出Bug:“等开发全部修完,我再接测,反正都测完了。”

各角色间有一定对抗。项目中任何一件小事都可能造成冲突。最终大家都耗在那,每人更在意“这是你的问题,不是我的问题”,却没把焦点放在达成整体目标。

传统项目管理,项目经理大部分工作就是厘清各方责任,界定权利与义务,疏通对抗情绪,并解决随之来的突发问题。但敏捷,更快速的交付压力,使这种等待和界线变得越来越难接受,我们不得不改变思路。

敏捷好比打橄榄球,所有队员都时刻关注场上比分。虽彼此有分工,但作为team,进球最关键。敏捷也一样。从敏捷思想中得到启发,开始一系列改进。

首先,开发和测试把位置搬到一起,并设定 共同的Sprint目标和完成标准

开发做完工作后,若测试进度被卡,大家会一起着急,一起想法解决,因为影响整体进度。

其次, 从“你完成-我开始”,到我们一起完成

敏捷团队,开发干得热火朝天时,测试也没闲,测试代码与开发代码几乎同时在写。往往代码刚“出炉”就测上,且只有测试结束并确认无BUG,开发工作才结束。使用故事点燃尽图,衡量整体进度偏差,团队约定好,只有一个功能点完全测试通过,燃尽图才往下走。

这燃尽图成了团队的计分牌,每人都关注同一目标。同时,还发明里程碑燃尽图,衡量每个迭代对整体进度贡献及多个迭代之间累积需求总量的变化,相当于一个赛季的累积记分牌。

燃尽图型项目进度模版,公众号后台领取。

这些措施打破角色间相互切分和推诿局面,共同目标让我们变成价值共同体。只有协作才能达成目标。

4 痛点三:需求理解不一致 (面对面澄清及估算)

至此,团队力量得到很好凝聚。复盘会上畅所欲言,共同得出下一个待改进项,是需求理解,技术类项目的共性。

我们没专职策划,开发人员在理解需求时,经常很困难。打开敏捷宝箱,找到一条重要价值观“ 个体与交互 > 过程与工具”。相比更多、更长的需求文档,决定采用更多的面对面交流解决这问题!

迭代计划分成:

  • 产品负责人向团队和用户代表,面对面讲解收集来的各方需求,最终明确需求优先级及验证条件,即在迭代结束的Demo演示会,我们拿什么呈给用户
  • 团队估算。采用敏捷估算扑克的形式,由团队成员共同给出估算结果,最后综合得出这迭代要交付的内容

团队估算过程是双向互动环节,可帮助团队和产品负责人共同加深对条目的理解。产品负责人也会根据大家反馈,及时修改、完善条目。

具体估算时,为避免干扰估算结果,当所有成员选择好代表自己估算值的纸牌后,大家同时亮牌。同时亮牌的好处: 不会有人跟风出牌,每人的估算都是经过独立思考得出,这也是扑克估算的精华所在。

若估算值差距明显,代表大家对该条目的工作量没获得共识,团队要对该条目的评估结果讨论,由max、min的牌主,分别说明自己的估算理由,并重新讨论,确定最终评估结果。

经过实践检验,这样面对面的需求沟通及评估,至少带来好处:

需求探索更深入

在计划会上,团队会直面一线用户,需求可得到面对面交流和澄清。团队估算其实也是团队共同探索需求的过程。因为只有到真正考虑要花多少成本去做时,才有各种各样问题暴露。这方法对于在早期进一步挖掘需求细节,特别有帮助。

3.2 估算结果更加全面、细致

传统项目管理也做估算。如WBS分配好任务,然后每个人估算自己的,每人都只对自己的那块任务熟悉,估算结果会有欠考虑,而团队估算就很好补足。

每个故事都会由全员出牌,各方从自己角度出发想问题,可互相补充。如估算时,测试成本也会被考虑进去,对测试成本高的功能点,开发主动想办法加强UT等白盒测试手段,估算结果自然更细致全面。

3.3 找到更优化的整体解决方案

由于各方共同参与估算,前端、中间层、后端、测试的思路能在一起交流碰撞,就利于找到最优解决方案。

这一系列敏捷尝试,始终围绕项目中切实痛点展开。从最开始缩短发布周期、经常交付可工作软件,到应对“接力综合征”,提升团队整体目标感和协作效率,再到探索更有效的需求理解及团队估算方式,增进团队交流同时,又保障需求质量。

敏捷实践的应用,带来好处:

提升客户体验:

  • 更低的延误率
  • 阶段性可见的产出
  • 更快的反馈、适应与调整

提升管理者体验:

  • 团队自主运行,管理更轻松
  • 变“赶”为“引”,为共同目标奋斗

提升团队体验:

  • 更高的生产力
  • 更好的责任感/主人翁意识

4 总结

敏捷方法不是拿来即用,这些方法大多以敏捷思想为指导,以敏捷方法为基础,在实际场景不断演化,一点点改进出的。没任何一种方法、工具可放之四海皆准,每人都要在自己场景中思考。

真正决定一个团队是否敏捷,不在是否应用那些实践,而在实践背后是否体现敏捷精神。实战中三项最重要敏捷精神: 快速可靠交付,用户价值驱动,持续自发改进

坚持敏捷精神,而非僵化套用特定做法。实践敏捷时,遵循小而美,每次一小步,挑个痛点集中解决,小步快跑,不断尝试优化。

做到这三点敏捷精神就是敏捷团队。

FAQ

你所在的团队有哪些敏捷实践已经偏离了敏捷的初衷?从敏捷精神出发,你还可找到哪些小而美好方法?文章来源地址https://www.toymoban.com/news/detail-497392.html

到了这里,关于小步快跑,敏捷开发的精髓!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 使用敏捷开发工具做敏捷需求管理流程

    上一篇我们介绍了如何管理产品路线图(用Leangoo领歌Scrum敏捷开发工具管理产品路线图?_哆啦B梦_的博客-CSDN博客),这一篇我们介绍下如何管理产品Backlog。 史诗故事通常都是比较大的故事,所以我们需要将史诗故事规划到产品Backlog中,以便让团队在产品Backlog中对史诗故事

    2024年02月04日
    浏览(45)
  • 系统架构师---开发方法---敏捷开发

    目录 前言 极限编程 四大价值观 沟通 简单 反馈 勇气 尊重: 十二个最佳实践 计划游戏 小型发布 隐喻 简单设计 测试先行 重构 结对编程 集体代码所所有制 持续集成 每周工作40小时 现场客户 编码标准 前言 2001年2月,在美国的犹他州,17位“无政府主义者”共同发表了《敏

    2024年02月13日
    浏览(33)
  • 【敏捷开发】测试驱动开发(TDD)

    测试驱动开发(Test-Driven Development,简称TDD)是敏捷开发模式中的一项核心实践和技术,也是一种设计方法论。TDD有别于以往的“先编码,后测试”的开发模式,要求在设计与编码之前,先编写测试脚本或设计测试用例。 敏捷开发大师Kent Beck在1996年提出了极限编程(Extreme

    2024年02月14日
    浏览(36)
  • 利用敏捷开发工具实现敏捷项目管理的实践经验分享

    Scrum中非常强调公开、透明、直接有效的沟通,这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一 。通过“可视化的管理工具”让所有人直观的看到需求,故事,任务之间的流转状态,可以使团队成员更加快速适应敏捷开发流程。 所以,有敏捷工具的支撑是非常

    2024年02月11日
    浏览(46)
  • 敏捷开发、V模型开发、瀑布模型

    在软件开发领域,敏捷开发和V模型开发是两种主要的开发方法。它们之间的差异主要体现在开发过程的结构和组织方式上。在以下讨论中,我们将深入探讨这两种方法的特点和差异。 敏捷开发是一种 迭代和增量 的软件开发方法,它强调灵活性和客户参与,一种自下而上的,

    2024年02月09日
    浏览(32)
  • 敏捷开发之Scrum

    我们一般习惯用 瀑布模型,它以文档为驱动 ,将软件生命周期划分为固定的六个基本活动,并且规定了它们自上而下、相互衔接的次序,如同瀑布流水,逐级下落。 那什么是敏捷开发呢? ​ 敏捷开发的核心理念是 适应变化,快速响应市场需求 。敏捷开发强调团队协作、客

    2024年01月21日
    浏览(47)
  • 敏捷开发SCRUM工具

    2024年02月12日
    浏览(41)
  • 什么是Scrum敏捷开发?

    第一次接触scrum 敏捷开发是7年前加入一直为服务团队。虽然不是第一个成规模的开发团队,但是跟以往的任务追踪制不同的是,沟通成了最大的利器。 Scrum是一种敏捷软件开发方法,它是一种迭代、增量式的开发方法,强调团队协作和自组织。 Scrum框架包括以下关键角色、活

    2024年02月10日
    浏览(50)
  • 敏捷开发时间估算 高端局

    在敏捷开发和项目管理中,“Initiative”, “Epic”, “Story” 和 “Task” 是用来描述和组织工作项的常见术语。以下是它们的中文翻译: Initiative:倡议或计划。这是最高级别的工作项,通常包含一组相关的 Epic,用来实现一个大的业务目标或策略。 Epic:史诗。这是一个较大的

    2024年02月15日
    浏览(34)
  • 敏捷开发的优势

    在现今这个快速变化的时代,企业对于软件开发的需求也在不断变化。为了满足市场需求,开发出高质量、具有竞争力的软件产品,越来越多的企业开始采用敏捷开发方法。 敏捷开发的优势在于其能够灵活响应变化,提升软件项目的成功率。 敏捷开发的优势主要包括以下几

    2024年02月07日
    浏览(23)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包