敏捷开发是什么_项目经理在敏捷开发中的作用敏捷开发 - CSDN
精华内容
参与话题
  • 什么是敏捷开发

    2009-05-18 11:38:00
    简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互...

    简单的说,敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。

      敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论,他采取了"敏捷方式"组建团队:Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5~7名IT人员,其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外,还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训,具备相关的技能。

      每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导),他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开发有规律地停顿--在9周开发过程中停顿3~4次,以评估过程及决定需求变更是否必要。在Capital One,大的IT项目会被拆分成多个子项目,安排给各"敏捷团队",这种方式在"敏捷开发"中叫"蜂巢式(swarming)",所有过程由一名项目经理控制。

      为了检验这个系统的效果,Bailar将项目拆分,从旧的"瀑布式"开发转变为"并列式"开发,形成了"敏捷开发"所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行"冲刺"--每个冲刺始于一个启动会议,到下个冲刺前结束。

      在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋--"敏捷开发"使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。"不过,有些需求不能用敏捷开发来处理。" Bailar承认,"敏捷开发"也有局限性,比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外,他觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但经过阵痛之后,需求处理流程会让CIO受益匪浅。

      敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:

    •   个体和交互 胜过 过程和工具
    •   可以工作的软件 胜过 面面俱到的文档
    •   客户合作 胜过 合同谈判
    •   响应变化 胜过 遵循计划

      并提出了以下遵循的原则:

    •   我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    •   即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
    •   经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
    •   在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    •   围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。
    •   在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。
    •   工作的软件是首要的进度度量标准。
    •   敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    •   不断地关注优秀的技能和好的设计会增强敏捷能力。
    •   简单是最根本的。
    •   最好的构架、需求和设计出于自组织团队。
    •   每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

      关于敏捷开发的方法研究

      (一)注: 本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法,Agile Software Development是一组软件开发方法的总称,包括(Crystal , Extreme Programming , Adaptive software development等等)。敏捷开发方法又称为“轻量级”开发方法。

      下面这段话摘自Martin Fowler的一篇文章:

      从无到繁重再到敏捷

      多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改” (code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。

    我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正规方法”(methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。

      这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法,或Jim HighSmith 所称的“巨型”(monumental)方法。

      作为对这些方法的反叛,在过去几年中出现了一类新方法。尽管它们还没有正式的名称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。

      敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来看,它们更象是“面向源码”(code-oriented)。事实上,它们认为最根本的文档应该是源码。

      但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象,它其实反映的是更深层的特点:

      ? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。

      ? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

      我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心

      (二) 方法背后的思想

      Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想

      人们掌握过程(process)可以分为3个阶段:

      1 following 遵循一个定义好的process

      2 detaching 知道不同process的适用范围,在不同的场合使用不同的process

      3 fluent 不关心是否遵循特定的process,知道在什么情况下采用什么动作

      软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件,遵循特定的过程和模型只是手段,只要传递了足够的信息,手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form of communication)。

      一般软件开发有两个目标:1 尽快的生产出软件 2 为下一个team或项目做准备,有时这两个目标是矛盾的,我们要在这两个目标之间寻求平衡

      在软件开发中,人的因素要远远大于过程和技术。人是有缺陷的:

      1 容易犯错误,因此必须在错误扩散之前找到并改正错误

      2 当觉得可能失去较多的时候,不愿意冒险

      3 重新构造而不愿意重复使用已有的东西

      4 难于坚持一个习惯

      针对个人因素的几个建议:

      1 具体的模型较抽象的模型更容易理解

      2 从一个例子开始是容易的

      3 通过观察他人的成果学习

      4 要有足够的不受打扰的时间

      5 分配的工作要与个人意向,能力匹配

      6 不正确的奖励会有坏作用,从长期看个人兴趣比奖励更重要,培养在工作中的自豪感:

      1) pride in work参与工作的自豪感,通常参与一个重要的工作会有自豪感

      2) pride in accomplishment 完成工作的自豪感,长期未完的工作会使士气低落

      3)pride in contribution 为他人贡献的自豪感

      7 鼓励关心其他人的工作和整体的工作

      在一个团队之间,交流是最重要的,实践证明面对面的实时的交流是最有效的,对交流的延误会损失信息,白板是最好的交流工具,交流工具的先进并不能提高交流效果。文档的作用是记录和备忘,不能通过文档交流。

    敏捷开发方法要避免的过程设计的几个常见错误

      1 对所有的项目使用同一种过程

      2 没有弹性

      3 过于沉重

      4 增加不必要的“必须完成”(“should do” is really should?)

      5 没有经过实践检验

      敏捷开发方法过程设计的几个原理:

      1 交互的面对面的交流是代价最小,最迅速的交换信息的方法

      2 超过实际需要的过程是浪费的

      3 大的团队需要重量级方法

      4 处理重大问题的项目需要重量级方法强调

      5 增加反馈和交流可以减少中间产品和文档的需求

      6 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill),重量级方法更强调文档(documentation),过程(process)和正式(formality)

    •   understanding指整个团队关于项目的全部知识,包括讨论的过程,documentation只能记录其中的一部分
    •   discipline是指个人主动的完成工作,process指个人根据指令完成工作
    •   skill指具有良好技能的人可以省略中间的产品,formality指必须按照规定步骤完成工作

      7 确定开发中间的瓶径,提高它的效率

      对于瓶径处的工作应该尽量加快,减少重复,(使用更熟练的人,使用更多的人,使用更好的工具,使瓶径处的工作的深入尽量稳定)对于非瓶径处的工作可以多一些重复,在输入还不确定的情况下也可以尽早开始。

      这些原理的几个结论:

      1 向一个项目增加人员要花费较大代价(constly),因为原有人员和新人员之间的交流要花费大量时间

      2 团队的规模经常是跳跃的,例子:需要6个熟练的程序员,但是只有4个,于是增加不熟练的程序员,结果团队的大量时间花费在培训不熟练的程序员上面,最后增加到了20个不熟练的程序员。

      3 应该侧重于提高团队的技能而不是扩充团队

      4 对不同的项目使用不同的过程

      5 在适用的条件下,轻量级的方法优于重量级的方法

      6 对不同的项目要裁减过程

      总而言之,敏捷开发方法的原则是“刚刚好”(Light and Sufficient)

    展开全文
  • 什么是敏捷开发流程

    千次阅读 2019-05-11 19:34:29
    什么是敏捷开发流程 】 这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。 一. 先说一下官方的定义: 敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观....

    这里是修真院后端小课堂,每篇分享文从

    【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】

    八个方面深度解析后端知识/技能,本篇分享的是:

    【什么是敏捷开发流程 】

    这个词猛一听起来感觉很高大上,其实现在已经是主流的团队开发流程 了。
    一. 先说一下官方的定义:

    敏捷不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括:极限编程(XP),Scrum,精益软件开发(Lean Software Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Crystal Clear)等等。所有这些方法都具有以下共同特征:

    1. 迭代式开发。即整个开发过程被分为几个迭代周期,每个迭代周期是一个定长或不定长的时间块每个迭代周期持续的时间一般较短,通常为一到六周。

    2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用,而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。

    3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时,团队对于用户的需求也能及时提供反馈意见。

    4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成,有些项目则每天都在这么做。

    5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队,是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制,而非把过程和机制强加给人。

    二. 然后是我理解的敏捷

    主要说一下我们公司自己的开发流程,因为接触时间尚浅,所以有点地方可能说的不是很到位,希望大家多多包含。

    需求评审(参与人员是 客户+产品+UI+开发+测试,也就是所有人员)
    主要是产品人员讲解需求,用户需要给出反馈或者提出意见,其他人员可以相应的提出自己的见解。

    Story划分(产品+UI+开发)
    产品根据UI做出来的原型图给开发人员讲解系统构成和运行,将整个网站按照功能划分成一个个细粒度的story来说明,开发人员(前端和后端)也需要明白自己应该关注那些关键点。

    人员划分(leader+开发)
    主要是项目小组的leader 根据story划分,给前端和后端开发人员划分story,开发人员根据自己的情况去估算所需时间。

    方案设计(数据库设计文档、接口设计文档、方案设计文档)
    先根据系统的实际情况去设计DB,包括数据库和表的名字,以及具体的字段。
    然后设计接口文档,按照页面和功能进行设计,包括具体的请求地址和入参出参。
    最后是根据接口文档中出现的疑难点去做方案设计文档,对遇到的问题进行分析并拿出至少两种具体的解决方案。

    方案评审(所有人员)
    对前端和后端给出的方案评审其它人员给出各自的意见,有问题的话下次再次开始。

    禅道任务拆分(开发人员)
    方案评审通过以后开发人员就需要按照预估的总开发时间去拆分story,可以分成多个小的任务,但是一个任务的时间最好不要超过4个小时。

    开发(项目日报+工作日报+进度邮件)
    每天实际开发过程中遇到问题可以写成项目日报;每天的任务完成情况写成工作日报;相比较整个系统的进度完成情况需要写进度邮件。

    端对端(接口)测试(开发人员)
    前端写好了页面,后端完实现了接口,就可以进行端到端的测试,可以远程测试,也可以本地测试。

    压力测试+集成测试
    系统完成以后需要用Jmeter 进行模拟用户访问,通过设置线程来提高并发量的方式达到一定的效果,测试生成的数据需要总结成测试报告。

    Demo
    对于复盘来说,这就是最后一个程序了,在前后端大师兄的评审下,主要是前端人员进行系统演示,各个功能是否实现、页面是否达到用户要求、有没有什么需要完善的地方。点评过之后如果有问题那就修改之后再次评审;如果没有问题那就算完成复盘项目了。

    这么一个流程走下来,特别期间各个环节的良好运行以及团队合作的情况都是确保项目能够正常实现并交付的重要因素,敏捷开发强调的是人的充分能动性,通过这种相互合作的开发模式,相信在前后端分类开发的盛行时代,公司或者团队可以在约定的时间内较好地完成用户委托的项目。

     

     



     

    【欢迎加IT交流群565763832与大家一起讨论交流】

    展开全文
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...

    今天你敏捷了没有?“敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。

    我们使用 tapd 写 feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?(注:tapd 是腾讯内部的敏捷项目管理系统) 。

    1.朋友,你听说过敏捷么?

    2.离开敏捷工具,我们怎么敏?

    3.设计也要介入敏捷流程?

    4.敏捷跟文档是对立的?

    5.我这有个几百亿的大项目,怎么敏?

    6.尽信书,不如无书。

    一、朋友,你听说过敏捷么?

    程序员说,要有敏捷

    从敏捷的滥觞看去,比起方法,这玩意貌似更像一个宗教(笑)。

    千禧之初,美国在计算机行业已经走了几十年,瀑布流、螺旋模型、快速迭代...各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善,但互联网的加速发展让传统方法显得笨重,难以快速适应变化。有十七个程序员(程序员改变世界)在美国犹他州的一个风景区开了个碰头会,找到了一个团队耦合度高,流程极其灵活的方法,他们把它称为agile program development。

    这十七个人如同开宗立派的长老,在会议之后给自己起了个名字“敏捷联盟”,他们不仅赋予了新方法名字,还有宣言,甚至纲领。

    盐湖城- snowbird(敏捷联盟成立地——雪鸟滑雪场)

    中文版的“敏捷宣言”。在建立于2002年3月的 《Manifesto for Agile Software Development》里你可以找到几十种语言的“敏捷宣言”。

    另外,长老们还制定了12原则,作为福音传播。

    显而易见,敏捷是绝对的结果导向,去文档化,去流程化,高效沟通和合作是究极奥义。

    看起来是个很不错的方法,文档不重要了,流程不重要了,大家聚在一起说一说就可以了不是吗?太棒了,感觉可以从繁重的文书工作中解脱出来了呢。

    失之东隅收之桑榆。一处的方便一定意味着另外什么地方以其他方式运行着简化掉的部分。

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

    胖友,这里有一份教义,你要不要听一下。

    初识敏捷,有一些概念需要了解,如果你是老司机,跳过这部分,阿敏。

    agile:迅速,敏捷。这是敏捷的理念也是精髓:迅速响应需求,快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型,速度上跑赢几条街。

    sprint:字面意思是短跑冲刺,一个开发阶段被认为是一次冲刺,一个个 sprint 首位相连,构成一个项目。

    Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。

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

    Product Backlog:

    backlog 即需求池。待办事项列表。

    Backlog 里面写什么:

    1.待开发任务。

    2.任务优先级。

    敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人(一般是产品经理)对所有待开发事项有深入了解,并且能够把待开发事项分解成更为细致的任务(或者跟敏捷教练一起,后面我们会再次提到敏捷教练)

    story board:

    很多领域都有故事板的概念,交互领域里,用故事板表述用户场景、电影领域里故事板用来更具体地描述分镜。在开发领域,故事版是任务流转的可视化窗口,一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块,所有任务由任务操作者负责流转至于下一个步骤,这样任何一个人项目成员都能看到任务的完成情况。

    一个app使用情景故事版

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

    burn down chart:

    燃尽图

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

    名词听起来都玄乎乎的,很符合开宗立派的气质。这些概念定义了敏捷各个环节的工作,这些流程和节点是敏捷开展的基础和保障。

    二、离开敏捷工具,我们怎么敏?

    一个误区:我们用了敏捷管理工具,就敏捷了

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

    (数据来源:“2016中国开发者白皮书”)

    我们在 tapd 上建迭代,建需求,研发、测试等着收到需求流转的邮件之后开始干活...任务在测试和研发之间流转,bug 提给研发,研发解决 bug .....我们宣称:我们敏捷化了!

    我们习惯于敏捷软件的便利,拉群解决一切,然而却丧失了敏捷的初衷,scrum 的本意。

    Jira的名字来自于哥斯拉

    假设我们没有任何项目协同软件,敏捷怎么实施?

    设定一个环境,现在没有任何协同工具可用,但是所有人都坐在一起。有人站起来说,既然这样,我们不如敏捷吧!

    敏捷工具消失了

    敏捷路径里必须有一个项目持有者,制定规划并把握项目走向。这位产品汪我看你骨骼惊奇,你就担负起这个责任吧。

    另外还有一个关键人物 SM(别想歪)。SM 全称 scrum master,中文称敏捷教练。一般说来,SM 需要由对技术开发以及当前项目明晰的技术经理担任。

    虽然缺少线上工具,但至少要准备一些简单材料:一卷双面胶+白纸或一沓便利贴;笔,一面平坦的墙或一块黑板。

    如果还有电脑可用,excel 或者 word,甚至写字板都可以,没有电脑那就白纸好了,总之你得找个地方写下你的需求池(backlog)

    需求池示例(任务名称、平台、详细描述、优先级按照P0-PX逐渐递减)

    确定一个 sprint 周期的自然天。可以用月/旬/周等时间概念作为周期,我们选择一周(五个工作日)作为一个 sprint 周期。

    按照优先级,从需求池中拉出你认为应该加入你们一穷二白的第一个 sprint 里面去的需求,别太贪心,大概觉得差不多一周左右的开发量就够了。拉上SM桑单独开一次小会。

    当然不是让你俩傻站着,你俩要开会

    你们一起通览需求,SM 桑根据经验对需求先行分解一遍,比如某需求在开发层面需要分解为 ABC 三部分,这三部分就形成三个开发任务。

    分解完成后,你得到了一个比较详细的待开发列表。

    正式开始一个 sprint 开始之前,产品、研发、测试需要一同开一次 scrum 会议,共同讨论本次 sprint 的功能点。

    会上讨论什么:

    1.需求讨论或技术讨论;

    2.成员预估需求所需开发时间;

    3.需求是否match人力时间,需求排入sprint;

    4.交流一下感情。

    每个任务的预估时间在最后由敏捷教练综合判定

    scrum 会后你的工作:

    1.整理这个 sprint 内的需求列表;

    2.整理每个需求的预期开发时间;

    3.撰写故事版上的小纸条;

    4.把小纸条贴到故事版上;

    5.制作一个燃尽图。

    一个改良版的小纸条,写明开发者、任务描述、预估时间和每日燃尽时间

    故事版布局如下:

    一个标准的故事版:最开始所有的小纸条都在“待开发”一栏

    到此为止,你可以开始 run 起一个 sprint 。

    以为这就完事了?天真。

    接下来你必须来参加每日举行的项目短会。这个环节在 agile 中非常关键,是 agile 的日常修炼。为了缩减会议时间,我们一般站着开——所以也叫“站会”,早上上班后或晚上下班前,抽出十到十五分钟时间,完成它。

    每日站会

    站会都有什么人参加:

    1.你(项目持有者)

    2.SM

    3.其他 scrum 成员

    站会干什么:

    1.昨天大家分别做了什么事,遇到了什么问题,如何解决或寻求解决方案;

    2.昨天任务的完成状态,剩余多少时间,是否需要进行时间修正(增加时间或减少时间),把已完成的任务流转到下一环节(把纸条从一个item内撕下,贴到下一个item里去);

    任务进行中,小纸条的示例

    3.功能测试后是否有返工;

    4.交流一下感情。

    站会之后你的工作:

    绘制燃尽图。

    一个燃尽图的示例:正常的 sprint 的任务时间是随着 sprint 的进程逐渐减少的

    周而复始,完成了一个 sprint 后,你们开了第二次 scrum 会。这时议题多了一项:复盘上一个 sprint。

    任务未能燃尽;研发返工过多;测试需求淤积.....

    针对问题讨论解决方案,根据实际情况进行下一个 sprint 的任务安排。

    自此,我们在没有任何敏捷工具的帮助下,开始了敏捷的旅程。

    说起来agile developing 本来就是排斥文档的作业方式,为一个小轻快的方法制作一套严谨庞大的工具,基本也算违背了元老们的初衷了吧,科科。

    三、设计师在敏捷中如何介入?

    我们正在使用或者听过的一些流程方法——不单敏捷,瀑布流,迭代式,结对开发,精益开发....似乎都不关设计师什么事。既然开发团队抱团敏捷了,设计,这个在产品流程中必不可少而工作内容相对独立的角色,要怎么介入敏捷呢?

    一种思路是,设计拥有自己的敏捷流程。设计师作为一个 scrum 存在,以从上游获取的需求进行 sprint 。

    另一种思路,是把设计和测试完全纳入到团队中来,一起进行 scrum 的合作。

    这样的话,UI工作至少要比开发工作前移至少半个 sprint 。

    有请产品经理(项目持有者)出场。

    很好,我们有了一个设计师

    项目持有者将需求分为“ UI 支持”和“非 UI 支持”两类。我们将小纸条扩展一下。

    多出来 UI 前置部分的小纸条

    U I设计师参与到 scrum 会中。对于需要 UI 支持的需求,设计师给出一个 UI 制作的时间预估。项目持有者将这部分时间加到扩展小纸条上去。在一个 sprint 中,设计师的工作跟研发的工作分别进行。

    当设计师将某一需求完成时,将小纸条的 UI 部分撕下,汇入到“”待开发”中去。

    一个已经完成了 UI 设计的小纸条示例

    四、敏捷不需要文档吗?

    一切为快服务的敏捷特别适合初创团队使用。它能把团队人员紧密结合在一起,高效而有序地输出产能。而常规高效的版本输出往往是初创团队高速发展的第一要务。

    敏捷了一段时间之后,产品进入正轨,项目拿到拨款,公司拿到投资,你们要扩大团队规模,新入职的同事想了解下产品和技术细节,你告诉TA:

    你要不翻下 backlog 看看?这个实现你要不看一下代码?这个字段我也不记得有没有了....你抓包看下?

    新同事一脸懵逼,难道咱们没有文档吗?你自豪地指出:

    “我们是敏捷团队。”

    十几个人八九条枪的阶段之后,产品趋于稳定,团队逐步扩大。无论从内部协调还是外部沟通上对产品流程的正规化和文档化要求与日俱增。

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

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

    一个以讹传讹的过程

    这样一个功在当代利在千秋的好事,当然要做。那么——

    谁来维护文档,怎么维护?

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

    产品文档:不好意思内个产品经理你过来下。虽然你要维护 backlog 、跟 SM 分解需求、开 scrum 会、写小纸条、开站会、画燃尽图、还有什么外部沟通啊,写 PPT 啊,绞尽脑汁想规划啊......你还得认真把这个文档维护好。

    对又是你

    产品文档包括:

    1.需求;

    2.加入日期;

    3.开发版本;

    4.呈现和详细方案

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

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

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

    长久来看,文档是提高效率的一大利器

    虽然《宣言》中明确地放低了文档的地位(“工作的软件大于详尽的文档”),敏捷强调互动和变化,以及对变化的及时响应。诚然文档恰恰做不到如此灵活。但敏捷真的完全排斥文档吗?

    文档的时效性和灵活性远低于口头沟通,但却有它实在的好处。

    1.空间上,文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下,跨 scrum 、跨团队甚至跨部门的沟通时有发生,文档的重要性和便捷性不言而喻。

    2.时间上,文档流传性更好。团队不是一成不变的,有人离开有人加入。更新换代中,新人快速了解系统,老兵传承研发理念;在更大的时间跨度上,团队可能成为忒修斯之船,文档的存在就是对产品历程的完整追溯,你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。

    五、大项目怎么引入敏捷?

    看起来敏捷方法特别适合产品常规迭代。有一种可能性是,你的产品需要插入一个巨无霸模块,与其说是模块倒不如说它几乎可以成为一个产品了。你想了想,这么大个项目怎么说产品、设计、研发、测试全情投入也得个一两个月。

    还能走敏捷吗?

    注意你的项目时间。有 deadline 的 scrum 是带着镣铐跳迪斯科,时间节点关乎 sprint 的大小。

    大项目敏捷之前,先得不敏捷几步。

    可能会发生一到多次需求讨论会。

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

    大项目敏捷中:

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

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

    一个需要加班的 sprint

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

    4.别忘了文档。

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

    文末再总结本文重点:

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

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

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

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

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

    展开全文
  • 敏捷开发是个啥

    千次阅读 2019-04-01 10:18:32
    今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分: 第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。 第二部分聊聊敏捷的核心思想。 敏捷开发是互联网界比较流行的软件开发模式...

    「齐齐兽」公众号授权转载
      原文连接:原文连接

    今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分:

    第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。

    第二部分聊聊敏捷的核心思想。

    敏捷开发是互联网界比较流行的软件开发模式,产品、技术、项目管理、运营、美术和测试等各岗位对其理解后都大有益处,运用得当可以事半功倍。现在信息爆炸、良莠不齐,网上很多讲敏捷的文章,Scrum词意没理解到位。去年看了敏捷革命的原版《Scrum: The Art of Doing Twice the Work in Half the Time》,结合大学所学的软件工程聊一聊这个话题,here we go~

     第一部分

    瀑布模型

    先上定义:瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作软件概念,主要分为需求分析,架构设计,详细设计,实现,单元测试,集成部署,系统测试,运营维护。瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠。

    为什么会有瀑布模型?

    如果一个人接项目,他也许不需要这么麻烦,但规模稍微大一些,就需要多人协作,这时候就需要有标准有规范。最开始的时候,大家用了建筑工程领域的模型来对标软件工程。是盖住宅还是盖工厂,或是商厦或是办公楼或是博物馆,需要有严谨的建筑设计图,水电管道布线甚至装修方案,才开始施工。瀑布模型就是这个思维,所以瀑布模型对软件架构师的要求很高,在瀑布模型下,如果把开发软件作为盖栋建筑的话,coder只需要“搬砖”就可以了(在敏捷开发过程中,对研发团队人员的要求会较高,瀑布重视流程、文档,敏捷强调团队内人员能力,特别是cross-functional,要有跨领域的能力。也有人把瀑布模型折叠起来,变成了V字型,目的是每个阶段都有要去验证的东西,看起来是有迹可循的,前后阶段是对应的。个人觉得瀑布模型最重要的是给大家树立了软件工程的基本观念:

    1.前期做足功课很重要;

    2.编码只是软件工程中的一部分。

    「V字模型」

    瀑布模型有什么问题?

    慢慢大家发现,瀑布模型有很多限制和问题,最主要的是不能拥抱变化盖大楼毕竟跟开发软件不一样,软件的需求往往是不断变化的,瀑布模型往往会导致牵一发而动全身,这就导致绝大多数瀑布模型是延期的,而且出来的东西也不是用户最初想要的。客户想要一把瑞士军刀,最终只出来一把螺丝刀,甚至只是一根小木棍儿。。。人们逐渐想办法克服了这个问题,这就是统一软件开发过程(RUP:Rational Unified Process)

    统一软件开发过程

    RUP是瀑布模型的改进,可以这样理解,这个模型把软件开发过程的类比从建筑行业改到了汽车行业。主要认清了两点:

    1.软件是不断迭代的;

    2.软件应该是面向对象的;

    当然,还有很多其他方面的改进细节,就不展开了。一个车型可以是系列的,舒适版、技术版、豪华版,不同年份还不一样,是不断迭代更新的。要想造一辆车,团队可以分头行动,简化一下比如要做一个四只脚的木凳,甲可以先去做凳子面,乙去做凳子腿,前提是两个人定义好怎样连接(接口),用什么样的螺丝,多大的孔,在什么位置连接,凳子腿多高等等,也可以有个专门的丙(项目经理)去协调这些事情。这样凳子腿可以在这个基础上自由地涂些花纹,加个皮套,做些镂空等等。

    「改进后的瀑布模型」

    这个模型已经具备了高内聚低耦合的思想,但还是有个问题,客户或领导通常想看到一些进展,也许一辆车从设计到出厂需要两年,但每几个月大家可以看到一些实实在在的东西,以上面做凳子为例,我们是可以看到凳子腿和凳子面的,也可以想象它们连接起来的样子。而软件不一样,只要各个模块还没有效的连接起来,那基本上啥都没有,特别是对于大多数没有计算机知识的人,基本上是一个“黑盒”过程。这个模型同样面临着延期超预算的风险,同时做出来的也不一定是客户想要的。

     

    随着互联网的发展,对软件的变化需求越来越高,就产生了大家最熟悉的迭代模型,inception,elaboration,construction,transition,四个阶段形成闭环,不断循环往复,其核心理念是软件是增量开发的每次迭代都能看到些进展。敏捷开发就是在这个生命周期模型下演变而来。

    「迭代模型」

    螺旋模型

    接着就有了螺旋模型,螺旋模型并不是推翻了瀑布和RUP,是一种改进,从某种角度来说螺旋也是遵循瀑布模型的,每一次螺旋迭代都要有清晰的目标,明确的需求,规划实现,交付条件等,这个循环也是迭代模型的迭代周期演变。比如说要做一辆汽车,我们可以先做一个自行车,再逐渐地在自行车上加个铃铛,加上发动机,变成4个轮子,加个篷,车把变成方向盘。。。在各方面持续地螺旋迭代下去,最终会出来一个跟汽车差不多的东西。这个例子有一些原型法的味道,螺旋模型往往是较大较复杂的系统使用,目的是减小风险,每一次投入能看到一些东西的产出,希望把整个过程“白盒化”。

    「螺旋模型」

    总结

    以上是关于软件工程的三个主要生命周期模型,逐渐地又出现了极限编程、原型开发、敏捷开发等模型。严格来讲,瀑布模型、迭代模型是生命周期层面的模型(当然,通常也包含了一系列开发层面的工具集),敏捷开发是基于迭代模型发展起来的一整套软件开发指导原则。个人观点是在实际操作中应重视指导原则,弱化方法论。迭代模型在学术上很早就有人提出,敏捷开发的作者之所以能从不同的视角去看待软件开发,并有独特的思维和管理方法,这跟他的个人经历有很大关系,因为他不是做计算机出身为了理解他的思想,我特意购买了《敏捷革命》的英文原版《Scrum,The Art of Doing Twice the work in Half the Time》来阅读,下面部分分享其核心观点。


    第二部分

    我们可以看看《Scrum》的作者杰夫·萨瑟兰的经历,他之所以能以全新的视角来认识和理解软件工程这件事情,很重要的原因在于他不是做这个行业出身。

     

    作者的经历

    杰夫·萨瑟兰毕业于著名的西点军校,他以战斗机飞行员的身份去参加越南战争,在他的队伍里50%的飞行员会被击落,一些会被营救,一些再也回不来。在这个环境里他构建了自己的行动模型,即OODA(Observe,Orient,Decide,Act)执行任务的每时每刻都在重复着这个循环,犹豫就会死。这个行为模式在他的著作里能感受到已经深入骨髓。

     

    参加完越南战争后,他去斯坦福进修了统计学硕士学位。后来边在空军学院做数学教授,边读了一个生物统计学博士,研究细胞、癌症相关的一些东西,学习了系统论方面的东西。在研究细胞的时候,他会不断考虑一个问题:whether the new state is better than the old one 现在这个状态是不是比上一个好。《敏捷革命》原文中多次提到state这个词,这也是作者非常重要的一种思考方式。

     

    其离开大学的第一份工作是做美国的ATM,这个时候他把自己在战争和研究细胞中的方法应用于IT领域,后通过大量实践(其中有为FBI构建犯罪嫌疑人数据库,著作中的重要案例)逐步总结发展出了敏捷模型理论。另外,Scrum不是作者的首创,作者是根据日本两个教授的理论发展总结而来。在学术界,日本的两个教授质疑瀑布,他们认为最好的团队应该像打橄榄球一样,球在队伍中间穿梭,队伍整体快速向目标移动(这才是Scrum想要表达的意思),日本的大企业最开始用这种指导思想(细算一下正是日本IT大发展的时代)。理论早就有了,但很少有美国人这样去实践,作者为了理解日本人的Scrum思想,练习了多年合气道,并用合气道来类比Scrum,并再次用到了“state”思维方式来解释。

    Scrum&Cross-functional

    说到Scrum,我们来聊聊cross-functional。橄榄球大家可能不熟,我们来聊聊篮球。球队里最吃香的是哪种人,当然是那种什么位置都能打且都打得好的,俗称万金油。勒布朗·詹姆斯号称可以从1号位打到5号位,这种人可以体会到在各个位置的人的“不容易”,从而更有利于团队发展。奥尼尔给人篮下巨无霸的印象,但其实他有灵活的运球技巧和出色的娱乐表演天赋,这些综合到一起才成为球迷心中大鲨鱼的人设。NBA里那些最受人崇拜的顶级后卫,基本都会多种绝学,乔丹科比韦德等人,控球、得分、突破、抢板、分球等各项技能均能登堂入室,有些方面甚至前无古人。有一项技能特别突出基本就可以独步武林,但想成为顶级选手,一定是cross-functional的而作为球队老板,希望在有限的资源下,尽可能多地把这种选手招致麾下,才有可能对拉里·奥布莱恩杯发起冲击。勇士的“死亡五小”更是将这种理念发挥到了极致,场上队员几乎都能快攻、投篮和抢板。

     

    回头来看,软件开发也是,cross-functional是对团队人员素质要求的提高,正所谓不会写代码的产品不是好美术。软件开发也是个跨兵种共同协作的同时不断面临变化的事情,从这个角度来看,跟打篮球和橄榄球是相同的,还记得NBA赛场上暂停时大家是怎么解决问题的么,结合上面说的场景“球在队伍中间穿梭,队伍整体快速向目标移动”,这是Scrum中非常重要的理念。

    敏捷作者的一些核心观点(为保原汁原味,摘抄部分原文)

     

    传统的瀑布模型其实是由一大堆图表构成,作者表达了对图表的一些观点:

     

    • Planning is useful. Blindly following Plans is stupid;计划是有用的,但盲目的按计划走是愚蠢的。这跟作者的从军经历有关,其执行任务的时候都是随机应变,也应了中国的那句老话“计划没有变化快”。

    • Every project involves discovery of problems and bursts of inspiration,scrum embraces uncertainty and creativity.任何一个项目都包含了未发现的问题以及随着项目进行的灵感爆发,图表会限制这些,Scrum“拥抱”这些不确定性和创造性。

    • Stop doing what you’re doing ,review what you’ve done;放下手中的事情,想一想我们在干啥。

     

    作者对“敏捷”的一些观点:

    MVP                    

    Minimum viable products to get immediate feedback from consumers,rather waiting until a project is finished;最小化可行产品Minimum viable products,也简称MVP(搜索这个短语会有大量方法论)。用最小化的可行产品来从用户那里快速获得回馈,而不是一直等项目完成。我们通常说的“小步快跑”;

     

    Inspect and Adapt cycle

    上面说的OODA行动模型的抽象,“观察—适应”,这两个过程不断循环。这里面作者提到了一个常用的方法5W2H,在每一个阶段(state)都问自己:

    • What;我们要做的是什么,有什么意义,现在是什么状态;

    • Why;我们为什么要做这个,可不可不做,有替代方案么;

    • When;什么时候做,deadline是什么;

    • Where;在哪做,哪里要用;

    • Who;谁来做,谁对此负责;

    • How;怎么来做,如何配合;

    • How much;多少、程度,多大开销,做到什么程度;

     

    敏捷革命可以应用在各行各业,作者已经在汽车制造、开洗衣店、学生培训、制造宇宙飞创、婚礼策划等领域展开实践,所以说Scrum模型不只是一套软件开发工具集,是具有普世性的价值观

    Agile Manifesto, It declared the following values:people over process;products that actually work over documenting what that product is suposed to do;collaborating with customers over negotiating with them;and responding to change over following a plan,Scrum is the framework I built to put those values into practice.There is no methodology.这就是敏捷宣言的所有原文,后来被各种媒体放大和解读,其实它非常简洁。敏捷宣言,它强调了以下价值观:

                           重于    过程;

    产品真正好用    重于    文档里的设计;

    跟用户合作        重于    跟他们谈判;

    对变化做回应    重于    按计划去做; 

    我建立Scrum模型就是为了把以上价值观揉进一套工具集以方便更好地实践,敏捷模型没有方法论;(没有方法论,没有方法论,没有方法论,这是作者的原话啊,啪啪啪打脸有木有);

     

    总结

    Scrum原著以案例来表达了他对图表、文档、对计划、对团队、对过程管理的一些观点,而Scrum正是这一系列价值观的合集,这才是Scrum的精髓所在,为了快速实践和方便理解这些价值观,作者提供了一些方法比如每日立会、sprint、backlog等。具体方法不赘述了,网上有很多介绍。这些方法都是为了落实上面的观点:我们处在什么状态,我们有什么,如何做下个状态会比现在的好。。。

     

    相比于拿过来方法直接使用,理解好上面的观点再根据实际情况选择方法是更有效的思路。

     

    友情推荐:此文转载于朋友的公众号「齐齐兽」,每周一篇高质量文章。如果你是程序员或产品经理,微信扫描底下二维码,必有收获!

    展开全文
  • 什么敏捷开发

    万次阅读 2015-04-19 15:18:07
     软件开发是一种对人类智慧的管理,对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元,这与冰冷的机器是不可比的,所以在中国的历史上,管理人是最难的工作;“学而优则仕”的...
  • 敏捷开发思想

    千次阅读 2019-04-12 22:55:16
    敏捷开发思想SCRUM 是什么?敏捷开发什么?以人为核心是什么意思?迭代 是什么意思?SCRUM 与 敏捷开发思想有什么关系?敏捷开发的模式分类(摘抄至互联网):SCRUM 的工作流程(摘抄至互联网)流程: SCRUM 是什么? ...
  • ios敏捷开发的理解

    2019-03-13 14:37:56
    1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? 4.采用敏捷开发的产品效果? 二.什么是敏捷开发敏捷开发是一种价值和原则,指导我们更加高效的开发。 敏捷开发以用户需求为核心,采用...
  • 那么,敏捷开发什么好处呢?    在软件工业界,敏捷开发已成为众多高效开发团队的制胜之道。在欧美软件企业中,有近半数企业已采用敏捷方法进行开发,而近几年受软件外包和外企的带动,敏捷开发在中国也出现了日渐...
  • 什么是敏捷开发流程?

    千次阅读 2018-08-22 08:15:51
    今天给大家分享一下,java项目中需要使用的敏捷开发流程   1.背景介绍   在很久以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多, 测试了半年...
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 敏捷开发初步了解

    千次阅读 2019-09-02 10:34:44
     笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些理解,并不全面,如有不同理解/或更深刻的理解可以回复进行...
  • 敏捷开发什么鬼?

    千次阅读 2016-12-07 10:03:38
    身为一个攻城狮如果你没有听说敏捷开发,那么你可能就out了,抱着与时俱进的态度,今天我们就来学习一下敏捷开发是个什么鬼?
  • 敏捷开发什么敏捷

    千次阅读 多人点赞 2013-09-29 17:54:09
    所以就出现了先搞可行性分析(其实真正开发的时候没人去搞这玩意儿,既然都要开发了还分析个什么劲~),然后是需求分析,遇到负责的开发团队偶尔会画画图,要是遇到奇葩的开发团队很有可能一个需求闯天下了。...
  • 摘自PM圈子网——项目管理牛人聚集地Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周...
  • 八分钟敏捷开发(scrum)扫盲

    千次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    什么是敏捷开发? 传统的开发模式和敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建...
  • JAVA敏捷开发环境搭建

    千次阅读 2016-05-19 18:06:23
    前面介绍了创业型软件公司的工作模式,这里详细介绍下...这是为什么呢,因为目前大部分开发人员还是比较熟悉windows下开发。对于mac和linux下直接使用软件并且开发的中国开发者还是少之又少,这套架构就这个现状做出
  • 敏捷开发流程

    千次阅读 2017-01-04 16:37:50
     在敏捷软件开发领域,更注重的以人为核心,迭代,循序渐进的开发方法。相比传统的开发方法,这种方法能更快速的开发,上线,反馈,调整、迭代。以敏捷的姿态去发展产品。 敏捷与传统开发的区别  
  • 那么什么是敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发模式:  1.瀑布式开发  瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型,是一种比较老的计算机软件开发模式, 也是典型的预见...
1 2 3 4 5 ... 20
收藏数 133,084
精华内容 53,233
关键字:

敏捷开发是什么