51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6375|回复: 17
打印 上一主题 下一主题

[讨论] 敏捷开发中测试管理的未来

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-9-4 18:02:31 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
敏捷项目是拥有一支支小规模但职能全面的团队,在这样一个普通的敏捷团队里,拥有具备不同职能的 成员,如1 名 UCD(User Centered Designer),1 名 Visual Designer,1 名测试人员(Tester), 1 名 Information Developer 和 3 名开发人员(Developer)。
      我不明白的是,当一个项目被分解成一支支小规模但职能全面的团队,那些测试经理在测试管理方向该如何做呢?
   他们的位置是不是要被取消?
   这时候他们的主要工作又是什么了呢?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

18#
发表于 2012-5-8 09:29:39 | 只看该作者
呵呵,想听更多的关于敏捷开发测试方面的东西
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2009-9-28 17:13:54 | 只看该作者
LS曲解Line Manger的意思了,LM+PM称作矩阵式的双线管理。主要适用于项目更替较快的外包公司。

由LM收集并储存人员,PM向LM的人才库中筛选合格的项目所需人员。

PM主要管理人员在项目的工作情况,主要是task的分配以及完成情况监督等。

LM主要管理人员的非项目问题,比如假期的审批(当然,这个审批也同样需要与PM协商),个人考核的最终裁定,个人发展的定位等等。

LS所说的那种LM其实并不是纯粹的LM,只是类似于一个研发部长的职能,然后这个部门下有N个PM,每个PM拥有较为固定的人员配置。
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2009-9-19 10:25:11 | 只看该作者
Line Manager通常是角色而不是职位。Tester Mgr, Dev Mgr一般是职位。一个Mgr管谁,就是谁的Line Mgr。

好的Mgr会帮助团队成员解决问题,提供指导和培训,避免外界干扰。差一些的,只能做人力资源方面的事情了。
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2009-9-18 12:11:05 | 只看该作者

回复 13# 的帖子

现在的外企普遍都有Line Manger这个职位,不过经常这个职位的下属一般都是Tester和Developer的混合体。其职能与13#的仁兄说的一样,相当于人力资源调度的一个职位。

也许是偶目前接触的外企不过,不排除存在单纯的人力资源方向的Tester Manger和Developer Manger的存在。
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2009-9-17 11:23:52 | 只看该作者
敏捷很适合实验室型的研发科技企业
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2009-9-17 11:12:01 | 只看该作者
外企也有 Test Manager。一般是作为每个tester的line manager。类似的,开发也可能有 engineer manager。不过,这些Manager一般都不参与具体的项目。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2009-9-16 11:43:40 | 只看该作者
在国内,敏捷开发模式根据各自企业/项目的不同,分成几个板块,比较有特色的如,外企如Nokia一直使用的scrum模型,华为/中兴则根据各个标准流程自己裁剪敏捷流程。

一般来说,外企中注重自身管理,一个PM宏观调控多个Team,PM通过scrum模型来控制整个项目组取得项目目标。而每个Team之间相对独立,各自组成一个个小的scrum开发模型。每个Team可能有1个或多个tester,他们大部分的工作靠自身管理完成,但是每天的工作情况需要让Team Leader或PM清晰了解即可。

在国企中,则更注重控制意识,在team之外设置一个Tester Manager的职位,主要负责管理和支持各个Team中的Tester的工作。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2009-9-14 21:19:48 | 只看该作者

回复 10# 的帖子

谢谢LS鼓励与支持,有时间相互交流一下。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2009-9-14 20:03:52 | 只看该作者
华为听说只是做持续集成。那样的企业文化,做自管理貌似不太可能。

LS做scrum master,不错。很有前途的职业。全中国也没几个像样的scrum master。好好干。

我也觉得敏捷不是每个人都适合的。很多工程师缺乏主动精神,做敏捷不合适。
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-9-14 18:54:37 | 只看该作者
原帖由 hexiangchang 于 2009-9-7 11:32 发表
这个问题问的很不错,目前华为在大力推行敏捷开发!
你别忘了,实际上测试经理的主要职责是统筹整个测试团队的测试协调工作,所以他有很多的事情做的。比如MC的工作,以及其他相当多的内部协调工作要做的,具体的内 ...


阿里有些部门尤其是原雅虎的成员,都是用的scrum管理。我在团队里担任scrum master职务,主要职责为协调或服务与团队。
个人总结:敏捷开发并不是每个团队都适合的,也没有固定模式,其前提条件是团队成员的责任意识,其核心内涵为团队效率最优化。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2009-9-13 20:22:13 | 只看该作者
敏捷团队中,测试人员一般是自我管理的。当然,他必须把自己的工作安排,和工作进度告诉团队中的所有成员。

测试经理在项目进行中的主要解决团队无法自己解决的,关于测试方面的问题。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    慵懒
    2016-4-26 13:27
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    7#
    发表于 2009-9-11 15:07:59 | 只看该作者
    敏捷开发只是一种开发过程,测试管理只要根据这个过程特点去做就行了!个人觉得对测试管理没有大的影响!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2009-9-11 14:38:28 | 只看该作者
    现在做敏捷测试的公司或者项目还不是很多嘛?

    怎么参与讨论的同仁不是很多嘛
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2009-9-8 10:14:59 | 只看该作者
    我曾经见到过这种团队,虽然我没有置身其中。
        不过敏捷开发团队虽然小,但在实际操作中不局限于楼主所说的人数。
        测试经理也许不会置身其中。而参与开发的测试人员主要是由这个敏捷团队的“队长”管理,每天的工作也向“队长”报告,而不是向测试经理报告。当然测试经理有权对该测试人员进行管理,比如了解以及跟进进度,给予技术指导,参与人员调配等等。
        在我的理解中,这个时候的测试管理主要是由敏捷团队的“队长”进行管理,而测试经理起的是一个辅助的作用。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
     楼主| 发表于 2009-9-7 13:53:32 | 只看该作者
    hexiangchang讲的主要是测试部门经理的职责吧? 我想说的是项目中测试经理的职责



    不过还是期待hexiangchang的详解!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2009-9-7 12:01:30 | 只看该作者
    期待详解
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
    发表于 2009-9-7 11:32:57 | 只看该作者

    这个问题问的很不错,目前华为正在大力推行敏捷开发!

    这个问题问的很不错,目前华为在大力推行敏捷开发!
    你别忘了,实际上测试经理的主要职责是统筹整个测试团队的测试协调工作,所以他有很多的事情做的。比如MC的工作,以及其他相当多的内部协调工作要做的,具体的内容,俺以后再讲!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-16 09:15 , Processed in 0.078793 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表