本文主要涵盖以下内容:反馈很低。对于现在的大部分团队来说,他们的沟通方式大多是链式的,从产品->架构->开发->测试这样一个过程。那么每个人都希望在完成规定的职责后成为一个不干涉的店主。最后的结果就是下游环节出现问题时习惯性的把责任推给上游环节。不顾大局,测试就是在开发中拼命找所谓的“漏洞”,而开发是说架构没设计好,架构是找产品的毛病说什么YY需要的产品。这其中最明显的特点就是测试看似表现不错,但产品质量还是一塌糊涂。这就引出了一个很现实的公司管理问题。小团队开发模式下,KPI和事件应该单独评估还是团队评估?新技术(微服务、容器化)的引入,不再适合大部队作战,而是需要一个与之匹配的灵活的端到端团队。在一个层次很多的组织中,最难做到的就是横向管理,往往在团队之外增加一个“保姆式”的组织或监控流程。这样一来,团队除了日常工作之外,还要处理那些层级管理带来的沟通和会议。就这样,整个团队都加班加点累了,事情还是不能按时完成。客户需求的变化不再局限于整体的产品采购,而是趋向于业务的快速迭代,在大部队作战中快速交付和快速变更变得困难。如何配合客户的业务变化,成为传统大型产品销售企业面临的最大挑战。因为一个客户的产品已经很难复制然后交付给下一个客户。在这样的市场条件下,如何对系统进行拆解和灵活组装,更大程度上考验着架构设计的能力,也考验着改变开发组织形式的能力。敏捷开发并不是什么新鲜事物,但是随着微服务、容器化等新技术概念的引入,敏捷开发找到了更合适的切入点。什么是Scrum敏捷开发值得思考的几个问题:团队在需求范围内是否有自主权?开发范围是否按时间倒转?是流程控制开发人员,还是领导流程的人?在一个有市场交付压力的团队中,最容易遇到的问题就是时间倒流。因为交付内容和交付日期已经确定,然后遇到开发瓶颈时,首先想到的就是给团队增加人手。但是别忘了一句经典的话,女人生孩子需要9个月,那么9个女人能生孩子吗?答案很明显。换句话说,如果所有要求都是高优先级,那么所有要求都是低优先级。具体什么是Scrum敏捷开发,可以参考这本书:<>但是我想跟大家强调一下,过程是死的,人是活动的,需要根据到团队情况。不同的是,现在流行的不再是敏捷开发,而是过程DevOps。其实可以说不基于敏捷开发的DevOps就是耍流氓。Scrum不等同于DevOps,也不等同于更流行的SRE概念。(具体SRE是什么,大家可以搜索一下)。DevOps和SRE将运维管理引入开发团队,形成运维与开发的闭环,让开发更有效地考虑实际使用情况。个人理解,三者的关系如下:“scrumvsdevopsvssre”的困境虽然很多时候大家觉得敏捷开发、DevOps等概念很好,但是执行起来却很难。最大的借口是需要做的事情太多了。但这个时候,不管你是团队还是管理者,都需要停下来想一想,因为你遇到的情况很可能类似于下图(来自网络):公司形式和Scrum模型业务形式与Scrum相同吗?我的理解是核心相同,方法灵活,适应性强。主要分为两种主要形式:自运营或服务形式提供B2B产品开发自运营/服务模式Scrum流程概述参考下图:“运营模式”自运营场景中,市场人员和产品策略经理(SPM)讨论产品的大体方向,然后业务分析师(BSA)制定相应的计划,然后每个子产品负责人,俗称产品负责人(PO),根据这些输入制定每个产品的Backlog,以及然后规划每个产品的迭代。那么问题来了,如何将抽象需求或者业务需求拆解成各种子产品呢?一般的做法是在顶层有一个对应的架构师(俗称首席架构师),负责规划产品的边界,大的需求拆分。但是这样的人比较难找,因为他不仅要懂业务,还要设计整体的系统架构,要能够分解需求的边界等等。如果遇到这样的人,千万不要错过。在自营或以服务形式为客户提供支持的场景下,各子产品的PO自行规划迭代范围和上线时间。并非所有功能都必须完成才能上线。对于跑得快的团队,其实可以先推出一个需要其他子产品配合的功能,即使这个功能还没有真正使用过。针对产品关联依赖的特点,可以通过PO之间的Scrum2Scrum协同来解决。(后面会讲到)B2BScrum流程概览参考下图:“b2b模式”B2B产品销售模式下,很难向客户发布独立的子产品,因为客户需要的是一个Turn关键交钥匙模式。这种模式是不是不能实现敏捷开发呢?事实上,它不是。不同于以往的自主运营模式,每个子产品不会发布到生产环境,但每个子产品仍然可以按照自己的节奏发布。只需要在特定的时间,将各个子产品组合起来,做一个基线测试和联调,就可以出一个整个产品的基线版本。这里最主要的是,与其对齐每个产品的版本节奏,不如根据时间点对不同的子产品进行版本选择。另外,集成测试团队只是在需要的时候临时组建,并不是一个固定的团队。请记住,通常这些集成测试人员应该在每个子产品的团队中。各子产品之间的集成测试应在功能特性完成后独立完成。这个基线测试更像是一个集成回归测试。Scrum2Scrum对于一个产品比较大的系统,一个业务流程可能涉及到多个子产品,这就需要不同团队的PO/SA共同协调沟通。“Scrum2scrum”通常由ChiefSA(平台产品)或BusinssSystemAnalyst(业务分析师)召集。战略产品经理和发布项目经理也将参与其中。需要注意的是,团队之间要避免交叉协调和沟通,因为这会导致团队效率极低。团队之间的沟通最好由PO/SA在这次会议中协调。另外,阻碍其他团队进度的需求应该先解决(不一定要完成整个功能,比如提供相应的接口也是一种形式),避免团队之间的等待。这次会议更多的是需求范围的确定和团队之间的协调,没有讨论具体的方案细节。原则上,不同的团队依赖接口,解决方案可以由各自团队的SA来处理。是否需要审查和控制每个团队的计划取决于团队的情况。因为难度比较大,所以几个都比较清楚整个系统各个模块的方案细节。当然,如果有的话,你可以成立一个ChangeControlBoard(CCB)来做专门的架构审查。ScrumTeam的组成和角色划分ScrumTeam的组成一直没有一个很好的定义,人数多少一直是争论的焦点。另外,遇到变化的时候,是团队里多加人好还是有别的好办法?从实践的角度来看,当一个团队中的事情发生变化,负担变重时,最好的办法是重新组建一个Scrum团队来接手新的任务,这比向团队中增加人手要容易得多。毕竟新人的加入在一段时间内不会给团队带来正向价值,因为需要沟通和融合。保持Scrum团队的稳定性是第一原则。那么什么样的团队比较合适呢?可能和数字7有关(我家车牌有777-:)),团队规模7人左右,比较容易操作,沟通成本也比较低,其次,有无需安排专人做管理工作。这样整个团队就会专注于特定的事情。团队的组成:1-1-3-2,如下图所示:“scrumteam”这里需要注意的是,在这样的大型团队中,沟通不再是链式沟通方式,而是有PO和整个团队沟通需求,SA和整个团队传递技术。这里没有真正的管理者,团队自我管理,高度自治。PO的职责是分析定义PRD并基于MRD设计解决方案(可选平台产品)竞品分析,外部数据收集,自行提出并制定产品改进需求并规划产品Roadmap,制定版本计划并选择各迭代范围,组织团队内明确需求的策划游戏,组织产品开发中的特性demo,组织各版本的交付。组织回顾会议,总结提升团队能力。(平台类)收集业务产品反馈,推动新特新产品的业务运营(平台类),收集产品运营数据,支持日常业务使用的解决方案支持,配合架构师规划产品的技术改进。这里强调的是,PO需要能够把控团队的发展节奏,屏蔽外界对团队的干扰,同时彰显团队的核心价值。永远不要扮演扩音器的角色。SA职责产品技术实现架构设计开发成员指导测试成员开发指导测试设计驱动测试自动化组织DesignReview,CodeReview,TestDesignReview等配合PO策划产品技术改进(平台类)指导业务团队架构师对产品使用SA的技术支持是团队技术的代表,需要能够对外代表团队的技术PK技巧。所以跟PO合作很重要。一个代表需求发布,一个代表执行方。没有谁比谁更重要,关键是如何用技术来体现业务的更高价值。SA对已开发技术能力的提升负有不可替代的责任。Develper职责产品技术实现负责子模块的详细设计负责自动化单元测试和集成测试开发提供产品技术持续改进建议明确测试技术细节,协助测试,改进测试设计,确保即时“可见”code:传送门展示/TestCasePass是最发达的。除了完成开发任务,还需要对行业技术,尤其是开源技术的敏感度。加入一些开源项目并提供一些自己的代码将是非常有意义的。如果能有自己的想法,创建自己的开源例子就更完美了。不过在国内开源的情况下,开源还是有公司做后盾的好推动的。测试人员职责产品测试设计测试自动化工具的改进和流程驱动开发开发思维的完善和补充负责端到端的系统级测试、性能测试、稳定性测试为开发和定位问题提供便利产品发布执行测试,这里需要多说一点。因为一些互联网公司已经开始实行不测试的团队。其实并不是说测试不重要了,而是互联网的日新月异使得对测试人员的要求和开发一样高,团队的运营也没有办法为测试预留空档期。不过,这还是要看球队的情况。如果测试能够从每次迭代开始测试设计,那么测试的独立性还是很有必要的。如果团队总是以开发为主,变化总是比较随机(或者叫无法拒绝变化),那么开发自己的测试可能更合适。另外,测试最重要的职责是测试设计,而不是开发的帮手,更不能为开发做杂务。测试最重要的价值在于发现架构和开发中的漏洞,而不是bug的数量。如果还用KPI的方式来考核测试有多少bug,对开发来说,除了助长开发和测试的矛盾外,没有任何好处。开发和测试的磨合,沟通,沟通还是交流。开发和测试的信息来源都将来自于产品需求,而不是测试上游开发测试的转化。在Scrum模式下,开发和测试的界限会更加模糊。测试最重要的功能之一是测试点的设计,而不是通过复杂的重复性工作来体现测试的价值。测试应该更好地考虑如何提供方便的工具。为了更方便定位问题和开发,应该结合测试详细回顾测试点的设计,从而思考开发中可能存在的问题。团队日常活动PlanningGamePlanningGame的目的是向团队传达本次迭代的范围,并确保团队中的每个人都有一致的目标。这应该会导致在一两次迭代后发布。那么每个版本都可以用一句话来概括。如果每次迭代都没有一个核心思想,那么迭代的范围就会很混乱,团队的工作也很容易出现乱序。确定的范围需要提前拆解成各个任务项,将任务放到gitlabissue中进行管理,这样每次提交的代码都可以关联起来,方便后续的codereview。同时,将任务写在便条上,并张贴在团队的看板上。看板现在有很多电子化的管理工具,但是不用担心。事实上,真正的看板更有用。(后面会讲到我们和电子看板的区别)“策划游戏”的经验PlanningGame:不要一次选择多个大功能,选择一个版本中的一些小功能或改进功能作为风控的缓冲预留。技术改进工作项计划在版本维度中。在一个版本中,最好有2个开发迭代(4周)需要发布到生产,并预留一周用于发布缓存看板和站立会议。目前,有很多电子工具都提供了看板的功能,但在实践中,使用真正的看板更容易操作。看板虽然不复杂,但也有相应的书籍,可以参考《看板实战》,如下图:“看板”与电子看板的区别主要在于:关注事物和人,而不是进步。在一般的看板中,总是根据进度粘贴不同的任务,处理者写在备注上。这让人很容易忽略谁在处理这件事,也容易忽略谁是最终交付的风险。把东西分类,比如把某个特性相关的东西贴在一起,这样就很容易控制某个特性每天能不能下发到终端。端到端的补全,让太多的特性开发同时并行,导致端到端的补全,最后无法完成。这也好办。在迭代末尾需要裁减任务时,有看板会更容易,所以每天的站会会更容易,但有几点需要注意:尽可能短(15分钟以内)),而且大家只谈完成情况,遇到方案不详谈,需要具体申明需要协调的内容。新增内容需要立即发布,PO会判断是否需要独立接收新内容。如果有工作依赖或困难的内容,TL需要协调风险需要立即提出尽可能完成一个任务,然后再领导下一个任务。如果发现任务太长,需要分析拆解。如果发现任务有难度,开发商应请SA给予设计。ReviewMeeting在团队的日常活动中,有各种类型的ReviewMeeting,主要目的是在团队内部有效传递信息,贡献团队智慧。具体操作经验如下:由每个主题的Owner组织,包括:DesignReview,CodeReview,TestDesignReview,RetrospectReview对于更大或者更复杂的设计,可以分阶段进行review:1/3->1/2->finalReview必须有最终的完整输出。时间长短一定要控制。一小时比较合适。如果时间太长,应分成多次。EndtoEndDemo团队PO必须确保验收迭代中的可交付成果。端到端功能特性的演示。培养团队有意识地在每次提交代码时快速展示结果。Demo会议的一些体会:当前团队对输出的理解是否一致,PO是否满足,不应局限于完整的测试,只要能完成端到端的场景即可。不要局限于交付前的版本,但是每个Feature都是一个维度,时间可长可短,越快越好,不要局限,要有接口,跑测试代码也是一种Demo。它不是用来挑选或测试的。同时,Demo会议也可以邀请一些关键任务参与,比如营销人员,建立每个人对产品的信息,传达团队对产品更深层次的理解。DoD会议DoD:一的定义。DoD会议的主要目的是让团队总结迭代的输出。这时候,团队可以找一个轻松的环境,比如咖啡店。“dod”DoD的一些经验:-DoD以迭代为维度-版本中第一次迭代的DoD要做好下一次迭代的风控,及时调整版本范围-不要随便关注代码是否已经完成,但同时关注自动化程度,代码质量(Jenkins状态,Sonar状态),文档状态(Doc,Wiki),测试结果,是否做过CodeReview,是否代码清理已经完成(比如扫描ToDo)等RetrospectMeeting返回主团队自我反省和自我提供主要是给团队成员提供机会去思考什么是好的,什么是需要改进的,以及缺什么。“回顾”的心得Retrospectmeeting:你需要回顾上次回顾会议的执行情况。每个内容和每个成员为每个内容写3个重点。在便利贴上写字不是批评会或奉承会。需要总结制定行动计划尽量在咖啡厅等轻松的环境中调节气氛。频率可以两个版本一次(8-10周)。总结“总结”人是活的,过程是死的;没有明文禁止,都应该是可以改变的,不要太拘泥于学术定义,而是真正根据自己团队的情况进行调整。适应和效率是好的过程。并不是说Scrum就可以保证高效率,也不是说没有Scrum就没有效率,一切都靠人。就像一些大型互联网公司的核心平台团队,每个人都有很强的能力和自主权,没有比散养更好的管理方式了。另外,管理者如果愿意看到团队自主权和效率的提升,其实应该考虑如何更好地信任团队,协助团队自主,而不是做“保姆式”的管理。【本文为专栏作者“VIPDOCKER-Leoge”原创文章,如需转载请通过联系作者】点击此处查看该作者更多好文