敏捷开发se是什么角色_敏捷开发产品处于什么角色 - CSDN
  • Scrum敏捷开发角色

    2014-02-22 23:56:44
    在Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是: 产品负责人(Product Owner) 确定产品的功能和完成时间;对产品的收益负责;根据市场需求确定产品功能的优先级;...
           在Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是:
    • 产品负责人(Product Owner)
    • 确定产品的功能和完成时间;
    • 对产品的收益负责;
    • 根据市场需求确定产品功能的优先级;
    • 在每个Sprint开始之前,可以修改功能需求和优先级;
    • 有权决定接受或否决各Sprint的工作成果。
           Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任,他的主要工作是根据市场需求,确定产品的功能,列入Product Backlog中,并为这些功能确定优先级别。
           Scrum团队按照功能的优先级,将它们从高到低分配到各个Sprint中进行开发,这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
           在产品的整个开发过程中,Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog,增加某些功能需求、删除某些功能需求、修改优先级等等,但这些行为只能在各个Sprint之间进行。
    • Scrum Master
    • 负责监督整个Scrum项目进程,调整项目计划
    • 确保开发团队成员的能力能够胜任产品的开发;
    • 促进团队中不同角色的成员间充分交流和沟通,并负责为项目的进行扫除障碍;
    • 保证开发团队不受外力的干扰和阻挠;
    • 掌握产品开发进度,参与每日Scrum会议、Sprint计划会议和Sprint评审会议。
    • Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当。
    • 开发团队

           一般由5-10个能全职工作的成员组成较为理想;团队成员横跨各个职能,通常包含开发,测试,文档设计人员等等。


           这与我们传统的开发模式(瀑布模式)截然不同了。开发团队可以及时有效的交流,而不是像瀑布模式中受职位和文档的限制,使得出错率低,积极性高,从而提高了开发效率。



    展开全文
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...

    敏捷开发模式下需求分析岗 BA

    传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法

    思考:敏捷开发过程是否存在完整需求分析? 敏捷过程到底是如何做需求分析?   用户故事和用例有什么区别?  敏捷过程如何去管理需求的?

    这些是一些想要实践敏捷的人一直在困惑的事情。 我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

    敏捷项目中谁来做需求分析?

    在敏捷的团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。 了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试

    敏捷项目中如何进行需求分析?

           敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

           在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。 举一个最常见的用户故事例子,“作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务”。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。 从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示“登录失败请重试”。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

     

    用户故事和用例有什么区别?

            用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在。 不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能,而不是文档。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的,可见的,并且是有价值的。 如下

     

    【敏捷项目需求分析案例】 公司有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。 在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。 项目经理圈子客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。 有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。 另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。 客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

     

    敏捷过程如何去管理需求的?

            用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用户故事,这样就可以安排下一迭代的开发。

              每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。 在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。 在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

              项目实践中实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中,让开发和需求分析并行进行。这就是公司敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色 。

    展开全文
  • 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP…为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有...

    原文出处:http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP…

    为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

    什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

    为什么说是以人为核心?

    我们大部分人都学过瀑布开发模型,它是以文档为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

    什么是迭代?

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    关于Scrum和XP

    前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

    什么是Scrum?

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

    而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

    【Scrum开发流程中的三大角色】

    产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    这里写图片描述

    //————————

    下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

    什么是Sprint?

    Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

    如何进行Scrum开发?

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

    3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    下面是运用Scrum开发流程中的一些场景图:
    这里写图片描述
    上图是一个 Product Backlog 的示例。

    这里写图片描述
    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

    这里写图片描述
    任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。

    这里写图片描述
    每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

    展开全文
  • SA ----------系统分析师 System Analyst PM ----------项目经理 Project Manager RTE---------发布培训工程师...DevOps-------开发运维协调者 Development&Operations Ops----------运维 Operations PO----...

    SA ----------系统分析师 System Analyst

    PM ----------项目经理 Project Manager

    RTE ---------发布培训工程师 Release Train Engineer

    DevOps-------开发运维协调者 Development&Operations

    Ops----------运维 Operations

    PO-----------产品或业务负责人 Product Owner

    SM-----------敏捷开发经理 Scrum Master

    Dev ----------开发者 Developer

    QA-----------质量控制Quality Assurance

    转载于:https://www.cnblogs.com/zjhblogs/p/10625453.html

    展开全文
  • 项目级敏捷定义:项目级敏捷指产品TR2完成系统设计后,在TR2-TR4A范围内,具有迭代、持续集成和自适应特征的软件开发模式。项目级敏捷聚焦单个项目组或多个项目组协同的软件开发过程和能力改进,对IPD版本级的交付和...
  • 
 00.管理是把事情做对,而领导是做对的事情。——彼得....  01.你必须管理系统,因为系统本身不能对自己进行管理——爱德华兹....02.企业文化是不可能随意改变的,企业文化来自员工对公司行为的探讨,是员工...
  • 敏捷开发中除了PO跟SM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.     因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个...
  • 回顾lab1,结对编程给了我们从未有过的体验,从实践到对理论的理解正是实践出真知的过程,只有亲身体会过才能领悟敏捷开发的魅力所在。
  • 总结的国外的敏捷开发资料且翻译成中文:The CIO’s Guide to Becoming a Trailblazer 资料下载:http://download.csdn.net/detail/u011774517/9747734下面谈谈我对翻译的内容“8个敏捷开发的最佳实践”的理解,我...
  • 敏捷开发的一些东西

    2012-03-28 14:14:32
    如何实践敏捷软件开发。这个是很多团队必须面对的问题,也是让项目经理比较头疼的问题。如果一个项目不能有一个很好的交付,那么项目就是失败的。 下面是一个关于对于提升团队交付能力的一些实践建议或者准则。 ...
  • 人们总习惯于想象“了解自己的工作”,所以,当BA接到一个新的项目,BA总是很快进入角色开始工作。这样看起来很合理,但让人吃惊的是,客户经常会失望,BA被责备,或者项目失败了,因为“BA”从开始就不清楚自己的...
  • 敏捷开发整理

    2013-08-24 16:24:01
    开发宣言: ...正因为敏捷开发的这些特征,原则,模式等等,才需要有相应的敏捷测试团队与之匹配,注重和敏捷开发团队配合,沟通,并且重要的是测试团队要理解和重视敏捷的思想,融入这样的一个大的
  • 首先强调一些Scrum的基本概念本文只想为那些不断实验敏捷开发方法、追寻快速交付产品的IT管理者提供全套经过验证的实践经验,供之参考。我首先假设你已经理解了Scrum这种敏捷开发方法的基本概念并认同之,但是仍然,...
  • 本产品从2014年开始正式推行敏捷转型,到2016年实现产品级敏捷,大概用了两年时间。本文是根据我在中兴通讯这两年的经验做的总结,见识比较肤浅,且大部分是靠回忆写下来的,免不了存在一些不一致的地方。 一、敏捷...
  • 业界关于敏捷的认证有很多,Scrum、SAFe、Devops等流派都有自己的认证体系,但都是关于个人的,对于团队/项目的敏捷开展状态则比较少见,借用CMMI的说法叫成熟度。这里介绍由ThoughtWorks提出的敏捷成熟度评估框架。...
  • 最近在敏捷中国发起了一场关于瀑布vs敏捷的讨论,论者纷纭。虽然争得热闹,但我个人认为,这样一个题目对于瀑布模型而言,本身就是不公平的。这样的一种比较,就好像拿现在的好莱坞大片去与上个世纪六七十年代的电影...
  • 我们汇总了您可能会在面试中获得的10个面试问题的清单,以及有效的答案,帮助您为梦想的敏捷Scrum工作做好准备! 1.在30秒内解释敏捷敏捷是一种方法和行为框架,鼓励“及时”生产,使客户能够更快地获得高质量...
  • SA,SD和SE的差别

    2015-07-22 22:52:23
    做软件开发项目规划时, 常会碰到助理问我一个问题, SA,SD和SE的差别在那里 ? 这 个问题我以前也有过, 还颇为困扰, 系统分析和系统设计及系统工程到底有什么差别 ? SA和SD的工作又有何不同 ? 这两者的养成教育又有...
  • 又是很长时间没有更新博客了,客观原因是真的很忙,主观原因是自己太懒了。但是想想,知识、经验都是慢慢积累起来的,...想是这样想,但真正忙起来的时候就什么都顾不了了。所以,趁着五一长假,终于有时间写一点东...
  • 我作SE的那点事

    2012-04-22 17:48:59
    离开XXX项目已经快半年时间了,其实早就想写点什么分享一下在这个项目中作为SE的一些感触,但又总是不...其实一直蛮幸运自己能有机会参与这个全新的开发项目,更加幸运自己能担任SE这个难得的角色,也是这个项目让已经5
1 2 3 4 5 ... 20
收藏数 677
精华内容 270
关键字:

敏捷开发se是什么角色