每日站会,两周一迭代,有自己的“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 总结
敏捷方法不是拿来即用,这些方法大多以敏捷思想为指导,以敏捷方法为基础,在实际场景不断演化,一点点改进出的。没任何一种方法、工具可放之四海皆准,每人都要在自己场景中思考。
真正决定一个团队是否敏捷,不在是否应用那些实践,而在实践背后是否体现敏捷精神。实战中三项最重要敏捷精神: 快速可靠交付,用户价值驱动,持续自发改进。
坚持敏捷精神,而非僵化套用特定做法。实践敏捷时,遵循小而美,每次一小步,挑个痛点集中解决,小步快跑,不断尝试优化。
做到这三点敏捷精神就是敏捷团队。文章来源:https://www.toymoban.com/news/detail-497392.html
FAQ
你所在的团队有哪些敏捷实践已经偏离了敏捷的初衷?从敏捷精神出发,你还可找到哪些小而美好方法?文章来源地址https://www.toymoban.com/news/detail-497392.html
到了这里,关于小步快跑,敏捷开发的精髓!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!