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

        

        通过上篇文章我们已经知道了敏捷角色中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 阅读数 3300

        

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

 

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

 

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

 

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

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

 

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

 

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

       

 

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

 

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

 

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

 

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


2019-02-28 23:40:57 lanyue1 阅读数 1655

部门开展敏捷已经三年有余,我是作为最早一批敏捷实践者,曾经也连续当了两年的SM。期间部门组织过大量的敏捷培训,也专门学习出差到各地的敏捷会议,看了不少相关书籍,对敏捷内容不说熟练,但也是相对比较了解的。也正是因为这场轰轰烈烈的敏捷让我开阔了眼界,增长了格局,影响了我的方方面面。虽然现在已转做BA,在整理资料时t突然发现两年前的敏捷经验总结,呵呵,都不记得是在什么情况下写的,但现在看看还是颇感意外,遂记录之。当然这里仅记录我担SM期间的感悟,对于其他的一些敏捷实践如需求实例化、MFQ、CI、单元测试等后面有机会再具体文章阐述。
一、SCRUM运作
不懂敏捷的人一般认为敏捷就是指四会,虽然不正确,但也恰恰说明四会对敏捷的重要性,而SM就是保证四会按时正常举行的关键人物。
1、计划会:BA需要提前准备好方案、原型设计和接口文档,在会上仅将关键要点陈述清楚,保证方案的可行性。计划会SM需要控制住时间,尽量在2个小时以内,否则人容易分散精力。对于故事估点和迭代故事承诺时间,其实经过团队成员几个迭代尝试可以慢慢量化成模型,比如我们团队承诺故事点数 = 迭代工作日剩余天数*迭代参与人员数*70%。
2、早会:需要制定规则,比如不能迟到等,而且会上要尽量少讲技术细节,多讲困难点,否则早会时间会不断拉长,形成习惯后就很难改变,然后就被认为浪费时间,也就会慢慢被嫌弃。
3、评审会:最好由相关开发人员来演示自己对应模块,将重点难点说清楚,有疑问的地方提出来,这样其他未参与的团队成员也能有针对性的给出建议和答疑。
4、回顾会:这个最好弄的轻松愉悦点,比如买点水果瓜子类的,可以先回顾下团队年度或半年目标的达成情况以及上个迭代的改进跟踪情况,然后让团队成员谈谈对本迭代的一些想法、改进点以及心情曲线。若团队有不擅长表达的,可以让大家用纸写下分享,然后讨论出重点问题的改进措施,设定相应的跟踪人,保证能正常的被实施。
二、团队建设
对于SM来说,团队建设是其关键职责,一些相关的举措会直接关系到团队对问题的重视程度和执行的效果。可以说SM就是一个团队的灵魂人物所在,SM雷厉风行,那么团队也差不到哪里去,如果SM吊儿郎当,那么团队也极有可能一盘散沙。
1、制度和流程很重要。其实制度和流程是一把双刃剑,如果涉及很多,会导致效率降低,团队成员反感,如果没有制度,又会没有边界,当出现问题时,团队可能会责怪没有提醒,所以在团队成立初期,对于一些大的原则和流程需要明确,当项目有新的规定和要求时,要实时的通知到团队,避免团队犯一些低级错误,对于特别重要的,需要不断提醒,让其深入到大家的心中。
2、职责要明确、做事有条理。虽然敏捷讲究主动承担任务,打破壁垒,但是在开始一个新故事时,对于职责分工还是要明确清晰,这样更利于协作,让大家更有责任感,不至于考虑哪个工作更轻松等影响开发效率,保证做事有条理不混乱。
3、各斯其职。目前SM大都是技术出生,如果将团队的方案、技术都囊括的话,那将是个大忙人,会顾此失彼,因此在与BA协作时,尽量要求BA做好他该做的事情,对于一些方案的讨论和确定也尽量让BA拍板确定。SM的职责是尽量服务于团队,保证他们需要的资源能够协调到位,保证团队工作的质量和进度,提升团队的凝聚力。
4、充分授权。人都有一个通病,总担心别人会不会捅出篓子出来,甚至什么事情都想亲力亲为。而我们现在提倡自组织团队,就要首先充分相信每一个人都能将事情做好,需要做的就是调动他们的积极性。
三、团队目标
一个好的团队需要有一个统一的目标,才能将人心凝聚起来,从而达到1+1>2的效果。
1、团队一定要有目标,若只埋头苦干,就很难看到团队的成果产出,看不到特色亮点,无论对于团队评优还是团队士气都是很大的打击,大家会觉得没有成就感。
2、团队目标最好每半年出一个,季度时间太短,频繁调整,容易耗时太多,年度又太长,定义目标无法预估未来变化。
3、目标一定要遵循SMART原则,必须是具体,可量化的,全团队认可达成一致的。
4、目标最好每个迭代末期在团队内进行定期回顾总结,及时调整,以免跑偏方向。
四、沟通协调
协调资源,内联外通也属于SM的一个重要职责,特别是对于大公司,这种异地办公、共同开发统一模块的协调更是难上加难,办法很多种,但需要具体问题具体分析,这里大致列举实践中的心得:
1、迭代任务开启前,确定好团队之间、模块之间的接口。
2、如果做Web开发任务,需要在迭代任务开启前,通过Axure Prototype制作好Web原型图。
3、迭代任务开启前,尽早确立联调时间,可有效的安排自己的时间。
4、联调开始前,通过发送联调日报汇报当前联调进度和效果。
5、如果团队之间碰到疑惑,需要讨论,按照效率由高到低的沟通方式有:电话、IM消息、邮件。本地联调,最好面对面沟通,异地联调,打电话沟通最快,IM其次,邮件最慢。
6、团队站会时,将沟通中碰到的问题汇总起来,然后找个合适的时间与对方团队最好电话会议一下,确定问题的解决方法。
7、讨论过后的变更,需要有图或文字为证,时间久了可以拿出来当做证明。
8、复杂业务,同时协调多个团队时,需要根据完整性、高效性、一致性等多方面考虑,减少交互,配置简化。

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

敏捷开发团队中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 阅读数 20

 

   

角色:

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 :当前版本

 

 

 

    

内外部协作

   

 

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