敏捷团队的人员分布

标签: 团队 分布 | 发表时间:2013-01-16 21:18 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

许多考虑采用敏捷的组织没有把团队迁移到开放式环境就尝试创建项目团队。敏捷价值和原则中,当团队成员可以随时接触到所有其他团队成员、易于获得所有的项目进度图表、在鼓励交流的环境中时,团队可以更好地工作。敏捷测试专家Lisa和Janet 分享了敏捷测试团队的人力资源经验。

测试人员和客户与程序员坐在一起可以促进必要的交流。如果实际情况不允许重新迁移位置,那么团队可以创造性地解决这问题。

Janet分享了自己的故事:

我曾经在这样一个团队工作,空间问题使得所有团队成员不能坐在一起。程序员有一个可以使他们方便结对编程的区域,但是测试人员和客户坐在其他的区域。首先,是测试人员走到程序员坐的用户故事白板区域去参加每日站立会议,当他们有需要问程序员的问题时,也是这样。基本没有程序员走到测试人员的区域(大约50英尺的距离)。我开始准备一些招待他们的糖果,并鼓励开发人员在需要的时候拿一些。但是有一条规矩——如果他们来拿糖果,他们必须问其中一个测试人员一个问题。随着时间的过去,所有的团队成员都会相互走到另一个区域了。不是一边总走向另一边,交流也更频繁了。

团队规模给组织带来了不同类型的挑战。小团队意味着小的区域,所以通常更容易将成员的位置换到一起。大的团队可能分布在全球,这时需要虚拟交流工具。调动大团队的座位通常意味着整修目前的空间,很多组织不愿意这么做。明白你的限制,努力找到团队遇到的问题的解决方法,而不是仅仅接受现实并“保持现状”。Janet举了一个例子:

我工作过的一个团队一开始在楼层的一角,但是通过三年的扩张,逐渐的占据了楼层的75%。墙被拆掉了,去掉了办公室,创建了大的开放区域。团队在这种开放区域工作地很出色,但是所有的开放空间意味着墙没有了。窗子变成用户故事板和白板,白板按顺序卷起以便团队需要时使用。

坐在一起的团队并不总是存在于完美世界中,分布式团队有另外的一些挑战。分布式团队需要帮助团队交流和合作的技术。电话会议、视频会议、网络摄像机和即时消息是一些可以促进在不同位置的团队实时协作的工具。不管团队是在一个位置的还是分布式的,通常存在的一个同样的问题是,敏捷团队需要什么资源,如何获取它们。

新的敏捷团队成员和他们的经理对于团队的组成有很多疑问。可以使用在传统项目中同样的测试人员吗,或者是否需要聘用那个不同类型的测试人员?需要多少测试人员?是否需要具有其他专业技能的人?

关于测试人员和开发人员的“正确”比例的问题已经有很多讨论。组织使用这个比例来确定项目需要的测试人员的数量,可以根据这个数量来聘用测试人员。在传统项目中,没有“正确的”比例,每个项目需要自己估计。需要的测试人员的数量是不同的,依赖于应用的复杂性、测试人员的技能和使用的工具。

Lisa和Janet曾经工作在不同的测试人员——开发人员比例的团队,从1:20到1:1都有。以Janet来说:

我曾从事一个开发消息处理系统的项目,他们的比例是1:10。GUI很少,我手动测试应用的这一部分,查看可用性和是否符合客户的期望。程序员做所有的自动化回归测试,我同他们一起验证编写的测试用例的有效性。我把测试的用户故事,包括某些用户故事的负载测试,分配到开发人员。

我从来没觉得没有足够的时间做需要的测试,因为开发人员相信质量是整个团队的责任。

Lisa则分享了自己的故事:

我曾经是一个有20名程序员的团队的唯一一名专业测试人员,该团队开发在线商店网站的内容管理系统。当程序员负责手动测试和测试自动化时,团队才真正有工作效率。一个或两个程序员在每个迭代的中扮演测试人员,在编码前编写面向客户的测试并执行手动测试。其他的程序员在迭代中承担起测试自动化的任务。

相反的,我现在的团队每三或五个程序员有两个测试人员。我们生产的基于web的财务应用有非常复杂的业务逻辑,有很高的风险,而且密集测试。测试任务通常与编码任务的时间一样多。即使是测试人员——开发人员高比例,程序员也会做一些功能测试自动化并部分承担手动测试任务。专门的测试任务,例如编写高层次的测试用例和详细描述面向客户的测试通常由测试人员完成。

与其关注比例,团队更应该估计他们需要的测试技能并找到合适的资源。负责测试的团队可以持续地估计是否有需要的技能和数量。使用回顾总结来确定是否需要聘用更多的测试人员是一个解决方法。

测试人员适合敏捷团队的工作需要一定的条件。我们不会过多讨论聘用什么类型的测试人员的细节,因为每个团队的需求是不同的。但是,我们相信态度是一个重要的因素。下面是Lisa的团队如何聘用一个新的敏捷测试人员的故事:

我们招募另一名测试人员的第一次尝试并不是很成功。第一个工作招聘公告吸引了很多人,我们面试了三名应征者,但是没有找到合适的人选。程序员希望找到“技术人员”,但是我们也需要有同业务人员合作和帮助他们描述实例和需求的技能的人。为了吸引有正确的态度和思想的应聘者,我们努力明确工作招聘公告的内容。

在听取Janet和敏捷测试社区的其他同事的想法和建议以后,Lisa改变了工作招聘公告,包含如下的条款:

  • 熟悉黑盒和GUI测试用例,设计测试减轻风险,帮助业务专家定义需求。
  • 熟练编写简单的SQL查询和插入/更新语句,掌握Oracle或其他关系型数据库的基础知识。
  • 至少使用某种脚本语言或编程语言和/或开源测试工具超过一年。
  • 使用基本Unix命令的能力。
  • 擅长与程序员和业务专家协作。
  • 最好有基于上下文环境的测试、探索性测试或场景测试的经验。
  • 融入自组织团队的能力,即与同事协调确定每天的任务,而不是等待分配的工作。

Lisa表示:这些需求带来了更适合敏捷测试工作的应聘者。我通过小心的筛选,排除了有“质量警察”思想的人。追求职业发展和对敏捷开发显示出兴趣的测试人员更倾向于有正确的思想。团队需要对测试工具和自动化领域有较强能力的人,所以学习的热情是极为重要的。这种新颖的招募测试人员的方式是值得的。当时,找到好的“敏捷测试”候选者是不容易的,但是接下来进行得更顺利。我们发现把测试职位公告放到不那么明显的位置,例如Ruby的邮件列表或者本地敏捷用户组,可以帮助延伸到更广阔范围的合适的候选者。招聘敏捷测试人员教授了我许多关于敏捷测试思想。有良好技能的测试人员对于任何传统测试团队都是有价值的,但是因为他们对测试的态度,可能不适于敏捷团队。

崔康 热情的技术探索者,资深软件工程师,InfoQ编辑,从事企业级Web应用的相关工作,关注性能优化、Web技术、浏览器等领域。

您可能也会喜欢

相关 [团队 分布] 推荐:

敏捷团队的人员分布

- - InfoQ cn
许多考虑采用敏捷的组织没有把团队迁移到开放式环境就尝试创建项目团队. 敏捷价值和原则中,当团队成员可以随时接触到所有其他团队成员、易于获得所有的项目进度图表、在鼓励交流的环境中时,团队可以更好地工作. 敏捷测试专家Lisa和Janet 分享了敏捷测试团队的人力资源经验. 测试人员和客户与程序员坐在一起可以促进必要的交流.

专访QQ大数据团队,谈分布式计算系统开发

- - 互联网 - ITeye博客
NoSQL是笔者最早接触大数据领域的相关知识,因此在大家都在畅谈Hadoop、Spark时,笔者仍然保留着NoSQL博文的阅读习惯. 在偶尔阅读一篇Redis博文过程中,笔者发现了. jacksu的个人博客,并在其中发现了大量的分布式系统操作经验,从而通过他的引荐了解了QQ成立之初后台3个基础团队之一的QQ运营组,这里我们一起走进.

干货|建议初创团队起初也要构建分布式应用

- - 行业应用 - ITeye博客
干货|建议初创团队起初也要构建分布式应用.          本文内容整理自W-Time技术分享沙龙-天津站现场演讲《一切都是分布的》,演讲者:李傲,问啊联合创始人,前中交车联网总架构.     好多人都会问什么是架构师. 其实架构师的定义很宽泛,前端后端的定义都不一样. 作为后端出身的架构师,我认为后端并不是大家想的封装组件,它要定义的是规划,规划模块之前的关系.

雅虎BigML团队开源大数据分布式深度学习框架TensorFlowOnSpark

- - IT瘾-tuicool
雅虎 Big ML 团队今日宣布开源 TensorFlowOnSpark,用于在大数据集群上进行分布式深度学习. 下面是该团队官方发布的开源说明. 近几年,深度学习发展的非常迅速. 在雅虎,我们发现,为了从海量数据中获得洞察力,需要部署分布式深度学习. 现有的深度学习框架常常要求为深度学习单独设定集群,迫使我们要为一个机器学习流程(见下图 1)创建多个程序.

团队

- Lorna - 坏脾气的小肥
我最近心情起落比较大,如果把时间线再拉长一点,则是去年多自负,今年多自责. 冷静下来的时候也会想,我能不能做得更好. 每一个团队都有它的长处,有它的短处,对于团队的缺陷首先要问自己几个问题:. 1、有没有激励大家全心全意地认同和投入这个项目. 2、有没有分工合理,使每个人认同和投入自己的任务. 3、他的缺陷是否可以通过工作指导、严格督促,在半年或一年时间里自我完善.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

DBA团队的使命

- 2sin18 - Alibaba DBA Team
DBA团队的使命:提供高可用、高性能、可扩展的数据存储服务. 高可用:可用性是运维的根本,我们不管做什么事情,都要把可用性放在第一位. 高性能:对性能的关注是我们一直坚持、做的最好的一面,仍需要继续做到极致. 可扩展:也就是最适合的,易部署,可线形透明伸缩. 数据存储:不只是关注某个数据库本身,是基于对各种最先进的数据存储技术的精深理解,提供最专业的服务.

谈团队知识管理

- - 人月神话的BLOG
如果要谈学习型团队,那么团队知识管理就相当重要,团队知识管理介于企业知识管理和个人知识管理之间,核心是知识能够成为整个团队的资产,并为团队创造价值. 今年在团队知识管理上,重点就是按照cmmi的一些思路,形成指导书,规范流程,工具模板,培训教材,检查单的完整知识库积累. 明确各个岗位职责和分工边界,能够按着规范流程做事情,大量前期积累的知识库又能够帮助团队成员快速的学习和解决问题.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.