关于Scrum

1,570 阅读6分钟

即刻作为一个创业公司,不管是团队还是产品都在快速变化。在提升每个人自身能力的同时,团队协作也慢慢成为一个重要的部分,因此我们不仅引入了Scrum,也在其基础上根据自身情况不停的调整。

先看下没有Scrum时的问题

  • 产品发布周期不稳定,迭代缺乏节奏感。
  • 开发缺乏明确任务时间表,时间安排全凭自己。对于工程方面的工作比较有利,想做的可以马上做,但是对于团队协作开发的需求效率较低
  • 产品需求不够明确(只有idea,缺乏具体细节)时就开始动工。不可否认这样的好处是小功能可以快速试错,但是随着项目发展,当多team协同开发大功能时,会极大地增加沟通成本。比如由于文档不够清晰,客户端A去跟产品经理B确认一个细节,完成了以后还需要通知其他产品经理C、客户端D、后端E、测试F等等,有时候还会推翻之前的结论。这样一来虽然看起来大家都在热火朝天地讨论,但是效率其实不高。
  • 产品和开发对于工期的预期不一致,时常会互相pending,客户端等后端接口,后端等具体需求等等。
  • 经常会因为事先未考虑到的突发情况(产品活动、技术上的障碍)而delay。
  • 在开发中途遇到新的需求或者idea,经常会犹豫是加到当前开发中的版本,赶一下工稍微推迟发布时间,还是顺延到下一版本?如果在赶的过程中还有另外的调整怎么办?

一些假设

  • 就像团队开发需要制定代码规范、模块调用需要调用规范一样,团队协作也需要敏捷开发流程规范,确保团队间互相预期一致,减少低效沟通和互相推锅。当出现问题,定责(不是为了blame某个人,而是找到原因)和改进就相对容易。
  • 在高速变化的创业公司,流程本身应该随着公司和产品情况不断迭代的(元迭代?),如果某个环节大家都不满意,应该立即优化并在下一个sprint中执行。
  • 对于team leader来说,提高流程和团队的效率比提升自己的效率更重要,尤其是对于项目环节越来越多的时候,需要尽量避免个人英雄主义。(一个大工程,光靠某一个好模块是不够的。只有当每个模块间的数据流通畅时,工程本身才能运作良好)
  • “改需求”是无法完全消灭的(在创业公司可能也不应该),但是可以通过合理的流程限制在一个可以接受的水平(好比bug无法完全消灭,但是code review流程可以让工程师自我监督,有效减少bug)。过于灵活的调整会降低开发效率,反过来死板的流程也会伤害产品。需要不停地在两者间做出平衡。
  • 产品经理永远是希望加入更多的功能的,而且一定能给出一些合理的理由来支撑,但是并不一定考虑实际的工作量。Scrum master谨慎评估,在必要时果断拒绝一些短期看似合理,但其实伤害长期效率的需求,防止Scope Creep发生从而破坏团队间的信任。
  • 工程师大多倾向于在自己的领域里单打独斗,天生反感开会等低效而耗时的沟通流程。如果能够减少被打断的次数,可以大幅提高工作效率(就像减少线程/上下文切换可以提高代码执行效率)
  • 功能开发不应该占用工程师全部的时间,敏捷流程应与工程师文化相辅相成。产品迭代、流程迭代和技术迭代、工具迭代一样重要。
  • 工程师应该参与到产品设计中去,从技术和自身角度出发提供建议,提升ownership。尽量在功能正式开发开始之前充分讨论,因此这对产品需求计划的前瞻性也提出了很高的要求。
  • 对于一个功能,如果花费1个小时时间可以做到70分,但是75分需要2个小时,那么优先选择1个小时的做法,在下个迭代中再看情况优化。
  • 一个重要的大前提是,公司能够招到足够优秀的人,且维持足够好的工程师文化。这一点也是即刻一直重点努力的方向之一,在这方面不管是产品、测试、开发至少都能做到“搁置争议,共同开发”。

执行

  • 确定一个稳定的Scrum周期,如两周。当产品的需求周期也是两周时,那么可以做到每两周发一个新版本。
  • Sprint planning前,产品需求应该到一个相当清晰的水平,否则每个team估算的时间成本可能与实际相比有大幅偏差,影响本次sprint计划的制定。
  • 在Sprint planning时,产品开发一起进行任务拆解,估算时间后,决定哪些功能放入本sprint,哪些延后。注意planning meeting不是需求讨论或者brainstorming,不应无休止的争论每个需求的细节。整个会议尽量控制在1小时以内。
  • 当planning完成时,每个小团队内部分配task。当分配完成时,整个sprint来自外部的任务就确定了,接下来工程师有权自主分配开发时间。大家只需要在sprint结束那天达到task完成,并开始beta测试的预期目标。
  • 大家共同的预期是,在Scrum结束时,必须要有一个准release版本进行beta测试。
  • 每天Daily standup meeting与大家分享目前进度,并提出可能遇到的问题(如被谁block,或者工期delay等)。一般每个人只需要十几秒时间就能说完,因此整个meeting最多不超过10分钟。
  • 如果遇到改需求,需要team leader一起评估:类似改字体或者图标,那可以随时改。如果大家认为是较大功能改动(如需要花费1天以上)会影响已有的工作安排,顺延到下个sprint。这对于产品team是一个负反馈,能够促使下一次的需求计划更加合理。
  • 当遇到重大突发情况(如突如其来的流量增长、critical bug fix等)同样需要大家一起沟通,可以延后一些相对不重要的task,但尽量不影响sprint的节奏。

快速迭代,快速反馈,快速改进,不管是产品、开发还是Scrum本身。Facebook(曾经)说Move fast and break things. 对于一个年轻的公司,年轻的团队来说,需要冲劲,更需要专注和执行。


PS: 如果你认同即刻的文化,又喜欢即刻的产品,那还等什么?一起来吧!有相当多的职位等着你。链接: 加入即刻