精华内容
下载资源
问答
  • 让我们来看这么一个故事: 一天,一头猪和一只鸡在路上散步 鸡看了一下猪说:“嗨,我们合伙开一家餐馆怎么样?...这个故事是Implementing Scrum网站为了解释,什么是Scrum而推出系列故事最具代...
    让我们来看这么一个故事:
    一天,一头猪和一只鸡在路上散步
    鸡看了一下猪说:“嗨,我们合伙开一家餐馆怎么样?
    猪回头看了一下鸡说:“好主意,那你准备给餐馆卖什么呢?”
    鸡想了想说:“餐馆卖火腿和鸡蛋怎么样?”
    猪说:“不开了,我全身投入(火腿是一次性资源),而你(鸡蛋是可再生的)只是参与而已!”
    

    在这里插入图片描述

    这个故事是Implementing Scrum网站为了解释,什么是Scrum而推出的系列故事中最具代表性的一个,它展示了在Scrum中的两组角色:猪和鸡。

    在故事展开之前,我们先来了解一下什么是Scrum。

    Scrum是迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法。

    好了,回到本文开头的故事。

    猪被认为是Scrum团队中的核心成员,在一个团队中产品的负责人和Scrum主管和开发团队就是"猪"角色。

    鸡不是Scrum的一部分,但必须要考虑他们,用户、客户或提供商、经理等扮演着“鸡”角色。需要说明的是在Scrum团队中不会有一个人同时成为“猪”角色和“鸡”角色。

    我们看看团队中的“猪”都有哪类角色:

    产品负责人(Product Owner)

    即负责维护产品订单的人,代表利益相关者的利益。

    我们可以把这一角色理解为没有项目管理权限的产品经理,他只对产品负责,决定做出来的产品是什么,包含哪些功能要点。传统的软件开发流程中,产品经理是要肩负起一定的项目管理的职责的,产品经理可能同时就是项目经理,甚至在一些企业中CEO就是最大的产品经理。但是在Scrum框架中,产品经理没有项目经理的权限,无权干涉项目开发的进度,项目的成功与失败也不需要产品经理独自承担责任。产品负责人最大的职责就是做好开发团队与客户之间沟通的桥梁,维护好“产品订单”,排列出开发的优先级。简单来说,有没有按时做完项目不是产品负责人的责任,但做出来的东西是不是客户想要的就是产品负责人的事情了。所以产品负责人必须是Scrum团队的一员,和其他成员一起时刻盯着团队开发的是否是“产品订单”中列举的东西。

    Scrum主管(Scrum Master)

    即为Scrum过程负责的人,确保scrum的正确使用并使得Scrum的收益最大化。Scrum Master需要知道团队其他成员如何完成开发工作。这一角色通常要团队中最资深的那个开发人员来担当比较合适,不仅仅是他的技能可以指导其他成员,更因为他有资历去排除哪些影响Scrum实施的外界干扰。 Scrum Master虽然同样无项目经理的权限,但需要他在关键的时刻站出来,帮团队推掉来自外界甚至是高层临时下达的产品开发需求。

    开发团队

    由负责自我管理开发产品的人组成的跨职能团队。Scrum教程里倡导的Scrum团队的理想人数是7人,那么即意味着除了1个Product Owner和1个Scrum Master外,开发团队应有5人。开发团队必须是跨职能的,如果大家的技能相同,很容易出现彼此推诿的现象。 每个人都应该明确,自己的工作只有自己才能最好的完成,这样才能组合在一起形成一个团队。另外,开发团队人数不能过多。

    Scrum倡导的是自我管理的团队,这其实是违背传统的管理模式的。团队人数少的时候,即使团队中个别人缺乏自我管理的意识,那周围同伴也很容易帮助其提高和改善自我管理的能力。但团队人数一旦很多,出现一群无自我管理意识的人群的时候,那影响的作用力就是相反的,这一小群人会影响周围更多的人,此时Scrum团队又无一个专职的管理者,便会出现“无政府主义”的现象,造成一盘散沙的恶果。
    在这里插入图片描述

    属于“鸡”的又有哪类角色呢?

    用户

    在Scrum流程中,虽然不能完全听取用户的意见,但还是得时刻关注用户的感受和反馈。 因为Scrum是一种迭代式增量软件开发的过程,如果每个小模块都能得到用户良好的反馈的话,那无疑最后完工的整个系统出差错的概率会小很多。毕竟用户不是专业软件开发人员,整个系统对其来说过于庞大和复杂,一个个小模块是其能最好理解的单元个体。处理好用户与开发者关系的重要人物就是前面所讲的Product Owner,他必须及时的收集用户的反馈,以此完善每次冲刺的订单,但同时又不能让用户的反馈去影响开发的步骤。

    利益所有者(客户,提供商)

    在Scrum体系中,一旦开发团队与客户确认好开发需求后,客户应该无权在中间干涉团队是怎么完成的。客户需要了解,随意的更改需求、干涉开发的流程是很危险的,极有可能出现鸡飞蛋打的双输场面。在前期项目立项的时候要尽可能多的和客户接触,完整的记录客户所有的需求。但在开发过程中,特别是每天的站立会中,建议不要让客户,特别是根本不知道什么是Scrum的客户来旁听站立会。

    经理

    可以把他理解为项目经理或部门经理,甚至是管理产品开发的副总或直接就是老板!这群人就是故事中的鸡爷爷,他们财大气粗,有权有势,为了能开发出新的有竞争力的产品,为小猪们提供了资金和场所,所以他们对产品的意见也是至关重要的。

    Scrum实施中一个令工程师们兴奋的就是项目经理将不再管理我们的开发过程,我们自己管理自己。但实际操作起来,这确实是最难的一个环节。

    一旦项目经理在Scrum“每日立会”中下达指示,而Scrum Master又没挡住的话,那这个团队的Scrum实施就失败了,团队成员会觉得自己失去了领导的信任,被授予的自我管理的权限又被无情的收回了。

    大家又会重新回到原先的模式,每一步听从项目经理的指示,按指示办反正不会有错,失败了是项目经理指示错误的责任,成功了也能跟着项目经理分碗汤喝。

    Scrum能否成功实施,很关键的是能否得到高层的认同和理解。一个团队要实施Scrum,首要需要接受培训的就是公司高层领导们,高层领导们要权衡实施Scrum的利弊,如果Scrum能带来高效、优质的开发成果,那就应该忘记Scrum实施过程中给所带来的心灵上的折磨。我们可以合理的定好Scrum团队中每个人的KPI,让每个成员真正意识到项目成功是自己的事,而不是项目经理、高层们的事。

    Scrum能否成功实施关键在于“猪”与“鸡”两种角色之间心理上的平衡与和谐!“鸡爷爷”切不可把“小猪”们看成是一群猪八戒,空有一身本领,但好吃懒做。“小猪”们也不可把“鸡爷爷”想象成周扒皮,只会半夜鸡叫,影响正常的开发进度。猪和鸡双方相互理解,达到项目开展过程中的平衡点,才能让整个项目顺利的完成。

    展开全文
  • 敏捷开发中测试角色的窘境

    千次阅读 2016-01-24 22:44:24
    敏捷开发中测试角色的窘境 先说说敏捷开发中码农哥哥与测试妹妹一段恩怨情仇: 测试妹妹:需求文档在哪里? 码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲...
    敏捷开发中测试角色的窘境


    先说说敏捷开发中码农哥哥与测试妹妹的一段恩怨情仇:


    ------------------------------------------------------------------------------------------------------------------------------

    测试妹妹:需求文档在哪里?
    码农哥哥:这个...,没有需求文档,产品经理发了我一句话,后来直接和我说了要求,很简单,我和你再讲一下吧。
    测试妹妹:好吧,懂了,那我开始测了。

    测试妹妹:测试完了,有5个bug,我都提交了,你看看吧。

    码农哥哥:好的,还有一个新需求,再和你讲一下。

    测试妹妹:终于测完了,全部测试通过了,恭喜啊
    码农哥哥:sorry,刚我改动了一个小点,你再重新回归测试一次吧,这次应该OK了。
    测试妹妹:终于回归完了,又发现一个问题...

    产品经理:客户反馈了一个bug,你赶紧看看
    码农哥哥:不可能啊,这个功能我都测过的,我看看
    码农哥哥:真晕,线下测试是好,线上有问题,有个配置错了,另外这个客户的数据比较奇怪,测试也没有验证过这种场景
    产品经理:XXXXXX,客户已经提故障了!
    码农哥哥:下次线上发布一定要叫上测试妹妹仔细回归

    码农哥哥:今天晚上12点产品更新,到时要你来回归验证啊
    测试妹妹:好吧
    测试妹妹:你们发布完了吗?都凌晨2点了,我什么时间可以回归验证啊?
    码农哥哥:再等等,还有一个小问题在搞。
    测试妹妹:现在好了吗?
    码农哥哥:sorry,没搞定,发布要回滚了,今天不需要回归验证了,你先回去吧
    测试妹妹:你妹啊!!!

    ------------------------------------------------------------------------------------------------------------------------------

    故事讲完了,以上就是一些项目敏捷开发中很常见的问题。

    敏捷开发强调的是快速迭代,通过快速迭代发布并验证产品是否满足用户需求来减少产品风险,而不是像传统软件一个花一年甚至几年才发布。敏捷开发在互联网行业里非常流行,大型网站基本每周都会有发布,甚至一周发布几次,超大型网站的应用都是分布式的,一天都可以发布上百个feature。
    互联网的需求变化很快,有些产品也是实验性的,所以更需要快速迭代,这也会导致许多产品在一些小的需求都没有需求说明书或者设计文档,全是靠产品经理与研发同学沟通需求,然后就快速发布上线了。这种模式在传统软件里是不可能,传统软件都会有很强的产品版本概念,并且会对每次升级都要制定详细的设计、开发、删除与发布计划。 

    面对互联网这种快速迭代,并且还有时缺少需求与设计文档的背景下,我们测试同学如何跟上节奏。如果按传统模式,测试与研发是不同的人员负责,那么必需要有清晰的需求设计文档,否则测试基本靠感觉。并且产品经理与研发同学还要与测试同学沟通需求,沟通项目计划与资源协同。第二,今天互联网的研发同学普遍比测试同学多很多,有些产品甚至是10:1以上或者是没有测试角色,这样的团队测试同学根本来不及了解需求细节,只能做一些核心主功能验证,对于边界测试没法顾上。总体看起来独立测试角色在敏捷开发里有点力不从心。

    经过几十年的发展,测试类型也细分成很多种,有白盒测试、黑盒测试、灰盒测试、单元测试、功能测试、集成测度、性能测试、压力测试、自动化测试、回归测试、灰度测试、安全测试、恢复测试等等概念。 当前业界的测试工具眼花缭乱,有QTP/UTF、LoadRunner、JMeter、Selenium、TestDirector、QACenter、Rational系列等知名产品,也有很多JUnit、TestNG、RobotFramework、gtest等测试框架,还有更多如网络、数据库、硬件等专业领域的测试工具。

    这些产品,除了JUnit、JMeter这类程序员可以轻松掌握的轻量级产品框架外,其它产品在敏捷开发中都感觉力不从心,主要原因是大部份产品为测试角色开发的,研发角色有学习成本,并且研发同学更喜欢白盒测试。

    如果测试的工作由研发来完成,这会更符合敏捷开发思想,大大减少沟通成本。但是问题来了,研发同学并不擅长使用各种测试工具,研发同学更多只会完成单元测试。如果能有一个专门面向研发同学的测试工具,岂不是很爽,那一个面向研发同学的测试工具应该是什么样的呢?我先说说程序员自测的一些现状:
    1.单元测试:目前JUnit、TestNG加各种Mock基本还能应付,就是测试代码写起来很多
    2.功能测试:这个很头疼,如果软件有界面,可以通过软件操作来完成核心功能测试,如果没有界面,就自己模拟软件对外API接口规约来模拟测试
    3.性能测试:这个要么使用JMeter这样专业工具来完成,实在不行,要不就自己再单独写一个程序或脚本来压测
    4.回归测试:不好搞,面对各种运行环境,人工回归太不靠谱了,真心需要一个全自动化的工具
    5.安全测试:太专业了,估计搞不定
    6.边界测试:写各种边界值来搞死自己,想到的就试试,没想到的就当不存在了
    7.bug管理:都自己测试了,还提个毛bug啊,自己老老实实把屁股擦干净

    从上面看起来,要是交给程序员自测也不靠谱啊,完全是靠感觉,凭经验测试了。

    如果有一款面向程序员自测的专业测试工具,它会是什么样的呢,我列了几点:
    1.学习成本低
    上手很容易,如果是框架,不要超过JUnit这样的难度吧,如果是产品,那应该有一套简单易用的界面,并且不要冒出很多测试概念,不要动不动就来1GB的安装文件,最好能免安装了。
    2.功能测试用例编写简单
    编写功能测试用例,不要只是简单的像bug管理那样写一堆文字描述,测试用例应该是可以运行的,编写完后就能直接运行、验证
    用例编写的语言应该非常简单易学,或者是直接用程序同样的语言(如JAVA、C、Python等),不要让我去学习一套新的语言或规范
    测试用例的代码应该很短,不要是我的业务程序写了100行代码,结果测试用例写了300行代码,这会很奔溃,可能会导致我花了大量的时间在调试测试用例脚本是否正确,如果测试代码小于程序代码的1/5就挺好。
    3.功能测试用例能同样显示测试代码覆盖率等信息
    单元测试可以比较简单的看到测试代码覆盖率,查看未测试到的代码。这个很有用,功能自动化测试希望也能看到这个,这样可以确认哪些地方没有测试到位。
    4.可重用,可扩展
        有些组件是已经写好的,测试用例应该能直接复用,比如java中一些标准jar包函数,或者是自己产品里封装的组件。这样对于编写测试就更高效了。
    扩展性要好,自己也可以封装一些测试组件,供别人使用或者模块公用。
    5.可以自动化回归测试
    面对各种环境:开发环境、测试环境、预发环境、生产环境A、生产环境B,自动化回归测试太重要了,最好是功能测试用例编写完后可以直接用在回归测试里,不要又单独写一套回测试用例。
    6.能自动造测试数据
    造测试数据很花时间,有时还需要造各种随机数据,另外各种边界数据也能自动化最好了,靠人想有时不靠谱的
    7.能支持UI自动化测试
    现在UI测试基本靠人工,Selenium之类的产品IDE比较简陋,语法也需要重新学习,学习成果不低,而且有点地方写起来很难受。需要能有更高效的UI自动化测试支持。
    8.调试方便
      编写测试用例脚本要有方便的调试功能,用例运行过程希望能显示详细的输出日志,特别是在用例运行失败的情况下,不然找问题很花时间。
    9.免费、开源
    你懂的

    最近自己团队也在做这方面的探索,希望能设计出一个适合程序员自测的专业测试工具与方案。 
    好了,写了这么多点,可能我孤陋寡闻,也不知道是否已经有这样专业的产品,谢谢推荐。
    展开全文
  • 我和敏捷开发的故事--敏捷角色PO

    千次阅读 2015-08-31 22:09:31
    在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线...当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解.     第一个

          

            在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.

     

            通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解.

     

            第一个要说的角色是PO

     

             敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。

     

            在我们的团队中PO是行方的专门业务人员担任并执行PO角色,本身并不开发.跟她打交道的一方面是我们这边的开发团队,另一个方面是行方的业务团队,她作为开发和业务的桥梁.

     

            PO主要是确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品负责。是维护产品需求清单( product backlog )的人.详细的职责为一下七点:

     

    1、确定产品的功能;

     

    2、决定发布的日期和发布内容;

     

    3、为产品的ROI负责;

     

    4、根据市场价值确定功能优先级;

     

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

     

    6、接受或拒绝开发团队的工作成果;

     

    7、参与ScrumPlanning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 SprintRetrospective Meeting(Sprint回顾会)

     

     

            结合我们的团队的PO来说一下实际的情况,在项目的初期我们的PO基本上上是神龙见头不见尾,很少有机会见到他的面,因为他本身还担任行里的其他职务,总是来也匆匆去也匆匆,所以导致了前期开发中很多不可避免的问题.之后行方安排了专职人员担任项目组的PO,整个项目组20个人分成两大组,两个PO负责我们这两个大组的任务和计划.

          

           随后经过团队的磨合,PO也越来越专业,开始进行原型设计,挖掘业务,更融洽的跟开发人员进行沟通和交流.

     

          一个迭代的成功与失败完全由PO说了算(在相对比较理想的情况下),总结就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    展开全文
  • 敏捷开发的角色和职责阐述

    千次阅读 2019-05-18 18:58:21
    敏捷开发中的PO即Product Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品...

        敏捷开发中的POProduct Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

        敏捷开发中的SMScrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

    Product OwnerPO

    Product Owner角色定义

    确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROIprofitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

    Product Owner工作职责

    负责最大化产品以及开发团队工作的价值。主要职责如下:

    1、确定产品的功能;

    2、决定发布的日期和发布内容;

    3、为产品的ROI负责;

    4、根据市场价值确定功能优先级;

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

    6、接受或拒绝开发团队的工作成果;

    7、参与Scrum Planning MeetingsSprint计划会议),Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)

    Product Owner在团队中的作用

    junior团队中:主要的需求来源,个人确定需求价值和优先级

    intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

    Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

    这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

    一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    Scrum MasterSM

    Scrum Master角色定义

    是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

    Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

    Scrum Master工作职责

    确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

    1、保证团队资源合理利用;

    2、保证各个角色及职责良好协作;

    3、解决团队开发中的障碍;

    4、作为团队和团队外部的接口,协调解决沟通中的问题;

    5、保证开发过程按计划进行,组织Scrum Planning MeetingsSprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review MeetingSprint评审会)和 Sprint Retrospective MeetingSprint回顾会)。

    Scrum Master在团队中的作用

    junior团队中:主导和控制

    intermediate团队中:引导和教导

    Senior团队中:辅导和协助

    一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    展开全文
  • 敏捷开发的角色分配

    2017-05-11 10:42:00
    敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。确定产品的方向和愿景,定义...
  • 概述:主要就敏捷开发模式对用户角色建模方法指引。 用户角色建模目的 敏捷项目,PO通过编写用户故事,以用户为中心来体现产品需求内容。所以在编写故事前识别用户角色和虚拟人物,对用户角色进行建模就...
  • 敏捷开发003-角色

    2018-11-27 15:33:36
    第一篇介绍了敏捷角色的划分及职责但是写太粗了,我觉得这点特别重要有必要给大家细划一下: PO (project manager) 性格要求: 能忍受孤独 用户故事经常被团队排斥并且在项目是独立,所以PO一定要经得住...
  • 01.精益——敏捷软件开发中质量保证(Quality Assurance,QA)的角色展开,涵盖了许多关键问题  *测试人员的作用是防止缺陷,而不是发现缺陷  *开始做开发周期计划时如何发挥验收测试的作用,以做到在最大限度上...
  • 敏捷开发3种角色

    2017-04-20 10:36:00
    在Scrum角色中包括:产品负责人(Product Owner,PO)、ScrumMaster(SM)、开发团队(Team)。 角色:产品负责人(PO) Scrum团队只有一个产品负责人,他负责在限定期限内拟定可能最有价值产品。这是...
  • 敏捷开发团队PO和SM角色介绍

    千次阅读 2017-05-14 09:48:51
    敏捷开发团队中PO和SM角色介绍 2013年05月20日 没有评论 19,832 views ...通过前面几篇关于敏捷开发总体的相关介绍,相信大家...敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业
  • 02.企业文化是不可能随意改变,企业文化来自员工对公司行为探讨,是员工与管理层接触时经验和对管理层行为评论。   03.管理者两个重要职责  *设定结果或团队预计要达成目标  *协助工作人员改进过程并...
  • 我和敏捷开发的故事--敏捷角色-SM

    万次阅读 2015-09-29 22:21:25
    通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是...敏捷开发中的SM即ScrumMaster,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队包括三个角色,他们分别是产品负责人、开发团队和 项目直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能完整...
  • Scrum敏捷开发角色

    万次阅读 热门讨论 2014-02-22 23:56:40
    在Scrum有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们职责分别是: 产品负责人(Product Owner) 确定产品功能和完成时间;对产品收益负责;根据市场需求确定产品功能优先级;...
  • 李烨_敏捷团队QA角色的转变 Pivotal首席软件工程师李烨参加TiD质量竞争力大会,并带来题为《敏捷...不仅经历过多种开发流程和团队组织形式,同时还具有多年的敏捷开发经验。 详细解读 和小伙伴们一起来吐槽
  • 我和敏捷开发的故事--敏捷角色-TEAM

    千次阅读 2015-09-29 23:23:16
    敏捷开发中除了PO跟SM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.     因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个...
  • 敏捷开发 所有角色 在“敏捷项目经理的职责”第1部分 ,我描述了促进敏捷项目经理的职责。 在“敏捷项目经理不做什么”的第2部分,我描述了一些更传统的项目经理可能会认为他们的工作仍然存在的角色,即使他们...
  • 敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的...
  • 简述敏捷开发中的测试流程

    千次阅读 2018-08-14 15:57:51
    需求讨论:这个阶段测试人员要把自己带入到用户角色中,列举用户角度场景需求,协助开发和产品制定技术实现方案; 确认验收标准:为了避免sprint进行产生扯皮推诿,应当在需求讨论会上就确定验收标准。 形成...
  • 项目级敏捷定义:项目级敏捷指产品TR2完成系统设计后,在TR2-TR4A范围内,具有迭代、持续集成和自适应特征的软件开发模式。项目级敏捷聚焦单个项目组或多个项目组协同的软件开发过程和...项目级敏捷流程中的角色说明
  • 对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式转型,这种转型相对传统测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大挑战,那么测试人员应该如何应对呢?...
  • 敏捷开发

    2020-10-09 11:28:20
    2. 敏捷开发流程中的三大角色: a. 产品经理:和客户沟通,编写产品需求文档,验收开发完成的产品。 b. 技术负责人(leader):技术上负责整个项目的开发流程,管理开发团队,分配开发任务,验收开发完成的产品。 ...
  • 软件测试思想者 - 敏捷开发中的Scrum术语 Scrum是一种项目管理方式。在Scrum团队中,有3种定义好的角色: 【PO - Product Owner/产品负责人】  在整个敏捷Scrum开发的过程中,Product Owner起着至关重要的...
  • 但发现其并没有紧扣敏捷开发测试特点,这五个约定在传统开发中已经早有实践,也有相关论述。哪么在敏捷开发的测试方面有没有不一样于传统开发测试并且是有效实践?  从敏捷团队组建上来说,敏捷团队并没有...
  • 敏捷开发中的Scrum流程

    千次阅读 2013-12-10 09:30:11
    任何人力流程都离不开人来执行,所以在讲解Scrum流程之前,有必要先把Scrum中的角色讲一下。 一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 814
精华内容 325
关键字:

敏捷开发中的角色