# 背景

随着大家对系统稳定性愈加重视,提高线上系统稳定,加强代码设计、编码等评审工作,成为京麦团队在本次迭代开展的一项重要工作。但是,本次迭代对设计评审过程中暴露出的问题,大家在本次迭代的回顾会议上也进行了思考和建议,从如何提高评审效率,总结出了有建设性的意见。

同时,在本次迭代中有一些时间点特质的故事出现严重延期,让别人对团队的能力产生了质疑,大家在本次迭代的回顾会议上也是痛定思痛,认真考虑和提议,从如何保障准时上线,总结出了有建设性的建议。

1. 如何提高评审效率

几乎团队的每个人都认为进行设计评审和代码评审是有必要的,并且会帮助团队提高代码质量,但是如何高效的召开评审会议,成为我们讨论的焦点。

因为本次迭代大家反映最多一点就是评审过多,时间太长,成果微薄。

大家积极发言,提出n+1模式(n代表业务小组成员,1代表外部专家),时间太长是因为缺少设计经验,设计评审能从别人业务中学到东西,评审之前应先讨论清楚方案,评审不能形式,参与人自愿,超过三人评审会议即可开始,建议小组结对设计等等。

大家提出了好多建议,最终总结以下几点,一、确认评审步骤,二、评审把握关键点,三、明确产出

# 步骤

(1) 思路确定

在进行设计之前,需要确认设计思路是否正确,如果是业务类需求,需与产品确认沟通业务逻辑是否一致,如果是技改类需求,需与架构师讨论设计思想是否存在缺陷。

(2) 设计

在确认设计正确的基础上,进行设计,不需要整理设计说明书,如果几张图能说清楚是最好不过的了。

(3) 小组讨论

在召开集体进行设计评审之前,需先进行小组讨论,确保小组沟通意见一致,如有异议,可保留至设计评审进行确认,但是,异议是采用提供多方案对比,而不是在集体评审上没有方案,等待大家出方案,以及对使用的技术不了解等,如果是这样,请回到步骤1。

(4) 集体评审

集体评审的目的在于:从听众者不同的视角给出设计建议,避免设计者因技术壁垒或钻牛角尖等问题出现的技术缺陷,而且集体评审的另一个作用要能对听众者启动有借鉴的作用。

# 关键点

在进行设计评审过程中,需要把握一些关键点。

(1) 时长

评审会议多长时间合适,开始大家讨论固定时长,但是考虑现实设计功能差异,是不能简单一概而论的。所以,最终确定在发起会议邀请的时候,邀请不仅要确认主题和会议产出,更要明确会议时长,即发起人自定义时长。并且,考虑会议太长,会议效率也会变差,所以评审最长时间40分钟,保障效率,同时也更高的要求了设计者的能力,不仅从设计能力,还包括演讲能力。

(2) 主持人和主讲人

由于设计评审先小组讨论的方式讨论,所以评审采用主持人和主讲人的方式进行,主讲人负责讲解设计和阐述,要语言简练、意图明确,让听众很简单的理解你的内容;而主持人则负责计时、提醒等,控制主讲人的时间,以及不要让主讲人跑题等等。

(3) 规模

会议采取自愿参加的模式,建议采用 n+?+1(n就是功能设计的小组成员,?就是自愿参加的听众,1就是至少1个专家)

补充:当时还考虑设计评审通过的方式,但认识到评审的目的并不在于反复评审,即使在评审中提出的多处不足,但大家都充分明确改造点,则不需要进进行二次评审;同理,如果评审之后的改动方案很大,当事人也没了底气,那可能还是要进行多次评审的。

# 产出

(1) 设计说明书

(2) 评审会议纪要

2. 如何保障准时交付

这个话题的由来主要是由于本次的故事延期严重且大家重视度不够,还有在需求讨论和故事评估时不够仔细,以及在说明需求的时候没有明确上线时间等多种因素造成的。

鉴于此,我们痛定思痛,我们要高度重视上线的时间节点,但是光从嘴皮上说说,可能也没人信,所以我们首先找到了影响上线时间点延期的主要因素,然后针对每个点进行有目的性的突破,最后从事前、事中、事后的全流程的进行保障。

# 影响延期的因素

(1) 外部依赖

我们知道产品大了,关注的人多了,与外部的合作自然而然的就会有,但是我们也知道,与外部有效的合作也是一件很难的事情。关于外部依赖的问题,我们在前期就要明确双方的排期,并且要不惜一切代价确保这点,用一个词形容就是:地推。拉个小凳子,坐在对方旁边,让要对方真切的知道这件事对我们很重要,而不是你说了一句话,还要等待依赖方来找你,如果是那样,这件事要不就不重要,要不你就是你不上心。

(2) 代码质量 

(3) 需求不明确、需求边界与需求变更

这几点其实很简单,出现问题多沟通,沟通不妥找领导。

# 沟通技巧

在这里还要啰嗦的分享下,如果与他人进行沟通的技巧,主要就是三部曲:

(1) 晓之以情,动之以理

(2) 事件升级

(3) 动手(打得过就打,打不过就跑,总之要搞定问题)

# 需求整理流程

这里还有一点很重要,就是规定了需求整理的流程。

(1) 需求阐释

在新迭代开始之前,由产品经理汇总业务类需求,由团队master负责汇总技改类需求,整理下个迭代的需求池,这个需求池是粗略的汇总,不是所有需求都会安排到下个迭代中,确认迭代故事是在计划会议中。

确认好需求清单之后,由产品经理和团队master召开需求阐释会议,进行需求阐述,在这个过程中,需要让团队充分需求内容,每个人可以提问,但不能讨论。并在此由产品经理、团队master与团队共同协商需求优先级,产品按照业务方要求和上线节点阐述需求重要性,团队master从系统稳定性和线上问题隐患等方面阐述需求重要性。

重点,做到过程公平。

(2) 自认领拆解故事 

当团队清楚下个迭代做的内容后,团队即可进行任务自认领,开始与产品和团队master进行需求确认和拆解故事,这个阶段不是设计,只是把需求熟悉细化的阶段,其中的目的在于,如果你做这个需求,你要非常了解这个需求。

对一些没人愿意认领的故事,可能就需要团队master进行指派了。

(3) 计划会议确认

当需求都通过自认领的方式分配好后,召开计划会议,在计划会议上由自认领的个人或小组代表进行需求阐述和故事说明,在这个阶段要求团队每个人对自认领的故事是非常负责的,充分了解业务需求,如果出现纰漏,就直接影响规模评估和上线时间点的设定。

(4) 规模评估

当确认所有需求被合理拆解之后,就进入评估故事规模的阶段,采用斐波那契数列(1,2,3,5,8,13,20),每个数字代表1人日,一个迭代10个工作日,假如团队10个人,那就总共100个人日。按照故事优先级进行评估,当评估的故事的累计规模达到团队上限即结束,没有排进的故事自动延至下个迭代。

(5) 拆解任务

这里唯一要说的就是拆解任务的工时总和不一定等于故事评估规模,但也不能偏差太大,如果很大,就说明前期哪个环节有问题。

# 事前、事中、事后

最后要多嘴的就是事中的日常沟通,以及事后的上线后跟踪。

日常沟通反映在早会,大家有问题、有风险,尤其是可能延期的风险一定要早会上多沟通。上线后跟踪的意思是,不是功能上了线就完事了,是需要上线后观察运行一段时间,或一周、一月等,必要的话每天要发监控或统计日报等。

# 总结

草草总结出了,这写内容出自京麦服务端一次迭代的回顾会议。