• 本文总结了开发团队中,在引入Scrum Master角色后在团队中是如何做的,以及在一个版本迭代后的复盘总结。方便今后在工作中随时查阅,希望对你有所帮助。

    本文总结了开发团队中,在引入Scrum Master角色后在团队中是如何做的,以及在一个版本迭代后的复盘总结。方便今后在工作中随时查阅,希望对你有所帮助。


    在这里插入图片描述

    0.相关术语解释

    • PM :是Project Manager的缩写,项目主管或项目经理,主要负责统筹规划项目进度及产品生命,其工作职能直接对公司高层负责。作为项目的管理者,PM通常会参与到一个或多个项目的管理与决策工作中。

    • TL: 是Team Leader的缩写,主要负责整个项目的统筹,安排等。细分之下有移动端 团队Leader,服务器团队Leader 或整个开发团队的Leader等等。

    • PO: Product Owner的缩写,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。

    • PRD: Product Requirement Document 的缩写,即产品需求文档。

    • Scrum:是迭代式增量软件开发过程,通常用于敏捷软件开发。

    Scrum 迭代流程图:
    迭代图

    1.什么是Scrum Master?

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

    2. Scrum Master的职责?和PM有什么区别?

    以下Scrum Master 简称为SM。

    SM的职责:

    简单来说主要有:组织会议、早会、临时沟通会、Sprint Review等等,重在协调资源 ,推动项目进度。

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

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

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

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

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

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

    区别:

    在Scrum指南中,唯一一个经过授权的角色理论上应该是PO。然而在Scrum中,SM在团队中是没有授权的,换句话说,敏捷项目团队既没有Manager也没有Leader。PM都是经过在项目层面上经过授权的,SM的职责是确保scrum的正确使用并使得Scrum的收益最大化,SM可以兼职,所以我们团队实行了SM 轮值。

    3. 实际迭代开发中我们是怎样做的?

    ​ 本次迭代开发我们仍然采用了敏捷开发,同时实行了 SM轮值的实行办法,以项目迭代为周期,做为一个迭代的项目负责人组织开发工作。

    会议主题:总结复盘本次开发中的经验和需要改进的地方。

    参与人员:产品经理、UI设计、移动端开发(AndroidiOS开发、H5开发)、服务器开发、团队负责人、担任本次的SM。

    以下是对最近一次迭代开发任务做一次总结复盘。

    3.1.关于PM
    • 开发任务需求及开发时间的确定

    ​ 开发任务需求一般来源于市场或上级Boss。角度不同,需求和实际开发中的安排也不同,上级希望多、快、好、省,尽快看到产品实现。而实际开发落地得根据目前的开发情况来定,此时对上级的需求PM需要好好评估,可以对需求分阶段拆解,首先满足主要需求,突出产品特色,对一些现阶段不是很重要的开发任务可以放到二三阶段,对上级沟通时要表达出对未来产品的规划,先实现主流需求,即先搭建产品体系,再完善细节,一步步稳步推进。PM要抗住压力,根据公司实际情况来合理与上级沟通。

    • 需求尽量详尽,增加交互设计;

      需求详细的同时,不要过度设计,简单功能复杂化,细节和需求做到均衡,时间允许的情况下,做出高保真原型设计及交互设计。

    • 以User Story(用户故事)为单位输出PRD

      产品需求最好以故事用例来体现,方便用户、开发团队理解,让开发人员到底要做啥。

    • 需求评审前至少提前4小时将PRD发给项目组提前查阅,期间与项目组成员沟通完成答疑;

    • 评审会议鼓励大家多提问,对于疑问点一定要有结论(无争议或确定最终回复时间)。

    3.2.关于UI设计

    如果开发时间充分,可添加设计交互设计,这个也可以是产品需求阶段实现,做一个高保真的交互设计。

    另外关于视觉呈现和需求的平衡,允许有调整的地方,如果在实现某一个功能上,在时间和开发资源消耗过多的情况下,不一定要坚持按UI设计效果实现,希望能适当兼顾开发人员的开发习惯,如兼顾AndroidiOS 开发设计规范和用户正常的使用习惯,不过度在一个简单的小功能上过度创新。

    3.3.关于服务器后端开发人员

    团队开发中,前端和后端 同步 开发,不可避免会出现服务器崩溃的问题,一般由于服务器要时常部署重启所致。

    另一原因,由于服务器的内存不足等原因,几个项目的内存占有率太多,无法及时释放,所以开发中,服务器时常崩溃无响应。

    解决办法:

    • 根据公司需求及实际情况,适当增加服务器存储空间;

    • 开发中,经常检测服务器是否崩溃,及时重启,同时在开发中告知开发人员,服务器要重启,保持信息同步。

    开发中为了保持信息同步,可以这样做:

    • 后端人员在必要的停服时刻,需要口头通知前端开发人员;
    • 后端服务开发同学,必须保证服务挂掉可以自动重启,比如,使用 supervisor 进程管理;
    • 后端服务开发环境实现 CI(持续集成),即:当某个 feature 提交后,即可自动重新编译并 supervisor 运行;
    3.4.关于移动端开发
    • 开发人员之间要互看代码Code Review,行成良好的代码风格。相互学习,共同进步。

    • iOS和Android发现两端的差异性后,应及早提出并统一;

    3.5.关于测试
    • 测试人员,在tapd的缺陷创建时,必须与需求进行关联;

    • 先发送“提测邮件”,再正式进行测试,提测邮件也需发送给产品和UI,并提醒他们验收。

    • 测试时,除了功能测试,UI测试也得同步进行,开发改Bug的同时也把UI细节优化了。

    • 测试用例

    ​ 测试驱动开发,需求评审通过后,测试用例应该及时编写出来,尽早进行测试用例评审,这样可以及时消除大家对需求理解上的偏差,这个环节其实很重要,大家往往容易忽略,一个合格的测试人员不仅仅是简单的进行功能测试,开发之初的测试用例建立有助于开发团队保持信息同步,尽早发现需求背后的问题,尽早解决,问题越到最后,解决越耗时,还会影响项目进度。

    举个栗子,测试人员根据产品需求整理了一个测试用例,以思维导图形式呈现效果,如下图所示:
    在这里插入图片描述

    小结:及时建立测试用例,尽早评审,保持信息同步。

    3.6.关于验收

    ​ 测试收尾阶段,PM及时验收,反馈产品的使用问题。细节问题交给测试人员跟进。

    3.7 关于SM
    • SM需要单独创建迭代版本,组织技术评审会议(排期),尽量以Story为单位设置任务点,大家一起创建任务清单,推动大家完成任务评估并提前设置好起止时间;工期与公司要求冲突的,反馈给PM,商讨应对方案(赶工、延期、缩减需求范围);

    • SM组织每日站立会,建议提前5分钟通知大家思考下会议发言内容,会议期间轮流发言(期间不要打断,发言完成后再提问);结合tapd故事墙(看板)进行例会;帮助大家养成及时关闭任务的习惯;

    • SM是上帝视角,是组织者,不要做裁判;充分调用项目全员的参与度,鼓励大家积极发言,尤其是偏内向、习惯被动沟通的同事;

    • SM要做好周知工作,让项目相关方(业务、PM、团队内部)充分了解本次迭代的上线时间、期间进度、风险。

    • 如果没有和团队商议,请不要代表团队做任何承诺。哪怕是一个很小的需求变更,都需要和团队沟通后确定。

    • 时间管理:管理和开发时间的平衡建议三七分,管理工作比较繁琐,会消耗大量碎片化时间,因此在开发任务中不要分配优先级过高的任务给SM。

    4.关于协同管理工具的使用

    4.1 tpad
    • PM任务的在tpad建立和分配

      任务建立时 可以按功能模块划分,先建立功能点,在功能点下建立二级子需求,分别建立如Android、iOS端、服务器端开发子需求,这样做 方便建立关联任务,及时追踪任务进度。

      举个栗子:

      在’'里程及保养信息’功能点中建立三端(Android、iOS、服务器网关端)的开发任务,关联同一个任务。
      在这里插入图片描述

    • 开发人员的任务认领、时间评估与开发中的状态更新

      开发人员认领任务后,及时变更开发人员,评估开发时间,开发中及时更新任务状态

    • 关于开发任务时间的评估

      需求评审进行前,可以先将PRD发出来,进行技术调研,方案选择,在评审时评估时间更准确。

    4.2 蓝湖

    蓝湖,PM喜欢用的产品原型设计协作平台之一,需求变更时 会 及时在线同步更新。

    4.3 磨刀

    磨刀UI喜欢用的产品设计协作平台之一,UI 变更时会及时在线同步更新。同时也支持在上面标注 ,方便开发人员查看开发中用到的UI细节, 如用到的颜色值、距离,以及交互细节等等。

    Tips:目前移动端用的这就这个平台协同开发,设计稿在PS上以iOS的尺寸 750x1624分辨率(iPhone x的渲染分辨率px),以设计的基准大小 375x812(逻辑分辨率(pt)),一稿两用,支持Android和iOS平台,以单位px标注单位。

    在开发中,Android端的同学涉及到底部高度时,需要将减去安全高度34px,这个高度是适配iphone x尺寸的。

    举个栗子:

    以基准的大小375x812 pt画布大小设计后,导出一部预览图如下所示,Android端最底部的高度需要减去34px。
    在这里插入图片描述
    Tips:UI推荐切图插件:
    1.cutterman:一键输出支持ios/android的各种分辨率图片, 自动比例换算, 批量导出; 再也不用在Android和iOS端分别切图啦,一次性切两端的。
    2.Sketch:Sketch上的可视化切图工具, 简单高效, 支持批量输出, 多分辨率支持;UI设计师必备,不用多说。
    相关扩展阅读:
    手机APP UI设计尺寸基础知识
    深入研究:如何一稿切图标注适配iOS和Android所有机型

    关于移动端AndroidiOS的设计规范不在此展开讨论,如大家有疑问可在文末留言讨论。

    5.关于项目组沟通

    沟通会一直贯穿整个开发周期,在时间紧,任务重的情况下,如何有效沟通 是整个团队都需要持续精进的地方。

    1.关于需求的沟通

    需求任务发起之初,以邮件、在线电子文档,如 Web离线查看文件和Axure原始文档查看PRD(产品需求说明书文档)。在正式召开需求评审前前,项目组最好能提前看下相关文档,有疑问尽早记下来,需求评审中如果涉及到的信息比较多,会议时间长 往往会忽略很多细节,所以在需求评审中鼓励大家一定要集中精力并对需求尽可能刨根问底,对于疑问点一定要有结论(无争议或确定最终回复时间),否则在开发过程中,遇到问题再来讨论调整会耽误的时间更多。反观以前的开发迭代,因需求的复杂程度不同,有争议不可避免,我们只能在开发中多磨合尽量减少。

    2.关于开发中的每日站例会

    早会的目的 不要拘泥于形式,不仅仅简单汇报一下Done、Doing、To Do。 除了汇报当前自己的开发任务与进度外,有问题最好及时抛出来,此时SM会协调推动,保证项目按进度走。

    早会召开前后,及时同步更新tapd的状态。

    3.开发中的沟通
    • 开发期间遇到的问题需要PM答疑或者涉及到需求改动的点,一定要在tapd留痕并@相关人,做到信息同步,避免只做口头沟通、避免只有部分人了解需求变更;
    • 建议SM确定一个沟通频次,例如每隔50分钟与上下游进行讨论,50分钟内做开发与记录问题,避免频繁打断相关人的开发思路;
    • 如果不能做到按功能点交付测试,那么在集中提测阶段,建议每日两次站立会,提升bug修复效率。
    4.关于加班时沟通

    如前端任务重时需要加班,而服务器开发人员工作不重时 下班就收工了。这时前端开发人员有服务器方面的问题时,往往得不到及时响应,所以服务器开发人员最好能留一个能及时响应,此时开发人员,可以留下来学习或者打游戏都是允许的,只要能及时响应前端开发人员联调服务器,保持一个良好的开发氛围很重要。

    6.关于团队开发小结

    1.各个开发人员,关注好开发的上下游,及时主动告知项目情况,注重交流的专业性和效率性。

    2.拥有产品思维,站在用户角度考虑问题,及可能全面,有问题及时提出,大家共同解决。

    以上,是关于SM职责的思考和Sprint Review中的总结思考,希望对你有所帮助。如有疑问,欢迎大家留言讨论。

    参考资料:

    1.啥是Design Sprint设计冲刺?

    2.敏捷开发:做一个合格的Scrum Master

    3.ScrumMaster与项目经理究竟有啥区别

    4.浅谈Scrum Master能力提升

    展开全文
  • 这些团队跟我分享了他们期待Scrum Master做的六件事情。 1. 帮助他们理解职责边界 敏捷团队被告知他们是自组织的。但是,这并不意味着每个企业的自组织都完全一样。比如说: 团队是否有权将团队的技术需求添加到...

    我一直在和你的团队交流,好吧,可能不是你正在带的团队,而是很多和他们类似的团队。这些团队跟我分享了他们期待Scrum Master做的六件事情。

    1.  帮助他们理解职责边界

    敏捷团队被告知他们是自组织的。但是,这并不意味着每个企业的自组织都完全一样。比如说:

    • 团队是否有权将团队的技术需求添加到Sprint中?
    • 团队是否可以决定谁在这个团队中?
    • 团队是否可以在不询问Scrum Master的情况下改变他们的Sprint长度?
    • 在未经许可的情况下,团队可以在工具、团建活动或任何其它事情上花多少钱?
    • 。。。。。。

    当团队第一次被告知他们是自组织时,他们通常会很挣扎,因为他们不知道这意味着什么。作为Scrum Master,你需要帮助团队了解他们可以自由操作的职责边界。

    2.  让他们感觉到安全

    Scrum Master的一项重要工作就是创造安全感。例如,团队能够进行Sprint计划,而不必担心如果他们没有完成他们预期的一切而被大吼大叫。团队需要交付高质量的成果,但是如果因为疏忽导致了一个生产环境的缺陷,团队诚实地承认错误,他们知道不会因此而遇到麻烦。当被问及完成这些功能需要多长时间时,团队能够真实地回答,而不用担心延期或者提前完成会产生不好的影响。

     3.  赞美他们

    每个人都喜欢听到“你做得很好,太棒了”。在我坐下来写这篇文章之前,我在遛狗的时候,遇到了一个女士带着一只漂亮的棕色拉布拉多犬,我说,“你的狗狗真漂亮啊。”她的脸发亮,笑容满面。我猜她在狗狗的打扮上一定下了不少功夫,她显然非常感激这种赞美。你的团队成员也是一样的。当某人做得很棒时,让他们知道。即使是简单的“你很棒!”也可以提供帮助。当然,态度要诚恳,一旦你开始寻找赞扬团队成员的机会,你会发现很多。

     4. 支持他们

    团队需要你的支持。帮助团队移除障碍是你职责的一部分,但更重要的是,你应该努力在问题成为障碍之前将其移除。支持团队不仅仅是处理障碍。当你对他们始终诚实,并且让他们感到公平时,团队成员会感受到支持。言出必行。当你告诉团队成员你会做某事时,紧接着就去完成它。你帮助团队,让他们对自己的承诺负责,对你自己要用同样或更高的标准。平易近人。如果你每天都是坏脾气,那你不可能指望团队成员在需要帮助时来找你。与团队成员交谈。不要说太多,以免影响团队工作的推进,但你应该了解每个人在Sprint期间的表现。知道什么时候提供帮助,即使只是为了倾听,或者在某个早晨为某人带来一杯他最喜欢的咖啡。

     5.  让他们感觉很牛

    我遇到的最糟糕的Scrum Master们都有一个共同的特点:他们认为这一切都是为了让自己看起来很棒。在Sprint评审会上,这些Scrum Master会说“让我来给大家展示我团队的成果”。Scrum Master的工作是让团队看起来很棒。这不是形式上的,而是感受到的。优秀的Scrum Masters帮助团队成员尽其所能。然后他们确保组织知道团队成员正在很好地进行他们的工作。

     6.  知道什么时候打破规则

    Scrum的规则很少,但它们存在的理由很充分。每个都有助于团队敏捷并增加成功的可能性。但是,正如俗话所说,规则意味着被打破。你的团队希望你在适当的时候可以打破规则。有时候常识占上风,而规则会妨碍常识。一个好的Scrum Master会认识到这些情况。例如,永远不要延长Sprint是我遵循的规则,通常是这样的。我打破过吗?是的,偶尔,而且总是有充分理由。3个小时是是Sprint回顾的时长上限。我的99%的回顾都是在更短的时间内完成的,通常时间要少得多。但是我辅导过的团队打破过3小时的规则吗?是的,我们偶尔会讨论一个非常热门的话题,而且似乎继续讨论比推迟要更好。你可以成为一个优秀的Scrum Master。成为一个优秀的Scrum Master,没有什么秘密、神奇或神秘的东西。你需要为团队做的很多事情,都是那些你过去的领导和经理为你做的让你很感激的事情。

     7、您怎么看?

    您认为我的清单中缺少什么吗?如果您是团队成员,还想从Scrum Master那儿得到什么?如果您是Scrum Master,我有错过什么您的团队想要的东西吗?请在下面的评论中分享您的想法。

    本文作者:Mike Cohn

    英文原文链接:

    https://www.mountaingoatsoftware.com/blog/six-things-your-team-wants-from-you-as-their-scrum-master

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


    图片来源于网络

    Scrum Master: Beauty and Beast

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

    展开全文
  • 在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
    展开全文
  • 这是敏捷开发一千零一问系列的第二十九篇。(在这里提问,之一,之二,之三,问题总目录)问题估算和度量几乎是敏捷开发及其他开发方法永恒的话题。不过,在进行估算之前,必须理解估算的价值,并觉得为估算所付出的...

    这是敏捷开发一千零一问系列的第二十九篇。(在这里提问之一之二之三问题总目录

    问题

    估算和度量几乎是敏捷开发及其他开发方法永恒的话题。不过,在进行估算之前,必须理解估算的价值,并觉得为估算所付出的工作量值得。

    请看下面这段对话,它发生在2003年为一家企业做CMMI咨询的时候,涉及到代码行估算(有改动和扩展):

    甲:假设一段代码是1000行。不估算,写完了一数是1000行;估算,写完一数还是1000行。为什么要进行估算呢?

    乙:因为如果知道是1000行,就可以按生产率来估计开发时间了。比如如果一天开发100行,那么10天就能开发完成。

    甲:知道是10天,要花10天;不知道是10天,开发完还是10天,为什么要估呢?

    乙:如果知道每个任务的具体天数,就可以均衡每个人的工作量。

    甲:如果我们这里都是主动领取任务和跨职能,那么每个人干完都会自己领取,不存在工作量平衡问题,是否还需要估算?

    乙:……

    这段对话表明,在做估算之前,以及在确认用什么方法估算之前,都是应该思考一下:我为什么要估算?其他实践也是这样。

    尤其是敏捷开发的估算会(就是Scrum的计划会),需要整个团队开接近一天的时间,如果不能找到合适的理由,浪费时间的可能性还是很大的。

    分析

    从1999~2001年左右开始做估算,而2002年之后又开始教别人估算。迄今为止,最经得住质疑、雷打不动的两个估算目的不是做计划、度量、平衡工作量、之类,而是:

    1. 报价或早期制定项目计划

    若报价是错的,老板极有可能已经承诺了不切实际的价格和目标。一旦这个已经确定了,那么相应的总体计划其实也已经敲定了。

    比如,若一个“本来(可惜无人知道)”需要100万和10个月的项目被签订为50万和5个月,其实无论团队如何努力,团队的绩效都会化为泡影。即使团队以超人的能力在80万(按工作量计算的成本)和8个月完成了项目,都不会拿到奖金。因为老板整个项目净亏损50万,无论责任在谁,反正钱是没有的。

    尽管造成这个结果,责任似乎在老板据多一些,但要知道老板签订合同之前可是问了两个人:一个是客户,客户回答:“50万,5个月。”;另一个是团队,团队说:“不知道,因为需求太粗略了”。你是老板你该怎么办?http://

    2. 用估算降低工作量

    这个说法听起来很奇怪:我们一般认为有个东西叫任务,我们只需要拿尺子去测量一下,看看结果就可以了;现在居然测量过程会改变实际结果

    本人在2001年左右得到高人真传,编程水平飙升而代码行数陡降,所以后来常常干一些杀代码的工作。比如:4000行代码、4000个常数、2个人月的工作=》700行代码、76个常数、0.5人月;4000行代码、65个函数,1个人月=》55行代码,1个函数,2小时。后来到一家企业,他们自己刚杀完一个代码,19万行代码,13人×9年=》1.3万行代码,1人×1.5年;估计好好杀杀能进万行以内……

    当然下一个问题:当问题发生了,再去看它,会很容易发现有众多浪费的代码和工作量,如果一切还没有发生前,有没有方法发现?

    对高手而言,他们总能及时预见到代码和工作量的浪费,并在第一次编写代码的时候就能做到最少代码和最少工作量。可是团队里边还是有很多新手的,他们没有能力做到这一点,甚至都不知道自己将会浪费90%的代码和工作量,怎么办?

    没想到后来是估算帮助解决了这个问题,所以很值得一试。

    方案见下一篇博客

    本人正在参加CSDN博客之星评选,如果您经常来本博客阅读或曾经下载《火星人敏捷开发手册》,欢迎投票(需要登录):


    http://vote.blog.csdn.net/item/blogstar/cheny_com


    每人可以为10个博主投票,所以如果看到其他常去拜访的博主,也请投上一票!


    展开全文
  • [敏捷开发实践] Scrum Master的职责 Scrum Master 是仆人式领导者,能够为Scrum团队提供支持,让团队功能完善并高效运作。 作为Scrum框架规则的维护者,帮助项目团队和组织遵守Scrum价值观和实践; 以被动和主动...
  • 这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷教练和 Scrum Master 是一种专业的职业。其职责是帮助团队和组织做到更好(本课程视 Scrum Master敏捷教练为同一职业的不同发展阶段)。敏捷能力的培养并不是简单了解后就可以速成的,但如同任何其他职业一样...
  • 在整个团队经过三面墙的快速对整个项目的三个方面进行整理了解之后,接下来便开始了开发的流程.     因为项目是新开始的,没有一个现有的开发框架或平台,所以初始阶段搭建框架的工作显得十分迫切.如果没有一个...
  • 觉得这篇文章写的非常好,非常有助于大家了解敏捷开发,原文链接在下面 https://www.jianshu.com/p/eb8f4448c5c8 什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。在...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster. ...
  • 你想成为一个优秀的Scrum Master吗?我想是的,除非你是一个产品负责人或者其他的角色。我作为一个Scrum Master已经有20多年了,这些年,我给出了很多的建议,也收到了很多的建议。我甄选出了我认为最棒的十个建议给...
  • 本人做过2个项目的敏捷开发ScrumMaster,经历了其中的酸甜苦辣,有了很多实践经验教训后,发现下面3本书能够帮助实践敏捷的兄弟的功力更上一层楼。很快我会把我的一些敏捷开发的实践心得分享给大家。 《敏捷...
  • 敏捷开发模式下需求分析岗 BA 传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 敏捷开发的价值观 敏捷开发应遵循的12条原则 敏捷开发的原则 敏捷团队运作机制 关键的团队角色 产品负责人(Product Owner) Scrum Master(流程主管) 关键的团队活动 敏捷团队的五个约定 约定1. 业务分析师...
  • 要问当前互联网公司普遍采用的开发模式是什么,毫无疑问那就是敏捷开发,据统计,目前90%的软件开发模式都采用敏捷开发。本文就给大家普及下敏捷开发的整个来龙去脉。 敏捷开发是什么? 百度百科的定义: 敏捷...
  • 接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。敏捷开发概念与价值观敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2...
1 2 3 4 5 ... 20
收藏数 10,832
精华内容 4,332