给经理的一封信:激发敏捷团队的力量!

发表于:2017-1-17 11:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:51ipm    来源:51Testing软件测试网采编

分享:
  关键要点
  ◆ 想要一个敏捷团队成功就要给他们创造一个适合他们的环境,这是团队经理的责任。
  ◆ 控制在制品数量,这样可以比对任何需求都说行的方式取得更多的成绩。
  ◆ 长期来看,尊重队员的反馈需求要比做实际工作更重要。
  ◆ 团队要获得支持才能达到“共享目标,共担责任”的状态,千万别因为直接进行个人管理而破坏了这一点。
  ◆ 团队不同,环境不同,要容忍各种不同的工作方式和产出。
  敏捷并不容易。按理说它是提高效率和促进创新的最有效的办法之一,所以才几乎所有的公司都想采用它。然而事实上很多公司却从来没有享受过敏捷方法带来的好处。为什么要采用敏捷?原因不外乎尽早发布产品、关注最能创造业务价值的核心工作等,还有提高效率和质量,或者提高员工的参与热情。但不管目标是哪个,如果你没有做好一个经理该做的事,你都要承担一无所获的风险,甚至可能会导致团队的冲突和解体。
  在我做为敏捷教练指导传统IT部门进行转型的经验里,好的坏的例子我都遇到过。敏捷失败最常见的一个原因就是团队的直接领导层不能给予团队最充分的支持,甚至有时候失败就是被这些领导设置的障碍导致的。
  通常管理层并不知道他的行为到底对团队和工作是有利还是有弊。为了帮助大家,我准备给大家提一些建议,希望每一个敏捷团队的经理都能看到,包括管理多个敏捷团队的部门经理。
  亲爱的经理,以下内容可以帮助你的敏捷团队获得成功:
  控制在制品数量和清晰的优先级
  在传统的工作模式下工作需求都直接来源于经理(直线经理、项目经理、质量经理等)。工作需求都是被认研究过的,需要的时间是被评估过的,而经理最后也会得到产出——至少是被通知一声说需求已经按要求完成了。但是在敏捷开发中,工作需求和经理之间并不是这样的一种模式。研发团队直接与客户沟通,大家的具体工作内容已经不需要等待指派,也不会事事经过评估了。这意味着经理无法掌控团队正在进行中的每一项工作,而当没有经理充当守门人的时候,某一个队员或者整个团队就都有可能会陷于需求之中而无法自拔。
  工作需求可能有很多不同来源,而且通常是非正式的渠道。这意味着不管是从行动上还是心理上,正常的拒绝需求的机制已经无效了,而且通常需求一来就会被要求马上开工。当大家一接到需求就立刻开工时,那些做了一半的需求就会被打断、排后,慢慢越积越多。于是效率开始下降,很多已经开工了的需求无法收尾。之后就会形成一个恶性循环,在这种情况下所有工作都会推迟,每件优先级略高的事都要硬塞进来,令人十分痛苦。
  为了避免恶性循环,打造良性循环,你就必须为需求排优先级和做限制,方法是既要在制品的数量,又要只做最重要的需求。要接受这样的现实:不是所有排在队列中的需求都会被完成的。要对你的产品有一个清晰的愿景,要有一个可靠的产品负责人,他在需求补充会议上或做迭代计划时都只会拿出最重要的需求来让大家做。要让团队明白,当他们决定了要完成多少工作之后,他们就要为承诺负责。
  不管你们用Scrum还是Kanban,你都要学会观察你的团队是如何限制在制品数量的,帮助他们守住那个限制。这方面的好行为有:
  ◆ 把新需求提给产品负责人,而不是直接提给团队中的某个人或者直接贴到白板上。
  ◆ 问问团队为什么大家现在同时开展了过多的事情?提醒他们清楚的知道当前的状况,鼓励他们遵守最初约定的限制数量。
  ◆ 用Scrum时约束一次迭代的工作内容范围,这样有助于提升效率,减轻压力。
  ◆ 鼓励团队使用累积流程图(Cumulative Flow Diagrams, CFD)和流动负债图(Flow Debt Diagrams,FDD)来展现他们的工作进度。累积流程图有助于理解随着时间的推移事情整体进展得怎么样了,流动负债图则清晰的展现了未完成工作和已完成工作之间的对比情况,这样究竟是哪里开展了太多工作而导致不能按时提交就一目了然了。
  偏离轨道很容易,但要是能马上发现的话回到正轨也很容易。你不加限制的时间越长,回到正轨所需要的时间也越长。
  尊重反馈的需求
  关于工作有一种普遍而幼稚的观点,就是如果你让一个团队或个人把更多的时间投入到工作上,你就能获得更多的产出。这听起来象是挺合逻辑的,但会间接造成他们没有机会去学习如何能把事情做得更好了。大多数经理只是承认这个观点而已,但几乎没人会鼓励他们的员工把时间花在其他事情上,比如回顾、改进流程、尝试其他解决方案等等。这样加班加点的工作方式会不时的受到经理有意无意的鼓励,结果不久之后团队的工作效率就会因为士气低落和身心疲惫而停滞甚至降低。
  作为软件开发这样的知识型工作,总是有几乎无限种新东西可以学习,相应的也就有无限种可能的方式来提高效率,而只采用其中的某几种就可以帮你做得更好了。一个团队每隔一两周找个安静的地方讨论一下某种方案是否可行,这样就可以找出大家效率最高的协作方式了。用这种探索不同解决方案的方式开发出来的产品,极有可能比你最初预想的更好。
  首先可以做的事情是保证开发的过程中有一些“空档”。空档的意思是有一些没有分配具体工作任务的时间,并且当出现空档时可以由团队或个人来决定这段时间如何使用。有很多办法可以留出空档,比如制定迭代计划时不要按照团队的能力安排100%的工作量,或者当同时进行的工作数量达到上限时就不要再启动新的工作了,等等。这样留出的时间非常适合于学习和做尝试。
  当有空档时,团队可以选择一些不同的东西去学习和改进。做回顾通常都可以帮你获得一个很棒的开端,因为好的回顾可以帮助团队建立信任,找到更好的合作方法。回顾的另一个好结果是发现新点子,可以尝试改进团队的工作流程和产品。所以当你留出了空档之后,你一定要保证有些团队成员知道如何做好回顾。
  还有一种要鼓励团队去做的好行为是让几个团队成员同时分别去设计一下架构或者用户接口等。这样团队就可以比较他们的设计成果并选出其中最好的一个付诸实施,甚至可以将它们整合起来形成一个改进版。通过这种方式你就启发了所有的队员去思考和交流,有可能会获得更好的设计,而做过设计的个人也会得到对他们的设计非常有价值的反馈。相对于获得的学习效果来说,这种作法又安全又不需要什么成本,因为你只不过是让几个队员同时去做了一下设计而已。
  另外一种非常重要但常被忽略的反馈方式是,如果一个团队可以与他们的经理沟通把某些问题提高到合适的层面上去,那问题常常可以得到简单而有效的解决。在传统的组织中,往往问题上报给管理层之后就呆在那里没人处理了,这种情况很常见。
  可以通过开辟正式和非正式的渠道来让员工和经理沟通问题,这种反馈方式也要大力加强。如果团队借助于经理的一点帮助就可以轻松解决掉某些问题,那团队和经理就都会体会到沟通的益处。如果有些问题经理也没法帮忙解决,那么经理可以把问题再向上级反映,或者动用其他可以动用的资源。
  有些公司甚至会有这样的机制,即如果一个经理或者一个团队在一定的时间内无法自己解决某些问题,那么问题就会自动上报到公司架构的上一层。这并不是为了惩罚那些解决不了问题的人,而是一种让上级管理层知道问题的方式,即公司里现在有什么样的问题是没法解决并需要帮助的。不管问题是不是自动上报的,向上级报告问题都是要鼓励的,因为只有大家意识到的问题才有可能被解决掉。
  做这些事都需要花时间和精力,但如果你用正确的方式做了,你也会获得指数级的回报。获得反馈和做改进都是敏捷流程的非常重要的部分,你要保证你没有把它们废弃掉。如果你发现团队不做回顾、不尝试新方案或者不和你沟通他们的问题,那么就是时候限制一下他们的“实际工作量”了。
21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号