敏捷开发工作职责_敏捷开发 职责 - CSDN
  • 【互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?】 前言================================================ 1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。 第一...

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

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

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

    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%========================

     

    展开全文
  • 敏捷开发 职责 我最近参加了#IDGTECHTalk ,这是美国东部时间星期四中午12点举行的Twitter聊天,主题是“编码的当前和将来状态”。 许多问题和推文都是关于编码语言和框架的。 我选择专注于软件开发管理在确保团队...

    敏捷开发 职责

    我最近参加了#IDGTECHTalk ,这是美国东部时间星期四中午12点举行的Twitter聊天,主题是“编码的当前和将来状态”。 许多问题和推文都是关于编码语言和框架的。 我选择专注于软件开发管理在确保团队达到目标,遵循最佳实践以及就解决方案进行协作方面的作用。

    许多组织授权自组织团队执行每个冲刺并交付可靠的应用程序版本。 他们期望高质量,低缺陷,安全和可维护的代码也能满足业务目标并减少技术债务。 具有多个敏捷团队并努力在标准与自组织原则之间取得平衡的大型组织必须考虑管理层和关键团队成员的角色和职责。

    [了解如何在敏捷开发项目中成为出色的Scrum管理员: Scrum管理员角色,解释 •将您的敏捷职业提升到新的水平: 如何提高您的Scrum管理员技能 •不确定“敏捷”的真正含义是什么? InfoWorld 解释了敏捷方法 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

    这就是需要定义软件开发经理的角色的地方。 敏捷开发对于Scrum管理员,产品所有者和团队的角色有特定的指导原则,但是大多数实践和框架对于软件开发经理没有什么可说的。 我认为这项工作既可以帮助队友发挥出色作用,又可以使标准化流程与敏捷原则保持平衡,并根据框架和最佳实践提供出色的技术。

    这是敏捷软件开发经理的五项具体职责。

    1.与产品负责人讨论实施权衡

    功能和用户故事应定义内容,原因对象,以便团队对要求和接受标准有共同的理解。 理想情况下,他们不应该是如何的功能或故事应该实施过于死板,虽然很多产品的业主选择将定义与实现细节用户故事

    如果功能或故事的说明性过强,则将开发团队锁定在特定的实现中,这些实现可能代价昂贵或难以扩展。 当细节太少时,开发团队可能不知道可以满足最终用户需求和业务需求的最佳实施方案。

    当需求过于规范时,软件开发经理应识别产品所有者,然后向其解释多种实施方案。 每个选项都可能有收益和折衷,而讨论通常会产生更好的解决方案。

    此外,当用户故事定义不清时,软件开发经理应阻止团队参与其中,然后就所需的详细程度咨询产品所有者。

    2.将最佳做法和标准翻译给团队成员

    定义和共享最佳实践和标准对于架构师而言是一项艰巨的任务,但要使团队正确理解和利用它们对于大型软件组织而言可能是艰巨的。

    团队可能有专家,他们希望做的事情与标准建议的有所不同。 团队中可能还会有经验不足的开发人员,他们可能无法完全理解最佳实践或如何将其应用于编码挑战中。

    软件开发经理需要了解团队中每个人的技能和思维方式。 她应该从体育场的角度审查实施方案,并确定哪些最佳实践和标准可能适用。 然后,她可以将他们翻译给团队,并与建筑师分享问题或挑战。

    3.挑战未解决创新和技术债务的积压订单

    产品负责人与许多利益相关者和客户一起确定产品愿景,路线图和功能优先级。 他们面临着巨大的压力,需要完成更多的功能,并使更多的利益相关者对优先级的选择感到满意。

    这种压力通常会导致敏捷积压的不平衡,积压了很多功能,并且缺乏足够的能力进行试验,创新,更重要的是解决技术债务

    当必须在快速的时间内交付关键业务功能时,某些冲刺和发布经常需要这种不平衡。 但是,在某些时候,团队必须回到平衡功能,创新和技术债务优先事项的平衡状态。

    在敏捷积压上开发仪表板是使优先级更加透明的一种方法。 一些团队引入了其他治理和流程来管理技术债务 但是,没有任何替代方法可以让一线领导人积极追求这一治理。

    软件开发经理就是那个人。 当团队感到沮丧时,他可以感觉到,并且需要更多时间来解决技术债务。 他还知道团队何时努力实施更复杂的解决方案,并需要时间进行试验和创新。

    4.按规定的时间表交付高质量的发行版

    敏捷软件开发经理的最重要职责可能是确保按时交付高质量的发行版。 执行质量差或在质量和时间安排上不可靠,前后不一致或不负责任的团队和小队将其组织和工作置于危险之中。

    当出现这些问题的症状时,敏捷软件开发经理的工作就是找出原因并加以解决。 当我与许多软件开发经理交谈时,对这些问题的常见React包括:

    • 责怪产品负责人,因为过多的复杂优先级使积压的工作超载。
    • 确定阻碍或减慢进度的其他团队或外部依赖项。
    • 指出团队缺乏培训,技能或知识。
    • 指向技术债务,缺乏标准或对新架构的需求。
    • 在测试, CI / CD(连续集成/连续交付)自动化以及提高质量或减少开销的其他实现方面指定额外的投资。

    在某种程度上,所有这些都可能适用,但是,如果团队表现不佳,这些并不是领导层想要听到的答案。 软件开发经理需要考虑他们将要采取的行动,并且在更大程度上是他们所控制的范围,以使团队重回正轨。 其中一些选项可能包括:

    • 在回顾会议上讨论问题,以便团队认识到问题并合作解决。
    • 审查并收集有关逃逸到生产中的缺陷的更多数据,并确定需求和测试差距。
    • 审查故事的接受标准,以确保团队完全了解质量期望。
    • 当工作需要外部团队的投入时,在发布和冲刺周期的早期进行计划和交流。
    • 致力于降低速度和缩小范围,直到团队回到正轨。

    5.推动多元化思考和解决问题

    成功的敏捷团队将学习如何团队协作和共同努力。 站立,演示和回顾之类的仪式可帮助团队团结起来,以了解需求,评估解决方案,制定解决方案并改善其流程。 这些仪式为合作奠定了基础。 软件开发经理必须决定如何从所有参与者那里获得想法和积极贡献。

    队友具有不同的个性和专业知识。 有些人可能会内向,很难为对话做出贡献。 其他人可能是主导房间的A类人物。 同样,经验丰富的开发人员可能会控制解决问题的会话或从事更高级的工作,从而阻止更多的初级开发人员分享他们的想法或执行有助于他们成长的任务。

    Scrum主管应在会议期间发挥积极作用,以确保每个人都做出贡献,并有多种想法。 软件开发经理需要进一步迈出这一步,并确保团队的行为举止像团队一样,尊重每个人的意见,分享想法,并使每个人都能参与和学习。

    现在这不是管理层的全部内容吗?

    翻译自: https://www.infoworld.com/article/3432206/5-responsibilities-of-the-agile-software-development-manager.html

    敏捷开发 职责

    展开全文
  • 在Scrum敏捷开发中有三种主要的角色:Product Owner(产品负责人,简称"PO"); Scrum Master(敏捷教练); Team(团队)。其中,Scrum Master是其重要的角色之一。那么今天我们就来探讨一下如何做一个...

    在Scrum敏捷开发中有三种主要的角色:

    Product Owner(产品负责人,简称"PO"); 

    Scrum Master(敏捷教练); 

    Team(团队)。

    其中,Scrum Master是其重要的角色之一。那么今天我们就来探讨一下如何做一个合格的Scrum Master。

    Scrum Master在许多的项目开发中被视为项目经理,这其实是个误区。同时我也经常看到有人主张将Scrum Master与项目经理完全区分,对于此我也不太同意。在我看来Scrum Master虽然并非项目经理,但是仍然肩负着很多项目经理的职能。那么Scrum Master的职责究竟是什么呢?该怎样做才能成为一名合格的Scrum Master呢?以下六项,供您参考。如有不妥之处,欢迎探讨;)

    管理Scrum流程


    这是Scrum Master最核心的职责,也是Scrum Master区别于项目经理的最显著的特征。Scrum Master需要维护每个sprint的流程,确保每个sprint能够顺利的实施以及完成。

    首先,Scrum Master负责主持召开sprint期间的每一个会议,包括sprint plan meeting, daily scrum meeting, sprint grooming meeting,sprint review meeting以及sprint retrospective meeting。

    另外,Scrum Master还需要帮助PO建立product backlog与sprint backlog,并确立其中每个story的优先级。

    最后,Scrum Master还需要帮助Team清除在开发的过程中遇到的障碍。Scrum Master应该有一个block list用来记录Team在开发中遇到的问题障碍,由Scrum Master自己进行管理并最终使得列表中的每一问题得到及时处理。

    保护团队


    Scrum Master应该最大限度的保护Team,以确保Team不会被外界,尤其是PO干扰。那么Scrum Master该如何保护团队呢?Team在什么情况下需要保护呢?

    在每个sprint的初期制定计划的时候,Scrum Master应合理的根据Team的工作能力以及过往经验,承诺工作量。不要盲目乐观的给PO承诺过量的工作。我就遇到过有的Scrum Master可能是对于Team的能力估计不足,也可能是希望通过承诺更过的工作获取老板的芳心,承诺了太多的工作,结果导致Team在sprint的后期连续加班,致使Team的效率严重降低。同时由于时间的匆忙,急于交付,导致了项目的质量很低,最终形成了恶性循环。一个好的Scrum Master在这个时候是应该要懂得如何与PO“周旋”,获取合理的工作量。这里的“周旋”并非消极怠工,故意减少Team的工作量,这其实是通过安排合理的工作量来使团队达到最大的工作效率,同时不会伤害Team的积极能动性。这是一个良性的循环。

    我们都知道,需求的变更对于每一个开发人员来说都是噩梦,而敏捷诞生的其中的一个很重要的原因就是为了解决这一问题,让开发者拥抱变化。然而在我们采用敏捷开发的项目中,经常可以遇到Product Owner越过Scrum Master,直接找到Team, 对他们指手画脚,发号施令。这个时候,Scrum Master应该像“猛兽”一样将PO“吼开”,以避免Team受到“伤害”。需求改变可以,但是不应该在sprint的过程中干扰Team, 可以在daily scrum meeting或者sprint plan meeting上提出,共商解决方案。我觉得Scrum Master对Team在很多时候都应该有一种“护犊子”的精神。确保Team神圣不可侵犯。

    有效沟通


    很多时候Scrum Master起到了一种“承上启下”的作用。一头面对的PO以及自己的老板,另一头面对的是Team。很容易使人感觉Scrum Master仿佛在夹缝中求生存,容易两边都不讨好。因此,沟通艺术的重要性不言而喻。如何说服PO,使得老板满意,并且让Team开心,这是一门学问。对于此,下面几点可以作为参考:

    1. 面向老板:

    应定期及时的通报项目的状态与进展,不要等到老板亲自来问,可以通过表格以电子邮件的方式发送。主要汇报进展状态,避免过于细节的内容;
    遇到问题,应及时上报,使得问题在出现时就能得到重视,并被及时解决。如果等到截止时间才发布坏消息,那么就给了你的老板对你进行微观管理的机会。

    2. 面向Team:

    最重要的一点,应以身作则,态度端正;
    充分了解Team中每个成员的能力状况,防止出现工作量盲目承诺的问题;
    通过daily scrum meeting让Team中每个人都能明确了解最新的进展与形势;
    遇到问题,应对事不对人。

    把关质量


    此刻开始,Scrum Master更像是一个项目经理。无论是质量,进度还是团队建设都更像是项目经理的职责。对于Team来讲,这时的Scrum Master不再是那个“保护”我们的人,而变成了那个“收保护费”的大佬。然而,在实际项目中,Scrum Master确实要承担这些职责,只不过有些已经融入到日常的scrum流程中去了。

    关于质量的管理,我想其重要性不言而喻。质量是决定了产品的命运。那么如何把关质量了。在敏捷实践中,如下的经验可供参考:

    1)欲速则不达。不应过于强调速度,应保持合理的开发节奏,才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整,使得Team形成习惯,最终达到良好的开发节奏。

    2)制定coding style,并坚持代码审查。代码的规范非常重要,好的代码可以提高整体团队的开发与沟通的效率。好的代码会说话。代码审查可以结对完成,只有审查通过,才可以提交代码。可以通过创建pull request来进行代码的审查,通过之后,再merge到代码库中去。

    3)写单元测试。单元测试的重要性我想大家都明白,只是很多人觉得写起来痛苦,麻烦,占用开发时间。有了单元测试,你的代码才是经得起考验的代码。

    4)冒烟测试。在每天下班之前,停止push代码,然后进行冒烟测试。冒烟测试成功之后,才会下班回家。这是一种很好的方法,它保证了每天功能都是可用的,从而确保了质量。

    5)自动化测试。它的好处,不用多说,谁用谁知道:)

    6)提早集成,以便频繁获取反馈。这样的好处在于我们可以及时的得到用户的需求反馈,进而能够及早修正。

    7)最后,我要强调一句:不要加班,不要加班,不要加班。

    跟踪进度


    进度管理是Scrum Master的又一项项目经理职责。对于scrum中进度的监控,我们有很多的方法,也非常有效。

    先说工具,敏捷开发中,比较传统的跟踪进度,同时使用也非常广泛的一种方式是Story Board(故事版)。这种方式简单直观,非常有效。即使现在已经涌现了很多非常优秀的电子管理工具,许多团队仍然对它情有独钟。近些年一些电子的跟踪进度的srcum工具出现了很多。比较有名的像是jira. 它的使用也非常的简单直观,而且功能非常丰富强大,强烈推荐大家使用。

    另外,我们可以通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。

    团队建设


    团队建设是项目开发中绝对不容忽视的一环。团队凝聚力如何,直接影响了整个团队的战斗力。因此,建设好团队,是每个Scrum Master的重要使命。

    那么如何有效的进行团队建设呢?

    1)放权。敏捷开发的其中的一个重要的特征就是团队自组织。团队自组织的优势就在于,通过放权给团队,让它们自主的思考,设计开发,不对其干预,从而使得团队中每个人具有成就感,进而提高整个团队的积极能动性。

    2)打造学习型团队。一个方法就是通过团队内部知识定期分享的方式,使得每个人都能可以学到新的知识,从而逐步使得团队成长。比如每周五的下午4点,可以利用一小时的时间,让团队的成员举办知识讲座。通过这种形式,大家的积极性会变的很高。可以约定分享的内容并非一定是技术方面的,也可以是生活娱乐等,只要大家感兴趣就好。这样做的好处在于不仅提高了团队的技术能力,也使得团队之间能够更轻松愉快的交流,从而提升团队的凝聚力,战斗力。

    3)最后,提高团队最有效的一个方法,那就是一个字:吃;)这是拉拢吃货们的大好时机。当然这个需要经费,不过方法总会有的,你懂的;)



    作者:Ifdef_Max
    链接:https://www.jianshu.com/p/72a5c42cec8b
    展开全文
  • 敏捷开发中的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这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    展开全文
  • 敏捷开发实行中的工作职责 敏捷开发前期 产品 在指定需求时需要保证需求的完整性,保证每一个需求是独立的、完整的、可上线的 将需求池中的需求按优先级排序 根据优先级&关联性选取本次迭代的需求(Sprint ...
  • 敏捷开发中的测试人员敏捷开发团队介绍测试人员需要具备的素质测试人员的主要职责定义质量 (Define Quality)交流缺陷(Communication)及时反馈 (Feedback):敏捷开发中QA的职责之敏捷中的QA敏捷QA的日常活动敏捷QA与...
  • 敏捷开发之PO

    2016-07-26 07:55:43
    讲到敏捷开发,那么在每个team里面,都会有一个叫做PO(project owner)的角色.在敏捷开发中,PO这个角色扮演了很关键的作用。首先讲讲PO都会干些什么: 1 PO是开发team与客户之间的桥梁,他负责与客户沟通,并且...
  • [敏捷开发实践] Product Owner的职责 在敏捷软件开发方法中,团队成员被分配不同的角色。敏捷开发Scrum框架具有以下角色:产品所有者(Product Owner)、Scrum Master、Scrum Team。当然还有项目干系人...
  • 浅谈敏捷开发

    2020-04-11 14:29:17
    浅谈敏捷开发 敏捷开发(agile development)是非常流行的软件开发方法。据统计,2018年90%的软件开发采用敏捷开发。 但是,到底什么是敏捷开发,能说清的人却不多。本文尝试用简洁易懂的语言,解释敏捷开发。 章节 ...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过...
  • 敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • 但是对于敏捷开发中的架构师因该如何展开工作以及他们的工作职责是什么,查了一些资料,结合自己的实践做一些总结: 1、将系统分割成更小的部分,以及合理的架构边界和相互之间的接口  在项目的执行任何时期...
  • 再次参与敏捷开发项目2年多了,期间有敏捷教练的指导,也有实践的一点感悟:由于从事的岗位,站的角度偏向于从开发人员的角度、开发负责人角度的一些总结:Part1:遵从的理念:尽快交付有价值的东西。敏捷开发尽快...
  • 敏捷开发是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。敏捷开发就是把一个大项目分为多个...有些团队会一个个排需求、做需求,而敏捷开发是通过任务分解把工作拆分为半天到几天的工作量,然后制
  • 敏捷开发 模型讲解

    2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • [敏捷开发实践] Scrum Master的职责 Scrum Master 是仆人式领导者,能够为Scrum团队提供支持,让团队功能完善并高效运作。 作为Scrum框架规则的维护者,帮助项目团队和组织遵守Scrum价值观和实践; 以被动和主动...
  • QA,通常指的是质量保证(Quality Assurance)工程师,但我更喜欢定义敏捷中的QA为质量分析师(Quality Analyst),主要基于以下几个方面的原因:  质量保证更偏向于工业说法,称参与软件测试的人员为质量分析师感觉更...
1 2 3 4 5 ... 20
收藏数 16,824
精华内容 6,729
关键字:

敏捷开发工作职责