敏捷开发问题_项目经理在敏捷开发中的作用敏捷开发 - CSDN
  • 有次去西安百度创业园谈项目,甲方直接丢了一句,我们需要敏捷开发。我们:放心,肯定高质量、短周期的交期。敏捷需要面对面沟通,随时沟通,计划紧凑,总之就是快准狠。 1、敏捷 敏捷软件开发宣言:个体和互动...

    今天学习了一波腾讯云里面的一篇文章:https://cloud.tencent.com/developer/article/1004881,你大概走了假敏捷:认真说说敏捷的实现和问题。

    有次去西安百度创业园谈项目,甲方直接丢了一句,我们需要敏捷开发。我们:放心,肯定高质量、短周期的交期。敏捷需要面对面沟通,随时沟通,计划紧凑,总之就是快准狠。

    1、敏捷

    敏捷软件开发宣言:个体和互动高于流程和工具;工作的软件高于详尽的文档;客户合作高于合同谈判;响应变化高于遵循计划;

    敏捷遵循的原则:

    • 目标:持续不断地早交付有价值的软件使客户满意;
    • 随时应对需求变化;
    • 短周期交付可工作的软件;
    • 业务与开发相互合作;
    • 面对面交谈实现高效信息传递;
    • 进度是首要度量标准;
    • 减少不必要的工作量;

    去文档,去流程,高效沟通和合作。去文档,敏捷管理者需要维护更为精细的需求池;去流程,口头沟通成为常态,对团队的耦合度要求更高。

    agile:迅速,敏捷。这是敏捷的理念也是精髓:迅速响应需求,快速反馈结果。

    sprint:字面意思是短跑冲刺,一个开发阶段被认为是一次冲刺,一个个 sprint 首位相连,构成一个项目。也可以理解为短期目标,短周期计划。

    Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。毕竟进展是最首要的度量标准;

    scrum 即为这样一种方式,大家一拥而上,团队是球员,球是产品目标,人员环环相扣,围绕着产品目标进行工作。这里面多少有点“统筹法”的影子,人员深入协作以达到最优化效果。统筹协作。

    Product Backlog:

    backlog 即需求池。待办事项列表。其内容包含:1.待开发任务。2.任务优先级。

    敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人(一般是产品经理)对所有待开发事项有深入了解,并且能够把待开发事项分解成更为细致的任务。众所周知,快速的开发需要责任到人,然后最有效的督促就是每天都有详细任务表,省得有偷懒的伙计。所以整个下来,会有一个详细的需求列表,每天都是deadline。

    story board:在开发中,故事板展现所有需求的工作流。

    burn down chart:燃尽图,一个 sprint 内,人/时是一个比较固定的值。在这个时间框架充分安排开发任务,每天进行时间结算,绘制时间燃尽图。项目成员通过燃尽图获知时间进展,若项目燃尽所用时间与预期时间契合,则需求时间预估和安排合理,若不契合则需要在下一个 sprint 进行调整。

    这种燃尽图就类似下图,

     

    2、 敏捷工具

    随着敏捷在行业内的不断融入,各种工具产品层出不穷。国外jira、redmine,Axosoft ,国内的leangoo 、禅道,三大家则都有自研的工具,百度的icafe,阿里的aone,我鹅自研tapd。

    项目协同软件还是很必须的,现在科普一下自己相关的工具

    clearcase: IBM Rational, 商用,贵

    perforce: P4,免费版支持5个license, 其他商用版

    cvs: 开源,旧

    subversion: 中小型公司常用,集中管控

    git: 开源,分布式,最新,代码托管于github,使用于非集中办公的情况(故开源软件开发多选用它)

    http://www.kuqin.com/shuoit/20141213/343854.html 【git开发流程好文】

    -------------------------------------------

    协同开发工具

    Source Control: CVS/SVN 
    Bug Tracking: Bugzilla, Trac, Roundup 
    交流工具: maillist, IM, Forum, IRC, Wiki 
    协同开发平台: sourceforge, BaseCamp

    禅道, redmine: 

    ---------

    Basecamp是37signals公司旗下的一款非常流行的基于云服务的项目管理软件。以简单易用和颠覆性的创新而出名。 Basecamp提供了消息板,待办事宜,简单调度,协同写作,文件共享。而不是甘特图,炫丽的曲线图,和繁重的电子表格。目前,成千上万的人同意这是一种更好的方式。来自的Farhad Manjoo说:“Basecamp代表了Web软件的未来。”

    禅道是第一款国产的优秀开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体,是一款功能完备的项目管理软件,完美地覆盖了项目管理的核心流程。先进的管理思想,合理的软件架构,简洁实效的操作,优雅的代码实现,灵活的扩展机制,强大而易用的api调用机制,多语言支持,多风格支持,搜索功能,统计功能——这一切,您通过禅道,都可以拥有!禅道在手,项目无忧!
    禅道百科地址:http://baike.baidu.com/view/7881832.htm

    Redmine是用Ruby开发的基于web的项目管理软件,是用ROR框架开发的一套跨平台项目管理系统,据说是源于Basecamp的ror版而来,支持多种数据库,有不少自己独特的功能,例如提供wiki、新闻台等,还可以集成其他版本管理系统和BUG跟踪系统,例如SVN、CVS、TD等等。这种 Web 形式的项目管理系统通过“项目(Project)”的形式把成员、任务(问题)、文档、讨论以及各种形式的资源组织在一起,大家参与更新任务、文档等内容来推动项目的进度,同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。

    Redmine百科地址:http://baike.baidu.com/view/2228665.htm

    上面来自:https://www.cnblogs.com/vigarbuaa/p/4317266.html

    看了半天,没瞅见maven,

    Maven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设,Maven使用标准的目录结构和默认构建生命周期。

    在多个开发团队环境时,Maven可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单,并且可重复使用,Maven让开发人员的工作更轻松,同时创建报表,检查,构建和测试自动化设置。

    第一次使用的工具就是这个,当时就知道可以版本管理,汗颜。

    敏捷工具的伟大作用,就是显而易见的需求、实时更新的计划、优先级明确的安排、详细的待开发列表。协同,最方便的是协同。

    在人保驻场工作那会,最大的感触就是到处都是的计划、任务、预估时间、燃尽图,看的人亚历山大呀。像我看见领导都脑波是燃尽图,根本不需要这种吧!但是变成老油条的时候,还是很需要的。

    3、设计师进入敏捷

    我也算是做设计出身的,人保的移动报价器就是我的第一个整体做设计的作品。那是龙哥辛勤教导才出来的正常设计。设计进入敏捷,就是每天都有计划、每天都有进度、每天都有沟通、每天都是deadline。要知道,你需要不停的改,不停,不停,不停。

    4、敏捷需要需求文档

    从短期收益上看,文档对于敏捷开发是非必须品,并且很有可能会拖慢进度。在一个 sprint 中,口头沟通显然效率更高,每个人都有精确到工时的任务,没人有等待文档更新的时间。强调文档就等于放弃灵活性。

    从长期和宏观上看,文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本,同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲,文档让后续的工作效率更高。

    几个重要的文档:产品文档、概要设计、接口文档

    产品文档:1.需求;2.加入日期;3.开发版本;4.呈现和详细方案

    在非敏捷开发流程中,文档在评审会后完善并更新,形成一个给研发参考的实现目标。在敏捷中,需求本身在 sprint 周期内不断完善,你可以在一个 sprint 之后将文档补全。

    概要设计:敏捷的常规迭代中,概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷,这个落你身上了。

    接口文档:必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档,如果你们没有云端存储的能力,至少咱们人手一份,定期更新。

    在和客户对接过程中发现,文档真是个好东西,就像区块链一样,有着你不可篡改的规矩。有时候客户不断的改动需求,还就说你没按计划,所以,白纸黑字最好的证据。如果说可以灵活变动需求,那看钱也是能实现的。

    文档最大的好处就是有据可寻。

    5、大项目的敏捷

    既然是大项目,需求确定至关重要。所以先要多次沟通需求(此处重点)。团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”,产品经理使用不断完善的原型同团队进(tao)行( jia )沟( huan )通( jia )。在最后的产品评审之前,至少敲定产品框架和大部分细节。这次评审邀请项目成员和所有协同团队,除了敲定的产品功能,技术上需要得到一些初步结论(比如“能不能做”。事实上,产品经理应该在产品规划阶段就知会协同团队将要做什么)。接下来进行概要设计(新产品、重构、重大新功能必须进行概要设计)。技术评审邀请除设计以外的项目成员和协同团队参会。

    首次接项目,遇到过一个奇葩,需求确定多次,这个不懂技术的客户,最后不要了。丢了一句,不符合需求。当时想一嘴巴子扇死他。后来也就咬咬牙,收手了。所以,多次确认需求,多次确认需求,无论项目大小,这是填坑最好的方式。

    大项目敏捷中:

    1.将 deadline 之前的时间分解为多个 sprint 。(deadline 之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )

    2.将所有需求分解成任务,开一次全局 scrum 会。预估时间之后,分散任务到各个 sprint 中。在时间较紧的情况下,sprint 的容量就要相应增加。

    3.进入敏捷流程,常规 scrum 会、站会,燃尽图,故事版。未完成任务在 scrum 会上重新预估时间,滚入新 sprint 内,以此类推(按时完成 sprint 内的任务是目标。实在不行我们还有“出血时间”呢)

    4.别忘了文档。虽然被推崇备至,但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活,而造成敏捷问题的根源也正是灵活。

    文末再总结本文重点:

    1.敏捷是一种流程、方法、理念,甚至信仰。

    2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作,线上的的流转如果削弱了这种配合性,反倒背离了敏捷的本意。实际上只要有白板纸张和笔,你的团队就能开始敏捷。

    4.我们敏捷了,不是不要文档了。在外部交流多、世代跨度长的情况下,文档的必要性显而易见。长期的面对面沟通最终会导致低效,这也是敏捷缺陷的根源。

    5.设计师可以完全介入到敏捷流程中,只需要做一些细心的安排。

    6.大项目开发中可以走敏捷,具体问题具体分析,需要根据项目特点制定敏捷计划。

    敏捷开发总结出来果然就是快、准、狠。

    展开全文
  • 敏捷开发中的问题

    2017-08-07 10:17:50
    有三种方式去演化我们的系统。1.改变实现或者增加新的实现来替换旧... 但是,这仅仅是开发类库的人要考虑的问题,因为他无法去改变exe文件。  反面教材:微软系统中的Ex结尾的函数一大堆,就是相当于扩展了原有的系

    有三种方式去演化我们的系统。
    1.改变实现或者增加新的实现来替换旧的。
    2.改变接口。
    3.增加接口。

     

    一.先说说我对多态的理解:
        多态大部分都是运行时多态,也就是说已经形成了.exe文件或者.jar文件后,仍然有办法去影响代码的运行!
        但是,这仅仅是开发类库的人要考虑的问题,因为他无法去改变exe文件。

        反面教材:微软系统中的Ex结尾的函数一大堆,就是相当于扩展了原有的系统。相当丑陋。微软为了给函数增加新的参数,很痛苦地设计了很多带有length的结构体。

    二.现在说一下大部分的开发状态。
       重点:大部分的开发状态是类库和客户端代码都可以改的,在这个前提下考虑多态有什么用处或许更有意义。下面论述一下:
    前提条件:所有的源代码都是可以修改的。

    1.改变实现

         改变实现有几种方式,一种是用修改源代码。一种是增加源代码。

      a. 修改源代码的方式:    过多修改源代码,将造成之前的代码丢失。

      b. 增加新的代码,最小限度地修改源代码。

    方法a:按照面向对象设计原则:系统设计的一大目标是:可以扩展的,但是不可以修改的,这种想法应该直接被否决

    方法b:这种方法有更大的灵活性。前提条件是接口定义要好。能满足可扩展性。

          ::不要修改函数,试着去增加函数。

          ::不要修改类,试着去增加类。 

    2.改变接口。

      在改变接口方面,多态不仅无能为力,并且会增加耦合度。使得改变一个父类的接口后,子类的接口都必须重新考虑。

    按照照面向对象设计原则:系统设计的一大目标是:可以扩展的,但是不可以修改的,这种想法应该直接被否决)

    3.增加接口。

      增加新的接口,似乎跟多态没有什么关系。其实还是有关系的。这个需要参照com原理。

     

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

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属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扫盲篇
    百度百科
    敏捷开发 模型讲解

    展开全文
  • 敏捷开发流程总结

    2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...

    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到管中窥豹的目的。
    
    敏捷开发宣言——
    个体和交互 胜过 过程和工具
    可以工作的软件 胜过 面面俱到的文档
    客户合作 胜过 合同谈判
    响应变化 胜过 遵循计划
    虽然右项也有价值,但是我们认为左项具有更大的价值。

    以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践:
    Iteration
    迭代开发。可以工作的软件胜过面面俱到的文档。因此,敏捷开发提倡将一个完整的软件版本划分为多个迭代,每个迭代实现不同的特性。重大的、优先级高的特性优先实现,风险高的特性优先实现。在项目的早期就将软件的原型开发出来,并基于这个原型在后续的迭代不断晚上。迭代开发的好处是:尽早编码,尽早暴露项目的技术风险。尽早使客户见到可运行的软件,并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
    IterationPlanningMeeting
    迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
    在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,ta需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
    站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
    结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
    持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
    总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
    演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
    重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
    测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    敏捷方法反思:
    自己参与的敏捷开发项目总的来说不是很成功,这可能也是业界遇到的通病:
    1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
    2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
    3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚本也多流于形式,测不出深层次的问题。
    4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
    5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
    6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
    7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • 什么是敏捷开发

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...
  • 敏捷开发的一些问题 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,...
  • 敏捷开发和迭代开发

    2019-06-27 17:05:44
    敏捷开发与迭代式开发是整体与局部的关系 敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试...
  • 无论在培训、咨询中,还是在日常博客、邮件、QQ群中,都不断有人提出不同的敏捷开发问题,一一作答的时间消耗太大;如不作答,又知道这些不只是一个“感兴趣”的问题而已,而是关乎某个团队若干人月的工作,或一些人...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 大家都知道,创业公司刚开始需要研发出...
  • 本博将通过 讲解敏捷开发概念->敏捷开发架构思想->开发环境搭建->项目源码敏捷开发构建、拆分 等逐步带您走进android敏捷开发的世界。 学敏捷开发,开启 架构师之路..(夸张了呵呵,其实没有,这是基础) 注:本系列...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum等敏捷开发方法。。。当然,自己也是敏捷开发的实施者和受益者。
  • (在这里提问,之一,之二,之三,问题总目录)正逢周末,又是愚人节,群中有人正在加班,想起上次培训中间休息的时候,讨论起这个“敏捷开发加班吗”的问题,虽然后来没有作为课后投票入选,但这里也完整回答一下。...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些...
  • 移动互联网行业发展速度快,需求不断变化,产品更新迭代的频率高,基于移动互联网的以上特点,就引入了Scrum这个敏捷开发框架。 Scrum简介:Scrum是一个敏捷开发框架,是一个增量的,迭代的开发过程
  • 敏捷开发实战经验

    2018-05-30 18:22:35
    敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。...
  • 敏捷开发工具:禅道

    2018-11-12 10:03:57
    敏捷开发,之前一直关注这方面的内容,因为现在的公司是个小型团队,也是刚成立不久的公司,没有完善的体系和开发流程,无疑,敏捷开发为最适合当前使用的开发理论和方法。 之前看了很多敏捷开发方法论等知识,都...
  • 接下来,将由浅入深地来分析分析敏捷开发的基本概念,然后说明一下敏捷开发的代表–XP(极限编程)与Srcum过程。敏捷开发概念与价值观敏捷开发运动历史相对于整个软件开发而言算是较为悠久的,其真正开始的标志是01年2...
  • 这是敏捷开发绩效管理的第一篇。(之一,之二,之三,之四,之五,之六,之七)“敏捷开发绩效管理”本身是个伪命题,因为敏捷开发本身不想涉及绩效管理,这就像“C++绩效管理”的搭配差不多。但是人们选择敏捷开发...
1 2 3 4 5 ... 20
收藏数 130,534
精华内容 52,213
关键字:

敏捷开发问题