• 敏捷开发-站立会议要点: 1、站立会议全员都需要参与; 2、当值员必须提前准备,识别出问题和风险,做好协调; 3、每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行; 4、每日站实践不能超过15...
    敏捷开发-站立会议要点:
    1、站立会议全员都需要参与;
    2、当值员必须提前准备,识别出问题和风险,做好协调;
    3、每个组员汇报进展和当天的计划。对于承诺的任务,需要完全执行;
    4、每日站会实践不能超过15分钟;
    5、三段论:昨天完成什么,今天计划做什么,困难;
    6、成员之间信息共享,每个组员都能了解项目总体进展;
    7、不要陷于技术细节的讨论,当值人员应该记录下所有的阻碍并跟踪;
    8、把每个问题用跟踪卡片(或在JIRA)跟踪起来。
    展开全文
  • 每日站立会议敏捷流程scrum中的很重要的一个制度之一。 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 2.给每个人一种精神压力,信守承诺。这是一种面对面的精神...

    每日站立会议是敏捷流程scrum中的很重要的一个制度之一。

    功能:

    1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展。 
    
    2.给每个人一种精神压力,信守承诺。这是一种面对面的精神压力,直面项目进展。
    
    3.培养团队的文化,让每个人意识到:我不是一个人在战斗,我们是一个团队。 
    

    站立会议的目的:

    1、让所有人了解其他人在做什么,当前项目计划进展如何 
    
    2、帮助大家解决那些阻碍做事情的问题,以及共享承诺这些都非常有利于提高团队合作精神的。 
    

    注意要点:

    1、主题明确,不能掺杂其他无关的话题

    每个人就4个问题回答:

    1)我们上次开会后你都干了什么?(要关注细节,又不能过分详细)
    
    2)每个你负责的、正在做的任务还剩下多少时间? 
    
    3)我们下次开会之前你要做什么?(当成员间的工作有依赖关系时,会给其他成员一个很好的提醒,自己给自己设定一个目标)
    
    4) 你的工作被阻碍了吗?(组长会后要及时解决会议上提出的阻碍,否则会影响大家反映阻碍的积极性)
    

    注:如果有问题需要讨论,但只需要几句话的讨论,那么在会上解决。否则需要详细讨论的,记下来,单独安排一个会议专门讨论。

    2、站立会议只允许“猪”讲话,不允许“鸡”讲话

    猪-团队成员鸡-其他人员(例如观摩的领导等)

    3、所有人站立围成一圈,不能围坐在一起桌子周围站立暗示这个会会很短,强迫大家更专注和投入,还可以避免有人坐着收发邮件和其他分心的事情。

    4、确保整个团队都要参加每日会议

    5、每日会议是团队交流会议,不是报告会议,每个与会者要清楚,团队是在互相汇报和交流情况,而不是向主管或经理做汇报

    6、每日会议应该控制在15分钟之内

    7、不要把每日站立会议作为一天的开始,不要太早也不要太晚避免有人从心里上把一天的开始跟这个会议联系在一起。

    8、站立会议要在每日同一时间同一地点举行

    注:以上内容来自网络分享或总结,仅供参考

    点评或感受:

    第8条有些人可能觉得没必要,不过对于敏捷开发来说一个熟悉的环境讨论同一个问题有助于让人回顾起一些已经快要遗忘的探讨内容,毕竟睹物可以思人,思考更是没话说。

    第2条则讲的是让大家安静的听从别人的想法,取其精华而不是过早扼杀在摇篮中,哪怕你有更好的解决方案,目的是互相学习和建立互相尊敬的氛围

    这个开发模式也是激发大家在短时间迅速表达和接收新思维的能力,长时间保持这种工作状态非常有助于提高团队协作能力。

    实践每日站立会议可能遇到的问题:

    第一条,会议本身的目的性非常强,不过对于长时间的团队配合难免有时候会出现将每日会议当例会来开,
    演变成懒散的"早会",所以这个会议的scrum master最好有一定的威信并且善于把握节奏
    
    第二条,听主讲人讲话是好的,不过经常会有瞬间的想法或者改进,按照会议要求需要继续听讲而不是打断,
    则需要抓紧记下笔记,以免过一会想法就遗忘了,新想法是好的,不过作为敏捷开发有时会有强制的时限要求,可能要考虑实施的价值
    
    第三条,之前看过一个调查,说是人的注意力持续时间大概在36分钟左右,所以15分钟的站立确实也能达到很好的效果
    
    第四条,每个人都到的会议是理想化的,一般也能达到,出现缺席也很正常,如果会议内容很重要不妨录音或者视频记录发给缺席人员。
    
    第五条,与会者需要锻炼快速表达思维的能力,避免啰嗦,多参加几次会议并发言估计也能达到提升的效果,大家要予以理解。
    
    第六条,15分钟,应该除了不可抗力这样非常紧急或者优先级高的事情,应该都能保证,会议宜短不宜长,明确好任务就可以解散执行了。
    
    第七条,有关会议心理,第一条可以一定程度上缓解这样的误解
    
    第八条,如果不能同时同地也要尽量维持周围环境一致性,有利于更好代入节奏
    

    每日会议的必要性,可行性和效果分析:

    从上面的要求来看,确实是从多维度的规则上保证并要求大家在同一地点时间等方面快速的把已完成,要完成等工作迅速阐述明白,而且在主持会议scrum master的带动下高效地明确统一任务安排,时间在15分钟内,并不算长,这样的高效会议长时间执行能提高各种能力,对于团队的自信和效率都是很有帮助的。

    不过相反的,敷于表面的会议形式或者心理上就不认同会议效果带来的就是时间上的浪费。换言之,这么简短的会议对于不同的人或团队是有不同效果的,基本上执行一段时间就会产生两极分化的结果。

    原文地址:https://www.cnblogs.com/jx8zjs/p/5863013.html (感谢原博主总结和分享)

    展开全文
  • 传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

    在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    传统的开发模式和敏捷开发模式的对比

    瀑布模型:
    这里写图片描述
    优点:
    1. 为项目提供了按阶段划分的检查点。
    2. 当前一阶段完成后,您只需要去关注后续阶段.
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点:
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型:
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一):
    这里写图片描述

    如图(二):
    这里写图片描述

    如图(三):
    这里写图片描述

    如图(四):
    这里写图片描述

    敏捷开发管理工具:teambition
    teambition

    参考

    敏捷开发之Scrum扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划,每日站,回顾,评审,其中数计划最为重要。...在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同

    从敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好团队,好的团队一定经常开会。经常开会是需要时间的,因此有利有弊,如果会议时间和节奏控制的不好,就会占用掉团队很多的精力和工作时间,那就得不偿失了。在敏捷开发模式中,每种会议都有其特殊的职责和使命,不同的会议上所讨论的内容是不一致的,只要把握住会议的关键点,就可以为团队的敏捷模式服务。

    关于开会,日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间,因此会议贵精不贵多,在最短的时间内达成最有效的决议,这才是一个有成果的好会议。产品团队必然也会面临这样的问题,在敏捷团队内部,除了必要的全员培训外,尽量保持在团队内部只有敏捷的这四个会议,其余的沟通和会议都可以由PO和SM去参加,然后回来传达给团队成员即可,这样可以减少团队整体的时间消耗,保证团队的工作效率。

    Scrum-workflow

    Sprint Planning敏捷迭代计划会议

    在每个敏捷迭代开始之初,由产品负责人讲解需求,并由开发团队进行估算工时的计划会议。 在会议上需要:排列需求优先级;分析和评估产品Backlog并确定该迭代的目标;计划会议上还需要制定迭代计划,包括: 根据产品Backlog(功能点)创建Sprint Backlog(即迭代任务);然后为Sprint backlog中的任务做估算;团队成员从产品Backlog中挑选他们承诺完成的条目。

    敏捷的迭代实现始于计划会议,所以一个好的计划会议是每个迭代成功的基础,一般分两个阶段进行,两个阶段参与会议的人员会不一样;

    计划会议的目标:

    1、基于敏捷规划产生的Product Backlog以及优先级,通过计划会议,确定迭代的目标、团队成员、形成Sprint Backlog,明确评审会、回顾会时间;

    2、分解Sprint Backlog并确定相应的完成时间,并由团队成员共同挑选这些Sprint Backlog;

    阶段一参与人员:产品经理、Product Owner、Scrum Master、团队成员,有业务人员的话还可以邀请业务人员一起参加。

    会议时长:1-4小时

    一般参考进程安排如下:

    1、Scrum Master公开迭代时间表;

    2、产品经理和Product Owner讲述Product Backlog,对应的业务价值和优先级;

    3、团队针对Sprint Backlog和优先级达成一致;

    4、Scrum Master和团队成员共同确定Sprint Backlog;

    阶段二参与人员:Scrum Master、团队成员,其他人员选择性参加

    会议时长:1-4小时

    一般参考进程安排如下:

    1、团队成员针对Sprint Backlog共同分解任务;

    2、团队成员共同进行工作量评估(每个Task不超过2天),确定开始时间和完成时间;

    3、团队成员共同认领任务;

    4、共同确定DoD,团队达成一致;

    5、团队共同确认迭代目标和价值;

    如果单个迭代内安排的Product Backlog安排的比较多的话,一般迭代计划会议需要开一个整天,虽然时间有点长,但这个会议会确认整个迭代的详细计划和安排,因此也是值得的。

    Daily Stand-up Meeting每日站会

    团队每天进行沟通的内部短会,因一般只有15分钟且站立进行而得名,团队成员通常会在会议上讲述如下3点内容:

    1) 昨天我做了什么

    2) 今天我计划要做什么

    3) 我遇到了什么问题,妨碍了我尽可能有效地工作

    Scrum Master记录会议上提出的问题,但是不要在会议上讨论和解决问题,而是要会后在找相关人员进行讨论和解决。

    Sprint Review敏捷迭代评审会议

    在迭代结束前给产品负责人演示并接受评价的会议,并根据反馈结果,提出新的产品Backlog

    参与人员:产品经理、Product Owner、Scrum Master、团队所有成员

    会议时长:1-4小时,视演示内容而定

    主要是检验迭代成果,检查是否完成迭代计划中的迭代目标,有可能的话要求用户参与测试流程,并得到用户对产品的认可,鼓励用户自己进行测试设计和进行破坏性测试,充分暴露产品的设计和功能问题。

    由Scrum Master来推进会议进程,Product Owner记录用户反馈,根据结果维护产品 backlog,一般在迭代结束前做一次。

    Sprint Retrospective敏捷迭代回顾会议

    在每个迭代结束后召开的关于自我持续改进的会议,围绕如下三个问题进行讨论:

    1) 本次迭代有哪些做得好;

    2) 本次迭代我们在哪些方面还能做得更好;

    3) 我们在下次迭代准备在哪些方面改进;

    团队确定问题优先级,并根据优先级确定团队能够解决的Top问题;团队讨论Top问题的措施,并选择在下一个迭代可以完成措施,分配责任人进行跟踪。

    参与人员:Scrum Master,Product Owner,团队成员。

    会议时长:0.5-1.5小时

    主要针对当前迭代,团队成员自由讲述可以需要保持的做法,改进的点以及持续跟踪计划。

    Scrum Master将团队讨论以及行动计划形成会议纪要,并发送给整个团队和有关同事。需要按照回顾会议的结论,维护一份待办事项列表,在下次回顾会议上进行跟踪。

    案例分析

    案例一:某Team在每日站会中,Scrum master准时组织大家开始晨会,成员一个接着一个说,昨天做了什么事情,今天计划做什么事情,遇到什么问题,成员A说昨天遇到了一个问题未能解决,Scrum master问遇到的是什么问题,成员A详细说明了该问题,这时成员B说这个问题他也遇到过,他是通过XX方式解决的,讨论后成员A明白了,然后继续晨会,由于小组成员有10个人,整个会议开下来大概花费了30分钟。

    问题分析:Scrum master不应该在每日站会上询问详细的问题细节,而应该转移到会下询问,当团队成员之间进行讨论的时候,Scrum master需要及时拉回来,讨论应该转移到会下进行,晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

    案例二:某Team在开回顾会议中,Scrum master详细总结了本次迭代中有哪些做不够好的,并指出了对应的事和人,接着对应的责任人开始述说哪些地方确实是做的不够好及其原因,最后给出改进措施然后结束会议。

    问题分析:回顾会不是批斗会,不应该只说做的不好的,做的好的也要说,Scrum master主要是鼓舞大家的士气,应该先从做的好的方面开始说起;并且做的不好的方面都只对事,不对人,做的不好是整个Team的责任,不仅仅是某几个人的责任;最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

    在敏捷的迭代执行过程中,上述四种会议会随着每个迭代一直进行,基本上形成了一个闭环,可以让团队在每个迭代的执行过程当中去学习和总结,从而正确的按照敏捷的要求去做,使团队真正的敏捷起来。

    展开全文
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 大家都知道,创业公司刚开始需要研发出...

    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。

    大家都知道,创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品,不过大部分创业公司没有那么容易一下就能做出来,很多公司还没有成功的产品资金链就断掉了,公司也死掉了。我们公司是这样一个状况,有一条产品线可以维持公司开支并仅仅刚够盈余,要扩大高速发展还不够,一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着,但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题,很大的难题!

    我们技术团队人员是这样的配置:1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作,能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师,参与新项目开发时间大概有80%。高级工程师要预留项目学习时间,参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目,但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命,属于机动部队。

    现在总共有六个老项目在维护,两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间,需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间,需要2周开发完成。而现在的人力按照能够投入的时间算一下,总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天,6个老项目每周需要4人天,一个月4周,需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天,而总共需要120 + 40 = 160天,足足少了44人天,这看起来是一个不可完成的任务。

    不过到最后,我们还是使用敏捷开发完成了这两个项目,也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发,这个时候只要两个人就能够很好的合作把产品开发出来,不需要什么模式。随着人员的扩充,团队间如何协作按时按质按量完成任务就需要好好思考下了。

    尝试一,传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式,不过套用在我们公司时我们是这么操作的。

    传统开发过程
    传统开发过程

    由于公司创业,老板有一个想法,但并不能很好的描述需求,所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成,后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成,资深工程师进行把关,再到测试人员测试,最后再交付用户验收、技术维护。看起来很好的模式,开发了几个产品最终有的延时有的产品离用户的期望差距甚远,参与项目团队的人信心受挫。

    为什么会失败呢?后来思考了这些问题:

    1、技术总监不是产品经理,不能够承担产品设计的责任。老板是信任技术总监能做好产品,就交给他做。但这里搞混了一个概念,产品经理和项目经理,技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好,责任所在。说到底,就是机制没有把产品设计和项目经理区分开,不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。

    2、需求不稳定,变化后改动代价大。由于创业,需求为了适应市场会经常调整,但是一但调整,很多开发计划就会受到相应的调整。如果部分功能已经正在开发,调整需求后很多工作要重新开始,严重影响了技术同事积极性。业务不调整需求是不可能的,他们是为了满足用户的要求,用户满意了才能给企业带来价值。不过如果调整,代价太大,很多代码要重写,大家就会责怪技术总监或者项目负责人没有把握好需求。

    3、团队经常加班,但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护,没时间指导新同事技术学习,而新同事技能暂时还没有发挥出来干活效率低,任务经常延期,没有成就感。核心团队事情很多,没有时间整理项目文档,新员工没有文档上手慢。大家每天很多事情,需要加班才能完成,比较疲惫。每个人除了工作还有很多事情需要做,比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作,他能同意,他家人也不一定同意。让大家愉悦的开发,比疲惫的上班效率要高很多。

    4、交付软件质量差,离用户期望差距大。创业时大家的想法都是好的,大干一番,做一个所有人都爱使用的产品。现实是残酷的,大家辛辛苦苦做出来的东西,老板不满意、用户不埋单,付出的努力没有人认可。交付的软件没时间自测试,或者自测试不充分,交给测试又是一大堆问题。有些公司还没有测试,直接出去给用户,相当危险。这样交出去的公司不仅仅影响了用户的使用,还影响了整个公司的口碑。

    不是说传统软件开发模式不好,只是不太适合我们这种创业公司。开始尝试其他模式,如果没有一个很好的体制就不能把大家的最大生产力发挥出来。

    尝试二,敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本,专注于交付对客户有价值的软件。在高度协作的开环境中,使用迭代式的方式进行增量开发,经常使用反馈进行思考、反省和总结,不停的进行自我调整和完善。

    敏捷开发的主旨

    一:个体及交互比流程与工具更具价值

    二:可用的软件比冗长的文档更有价值

    三:与客户的协作比合同谈判更有价值

    四:对变化的响应比遵循计划更有价值

    而我们之前的问题,交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试,先看一张敏捷开发的流程图。

    创业公司敏捷开发敏捷流程化
    创业公司敏捷开发敏捷流程化

    敏捷开发简单流程

    1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
    2、召开产品backlog计划会议,预估每个backlog的时间,确定哪些backlog是需要在第一个sprint中完成的,即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
    3、把sprint的backlog写在纸条上贴在任务墙,让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上,这样大家都可以看得到任务的状态 )
    4、举行每日站立会议,让大家在每日会议上总结昨天做的事情、遇到什么困难,今天开展什么任务。(每日站立会议,是在每天早上定时和大家在任务墙前站立讨论,时间控制在15分钟内)
    5、绘制燃尽图,保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制,每天记录一下,可以看到每天还剩多少个任务,直到任务数为0 ,这个sprint就完成了)
    6、sprint评审会议是在sprint完成时举行,要向客户演示自己完成的软件产品 。
    7、最后是sprint总结会议,以轮流发言方式进行,每个人都要发言,总结上一次sprint中遇到的问题、改进和大家分享讨论。

    我们怎么结合敏捷开发解决现有项目的问题,要记得任何措施都是为了保证按时按质按量把软件交付给用户,不要为了敏捷而教条实施敏捷,公司不能产生商业价值,任何先进的理念或者技术都是无意义的。我们做了这些措施:

    1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的,才能被认可。

    • 首先培养测试小妹学习敏捷开发,后续让她承担部分产品责任人和敏捷指导者的角色,原因有:
      a、测试要验收功能,必须理解业务需求。
      b、测试也是QA质量体系的一块,学习好了对于软件质量有个更深的认识。
      c、团队大部分是男生,女生推广更有亲和力一些。
    • 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下,怎么给大家说更有效,更容易接受。她要讲解一定要自己非常清楚敏捷开发,并且准备充分知识点。开会时先指出我们现在问题,让大家看看有什么想法解决问题吗?现在我们做的产品,客户不认可、老板不满意、自己很累没有成就感,有什么办法解决。在大家讨论后,抛出敏捷开发的优势,一般情况下大家都会认可的。大家可能会问到如何执行、落地,可以尝试找一个项目试点,如果实施成功就可以让大家全面推广,不成功也只影响了部分项目。

    2、搭建敏捷开发环境。大家要实施敏捷开发,需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件:nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》

    3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说,目的是完成这个项目,需要进行这几步:

    • 先根据各自的能力和意向聚集一批完成这个目标的勇士,不管技术和非技术。如果聚集的人不够,技术总监可以根据总体项目的投入机动调整资源以支持,不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试,除去大家做其他事情的时间,总共可以算作4个人。
    • 充分调动客户(老板和业务同事)参与进项目,他们的参与直接决定了项目成功与否。结合之前的经验,如果他们参与不够,最终做出来的东西就不是他们要的,或者离他们要的差距很大。他们刚开始加入的时候,很迷茫有时会表现的比较抗拒,这个时候一定要耐心坚持让大家把第一个sprint开发成功,使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化,如果有需求变化,就添加任务到任务墙,大家可以对所有任务的时间有个全面了解,如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
    • 技术总监安排和客户沟通,客户这里指老板和业务。测试小妹负责和客户沟通记录,技术总监辅助。多次沟通后,尝试让测试把需求原型用最简单的工具绘制出来,技术总监审核通过后和客户沟通确认,反复迭代,直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行,但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题,过度技术设计产品。
    • 产品设计出来后,召集项目成员分解任务,确定每个任务的时间,可以使用敏捷扑克牌来估计。任务分解尽量控制在 1-2天的粒度,这样大家1-2天就可以做出一个能测试的原型,尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周,不能太长,也不能太短。太长会出现疲劳,太短的sprint会让大家觉得工作太多,做完一个又一个。“项目1”估算结果为120人天,总共投入4个人,需要30天4周时间,我们切成了4个sprint,差不多1个月时间完成,满足业务的时间要求。
    • 分阶段实施sprint,绘制任务墙,划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙,贴到未开始的地方。

    创业公司敏捷开发任务墙
    创业公司敏捷开发任务墙

    • 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务,统一管理起来。强调的是一个团体,如果有同事请假,其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题,对于当前的任务有什么建议,尽量控制在15分钟内,有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果,而是团队驱动,每天大家做的事情都反映在墙上,谁出现了什么状况,大家都会帮他想办法,保证整个项目能够成功。每一个任务完成,由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
    • 软件开发过程。认领任务后,怎么保证大家开发有质量的代码?团队有资深点的工程师,不需要太多指导,直接可以参与项目的开发。而学习型工程师,需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务,他负责开发团队的概要设计审核,没有审核通过的设计不能开发,并指导大家分析和设计系统。大家都知道,系统思路有了,剩下就是技术实现的过程,只要技能掌握熟练实现基本难度不大。大家可能会问,敏捷开发不是强调软件开发的产品是软件,而不是文档吗?我们这里也不是像传统开发软件一样为了文档而文档,只是让大家把自己的设计思路写下来,只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论,这样的文档是不欢迎的,受欢迎的文档只需写出用例分析,表设计,复杂的逻辑需要画出流程序列图。
    • 结对编程。之前这个编程模式被无数人调侃过,其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时,会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时,很多时候都会结对,比如指导新同事、讨论设计模块,而之前这些都没有算在我们的开发工作量里。

    创业公司敏捷开发结对编程
    创业公司敏捷开发结对编程

    • 项目演示和总结会议。在项目结束后,让所有参与项目的成员都参加,一起演示给客户展示,并解答客户的问题,充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享,并为下一个sprint做准备。

    经过敏捷实施后,我们的生产力提高了很多,员工的积极性提高了,业务的参与使整体需求把控也很好,大家沟通多了,30天的任务提前了5天完成。我们多出来的时间,让大家每周有一天或者半天研究自己感兴趣的领域,但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术,最后做完需要写个ppt 给大家分享下。既能让大家做自己想做的事情,也给大家创造了一个互相学习的氛围。

    ps:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

    另曝光一下项目1参与成员:

    项目1敏捷团队 
    项目1敏捷团队
    展开全文
  • 很显然传统的瀑布开发模式已经不能满足需要了,于是,敏捷开发这种模式就出现了。  接触过敏捷开发的朋友可能知道,敏捷开发有如下的价值观:  个体与互动 胜于 过程与工具,可工作软件 胜于 复杂文档...
  • 敏捷开发模式

    2018-07-01 01:34:06
    1、敏捷开发的概念从1990年代开始逐渐引起广泛关注,是一种以人为核心、迭代、循序渐进的开发方法。强调以人为本,专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。2、敏捷开发的流程(图为禅道...
  • 文章目录1 敏捷开发2 传统的开发模式和敏捷开发模式的对比2.1 瀑布模型:2.2 敏捷模型:3 敏捷开发scrum的实施4 敏捷工作件5 敏捷管理实践 1 敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 开发工作中使用的敏捷开发模式 来现在的公司有一段时间了,现在主要用java开发采用敏捷的开发模式。因为以前工作中对敏捷的了解比较少所以觉得有必要进行梳理总结下。 敏捷开发的定义及解释说明这里就略过了,想要...
  • CMMI与敏捷开发模式比较 四月 9, 2012 07:07 by FlySky 我曾经参与了一个新产品项目两个版本的开发,分别采用了CMMI与项目级敏捷方式,总结一下两种模式。 CMMI采用的是传统的瀑布模式开发,开发流程是...
  • 主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到...
  • 每日站立会议内容: 地点:九栋宿舍楼 时间:2018/1/6早 会议具体的内容: 昨天还遗留一些问题没有解决:继续界面优化,重新设计留言评论界面,加入字数限制 会议照: 燃尽图: 任务看板: 转载于:...
  • 软件开发模式敏捷开发(scrum) 版权声明:本文为博主 android_Mr_夏 原创文章,未经博主允许不得转载。 https://blog.csdn.net/xiajun2356033/article/details/81513957 简介 这几年关于敏捷开发在互联网企业...
  • Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...
1 2 3 4 5 ... 20
收藏数 1,886
精华内容 754