2015-09-29 22:21:25 jnqqls 阅读数 7576

        

        通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster.

 

Scrum Master(SM)

 

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

 

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

 

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

 

       这一点在实际项目经验中是很难达到的,因为想要达成自我组织的团队并非一朝一夕,尤其是新组建的团队,本身团队就是一个磨合的过程,只不过我们是通过哪种方式可以磨合的更快,更有效率.如果SM这个角色能够很好的担当和把控,非常有利于整个团队的磨合.

 

Scrum Master主要工作职责

 

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

 

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

 

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

 

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

 

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

 

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

 

            结合我们项目中的实践,SM的角色一直处于变化的过程中,大概在项目进行半年之后才稳定下来,前期因为变更着,导致项目整体比较混乱,没有一个主线.SM稳定之后,整个局面有好转,但是并没有预期的效果好.

 

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

 

2015-09-29 23:23:16 jnqqls 阅读数 3306

        

      在敏捷开发中除了POSM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.

 

      因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个新的团队磨合成敏捷开发所要求的自组织团队是一个比较难得过程,尤其是在实际的开发进度和需求等不定因素的影响下.

 

     因此提高Team的凝聚力是创建自组织团队一个 重要因素.

 

    团队的凝聚力来自于大家都在为一件事而努力,每天都在做,而且经常有提高。

      为了提高团队凝聚力,有很多途径可以实施,例如在每天的站立会议,Team成员除了介绍每天的工作,还可以做两个额外的事情:

 

        一个是快速形成某个团队级别的决议,例如将某个方法作为公共模块,临时调整资源等,解决阻碍团队的重大问题;

 

          另一件事情是代码分享或者代码复查,每个人都会拿出昨天最核心的功能代码,讲给大家听,只包括外部模块的耦合,业务逻辑,大家进行讨论,结果不是发现了漏洞,就是发现了某个人的代码更加规范,其他人都会和他保持一致。当然,因为涉及到具体代码此过程在站会的时候进行可能会耽误比较长的时间,项目团队可以根据实际情况,每天留下固定实际来进行此项操作,因为是良性的,所以会越来越好.

       

 

       Team成员每天进行集体沟通,每个人都有机会发言,每个人都不只是听客,每个人都可以感受到其他人对项目的贡献,每个人都有是整个项目和产品的主人翁的感觉.

 

       为了让整个Team的沟通有效率,因此每个敏捷团队人数不易太多,如果有很多人,首先站会就会浪费大家很多时间,也同时因为人数太多,大家的关注点就开始分散起来,不利于高效的去解决问题.

 

       所以在实践过程中,我们原先的20多人的团队分开成两个敏捷团队,每个团队都有各自的PO,SMTEAM.每天的站会分开两部分进行.如果需要两个团队共同来解决公共问题,则还有站会的站会,每个Team派代表来给项目经理说明问题,进度等.

 

       至此,整个敏捷项目的角色基本上全了,PO+SM+TEAM.


2017-05-14 09:48:51 totty2006 阅读数 2795

敏捷开发团队中PO和SM角色介绍

通过前面几篇关于敏捷开发总体的相关介绍,相信大家对敏捷开发模式已经有了一个比较清晰的了解,后续会介绍一些比较细分的方面,结合我在敏捷开发实施过程当中的一些体会,来阐述自身对敏捷开发的认识。

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

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

Product Owner(PO)

Product Owner角色定义

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

Product Owner工作职责

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

1、确定产品的功能;

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

3、为产品的ROI负责;

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

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

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

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

Product Owner

Product Owner在团队中的作用

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

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

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

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

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

Scrum Master(SM)

Scrum Master角色定义

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

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

Scrum Master工作职责

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

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

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

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

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

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

Scrum Master

Scrum Master在团队中的作用

在junior团队中:主导和控制

在intermediate团队中:引导和教导

在Senior团队中:辅导和协助

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

案例分享

某Team在Plan Meeting会议中,邀请了PO参加,但PO因会议时间冲突未能参加,在讨论Sprint  Backlog的时候,因需求有变动,团队未完全按照product  backlog上的优先级去拿,选好Sprint  Backlog 后,Scrum master详细讲解了每一条Sprint  Backlog应该如何拆分及理由,最后给出了每个task的评估工时。

问题一:PO未参加计划会

应与PO提前协商时间,若PO没有时间需调整时间,PO一定要参加;

问题二:未按已排定的优先级做

如果不按照product  backlog上的优先级去拿需要和PO一起决定;

问题三:SM一个人完成需求拆分和工时评估

任务的拆分及工时的评估需要和团队共同确定,不是Scrum master一个人说了算。

在敏捷开发团队内部,PO和SM角色是非常重要的,基本决定了团队是否可以很好的执行敏捷开发这种模式,因此这两个角色一定都要十分熟悉敏捷开发的整个运转流程,带领和引导团队一步一步的往敏捷的方向迈进。很多时候PO和SM的不专业,很容易使团队偏离敏捷的模式,因此决定一个团队能否完全进入敏捷开发模式时,这两个角色很关键。


2019-08-02 14:01:59 fguotju 阅读数 22

 

   

角色:

Product Onwer PO 

 

Scrum Master SM

 

Scrum team

 

 

 

          


 

敏捷研发

 

规范机制

    JIRA

JIRA和Atlassian公司

JIRA是Atlassian公司的产品。Atlassian公司于2002在澳大利亚悉尼成立,提供面向企业业务流程的协同办公产品,并于2015年12月在纳斯达克上市。作为一家SaaS公司,不雇佣一个销售人员,仅通过口碑获客,市值达10亿美金级别(64亿美元-2017年3月13日),这也从另外角度反映出这个产品的独特之处。

Atlassian主要有5款产品,分别面向不同的市场。

        

JIRA中的核心概念

Project(项目)

JIRA中的项目是一组问题单(Issue)的集合,项目可以根据组织需求来定义,例如:软件研发项目,市场营销活动,服务台(helpdesk)系统,一个请假管理系统等等。每一个问题单属于一个项目。

Workflow(工作流)

JIRA中的工作流由一系列的状态(statuses)和变迁(transitions)构成,一个问题单在其生命周期中会经过这些状态和变迁。

Issue(问题单)

JIRA的问题单非常灵活,页面可以定制,字段也可以定义。这里介绍一些内置的基本概念。

研发流程:

 

Story规范

通常用户故事描述了对用户、系统或者软件购买者有价值的功能。用户故事是一种通用于敏捷开发中的描述需求的方法工具。

需要满足INVEST模型:

 

Independent:独立,自我包含,非继承的

Negotiable:非合同,可商量,可改写

Valiable:对客户有价值

Estimable:可估算,供客户排序

Small:小故事点

Testable:客户可使用

 

 

 

 

Story创建时需要填写的内容:

 

1.主题 / Summary :角色、需求、价值

2.描述 / Description:验收条件

3.特性团队 / Feature Team :承接团队

4.故事点数 / Story Points

5.所属迭代 / Sprint :当前迭代

6.修复版本 / Fix Version :当前版本

 

 

 

    

内外部协作

   

 

2018-03-09 10:37:19 u014378181 阅读数 322

Scrum 使用迭代的开发方式,每一次迭代,都会经历一个“计划-实施-验证-反思”的工程。

Scrum 框架包括3个角色,5个会议,3套工具。

3个角色:

    1、SM:Scrum Master,Scrum 过程管理者,服务于PO、团队和组织。

    2、PO:Product Owner,对产品 Roadmap 和 Backlog 负责,确保产品价值最大化。

    3、Dev Team:架构师、开发人员、测试人员等,负责实现 Sprint 目标。

5个会议:

 WhyWhoWhenWhat/HowHow long
需求澄清会把不清楚的需求梳理清楚,为下面1-2个Sprint准备PO、Dev Team、SMSprint期间

1、拆分Story

2、优先级排序

3、澄清

2小时
计划会把清楚的Product Backlog变成Sprint Backlog,确定Sprint交付增量以及如何完成PO、Dev Team、SM

Sprint开始前

回顾会之后

1、PO讲解Sprint目标及待办列表

2、Team 预测Sprint开发功能

3、Team确定如何完成

2小时
每日站会为了开发活动同步指定下一个24小时Dev Team、SM每天

1、检视昨天

2、计划今天

3、确认和清除障碍

15分钟内
评审会检视,调整PO、Dev Team、SMSprint结束前

1、Demo

2、收集反馈

3、Review DoD(众测)

1小时
回顾会检视、改进Dev Team、SM评审会与计划会之间

1、检视:人、关系、过程、工具

2、成就、困难/挑战、解决方案

3、指定改进计划

1小时

3套工具:

    1、Product Backlog产品功能列表

    2、Sprint Backlog迭代任务

    3、Burn-down Chart燃尽图

        燃尽图能形象的展示当前迭代中剩余工作量和剩余工作时间的变化趋势,是放映项目进展的一个指示器。


scrum理解

阅读数 232

敏捷开发3种角色

阅读数 13

没有更多推荐了,返回首页