敏捷开发提升角色那些能力

2017-03-20 16:22:26 Trinity_Techologies 阅读数 2176
敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。

敏捷开发过程中,很多时候测试人员就时常被当成项目无法加快的阻力,一下这边爆一个bug,那边有个缺陷,所以项目经理痛恨测试,程序员们也巴不得测试快快放行,让程序好好上线,但我们都知道没有测好的东西是不能硬上的,测试这种把守项目上线最后一关卡的,若没有两把刷子,可能会时常变成项目延迟的炮灰。

为了让测试的效率跟上项目开发的进度,需要抓住两个关键点:
1. 品质是规划出来,非测试出来的
测试在专案的早期就必须参加,熟悉需求,并从测试角度提出各种问题,确保产品经理、开发、测试的等角色的关注点都有备考量到,而测试也会从早期就开始撰写测试用例,在撰写过程中如果有发现任何问题也趁早反馈给产品经理、项目经理,趁早把问题给理清,这样做测试才能把自己的角色提升到为质量负责的角色。

2. 落实自动化
所有重复性的工作都应该被自动化,包含测试,如果你项目大多数的时间都花在基础功能测试,那效率肯定不会高的,所以测试环境、测试资料的准备应该都要有工具能辅助,各种测试用例如果是反覆发生且变动性少,绝对值得你花时间去撰写自动化脚本,而对于后端API接口的测试更是关键,一般的测试可能大多针对功能进行测试,但我们知道很多会露出被用户测到的bug,大多都不是点一点就能测的出来,很多都是因为API在某种情境下出错了,或在某种负载下出错了,这些靠人工非常难验证,透过自动化工具就相对简单多了。

对于敏捷开发项目的测试而言,单元和集成测试是测试策略的关键环节。单元测试是验证最小和独立单元代码行为的过程,比如C++类,C函数,Ada包。这通常在系统测试之前进行。单元和集成测试是构建稳定减少错误应用程序的重要方法,因为它允许测试人员更容易模拟应用程序基本逻辑功能,并验证其是否满足设计需求。

传统的单元测试,通常针对开发人员写的每个软件单元生成测试用例,执行这些用例验证代码功能的正确性。这种模式存在一定风险,因为开发人员在设计测试用例时,很容易受自己实现该代码的思维的影响,从而导致某些情况不能被考虑到或测试到。


自动化测试工具,如:VectorCAST可支持C/C++语言(VectorCAST C/C++)和Ada(VectorCAST/Ada)的单元测试和集成测试。两者都可以自动化地完成单元测试和集成测试的关键步骤。包括测试驱动的生成,测试用例和测试结果的管理,以及自动化的回归测试。

自动化的测试不仅大大提高了测试效率,而且自动化的客观性还能大幅提高测试的准确性。测试的自动化让敏捷开发更加“敏捷”!



2019-08-23 19:38:07 baidu_36943075 阅读数 1527

敏捷开发


  敏捷开发,现在大多数团队都在推崇敏捷开发模式
  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?

  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不全面,如有不同理解/或更深刻的理解可以回复进行互相学习。更深入的理解仍需要长时间实践的沉淀


1. 敏捷开发是什么?


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

2. 怎么理解呢?


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

3. 敏捷代表Scrum和Devops


其实现在大量推崇的敏捷开发主要以Scrum和Devops为主
  Scrum扫盲篇 https://www.cnblogs.com/taven/archive/2010/10/17/1853386.html (感谢博主的分享)
  Devops扫盲篇 https://www.cnblogs.com/jetzhang/p/6068773.html (感谢博主的分享)

 

3.1 两者在敏捷开发中分别起到什么作用呢?


个人的理解是:
  Scrum是一种开发流程,该流程通过将需求从产生-评审-研发-测试-上线-反馈-产生新的需求闭环的形式,将一个产品分解为一个个互相影响的闭环,就是一个个迭代的版本。
  Devops是一种交付理念,主张通过使用CI/CD工具链方式将一个迭代版本中的每个环节都通过工具自动连接,完成每个环节的交付工作,直至上线交付用户。

两者是一个相辅相成的关系,Scrum提供研发流程,Devops提供CI/CD工具链

 

3.2 对于Scrum理解

             (图片来自网络)

个人对于Scrum的理解是:站在产品/项目的角度,怎么让需求得到更快/更好/更准确的实现。

  对于产品人员,希望设计的产品功能等能够快速得到实现、上线、验证、更新。传统的瀑布式开发往往是一次性完成所有的需求,如果上线后发现无法满足市场再次进行新的调整,再次上线可能已经是半年后了,对于互联网产品简直是一个致命的伤害。对于产品特性的刨析分解,将特性重点提取出来,快速实现开发上线得到市场用户的验证,再不断丰富特性无疑是互联网产品占据市场的最好方法。

  所以在Scrum中对产品人员的要求变得严苛,要求产品人员能够对产品特性进行丰富准确的刨析分解(对产品的定位、用户的画像、数据的分析、特性的分解、市场响应的应对、需求管理都是很大的考验)

  对于研发人员,需求的理解偏差/需求变动/Bug修复应该一直都是一个头疼的问题。如果研发人员对于需求的理解存在偏差,也就只有等到测试阶段才能发现需求实现偏差,此时再次进行返工将导致整个产品的上线延期(如果是瀑布式模式,延期时间更长项目成本更高)。如果研发过程中出现需求的变动(因为产品/市场/政策等等因素造成),研发人员将需要重新理解需求,如果需求变更较大之前的编码将进行重新编写,对于整个产品的上线也是一种延期(如果需求变动为主要业务流,在瀑布式模式中可能导致整个项目停工重新设计)。如果测试人员无法快速准确的识别需求偏差/发现系统Bug,将会导致交付延期甚至带来交付隐患,随时带来不可预想的后果。

  所以Scrum提倡快速的版本迭代而不是瀑布式模式,目的就是为了将项目成本损失最小化;

  同时Scrum也很注重研发人员对于需求的理解,目的就是让研发人员对需求进行详细的理解,根据理解进行需求分解后让产品人员进行评审检查是否偏差遗漏;

  并且需要测试人员全程参与产品/研发环节,通过对产品的详细了解/研发的实现逻辑快速分析定位是否满足要求/是否存在Bug,同时也提倡将传统的手工测试自动化,加快测试环节的效率减少工作成本。

 

3.3 团队融合Scrum

  对于Scrum,它本身的研发流程并不一定适用于所有团队,因为每个团队的产品方向/人员配置/团队氛围都不尽相同。

  个人认为对于Scrum的学习,不是对于Scrum流程的照搬,而是对于快速迭代交付的理解,然后根据自己团队的其他种种因素结合,输出适合自己团队的研发流程

  当然Scrum中有很多环节/方式是可以直接借鉴进来使用的,比如任务看板/每日站会/工作量评估/需求分解会等。任务看板可以帮助大家快速同步任务进度,方便进行下一步的工作准备;每日站会,可以让大家同步进度并且提出问题风险;工作量评估,可以让大家不断对自己的工作量化表现战斗力;回顾会议,探讨发言改进的地方共同进步。

  个人认为团队对于Scrum的融合(1)根据团队现状因素等,拟定一套研发流程(2)对全员进行敏捷概念的普及(3)详细讲解流程各环节作用,试行一个版本迭代后召集全员进行回顾会讨论,集思广益对流程进行近一步优化(4)确定合适的研发流程进行强制推广执行,中间出现的问题于每个版本回顾会讨论记录(5)每版本或月或季,进行一次流程优化并继续推行

  让团队去适应一个新的研发流程是一件很难的事情,了解敏捷思想后制定一个适合的研发流程难度不大,难点在于流程的执行监督需要消耗一定的时间/精力,因为敏捷开发的主要驱动核心是人。团队融合Scrum可能会增多一些环节/会议等,想要完成真正的融合一定要加大力度的监督执行,让大家养成习惯才是真正的融入新的研发流程

 

3.4 对于DevOps理解

            (图片来自网络)

              (图片来自网络)

个人对于DevOps的理解是:站在集成/交付的角度,怎么让研发流程各个环节无缝连接,同时推动工具链减少人员操作(当然DevOps是一种理念,理解起来肯定不仅如此,只是在落实方面CI/CD思想比较着重)

  对于研发流程而言,一个好的研发流程就是一个完整的闭环,每个环节都有其存在的意义并且每个环节的完成都意味着工作交付(产品人员将需求交付给开发人员编码,开发人员将系统交付给测试人员测试,测试人员将系统交付给运维人员上线,运营人员将系统交付给客户使用,客户将使用意见交付产品人员分析)。完整闭环就需要产品/开发/测试/运维/客户等角色共同参与,闭环的形成、多种角色的参与都意味着每个环节、角色的交付都是一个重点。更好的交付将减少下游环节、角色的工作成本;更好的交付将提高研发流程的流畅度(对于研发流程的推进也有帮助);更好的交付将提高产品的市场、乃至提高产品的收益。

  笔者接触到的大多数DevOps的讲解,DevOps是将开发、测试、运维融合起来,但是笔者认为DevOps并不仅仅是这3者的融合,而是整个产品至上线所有环节/角色的融合

  DevOps提倡使用工具链,将所有的交付/监控等等环节操作工具化,并通过工具之间的API互相关联形成一套完整的工具链体系。通过工具减少人员的操作,即减少了人员成本又极大的避免了人为操作失误带来的损失。

  笔者之前看到过一个比较完整的DevOps工具链概览,分享给大家(同时也感谢作者的分享)https://blog.csdn.net/qq_31977125/article/details/82796739

  顺便再分享一个 DevOps BookMarks ,涉及了DevOps方方面面的工具和内容,有兴趣的同学可以去学习下。http://www.devopsbookmarks.com/

  (笔者也有简单分享过一些工具相应的介绍/安装/配置文章,后面笔者也会继续学习继续补充)

3.5 团队融合DevOps

  对于DevOps,它是一个理念。个人认为对于DevOps的学习,首先是真正的理解集成/交付的思想,然后就是工具链的学习使用(硬核技术)。

  团队对于Devops的融合是需要全员参与的,也是对团队整个技术栈的全面提升。首先是组织推广CI/CD的思想,让大家理解交付的意义;然后团队整体寻找适合团队的工具链,进行技术栈的全面提升。

 

4. 团队走向敏捷开发

  个人认为团队想要真正的走向敏捷开发,需要对于Scrum和DevOps进行一个完整的融合。

  通过DevOps闭环的思想、Scrum迭代的思想,结合Scrum可以借鉴的环节/方式,制定一套闭环、适合团队的研发流程。

  通过JIRA等项目管理工具将研发流程工具化管理,再将研发环节交付工具化执行,然后打通项目管理工具、研发各环节交付工具形成一个完整的工具链。

  最最重要的一点还是人,一个团队想要真正的走向敏捷开发,首先也是必须要让团队人员都认同迭代、闭环、集成、交付思想。只有思想上的认同,才会让整个团队共同努力向着敏捷开发的方向不断前进

2019-05-21 10:11:30 jnshu_it 阅读数 16763

这里是修真院前端小课堂,本篇分析的主题是

【互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?】

前言================================================

1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。

第一篇对IT职业做了一个相对深入的介绍,给了想从事互联网职业的人一个了解各个职业的机会,已经有4000+赞了,我想是真的帮助到了很多人。 IT行业都有哪些职位,初学者(0基础,新人)该如何选择,才能够快速进入这个行业? - xdyl 的回答

第二篇是对敏捷开发和项目管理做了一介绍,这篇贴子还没写完,其实它的价值远远大于第一篇走马观花的介绍。只是大家还没有到能够理解敏捷开发的时候,所以我想了很久,决定暂时不写了。互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么? - xdyl 的回答

 

这是第三篇,写这个贴子的动机是因为,在修真院有不少人在问,我要学到什么程度才能找到工作,我是零基础啊,有没有视频和教程可以教我。有哪些IT初学者(新人)成长为技术大牛的真实经历? - xdyl 的回答

 

2.本回答和第一篇不同,纯属分享,并不需要有任何的广告。3.但是,本人依然不对分享出来的任何内容的可信度负任何的责任,也根本不保证是一篇公正,客观,完美的回答。4.这个回答,是任何一个初级或中级甚至是高级的程序员,产品经理,Leader都可以认真去思考和尝试的,某种程度上,这个回答比写两行代码更有效果。

5状态:未完待续

 

正文========================================

 

首先讲为什么需要敏捷开发。在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多。总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求。

怎么办?继续改。这一改又是半年多的时间过去了。马丹用户的需求还再改,怎么办?

这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大。文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多。

不仅仅在几万年前,就是在现在,也是经常会有团队出现这种问题。不相信,你可以看看是否遇到了以下这些问题:

1.需求总是在变动,反复变动,无限拖延。

2.开发工程师做出来的项目,bug不但多,而且经常改不好。常常是改了一个Bug,出现另一个Bug,好不容易把一个Bug改好了,过了没多久又重现了。原本好好的功能,反而会因为改Bug导致出现的问题更多。

3.做出来的东西完全不是产品经理想要的样子,沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的。

4.项目延期不是最坏的结果,最坏的结果是还从不知道项目倒底会延期多少,根本没办法去衡量工作量,团队的成员都在加班加点,然而完全看不出来问题出在什么地方。

5.开发文档,产品文档,接口文档,测试报告和真实的代码从没有完美契合过。产品经理设计出来的原型和UI设计出来的页面和程序员开发出来的代码完全是一种不同的体系,三位一体的故事从没有真正发生过。代码的实现和接口文档根本不一致,最后索性干脆不看接口文档,完全口头交流。出错的时候各种撕逼扯皮,谁也分不清倒底谁错了。

6.Team的战斗力和凝聚力不强,经常是对着干,对分配的任务总是各种报怨,出现问题之后第一反应是这个不关我的事,不是我的问题,是后端前端设计QAPM的问题。

 

如果你遇到了这种情况,或者说你不甘于这种现状,那么恭喜你,你可以真的需要敏捷开发流程了。

第二,敏捷开发包括了哪些内容

 

敏捷开发总的流程如下:1.需求规划和分期2. 需求评审3. 需求讲解4. 方案评审5. 每日晨会6. 性能测试7. CodeReview8. Demo9. 测试阶段10.线上Bug修改流程

表跟我说哪些东西不应该包含在敏捷开发流程里,如果你不喜欢,跟你的观念有冲突,你可以把敏捷开发这四个字换成任意四个字。总之,如果要解决这些问题,这是我目前看到的最佳实践,每一个节点都非纸上谈兵,而是经过无数个尝试和失败总结出来的。

如果你是一个IT公司的管理者,如果你不知道该怎么去管理自己的团队,我强烈安列你按着我说的这种标准化方式去做,放心,出了问题我保证不会负一点责任。

确切的说,我说的敏捷开发流程,并不仅仅是开发团队的事情,它背后隐藏着更多的理念。我可能整理的不够清楚,毕竟这是第一版。

1.产品和开发必须是一个Team,大家只是分工不同,角色不同,并不是两个对立的团队。

如果你的公司是把产品和开发分成两个部门,那么恭喜你,产品和开发之间的纠纷一定无限多。

在所有我带的Team中,自始至终强调的理念就是:出了问题,别跟我说这是产品设计出来,这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任,这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题,那么也只是为了避免下次出现同样的情况,用户只会知道是一个公司出了一款垃圾产品,没有人关心到底是产品还是开发的锅。

这是做敏捷开发的大前提。或者不仅仅是产品和开发,责任共担,One Team这个理念是贯穿始终的。这并不是说,大锅饭,而是说,面对不好的结果,所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景,以避免后续会出现同样的情况。

 

产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候,会提高的。实际上,需求分期如果没做好,敏捷开发只能流于形式。

需求分期怎么做,这是MVP的事情,另一个话题。简单来说,每一期都要有一个提前的预测,这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

 

2.职责明确,每个人要负责的事情必须清晰无误,谁该做哪些事情,必须要提前讲清楚。

开发团队的推荐角色应该是这样的。 PM 1个 UI 1个 CSS/js 1~2个 Java 2~4个 Android 1~2个 IOS 1~2个 QA 1个

这是一个相对平衡的模板,这样的一个8~10人的小Team,是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式,可以支持五到六个小Team同时启动。

在讲到最后多Team并发协作的时候,我也会提到的。 除了这些项目小组的角色,还有各个Team的Leader。我比较推荐小组分成如下几种: 1.产品Team 产品团队 2.用户体验 Team 传统的UI团队升级为UE,升级为整个系统甚至是公司的用户体验师。 3.后端Team 苦逼的后端 4.前端Team Android/IOS/JS 表问我为什么把这三个放到一起,我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入,但是普通的项目上手还是应该没有问题的。 5.QATeam QA只需要做功能测试,回归测试,边界测试,并不需要做性能测试。这里也会在后面提到。



 

那么来描述一下每个角色的不同职责。这些不同的角色牵涉到团队并行开发,所以并不是简单的随便扒拉到一堆就好了的。

PM : PM的职责并不是画原型,而是去分产品的分期,确定产品要做的功能和优先级。 对于产品来说,最大的职责并不是将原型画出来,而是要证明自己要做的功能是合理的。 如果你证明不了自己要做的功能是合理的,是值的尝试的,就是产品经理的失职。

可以参考MVP,有无数的办法可以提前验证,如果不能够提前验证,那么就证明这是有风险。做为PM,一定要有这种风险的意识,要知道自己身上担负的责任,PM花了两周时间设计的原型,8人的开发团队要折腾近三周左右的时间。

原型和产品文档都是辅助的东西,我甚至不推荐产品经理去做原型设计,只拆分Story。 原型设计交给传统的UI更合适。然而在真实实施的过程中,因为很少有UI具备原型的设计能力,所以实施起来会有一些难度。这个不算特别重要,慢慢培养。

PM不需要为开发进度负任何的责任,这很重要,不要把PM当成项目管理来使用,如果你让PM去做了项目管理,恭喜你,Game 近乎 Over,产品经理没有时间再去思考如何做功能了。

PM的职责就是把功能设计好,优先级排好,给开发团队讲清楚需求,结合Story优先级和功能实现的大概时间点去做排期。

开发工期交给开发团队去做,Bug会和QA,开发团队一起来定。记着要在开发团队开发项目的时间里,去做好下一个产品迭代的设计。

 

小组Leader:需求评审会的成员应该包括PM组的Leader,前端组的leader,后端组的leader,测试组的Leader,或者是其他公司的中层骨干。

这应该是一个公司所有应该为这个项目负责的人的评审会,在评审会上的结论,就应该被坚定的执行下去了。不参与评审会的人,不应该再对需求指手画脚。

需求评审会的目标就是确定原封不动的需求,所以在这里要格外的注意,PM拿出来的方案设计,一定是完整的,而且必须评细节。如果说,一个公司的中层骨干经过需求评审会议,仍然需求乱成一比,那就没什么可说的了,继续努力提升自己的水准,或者是补充真正的中层。

而PM的目标就是吸引需求评审会的意见,尽量让自己的需求和设计通过评审。各个小组的Leader还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。

小组的Leader还应该负责项目中风险的调控,考虑是增加人手,安排加班,项目延期,还是调整功能。

与些同时,应该去审核最后的性能报告,看看是否达到系统的期望值,遇到了疑难问题如何解决。

 

开发组成员:项目进入真正的开发阶段后,开发组的成员就应该是主动去控制项目的进度,和风险,以及主动去测试项目中存在的问题,在这个阶段,除了一些需求不明,或者是发生变动的情况出现,不应该去打扰产品经理。不要让产品经理做开发团队的保姆。

开发组的成员的目标就是做好项目的进度控制,有风险就及时反馈给Leader,确保自己理解的需求是明确无误的,确保自己的测试是完整和严谨的,确认自己写出来的代码是可以维护的。

一定要理解清楚,一旦PM通过Story讲解,将需求交付给开发组成员,那么开发组成员就应该主动而独立的为这件事情负责。

当项目完工以后,开发组成员应该交叉去做CodeReview,并且出性能测试报告,以及组织Demo。

 

测试组成员:测试级成员的职责不是做功能性的测试,也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成,除了一些特别麻烦的,需要各种极端条件才能复现的,正常的操作过程中出现的问题,都应该是有开发组承担。性能测试同样是开发组人员自行完成,各小组Leader只需要知道一件事情,测试报告是否能够通过。

所以测试组的主要做的就是准确的记录,以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

回归测试是需要做的,但是也不是完全必须要做。如果能够积累足够多的自动化测试用例,就去正常使用它,如果不能,就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚,他们往往更清楚,什么地方容易出问题。

接受线上的反馈并且记录也应该是QA的职责,如果Team足够细,可能会有运营或者是客服统一对外收集,然后交给QA,QA再负责录入Bug系统中。

基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情,其中的很多小细节,都照顾到了每个角色的职责和义务。理论上来说,如果有一张图的话,可以更清楚的画出来不同角色的功能。

这种职责的划分,和传统的职责会有一些不同,反正,在我带过的Team中,这是最高效的,也是最能发挥出团队的能力的方式。你可以信,也可以不信,这中间的每一个细小的调整,都是经过无数个日日夜夜的验证而得来的,我还未曾看到过比这种职责划分方式更高效,更合理的做法,虽然我接触的Team也不够多,爱信不信~

3.每个人必须学会主动去为自己的事情负责

当有了第二条,你很快就能发现团队中,谁是能够尽守职责,更主动的人。第3条很难做到,特别在很多公司,并不注重对于团队凝聚力的培养,也不会注重和他们之间的交流,不知道他们想要什么。

所以这也是我一再强调的,敏捷开发并不仅仅是一个开发流程,更是一种管理的方式,他牵涉到绩效考核,公司福利,上下班制度等等你看不到的东西。

如果说你的团队成员并不能做到为自己的事情负责,那么你需要的就是,要么就是去更换团队,要么就是想办法去激励团队。这是另一个话题了,我心情好的话,可能会在这里提到,如果心情不好,可能会在下一个文章里,也可能根本就不会写了。

这件事情其实也不算难,第一,明确这种职责的分工是合理的,第二,Leader都需要了解自己的团队的状况。第三,不断的去强化和培养这种做事的习惯。

就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提,而不是说,有了这三点,敏捷开发就一点能做好了。

在具体的实施上,还有无数的细节是需要去整理和落地的。

隔了好几天没写,我已经忘记了自己原本的思路是什么了,先写到这里再说。

 

========未完待续,进度15%========================

 

2017-05-02 10:02:26 u012562943 阅读数 9868

Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。

三个角色

Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。

Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他 们。

跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。

Scrum角色之:产品负责人

产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。

产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

● 清晰地表达产品代办事项列表条目

● 对产品代办事项列表中的条目进行排序,最好地实现目标和使命

● 确保开发团队所执行工作的价值

● 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

● 确保开发团队对产品代办事项列表中的条目达到一定程度的理解

产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。

产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负 责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

Scrum角色之:开发团队

开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

开发团队不包含如测试或业务分析等负责特定领域的子团队。

Scrum角色之:Scrum Master

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人

Scrum Master 以各种方式服务于产品负责人,包括:

● 找到有效管理产品代办事项列表的技巧

● 清晰地和开发团队沟通愿景、目标和产品代表事项列表条目

● 教导开发团队创建清晰简明的产品代表事项列表条目

● 在经验主义环境中理解长期的产品规划

● 理解并实践敏捷

● 按需推动Scrum活动

Scrum Master 服务于开发团队

Scrum Master 以各种方式服务于开发团队,包括:

● 指导开发团队自组织和跨职能

● 教导并领导开发团队创造高价值的产品

● 移除开发团队进展过程中的障碍

● 按需推动Scrum活动

● 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

Scrum Master 服务于组织

Scrum Master 以各种方式服务于组织,包括:

● 领导并指导组织采用 Scrum

● 在组织范围内计划 Scrum 的实施

● 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

● 发起能提升Scrum 团队生产力的变革

● 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

四个会议

四个会议指的是Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

Sprint计划会议(Sprint Planning)

在Scrum中,Sprint计划会议有两部分:

1. 决定需要完成哪些工作?

2. 决定这些工作如何完成?

第一部分:需要完成哪些工作?

参会人员:团队、项目负责人(Scrum Master)、产品负责人(Product Owner)

第一部分的会议,产品负责人向开发团队介绍排好序的产品待办事项,由整个Scrum团队共同理解这些工作。

Sprint中需要完成的产品待办事项数目完全由开发团队决定。做多少工作只能由开发团队决定,产品负责人或任何其它人都不能给开发团队强加更多的工作量。

第二部分:如何完成工作?

参会人员:Team 、Scrum Master

第二部分的会议,开发团队需要根据当前的“完成的定义”一起决定如何实现下一个产品增量。他们进行足够的设计和计划,从而有信心可以在Sprint中完成所有工作。

决定如何完成工作是开发团队的职责,决定做什么则是产品负责人的职责。

Sprint计划会议最终需要Scrum团队对Sprint需要完成工作的数量和复杂度达成共识,最终产生的待办事项列表就是“Sprint待办事项列表(Sprint Backlog)”。

Sprint待办事项列表是一个需要在当前Sprint完成的且梳理过的产品待办事项,并包括了一个团队完成这些工作的计划。

每日站会(Daily Scrum)

开发团队是自组织的,通过每日站会来确认他们仍然可以实现Sprint的目标。

每一个开发团队成员需要提供以下三点信息:

● 从昨天的站立会到现在,我完成了什么;

● 从现在到明天的站立会,我计划完成什么;

● 有什么阻碍了我的进展。

每日Scrum通常不超过15分钟。

每日Scrum中可能有简要的问题澄清和回答,但是不应该有任何话题的讨论。

每日Scrum既不是向管理层汇报,也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议,来保证他们对现状有一致的了解。

只有Scrum团队的成员,包括ScrumMaster和产品负责人,可以在会议中发言。其他感兴趣的人可以来旁听。

Sprint评审会议(Sprint Review)

Sprint结束时,Scrum团队和相关人员一起评审Sprint的产出。所有Scrum会议都是限定时长的,Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时(比如,一个Sprint包含2个星期,则Sprint评审会议时长为2个小时)。

每个人都可以在Sprint评审会议上发表意见。产品负责人会对未来做出最终的决定,并适当地调整产品待办事项列表(Product Backlog)。

Sprint评审会议向每个人展示了当前产品增量的概况。通常都会在Sprint评审会议中调整产品待办事项列表。

Sprint回顼会议(Sprint Retrospective)

在每个Sprint结束后,Scrum团队会聚在一起开Sprint回顾会议,目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好,哪些做得不好,并找出潜在的改进事项,为将来的改进制定计划。所有的Scrum会议都是限定时长的,Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时(译者注:比如,一个Sprint包含2个星期,则Sprint回顾会议时长为2个小时)。

Scrum团队总是在Scrum的框架内,改进他们自己的流程。

SCRUM的三个物件

三个物件指的是产品待办事项列表(Product Backlog)、Sprint Backlog和燃尽图

Product Backlog – 产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列,每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。

梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优化通常占用不超过开发团队 10%的时间。

开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。

SPRINT BACKLOG

Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。

Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。

Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。

当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。

Product Backlog 功能点被放到Sprint的固定周期中,Sprint Backlog 会因为如下原因发生变化:

❶随着时间的变化,开发团队对于需求有了更好的理解,有可能发现需要增加一些新的任务到Sprint Backlog中。

❷程序缺陷做为新的任务加进来,这个都做为承诺提交任务中未完成的工作。

Product Owner也许会和Scrum team一起工作,以帮助team更好的理解Sprint的目标,ScrumMaster和team也许会觉得小的调整不会影响sprint的进度,但会给客户带来更多商业价值。

燃尽图(BURN-DOWN CHART)

Sprint燃尽图(Sprint Burn-down Chart)

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

在Sprint开始的时候,Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成,但没有完成的任务的工作量是累积工作量,团队会根据进展情况每天更新累积工作量,如果在Sprint结束时,累积工作量降低到0,Sprint就成功结束。

由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能略微呈上升趋势。

发布燃尽图(Release Burn-down Chart)

在Scrum项目中,团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期,以Sprint为单位, Y轴代表的是剩余工作量,通常以用户故事点、理想人天或者team-days为单位。

2017-04-20 10:36:00 weixin_30391339 阅读数 118

摘要:

在Scrum角色中包括:产品负责人(Product Owner,PO)、ScrumMaster(SM)、开发团队(Team)。

角色:产品负责人(PO)

Scrum团队只有一个产品负责人,他负责在限定期限内拟定可能的最有价值的产品。这是通过管理流向团队的产品待办事项,选择并梳理这些事项来完成的。产品负责人维护产品待办事项列表(Product Backlog),并确保大家都知道包括的内容以及优先级。产品负责人可能需要其他人的支持,但他只能是一个人。

并不是所有的事情都由产品负责人一个人负责。整个Scrum团队需要让团队变得尽可能的高效,改善他们的实践、提出正确的问题、帮助产品负责人等等。开发团队决定一个Sprint要做多少事情,并负责每个Sprint产出可用的产品增量。

然而,在Scrum中,产品负责人处在一个独特的位置。产品负责人通常是离项目的“业务面”最近的人,一般由组织指派来负责“把这个产品做出来”,而且通常期望他以最好的工作成果来满足所有的利益干系人。要做到这些,产品负责人需要管理产品待办事项列表,并确保产品待办事项列表和它的进度可见。

产品负责人通过选择开发团队下一步应该做什么以及要推迟什么,来权衡范围和进度,以得到尽可能好的产品。

图片来源:周金根 老师内部培训资料

角色:ScrumMaster(SM)

ScrumMaster是一个“仆人型领导”,帮助Scrum团队遵守他们的流程。ScrumMaster必须对Scrum框架有很好的理解并且有能力培训其他人去了解Scrum的微妙之处。

ScrumMaster帮助产品负责人理解如何创建和维护产品待办事项列表(Product Backlog)。为了确保团队在Sprint结束时能够完成工作,他和开发团队一起发现并实施技术实践。他和整个Scrum团队一起来演进完成的定义。

ScrumMaster的另一个职责是注意团队前进的障碍已被清除了。这些障碍可能来自团队的外部,比如缺乏另一个团队的支持,也可能来自内部,比如产品负责人不知道如何恰当地准备产品待办事项列表。

ScrumMaster培养团队的自组织能力。团队应该尽可能地独立解决问题。

作为Scrum团队的教练,ScrumMaster帮助团队执行Scrum的流程。他帮助团队更好地合作,帮助他们理解Scrum框架,并且保护他们远离内部和外部干扰。他可以引导会议,帮助Scrum团队保持正确的方向,提高效率,并提升能力。

ScrumMaster负责确保团队内部和外部人员对Scrum有充分的理解,并保证Scrum被恰当地使用。他帮助团队之外的人理解流程,并明白和团队的哪些交互是有益的,哪些不是。

ScrumMaster帮助每个人改进,使团队更加高效和有价值。

 

角色:开发团队(Team)

开发团队是由实现产品增量的专业人士组成,他们采用自组织的方式完成工作。对于项目而言,开发团队的成员是全职的。

Scrum要求开发团队成员由一批跨职能的人组成,他们拥有完成每个产品增量所需的全部技能。

开发团队成员需要以自组织的方式实现Sprint目标,根据Sprint的计划完成产品增量。

产品负责人准备一个有序的代办事项列表。开发团队成员共同预测在一个Sprint里能完成的工作量,并决定如何实现。

转载于:https://www.cnblogs.com/lplp/p/6737438.html