敏捷开发 迭代计划_敏捷开发如何计划每个迭代的周期 - CSDN
  • 1、什么是iteration和release? iteration和release是两个不同的...Iteration(迭代):在固定的周期内,经过需求分析、设计、实现、测试等活动,完成计划的的业务需求,迭代结束提供一个可工作的产品(Release/Report)
     1、什么是iteration和release?
    iteration和release是两个不同的概念,但在敏捷实践活动中,我们往往认识的比较模糊,一个Iteration就是一次release,其实不然。那么,具体有什么区别和联系呢?
    Iteration(迭代):在固定的周期内,经过需求分析、设计、实现、测试等活动,完成计划的的业务需求,迭代结束提供一个可工作的产品(Release/Report)。计划的业务需求(CR),可能是一个完整的User Story,也可能是一个Story中的若干task。
    Release(发布):经过一个或若干个iteration后,完成计划中的所有User Story
    (多个CR),经过测试后才release,最终真正交付给客户使用。
    在我们的实践活动中,一个User Story (CR) 所需的工作量超过我们的有效资源,无法安排在一个iteration内。我们就会想当然的会去延长迭代周期,增加有效资源以适应所需工作量。殊不知,这更象是形式上的迭代开发,无异于瀑布式项目开发过程。

    2、建立固定的迭代周期,保持稳定的开发节奏
    Scurm方法也非常强调稳定的迭代节奏,一个稳定的迭代节奏就如同项目的的心跳。Simon Baker描述说:"就像心脏有规律地跳动来保持身体运行,固定的迭代长度提供了一个恒量,有助于建立开发和交付的节奏。根据我的经验,节奏是帮助取得不变的步幅的重要因素"(2004)。对于敏捷开发的团队而言,稳定的迭代节奏可以让产品保持更稳定的交付。

    3、如何保持稳定的开发节奏?
    当一个迭代期内可提供的有效资源无法实现一个User Story时,我们如何按排呢? 在
    迭代周期控制的困惑 中已谈到,这里不在细述。

    4、如何选择适合自己团队的迭代周期?
    一般需要考虑以下因素:
    1)、整个项目周期长度(完成计划的商业需求所需时间)
    较短的迭代周期将会有以下一些好处:更频繁的向客户展示/交付可用的软件;更频繁的度量开发进度;更频繁的取得反馈并改进;一般大的项目最好有多次(3次或以上)获取反馈、修正的机会,根据项目周期调整迭代周期长度。
    2)、不确定性的多少
    不确定性有多种形式,客户到底想要的是什么?小组的工作效率,时间?技术门槛等都不存在不确定性,不确定性越多,迭代就应该越短。
    3)、获得反馈的难易程度
    指小组获取反馈数量、频度和及时性,视所处的环境不同,选择合适的迭代长度;
    4)、优先级要以多久保持不变
    开发小组承诺在一次迭代中完成一组特定的功能,重要的是不要改变他们的目标方向,
    优先级不会被改变的时间长度是选择迭代长度时需要考虑的因素。
    5)、迭代的系统开销
    每次迭代的成本(时间),如迭代中进行的完整回归测试。最佳迭代周期的目标之一就是减少或近似消除每次迭代的系统开销。如每次回归时间成本很高,那决定周期长度时更倾向于长一些。
    6)、团队成员的紧迫感
    Niels Malotaux指出:"只要项目的结束日期还在遥远的将来,我们就不会感到任何压力,并从容不迫的工作。当结束日期逼近时,我们才会开始更努力的工作"。意思指项目开始大家比较放松,而越临近结束,工作越忙压力越大。因此,选择一个合适的迭代周期长度,让团队成员在整个迭代过程中感受到的压力更平均,不是给团队更多的压力,而是压力总量平均分布在迭代过程中。

    每个团队根据所在环境和条件确定一个合适的迭代长度,一般建议2~4周。在我们的实践中,以2周一次迭代的频率,保持相对稳定的开发和交付的节奏。

    5、参考资料:
    《敏捷估计与规划》 Mike Cohn

    展开全文
  • 敏捷开发迭代开发

    2019-06-27 17:05:44
    敏捷开发迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...

    敏捷开发与迭代式开发是整体与局部的关系

     

    敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。敏捷开发过程中,只有开发团队,没有各个开发环节工种(分析师、设计师、架构师等)的划分,所有的工作都是团队会议明确、按照时间节点和任务节点交付。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式,目标是提高开发效率和响应能力。除了原则和实践,模式也是很重要的,多研究模式及其应用可以使你更深层次的理解敏捷开发。

    迭代开发:每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代。在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。迭代是敏捷开发中被划分出来的一个周期实现方式。可理解如下: 迭代一般指某版本的生产过程,包括从需求分析到测试完成; 版本一般指某阶段软件开发的结果,一个可交付使用的产品。迭代开发和敏捷开发都是弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。

     

    1、在项目初期先挑选系统核心架构的需求来实现,待系统核心架构完成后,再在系统核心架构的基础上不断的添加其他功能模块,通过累加开发的方式,来不断的完善系统,并在完善系统时,对系统的瑕疵或不足,不断的进行重构和改进设计工作。通过多个迭代的敏捷开发,并且每个迭代都会产生一个可使用的产品。这样一来,我们就会达到降低产品开发风险的目的。

     

    敏捷建模不可缺少,UML规范就是给我们提供建模标准的,建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通,通过画一两张图来代替几十甚至几百行的代码,建模成为简化软件和软件(开发)过程的关键,而且比代码更容易控制和改变。这一点对开发人员而言非常重要-它简单,容易发现出新的想法,随着你(对软件)的理解的加深,也能够很容易的改进。

    3、有目的的建模,开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,但是要特别强调,我们没有必要每次应用所有的模型,而应该针对系统的具体情况,挑选能够解决问题的模型,不应该毫无意义的建模。首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单和完整。

    4、并行创建模型,和团队他人一同开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候由于每种模型都有其长处和短处,没有一个模型能够完全满足建模的需要。例如你在收集需求时,你需要开发一些基本用例或用户素材,一个基本业务流程等。敏捷建模者会发现在任何时候,同时进行多个模型的开发工作,要比单纯集中于一个模型要有效率的多。

    5、持续测试和集成,每个迭代,我们都在做增加新功能和变更需求,产生新的版本,因此不断进行测试和集成,已达到可交付的产品,但是无论如何变更,模型都可以是最轻量级的持续改进,以保证最终的完整性和准确性。

     

    针对中大型的软件开发来说,用例驱动、架构为中心的,无论是从需求用例还是测试用例,都可以统一对应,保证过程的完整统一。敏捷开发是一个轻装前进的过程,每一个过程都只关注当前的任务,但是在开始之前,我们必须要高瞻远瞩,综合评定,无论是在一开始的架构模型还是开发过程中的每一个系统模型,都要有合适的取舍,但是也要有考虑可扩展,可变更,可迭代的过程。

     

     

    传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
    特别是前期阶段,设计的越完美,提交后的成本损失就越少。

    迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,
    最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

    螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

     

    敏捷开发优点:

     1、降低风险
      2、得到早期用户反馈
      3、持续的测试和集成
      4、使用变更
      5、提高复用性
    --------------------- 
    作者:ouyanghaitao 
    来源:CSDN 
    原文:https://blog.csdn.net/ouyanghaitao/article/details/84923309 

    展开全文
  • 从2006年开始,腾讯的研发规模开始膨胀,开发模式急需规范和标准化,到底走IPD(集成产品开发)还是Agile(敏捷)的开发路线,公司管理层也在为拿不定主意而犯愁,之后研发管理部开始与ThoughtWorks公司接触,逐渐将...

    原文链接:https://www.biaodianfu.com/tencent-agile.html

    从2006年开始,腾讯的研发规模开始膨胀,开发模式急需规范和标准化,到底走IPD(集成产品开发)还是Agile(敏捷)的开发路线,公司管理层也在为拿不定主意而犯愁,之后研发管理部开始与ThoughtWorks公司接触,逐渐将敏捷产品开发引入进来,并正式命名为TAPD(Tencent Agile Product Development)。

    接触是从一次3天15W的培训开始的,ThoughtWorks派来了一个4人讲师团队,由此也诞生了腾讯日后推行敏捷的第一批种子。接着总结腾讯本身是怎么样子的,有这样一个框架之后就搞一些团队去实践,通过实践以后再不断改进,本身也是一个不断迭代的过程。

    整个实施阶段大概分成几个阶段:

    试点期:组织很多专题研讨和内部培训,树立标杆,更大范围内进行培训。 推广期:内部建立一个顾问团队,开发一些扫盲的课程,不断的到一些团队里面去介绍去培训,让大家接受这些理念。 同样腾讯在推广敏捷的过程中也面临一些挑战:

    团队非常多,每个团队特点都不一样,比如规模不一样,应用方法不一样; 产品非常广,互联网上所有的产品腾讯几乎都有,这种多元化的产品它本身产品的研发模式会有一些不一样,那么敏捷、TAPD怎么样去适应这种多元化产品的研发; 敏捷在腾讯也是存在一个过程改进,这样就会存在一些不适应性,针对这种不适应性应该怎么样去做才能更好; 腾讯人员本身的素质也是参差不齐,每年校园招聘大概会招聘1000多个毕业生,这些毕业生从毕业到能上手工作,他们对敏捷的了解,融入到团队中都需要一个过程; 一些长周期的项目,比如QQ客户端,一个版本的发布可能要半年到1年的时间,像这样一个产品怎样去做敏捷开发,也许它就不适合敏捷开发。 正是由于这些挑战,才孕育出了独特的腾讯敏捷模式。以下为收集的一些资料整理:

    一、整体的框架结构

    简言之,腾讯的TAPD是吸收了XP+SCRUM+FDD三者特点的并行迭代开发模式,涉及范畴包括敏捷项目管理和敏捷软件开发。

    1、产品

    采用FDD,即产品特性开发驱动的一种模式,腾讯的产品会有一个明确的产品经理这样一个角色,他会负责整个产品,包括产品的验证、产品的方向、市场调研、用户调研等。FDD 模式是一种非常适合产品经理来对产品做一些滚动的要求,腾讯在产品设计上引入了类似FDD这样的模式,但是也不完全是FDD,只是参考FDD,所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。

    FDD的核心是面向产品的功能点,但这个功能点是从客户角度出发的,并不是从系统角度出来的。功能点是用一个短句描述出一个业务需求,而这个业务需求的粒度是按开发时间来衡量的(一般不超过两个星期)。特征与用例的相似之处是,两者都可以用短句(动宾短语)来描述;两者的不同之处在于,用例用UML的用例图来表示,而特征是用四色原型(类图)来表示。产品经理这个角色有点Scrum的Product Owner的味道。但产品特性和backlog相差甚远,因为产品特性只是一个动宾短语,而backlog却是一个完整的故事(story)。

    2、项目管理过程

    腾讯采取了SCRUM,但也不完全是SCRUM ,腾讯根据自己的特点去总结的一些实践,大概的项目管理过程同SCRUM的过程比较类似,包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。

    3、开发实践

    参考了很多XP的实践,就XP完整的实践来说会比较理想化,很多东西不一定在实际开发中能够采纳,所以腾讯也是采纳其中的某些实践,比如自动化测试和持续集成,通过这样的实践就能保证产品有一个快速发布的过程。

    二、腾讯的快速迭代过程

    一个完整的迭代过程 包括概念、设计、开发、测试和发布五个过程。

    在概念阶段,会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发,会制定一些产品发布的计划,比如产品在未来,某个迭代什么时候发布,要发布哪些产品特性,都是在这个阶段做的。 在设计阶段,会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验,比方产品在某个迭代的一个小迭代里面,可能会在一个团队里面先去体验,可能就会采取发布到公司某一个部门去体验,或者发布到整个公司范围去体验,它会是一个不断放大的一个过程。 在开发和测试阶段,更多的采取XP的一些实践,包括编码规范,代码走读,比如1周一次代码走读,构建持续集成的环境,包括自动化构建,自动化测试等,会有一些好的测试上的实践,如全员测试,就是将测试看成不仅仅是测试人员的工作,更多的是整个团队的工作,当然也包括这个产品的其他同事的工作,通过全员测试来激发大家对产品质量负责。 在发布阶段,腾讯采用的是灰度发布,同传统的软件发布不一样。项目中整个迭代过程就通过类似SCRUM模式去管理,如有每日晨会,如何建设团队氛围,统一的管理平台,每次迭代完成时的总结回顾等等,这属于项目管理的工作。 其中分析、设计、开发、测试、发布这五个过程可以内部再迭代,而且这五个过程不是分阶段开展的,即不是分析完了之后才设计,全部设计完了才开发,开发结束了才测试,测试通过了才发布。而是边分析边设计——在业务不复杂的情况下,这是可行的——边设计边开发,开发完一个功能就测试一个功能,同时开发下一个功能。

    还有一些基础的工作,如代码管理,版本管理,文档管理,异地开发管理,这些在腾讯的整个管理体系里面都包含的,还有会制定一些相关的规范,不过规范不是很强硬的要求每一个项目必须执行,更多的由团队自己选择,让他们根据自己团队的特点、规模去选择应该采取哪些实践。

    二、腾讯是如何做敏捷管理的?

    1、故事墙

    就是白板story wall,平时工作中很多团队都会使用,这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来,整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程,包括整个产品特性的过程。写在白板上比用Excel或者其它工具管理好,因为写在白板上让人感觉更紧迫、更正式、更一目了然,有一种别人在监督、在注视的感觉。

    2、每日晨会

    每个团队每天大概花15-30分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作。对Team而言这是检查进度、快速调整非常有效的形式。

    最早是通过白板的方式去做,就是每天项目经理组织团队成员对着白板,白板上体现项目的进展情况,通过会议可以很明确的知道昨天大家做到什么样子,今天大家计划做什么,最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题:

    对于一个20、30人的团队,每天要怎样做晨会,这是目前遇到的比较大的困惑; 晨会很容易形式化,究竟带来什么样的效率和效果,目前也在通过一些方式去研究,去探讨。 有一些形式上的呆板,刚开始做会觉得比较有意思,觉得这跟传统做法不一样,每天这样做并且做多了就感觉很枯燥,这也是面临一个挑战。 后来腾讯也做了一些改进,比如为了让成员的参与程度更强一些,包括形式上会更强一些,现在有些团队就会采取每个人轮流主持的方式,刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西,但是现在看来的话,感觉改进的还是不是很透。在腾讯内部有一个交流通信的软件,有些项目也开始不采用站起来开晨会的方式,觉得站起来效率也不高,就会通过即时通信软件每天去交流,最后由一个人去统一输出,这样能解决一些分布式团队的合作。所谓分布式团队就是这个团队中有些同事在这个大楼,有些同事是在那个大楼,通过这种实时交流的方式可以解决一些问题。

    3、规划游戏

    对敏捷的一种常见误解是不要计划,其实在敏捷的体系中不仅强调计划,甚至区分Release计划、Iteration计划和Task计划等多种不同粒度、不同时长的计划。规划游戏突出的是让用户代表参与,由用户代表评估用户故事/特性的优先级,开发人员评估任务的开发时间,由用户代表+项目经理+核心 成员三方共同排序、组合,确定本次迭代计划需要实现的特性列表。在腾讯用户代表就是产品经理。腾讯特别强调的是并行迭代,即多个版本并行,最大程度发挥资源的效率。Release(发布)可理解成当实现的产品特性累积到一定用户价值时的正式发布,它是比迭代更大的概念;迭代是在固定时间内开发特性的过程,Release一般包括多次迭代。

    4、时间盒

    在腾讯的产品研发中,产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次IPM会议,即本次迭代的计划会议,会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导,一起去敲定本次迭代要完成的任务,一旦任务敲定下来,本次迭代就会严格按照这个去落实执行。TimeBox反映了敏捷开发的节奏,即在固定时间内实现不固定特性的周期,抛开需求定义阶段,从设计-实现-测试到部署,在腾讯一般一至两周时间居多。

    5、产品演示

    提交测试前由开发人员演示实现的功能,产品经理到场Review是否符合当初的设想,避免接近发布时才反馈。

    6、迭代总结

    在每一个产品发布的时候都会有一个总结。具体的做法是,把做得好的、不好的总结出来,做得好的在下一次迭代发扬光大,做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加,包括项目的开发人员、测试人员、QA、项目经理、产品经理等,每个人都要去去总结他在上一个迭代中碰到了什么问题,通过便签纸的方式贴出来,项目经理实际上可以看成是Scrum Master ,包括站起来总结这样一些东西,包括我们下一次迭代继续发扬什么,必须要注意什么东西,最后就会得出一个excel的文档,包括上一个迭代中出的问题,具体的解决办法,都会有

    7、自运转团队

    早期的项目,为了能提高效率,项目经理希望每个角色都能全力以赴的提升自己的效率,于是自己承担起来大量沟通和推进的工作,那个时候的都在被PM推着走,一旦PM休假,项目基本没有什么产出,当时去了以后,发现问题很严重,团队的主动性必须被调动起来才行。

    自运转团队,是将需求开发过程详细划分成开发的各环节,并明确每个环节的负责人,由该负责人来驱动上下游的负责人,而不再由项目经理来连接各个环节,再配合上高效的项目协助工具平台,实现开发过程自运转。这时项目经理则由指挥者变成服务者,观察环节之间产生的瓶颈,并及时采取措施扫除障碍。

    三、腾讯是如何进行敏捷开发的?

    1、用户研究

    如何加强用户的参与度,这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析,分析用户在这个产品上整个体验的过程是怎样的,通过后台的数据可以看到整个活动的曲线,同时CE也可以通过一些科学的手段去保证,包括市场调研、用户研究、数据挖掘、产品体会等,这就是通过一些对用户反馈、用户观察的工具去配合去对用户做研究。比如QQ拍拍的一个用户的研究,我们可以到现场去做的一个调研,经常会由产品经理和用户研究人员到用户的实际办公地点进行调研,做一天的反馈,通过观察用户一天是如何使用你的产品,配合一些相关的工具去科学的分析。因为互联网是非常强调同用户的这种反馈的,腾讯有自己内部的一个CE反馈平台,在这个平台上可以收集到所有用户的反馈,产品经理可以每天都会看到他所负责的产品有哪些反馈,包括内部的、外部的,然后他就可以根据这些反馈对产品进行一些快速的调整,包括开发一些什么样的产品特性,内部同事也可以踊跃的在平台上反馈,内部同事本身就是QQ用户。

    2、故事卡片/故事墙/特征列表

    StoryCard是XP中推荐的需求定义方法,要求符合Invest和Moscow原则;故事墙则用于跟踪故事卡片的 变化状态,而特征列表是Tencent一直沿用的需求表达形式,在腾讯的TAPD工具中已经实现了类似ThoughtWorks 的Mingle的故事卡片管理功能,对于需求跟踪而言这是不错的方法,一目了然。

    3、结对编程

    理论上结对编程可以提高代码的质量,而且并不会降低开发效率,但腾讯的业务繁忙,资源上不允许两人结对。但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序,旁边还有一个人,同时记录编写过程、编写思路、碰到的问题、自己的想法,编写完以后一段时间他们会交换一下,就是互相交换着进行编程,这是一个结对编程的一个过程。

    4、测试驱动

    “测试驱动开发”在腾讯执行地并不太好,腾讯的产品以Web形式居多、业务逻辑相对简单,C++下的单元测试有些力不从心。相反自动化测试在腾讯比较盛行,因为有测试部门专门的自动化测试Team在推动,而且链接的是正式生产环境,可以即时反映产品当前的状态。

    5、持续集成 持续集成可以降低发布前集成阶段的难度与成本,腾讯的自动化构建系统推行的比较早,覆盖了大多数产品,而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。作为加快产品的发布的能力,持续集成在以下几个方面作用明显。

    自动编译输出报告,维护代码可运行,及时暴露风险,降低集成成本。 Dailybuild日构建系统,让产品经理、测试人员可以尽早进行体验和测试。 作为一个自动化系统,利用静态代码检查、单元测试报告等手段为团队提供报告,促进编码质量不断得到重视,降低缺陷解决成本、缩短解决时间。 6、灰度发布

    灰度发布是腾讯的又一创新,它将产品试用扩大到海量用户一端,在小范围及时吸取用户反馈,分析用户行为和喜好,持续修正自己产品的功能体验。在互联网行业,灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能,让他们先来体验新功能、新特性。通过用户反馈、数据运营的手段及早获得反馈,及时改进。以此方式,既可以降低发布风险,也可以提升发布频率,加快发布节奏。

    简单说就是,将一项业务不是一下发布给所有用户,而是分批分期的发布,目的有两个方面,一是减轻服务器压力,二是期间可以在小范围收集到用户的反馈,如果业务出现问题,不会让大范围用户受到影响。随着经验的累计,我们有了许多种灰度策略和方法,灰度也有了更多的应用,甚至引入到了测试环境,即选择一些热心用户,将功能首先发布给他们,通过他们的使用,来帮助进行一些现网测试,这使得一些难于模拟的测试场景变得简单,测试人员的压力大大降低;更重要的用户是最好的测试人员,测试结果更加真实;同时他们也享受到了优先体验的特权,可谓一举三得。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证4小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。

    7、发布汽车

    过于频繁的发布会打破团队节奏,有效的发布管理是必不可少的,根据业务特点,我们通常会采用三种发布模式,我们管它叫“发布汽车”。

    班车模式:像班车一样,固定周期进行,比如每两周发布一次,这周比较适合特性规划比较好的产品,比如QQ客户端基本每个月都会发布一个版本。 的士模式:与QQ客户端不同,QQServer作为一个平台,它的需求来源非常多,因此它采用多线并行的方式,根据需求来源分成十多个子项目,根据每个子项目如果想要发布,就像打的一样随叫随发布。他的好处是快,但是协调发布的成本是比较高的,比作班车花钱要多。 警车模式:顾名思义可以不按法规来开车,因此对于一下特别紧急的需求或运营事件,必须采用警车这种模式,紧急发布,但这样做成本更高,会把交通秩序搞乱,开发节奏打破。 8、重构

    好的代码不是设计出来的,而是重构出来的。

    四、总结

    当然流程和开发方法确定了还远远不够,更难的是如何将它推动落地。首先腾讯组织开发了承载敏捷思想的TAPD项目管理工具,它类似 ThoughtWorks的Mingle;然后推出了敏捷能力模型,类似CMM成熟度模型一样对Team评级加以引导;同时还推出了敏捷指数排行榜形成竞争,营造你追我赶的声势氛围。后期会针对TAPD再做一次讲解,尽情期待~

    从某个渠道了解到,TAPD的原型是:http://www.jetbrains.com/youtrack/index.jsp,果然是强大的山寨帝国啊~~~

    展开全文
  • 敏捷开发及快速迭代

    2019-06-17 02:40:00
    2019独角兽企业重金招聘Python工程师标准>>> ...

    1、产品

      采用 FDD,即产品特性开发驱动的一种模式,腾讯的产品会有一个明确的产品经理这样一个角色,他会负责整个产品,包括产品的验证、产品的方向、市场调研、用户调研等。FDD 模式是一种非常适合产品经理来对产品做一些滚动的要求,设计上引入了类似 FDD 这样的模式,但是也不完全是 FDD,只是参考 FDD,所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。

    FDD 的核心是面向产品的功能点,但这个功能点是从客户角度出发的,并不是从系统角度出来的。功能点是用一个短句描述出一个业务需求,而这个业务需求的粒度是按开发时间来衡量的(一般不超过两个星期)。特征与用例的相似之处是,两者都可以用短句(动宾短语)来描述;两者的不同之处在于,用例用 UML 的用例图来表示,而特征是用四色原型(类图)来表示。产品经理这个角色有点 Scrum 的 Product Owner 的味道。但产品特性和 backlog 相差甚远,因为产品特性只是一个动宾短语,而 backlog 却是一个完整的故事(story)。

    2、项目管理过程

      采取了 SCRUM 但也不完全是 SCRUM ,根据自己的特点去总结的一些实践,大概的项目管理过程同 SCRUM 的过程比较类似,包括每天的晨会、迭代、timebox、每个迭代完成的时候会有 showcase、回顾总结等。

    3、开发实践

      参考了很多 XP 的实践  就 XP 完整的实践来说会比较理想化,很多东西不一定在实际开发中能够采纳.其中的某些实践,比如自动化测试和持续集成,通过这样的实践就能保证产品有一个快速发布的过程。

    一个完整的迭代过程包括概念、设计、开发、测试和发布五个过程。

    在概念阶段,会采用 FDD 里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发,会制定一些产品发布的计划,比如产品在未来,某个迭代什么时候发布,要发布哪些产品特性,都是在这个阶段做的。在设计阶段,会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验,比方产品在某个迭代的一个小迭代里面,可能会在一个团队里面先去体验,可能就会采取发布到公司某一个部门去体验,或者发布到整个公司范围去体验,它会是一个不断放大的一个过程。在开发和测试阶段,更多的采取 XP 的一些实践,包括编码规范,代码走读,比如 1 周一次代码走读,构建持续集成的环境,包括自动化构建,自动化测试等,会有一些好的测试上的实践,如全员测试,就是将测试看成不仅仅是测试人员的工作,更多的是整个团队的工作,当然也包括这个产品的其他同事的工作,通过全员测试来激发大家对产品质量负责。在发布阶段,采用的是灰度发布,同传统的软件发布不一样。项目中整个迭代过程就通过类似 SCRUM 模式去管理,如有每日晨会,如何建设团队氛围,统一的管理平台,每次迭代完成时的总结回顾等等,这属于项目管理的工作。

    其中分析、设计、开发、测试、发布这五个过程可以内部再迭代,而且这五个过程不是分阶段开展的,即不是分析完了之后才设计,全部设计完了才开发,开发结束了才测试,测试通过了才发布。而是边分析边设计——在业务不复杂的情况下,这是可行的——边设计边开发,开发完一个功能就测试一个功能,同时开发下一个功能。

    还有一些基础的工作,如代码管理,版本管理,文档管理,异地开发管理,这些在整个管理体系里面都包含的,还有会制定一些相关的规范,不过规范不是很强硬的要求每一个项目必须执行,更多的由团队自己选择,让他们根据自己团队的特点、规模去选择应该采取哪些实践。

    如何做敏捷管理的?

    1、故事墙

    就是白板 story wall,平时工作中很多团队都会使用,这些团队会把每天开发的一些产品特性采用 story 的方式每天都在白板里面展示出来,整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程,包括整个产品特性的过程。写在白板上比用 Excel 或者其它工具管理好,因为写在白板上让人感觉更紧迫、更正式、更一目了然,有一种别人在监督、在注视的感觉。

    2、每日晨会

    每个团队每天大概花 15-30 分钟,回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作。对 Team 而言这是检查进度、快速调整非常有效的形式。

    最早是通过白板的方式去做,就是每天项目经理组织团队成员对着白板,白板上体现项目的进展情况,通过会议可以很明确的知道昨天大家做到什么样子,今天大家计划做什么,最早的时候每个成员都是口头汇报的。实践一段时间就发现了一些问题:

    对于一个 20、30 人的团队,每天要怎样做晨会,这是目前遇到的比较大的困惑;晨会很容易形式化,究竟带来什么样的效率和效果,目前也在通过一些方式去研究,去探讨。有一些形式上的呆板,刚开始做会觉得比较有意思,觉得这跟传统做法不一样,每天这样做并且做多了就感觉很枯燥,这也是面临一个挑战。一些改进办法,比如为了让成员的参与程度更强一些,包括形式上会更强一些,现在有些团队就会采取每个人轮流主持的方式,刚开始晨会的时候我们也会通过一些好玩的东西去刺激一下某些东西,但是现在看来的话,感觉改进的还是不是很透。有些项目也开始不采用站起来开晨会的方式,觉得站起来效率也不高,就会通过即时通信软件每天去交流,最后由一个人去统一输出,这样能解决一些分布式团队的合作。所谓分布式团队就是这个团队中有些同事在这个大楼,有些同事是在那个大楼,通过这种实时交流的方式可以解决一些问题。

    3、规划游戏

    对敏捷的一种常见误解是不要计划,其实在敏捷的体系中不仅强调计划,甚至区分 Release 计划、Iteration 计划和 Task 计划等多种不同粒度、不同时长的计划。规划游戏突出的是让用户代表参与,由用户代表评估用户故事/特性的优先级,开发人员评估任务的开发时间,由用户代表+项目经理+核心成员三方共同排序、组合,确定本次迭代计划需要实现的特性列表。用户代表就是产品经理。强调的是并行迭代,即多个版本并行,最大程度发挥资源的效率。Release(发布)可理解成当实现的产品特性累积到一定用户价值时的正式发布,它是比迭代更大的概念;迭代是在固定时间内开发特性的过程,Release 一般包括多次迭代

    4、时间盒

    在产品研发中,产品的每一个迭代都有一个明确的时间盒。在每一次迭代开始的时候会召开一次 IPM 会议,即本次迭代的计划会议,会议中团队中的所有成员包括产品人员、开发人员、项目经理、总监、部门领导,一起去敲定本次迭代要完成的任务,一旦任务敲定下来,本次迭代就会严格按照这个去落实执行。TimeBox 反映了敏捷开发的节奏,即在固定时间内实现不固定特性的周期,抛开需求定义阶段,从设计-实现-测试到部署,一般一至两周时间居多。

    5、产品演示

    提交测试前由开发人员演示实现的功能,产品经理到场 Review 是否符合当初的设想,避免接近发布时才反溃

    6、迭代总结

    在每一个产品发布的时候都会有一个总结。具体的做法是,把做得好的、不好的总结出来,做得好的在下一次迭代发扬光大,做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加,包括项目的开发人员、测试人员、QA、项目经理、产品经理等,每个人都要去去总结他在上一个迭代中碰到了什么问题,通过便签纸的方式贴出来,项目经理实际上可以看成是 Scrum Master
    ,包括站起来总结这样一些东西,包括我们下一次迭代继续发扬什么,必须要注意什么东西,最后就会得出一个 excel 的文档,包括上一个迭代中出的问题,具体的解决办法,都会有

    7、自运转团队

    早期的项目,为了能提高效率,项目经理希望每个角色都能全力以赴的提升自己的效率,于是自己承担起来大量沟通和推进的工作,那个时候的都在被 PM 推着走,一旦 PM 休假,项目基本没有什么产出,当时去了以后,发现问题很严重,团队的主动性必须被调动起来才行。

    自运转团队,是将需求开发过程详细划分成开发的各环节,并明确每个环节的负责人,由该负责人来驱动上下游的负责人,而不再由项目经理来连接各个环节,再配合上高效的项目协助工具平台,实现开发过程自运转。这时项目经理则由指挥者变成服务者,观察环节之间产生的瓶颈,并及时采取措施扫除障碍。

    三、如何进行敏捷开发的?

    1、用户研究

    如何加强用户的参与度,这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析,分析用户在这个产品上整个体验的过程是怎样的,通过后台的数据可以看到整个活动的曲线,同时 CE 也可以通过一些科学的手段去保证,包括市场调研、用户研究、数据挖掘、产品体会等,这就是通过一些对用户反愧用户观察的工具去配合去对用户做研究。比如  一个用户的研究,我们可以到现场去做的一个调研,经常会由产品经理和用户研究人员到用户的实际办公地点进行调研,做一天的反馈,通过观察用户一天是如何使用你的产品,配合一些相关的工具去科学的分析。因为互联网是非常强调同用户的这种反馈的,自己内部的一个 CE 反馈平台,在这个平台上可以收集到所有用户的反馈,产品经理可以每天都会看到他所负责的产品有哪些反馈,包括内部的、外部的,然后他就可以根据这些反馈对产品进行一些快速的调整,包括开发一些什么样的产品特性,内部同事也可以踊跃的在平台上反馈,内部同事本身就是 用户。

    2、故事卡片/故事墙/特征列表

    StoryCard 是 XP 中推荐的需求定义方法,要求符合 Invest 和 Moscow 原则;故事墙则用于跟踪故事卡片的变化状态,而特征列表是沿用的需求表达形式,在 TAPD 工具中已经实现了类似 ThoughtWorks 的 Mingle 的故事卡片管理功能,对于需求跟踪而言这是不错的方法,一目了然。

    3、结对编程

    理论上结对编程可以提高代码的质量,而且并不会降低开发效率,但如果业务繁忙,资源上不允许两人结对。但是在一些团队里面还是一直在尝试着做结对编程的工作。一个在编写程序,旁边还有一个人,同时记录编写过程、编写思路、碰到的问题、自己的想法,编写完以后一段时间他们会交换一下,就是互相交换着进行编程,这是一个结对编程的一个过程。

    4、测试驱动

    “测试驱动开发”在执行地并不太好,产品以 Web 形式居多、业务逻辑相对简单,C++下的单元测试有些力不从心。相反自动化测试比较盛行,因为有测试部门专门的自动化测试 Team 在推动,而且链接的是正式生产环境,可以即时反映产品当前的状态。

    5、持续集成
    持续集成可以降低发布前集成阶段的难度与成本,自动化构建系统推行的比较早,覆盖了大多数产品,而且正在朝自动化构建-自动化测试-自动化发布三者协同的目标迈进。作为加快产品的发布的能力,持续集成在以下几个方面作用明显。

    自动编译输出报告,维护代码可运行,及时暴露风险,降低集成成本。Dailybuild 日构建系统,让产品经理、测试人员可以尽早进行体验和测试。作为一个自动化系统,利用静态代码检查、单元测试报告等手段为团队提供报告,促进编码质量不断得到重视,降低缺陷解决成本、缩短解决时间。

    6、灰度发布

    灰度发布是一创新,它将产品试用扩大到海量用户一端,在小范围及时吸取用户反馈,分析用户行为和喜好,持续修正自己产品的功能体验。在互联网行业,灰度发布已经成为最重要的发布控制手段。有时我们希望通过向小部分用户开发新功能,让他们先来体验新功能、新特性。通过用户反愧数据运营的手段及早获得反馈,及时改进。以此方式,既可以降低发布风险,也可以提升发布频率,加快发布节奏。

    简单说就是,将一项业务不是一下发布给所有用户,而是分批分期的发布,目的有两个方面,一是减轻服务器压力,二是期间可以在小范围收集到用户的反馈,如果业务出现问题,不会让大范围用户受到影响。随着经验的累计,我们有了许多种灰度策略和方法,灰度也有了更多的应用,甚至引入到了测试环境,即选择一些热心用户,将功能首先发布给他们,通过他们的使用,来帮助进行一些现网测试,这使得一些难于模拟的测试场景变得简单,测试人员的压力大大降低;更重要的用户是最好的测试人员,测试结果更加真实;同时他们也享受到了优先体验的特权,可谓一举三得。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证 4 小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。

    7、发布汽车

    过于频繁的发布会打破团队节奏,有效的发布管理是必不可少的,根据业务特点,我们通常会采用三种发布模式,我们管它叫“发布汽车”。

    班车模式:像班车一样,固定周期进行,比如每两周发布一次,这周比较适合特性规划比较好的产品,比如 QQ 客户端基本每个月都会发布一个版本。

    的士模式:与 QQ 客户端不同,QQServer 作为一个平台,它的需求来源非常多,因此它采用多线并行的方式,根据需求来源分成十多个子项目,根据每个子项目如果想要发布,就像打的一样随叫随发布。他的好处是快,但是协调发布的成本是比较高的,比作班车花钱要多。

    警车模式:顾名思义可以不按法规来开车,因此对于一下特别紧急的需求或运营事件,必须采用警车这种模式,紧急发布,但这样做成本更高,会把交通秩序搞乱,开发节奏打破。

    8、重构

    好的代码不是设计出来的,而是重构出来的。

    四、总结

    当然流程和开发方法确定了还远远不够,更难的是如何将它推动落地。首先腾讯组织开发了承载敏捷思想的 TAPD 项目管理工具,它类似 ThoughtWorks 的 Mingle;然后推出了敏捷能力模型,类似 CMM 成熟度模型一样对 Team 评级加以引导;同时还推出了敏捷指数排行榜形成竞争,营造你追我赶的声势氛围。

    转载于:https://my.oschina.net/liupengjun/blog/756237

    展开全文
  • 敏捷开发-快速迭代

    2013-05-08 19:57:45
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 敏捷开发 迭代流程

    2011-06-12 07:46:00
    敏捷是一柄双刃剑,用的好能极大的提升开发效率,适应需求的变化!用的不好则会导致项目的混乱。现在很多公司都说自己在用敏捷开发,很多程序员也说自己懂敏捷开发!简单的认为敏捷就是站立会议,... 敏捷开发提倡迭代
  • 从传统开发模式的思维,转换到敏捷迭代开发肯定会有很多的疑问,这些疑问通常是公司管理层对敏捷迭代开发抱怀疑态度,或者没有信心的主要原因,因此,在本文中,我以问答的方式,试图去整理一下自已对敏捷迭代...
  • 软件研发中敏捷开发迭代开发的异同 在讲敏捷开发之前,先了解几个常见的软件研发模式 瀑布模型:瀑布模型的软件研发过程与软件生命周期一致,由文档驱动,两相邻之间存在因果关系,需要对阶段性的产品进行review。...
  • 敏捷开发-迭代会议

    2016-04-19 00:33:42
    敏捷开发迭代会议,主要是挑出产品设计和功能问题,保证迭代版本的产品原型完整性、正确性、合理性。如果产品大致功能没有多大问题,留下些小问题,那么可以进行项目拆分、工时估算。(一个细节要提醒的,产品必须在...
  • 联系信箱:feixiaoxing @163.com】 软件开发有很多的模式,一般认为有三种模式,分别是瀑布、迭代开发、敏捷开发。瀑布模型是最基本的开发方式,它有严格的处理流程,分别是需求、设计、开发、测试、交付。瀑布...
  • 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把...
  • 一、迭代计划会 整个团队通过举行迭代计划会议来为下一轮迭代做计划。 什么人参加迭代计划会议?——客户及团队中的所有开发人员 迭代计划会的内容是什么? 讨论故事 从故事中分解任务 开发人员承担每个职务的...
  • 2、迭代计划会议 重新讨论、确定本次迭代需要实现的Story,达成共同理解; 若有必要的话,则继续细化Story; 对Story进行优先级排序; 开发、测试、资料人员认领任务,估计工作量并做出承诺,这是敏捷的重要...
  • 敏捷开发迭代开发

    2018-04-22 23:09:48
    2.敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。二、区别:1.性质不同:迭代开发是软件开发的生命周期模型,是一种开发过程;敏捷开发是多种软件开发项目管理方法的集合,是一...
  • 在这敏捷开发横行的时代中,人人都在谈敏捷,人人都在谈迭代,似乎大家好像都尝到了敏捷带来的甜头,记得有一次跟朋友吃饭,说他们现在的项目用敏捷开发,每个迭代都能看到不断完善的产品,非常有成就感,客户的满意...
  •   迭代0是指在启动敏捷开发前的准备工作阶段,迭代0一般的时间长度不超过所选择的迭代周期。 对于看板类做法,如果没有明确的迭代周期,那么建议不超过2周,为方便,将看板类的准备工作阶段仍然称为迭代0。 ...
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...
  • 迭代计划会议(不超过1个小时) 1. 需求人员与测试人员对将要到来的迭代的故事进行精化,添加验收条件,并对验收点着重表现。每一个故事进行冻结。(提前准备) 2. 迭代计划会在每个迭代的第一天召开,目的是...
1 2 3 4 5 ... 20
收藏数 37,942
精华内容 15,176
关键字:

敏捷开发 迭代计划