敏捷团队如何把控代码质量和准时交付
|
# 背景 随着大家对系统稳定性愈加重视，提高线上系统稳定，加强代码设计、编码等评审工作，成为京麦团队在本次迭代开展的一项重要工作。但是，本次迭代对设计评审过程中暴露出的问题，大家在本次迭代的回顾会议上也进行了思考和建议，从如何提高评审效率，总结出了有建设性的意见。 同时，在本次迭代中有一些时间点特质的故事出现严重延期，让别人对团队的能力产生了质疑，大家在本次迭代的回顾会议上也是痛定思痛，认真考虑和提议，从如何保障准时上线，总结出了有建设性的建议。 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) 拆解任务 这里唯一要说的就是拆解任务的工时总和不一定等于故事评估规模，但也不能偏差太大，如果很大，就说明前期哪个环节有问题。 # 事前、事中、事后
最后要多嘴的就是事中的日常沟通，以及事后的上线后跟踪。 日常沟通反映在早会，大家有问题、有风险，尤其是可能延期的风险一定要早会上多沟通。上线后跟踪的意思是，不是功能上了线就完事了，是需要上线后观察运行一段时间，或一周、一月等，必要的话每天要发监控或统计日报等。 # 总结 草草总结出了，这写内容出自京麦服务端一次迭代的回顾会议。 本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然) ©著作权归作者所有 |
