我的组织一直在尝试引入更多"敏捷"方法.我们一直在尝试Scrum方法,大多数团队或多或少都适应了它.我喜欢它作为一个整体,但我担心该方法的一个潜在的严重影响:由于团队一直专注于功能和积压项目,并且测试人员与整个开发过程更加整合,似乎技能组合正在变得模糊不清,人们对自己的个人能力缺乏尊重.
我们的一些开发人员在服务器端技术和优化重量级数据配置方面表现出色.其他人已经投入了大量的职业学习GUI技术,并在应用程序中对用户和可用性有了基本的了解.技能组合都不比另一组技术好,但它们肯定是不同的.
这是Scrum流程的必然结果吗？由于团队中的每个人(据我所知)都有助于满足下一个功能/要求,积压项目或测试目标,因此基本理念似乎是"任何人都可以做到".根据我的经验,这根本不是真的.大多数工程师(开发人员,测试人员等)都拥有他们多年来磨练的特定技能,而在我看来,Scrum方法往往会贬低他们之前所尊重的那些能力.
这是一个澄清的例子:
如果服务器端数据配置发生突然的技术更改,并且sprint的待办事项列表中的每个项目都基于这一新变化,那么GUI开发人员(可能没有时间适应新技术)可能无法为冲刺做出贡献.至少,他们需要投入时间来加强,然后他们的代码将因为缺乏经验而受到怀疑.
我理解快速发展的必要性,以阻止"角色孤岛",但这并没有打折一个基本现实:人们根据必要性,兴趣或经验发展技能.当人们认为他们的位置是"插件能力"之一时,他们似乎没有那么积极性(例如,我们可以"插入"任何人来执行这项特定任务).Scrum如何解决这个问题？如果没有,有人在采用Scrum方法时解决了这个问题吗？
简短的回答是强调不!Scrum的也不会模糊或贬值专业化所需的技能.Scrum不会促进泛化.
答案很长,在Scrum中,最重要的是让工作"完成".团队作为一个团队(而不是一群个体"明星")根据需要进行协作,以完成工作.无论需要什么 - 无论他们想要什么(Scrum是关于自我管理,自我激励的团队,对吧？).
这意味着scrum团队可能由几位专家组成,他们主要负责他们的专业(DBA,平面设计,甚至是技术作家).作为一个整体,团队应具备满足要求所需的所有技能.这与说每个团队成员必须具备上述所有技能不同.
话虽这么说,经常期望-通常由会员自行-其他成员比专家至少有足够的技能,从他们的专业不同.另一张海报已经提到过Scott Ambler的"综合专家".当专家缺席时,这可以帮助团队完成一种类型的工作,并且当他真正希望获得专业以外的经验时,它可以帮助该成员.
鉴于团队是自我组织的,如果由于某种原因,专家发现自己处于冲刺的中间,没有任何工作可以做他的专业,处理它的最好方法是简单地询问专家他想要什么做.让团队决定.专家可以决定在其他方面提供足够的帮助,为下一个冲刺做一个POC,通过修复一些长期被遗忘的技术债务来"支持"防御,或者照亮正在工作的成员的鞋子.
对.我不知道这是不是很长的答案.但这肯定是一个很长的答案.:-)
Scrum的观点是让开发人员自我组织.我们在我所处的位置使用scrum,并且根据一个人的关注点对作业进行被动排序.我们不是故意用图表和列表来做的,它只是发生了.我们都知道谁最擅长什么,或者他们的主要/次要重点是什么.如果"主要"人员需要帮助,他们会让那些以次要为重点的人/人来帮助他们.我们确实得到了大量的任务,不一定与我们特别关注的任务一致,但你总是知道该向谁寻求帮助.
对于你的例子 - 我不知道如果你说有3个服务器人和5个gui家伙,你希望在那个sprint中完成所有工作(如果服务器人员+其他人的帮助不是足够).sprint的工作方式是,从优先级列表中,开发人员选择他们认为可以在30天的时间范围内完成的工作.如果这意味着GUI人员需要2天的服务器端培训才能提供帮助,这就是它的意思.除非在列表中同时存在并发事项,否则他们可以做到.冲刺任务不应该被管理层规定为伪造的截止日期.
如果你有一个Safari帐户,那么一个发明scrum的人就会有一本很有趣的案例研究书.
京公网安备 11010802040832号 | 京ICP备19059560号-6 