最近在实践Scrum,有一些心得。Scrum不是一个技术名词,而是一种开发流程,确切的说,是敏捷开发(Agile Development)的一种。

通常讲,在一个完整的Scrum流程中,会有产品负责人(Product Owner),流程管理者(Scrum Master),开发团队(Scrum Team)三个角色。大家各司其职,从一个产品需求列表出发(Product Backlog),细化成每个迭代周期(Sprint),再接着利用每天的站立会议和看板更新每个人的开发进度(通常还有燃尽图)。

一些讲Scrum实践的书里,(甚至)会提到用计划纸牌(Planning Poker)来精确预估研发周期的方式,招式百出。

听起来很美好对不对?

实际差之千里。

Scrum对于很多初创团队,都好似Teenage Sex,臆想跟现实判若两然,做不好实践,就觉得是完全扯淡,屁用没有。

事实上,敏捷一定要多实践,自己实践得出的经验才是最牢靠的。我们之所以抱怨敏捷开发没有解决问题,是因为对它的理解有误区。

很多人觉得敏捷就是:

  1. “想做就做”的态度,避免任何形式的管理、流程和规矩。
  2. 每日站立会议上,对着空气念经,随便挪一挪看板上的任务
  3. 一个领导管下属的噱头,走个流程而已

看起来日日有产出,实际上鬼才知道这些产品做了有没有用,这些代码堆完意义在哪里。团队浑然不知下一步要做什么,纷纷两眼看天。

为什么会这样?

问题的本质不在于敏捷开发这种流程,而在于团队本身。

初创团队永远是在在极端不确定的情况下,开发新产品或新服务。

这本身就无路可循,无迹可探,没有围绕着问题的核心去做产品,是没有办法获得要领的。

所以如果要做好敏捷开发,就必须:

#厘清产品诉求,认真完成商业闭环

  • 你的产品多大程度上解决用户的问题,有没有比现有的方案好10倍
  • 你能从产品上赚多少钱,天花板在哪里
  • 用户会主动推荐你的产品吗,自然增长引擎在哪里
  • 产品要做到何种规模可以覆盖团队开支,你能闭着眼睛算出来吗

#面对现实,解决核心问题

  • 你现在手里做的,是不是在解决用户真实的产品诉求,还是你自己脑补的产品诉求
  • 有什么方式可以快速解决问题救火上线,而不是等待一周后的新版本
  • 面向用户场景输出需求,不要过于在意何种格式,Done is better than perfect

#落实到人,而不是流程

  • 任务最终要拆解到人头上,围绕一个人每日工作量/难度来追踪进度,而不是大锅煮汤摸鱼,要保证进度透明
  • 保持同理心和道义,你的接口或者文档写的烂,是不专业的表现。己所不欲,勿施于人
  • 朴素的拆分任务并完成,你的队友不会把一个简单任务描述的艰难万重,你也不会。

自我欺骗是敏捷开发的禁忌。不管你用什么样的工具(比如用Geekbot代替每天早上的站立会议),都解决不了自欺欺人。

装作看板上一直有任务(哪怕是个简单issue也要拆成好几个),装作设计的产品就是用户想要的,却根本没有调研过友商出品的水准,装作采集的数据有意义,结果根本无法从中得到任何帮助决策的信息,装作每天刷微博是在看行业动态,实际上真的就是在刷微博。

遇到这些情况,团队的负责人必须立刻马上One One,一个人滑水的最大的问题是让团队其他人感到深深的不公。

敏捷开发让你做到在产品夭折前,留出救命的发育机会,越早推出产品,越早拿到你的Alpha用户的真实反馈(他们通常对于现阶段的产品缺点充分包容,但提出问题时却毫不含糊),你也就有更多的机会修正轨道。

如果一个软件开发上线了,最终客户根本没去体验,这样的上线,算不算上线成功?

Scrum必须回归业务本质,才能被善用,否则都是假的。

5 2 votes
文章评分