敏捷开发模型图和描述

2020-03-22 11:36:31 IGGIRing 阅读数 113
  • 敏捷开发(一)

    使学时理解软件工程相关概念知识,掌握软件工程的相关过程,掌握常用的软件工程工程过程,能够通过软件工程指导软件开发过程。

    528人学习 刘安战
    免费试看

 

  • 经典过程模型(瀑布模型)

    • 可行性分析(研究做还是不做),输出《可行性分析报告》。
    • 需求分析(研究做什么),输出《需求规格说明书》和产品界面原型图。
    • 概要设计和详细设计,输出概念模型图(ER图)、物理模型图、类图、时序图等。
    • 编码 / 测试。
    • 上线 / 维护。

    瀑布模型最大的缺点是无法拥抱需求变化,整套流程结束后才能看到产品,团队士气低落。

  • 敏捷开发(Scrum)- 产品所有者、Scrum Master、研发人员 - Sprint

    • 产品的Backlog(用户故事、产品原型)。
    • 计划会议(评估和预算)。
    • 日常开发(站立会议、番茄工作法、结对编程、测试先行、代码重构……)。
    • 修复bug(问题描述、重现步骤、测试人员、被指派人)。
    • 发布版本。
    • 评审会议(Showcase,用户需要参与)。
    • 回顾会议(对当前迭代周期做一个总结)。

    补充:敏捷软件开发宣言

    • 个体和互动 高于 流程和工具
    • 工作的软件 高于 详尽的文档
    • 客户合作 高于 合同谈判
    • 响应变化 高于 遵循计划
2015-05-28 22:40:58 swebin 阅读数 18314
  • 敏捷开发(一)

    使学时理解软件工程相关概念知识,掌握软件工程的相关过程,掌握常用的软件工程工程过程,能够通过软件工程指导软件开发过程。

    528人学习 刘安战
    免费试看

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

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

我们技术团队人员是这样的配置: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敏捷团队
2017-09-25 11:21:16 struggle6688 阅读数 3601
  • 敏捷开发(一)

    使学时理解软件工程相关概念知识,掌握软件工程的相关过程,掌握常用的软件工程工程过程,能够通过软件工程指导软件开发过程。

    528人学习 刘安战
    免费试看

1.瀑布模型

  1.1 瀑布模型介绍

 

  1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

 

  1.2 瀑布模型核心思想

 

  瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

 

  1.3 瀑布模型有以下优点

 

  (1)为项目提供了按阶段划分的检查点。
  (2)当前一阶段完成后,您只需要去关注后续阶段。
  (3)可在迭代模型中应用瀑布模型。
  增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

 

  1.4 瀑布模型有以下缺点

 

  (1)在项目各个阶段之间极少有反馈。
  (2)只有在项目生命周期的后期才能看到结果。
  (3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
  (4)瀑布模型的突出缺点是不适应用户需求的变化。
--------------------------------------------------------------------------------------

 

2.迭代模型

  2.1 什么是迭代模型

 

  在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:需求、分析设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

 

  2.2 迭代模型的使用条件

 

  (1)在项目开发早期需求可能有所变化。
  (2)分析设计人员对应用领域很熟悉。
  (3)高风险项目。
  (4)用户可不同程度地参与整个项目的开发过程。
  (5)使用面向对象的语言或统一建模语言(Unified Modeling Language,UML)。
  (6)使用CASE(Computer Aided Software Engineering,计算机辅助软件工程)工具,如Rose(Rose是非常受欢迎的物件软体开发工具。)。
  (7)具有高素质的项目管理者和软件研发团队。  

 

  2.3 迭代模型的优点  

 

  与传统的瀑布模型相比较,迭代过程具有以下优点:
(1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
(2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。
(3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
(4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。
--------------------------------------------------------------------------------------

 

3.敏捷开发模型

  3.1 什么是敏捷开发

 

  是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本。能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。敏捷建模(Agile Modeling,AM)的价值观包括了XP的四个价值观:沟通、简单、反馈、勇气,此外,还扩展了第五个价值观:谦逊。

 

  3.2 敏捷开发特点  

 

  (1)人和交互 重于过程和工具。
  (2)可以工作的软件 重于求全而完备的文档。
  (3)客户协作重于合同谈判。
  (4)随时应对变化重于循规蹈矩。  
  项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果:关注业务优先级; 检查与调整。
  
  最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,
因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。

 

4.螺旋模型

 

  详见 http://baike.baidu.com/view/551040.htm  

 

5.快速原型模型

 

  详见 http://baike.baidu.com/view/1449532.htm  

 

6.几种模型间的对比

 

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

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

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

敏捷开发,相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。
  敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。 

 

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

参考文章:

1.瀑布模型百度百科参考  http://baike.baidu.com/view/551037.htm

2.迭代模型参考http://baike.baidu.com/view/1380740.htm

3.敏捷开发参考http://baike.baidu.com/view/309926.htm  

4.软件开发模式对比(瀑布、迭代、螺旋、敏捷)  http://www.cnblogs.com/-OYK/archive/2012/10/08/2714669.html

2019-06-27 17:05:44 weixin_37641163 阅读数 2877
  • 敏捷开发(一)

    使学时理解软件工程相关概念知识,掌握软件工程的相关过程,掌握常用的软件工程工程过程,能够通过软件工程指导软件开发过程。

    528人学习 刘安战
    免费试看

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

 

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

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

 

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

 

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

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

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

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

 

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

 

 

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

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

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

 

敏捷开发优点:

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

2017-03-01 16:56:54 zhyb0306 阅读数 7450
  • 敏捷开发(一)

    使学时理解软件工程相关概念知识,掌握软件工程的相关过程,掌握常用的软件工程工程过程,能够通过软件工程指导软件开发过程。

    528人学习 刘安战
    免费试看

CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法?

黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想,Scrum 是对让这个思想落地的一个参考。也就是说,我们大可不必完全拘泥于 Scrum 定义的规范,只需要参考它并结合自身的条件做适当调整即可。比如说,每日站会这个环节就非常重要,不管是放在每天上午,还是放在每天下午,总之最好要有固定的周期。此外,每次 Sprint(迭代)结束后除了有评审会以外,Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结,哪些是本次迭代中做的好的地方,哪些是做的不好的,再对比上次迭代的的结论,哪些是有改进的,哪些是新的问题。

Scrum 提供了三类角色,分别是:Product Owner(一般由产品经理担任)、Scrum Master(一般由开发经理担任)、Scrum Team(包括开发与测试人员),其中,Scrum Master 的角色至关重要,对项目的成败起决定性作用。

阿里巴巴也在广泛使用 Scrum 敏捷开发模式,而且整个项目几十人都可以用 Scrum,只是首先需要将整个团队拆分成若干小团队,保证每个小团队按照 Scrum 进行操作,此外,再将每个小团队的 Scrum Master 召集在一起,再做一轮 Scrum,这就是所谓的 Scrum of Scrum。过程稍微复杂一点,但可以将敏捷用于更大的团队规模,并能保证敏捷的效果。

CSDN:你认为Scrum Master 的角色至关重要,对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题?

黄勇:我个人不太建议由产品经理来担当Scrum Master,原因如下:

  1. Scrum Master 关注的是项目开发视角,而产品经理关注的是产品功能视角,两者关注的视角是不一样的。
  2. Scrum Master 需要有一定的技术开发功底,需要对开发工作量进行评估,也需要对技术实现进行评审,可能还会有一定的编码工作,而具有技术功底的产品经理毕竟太少了,即便有的话,可能对技术方面也不会太深入。
  3. 需要有一个人,他来对整个产品负责,这个人就是Product Owner,该角色最好由产品经理来担任。

CSDN:敏捷开发过程中测试团队的职责和产出是什么?

黄勇:在敏捷开发过程中,我认为测试团队的职责有以下几点:

  1. 根据产品需求,定义测试用例。
  2. 针对测试用例进行功能测试,并将测试的结果反馈给开发人员。
  3. 负责搭建系统运行所需的环境,包括软件安装、数据初始化等。

CSDN:除了Scrum,还有XP、CM、FDD、ASD、DSDM等敏捷开发方法,如何去选择一个合适的敏捷开发工具或者方法呢?

黄勇:敏捷开发方法有很多,不仅仅只有Scrum 一种,其实不妨相互借鉴,再结合自身的特点,定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等,这些都是很好的方法,值得借鉴。包括看板也是一个很不错的工具,可以结合Scrum 来工作。

CSDN:从博客上,你也研究过「使用看板进行敏捷开发」,能不能分享你的研究成果?

黄勇:敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

  • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
  • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
  • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


下面我们来理解一下这个表格吧!

  • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
  • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
  • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

好!继续我们的 Kanban,有意思的事情即将发生!


产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!


CSDN:一个成功的项目,离不开每个人的努力,能够分享下你曾经的项目管理经验?

黄勇:给大家提出以下 10 点建议及其目标:

  1. Sprint 第一天,需要将目标定义清楚,并让团队所有人都知道「确保建立一致的目标并使之明确」;
  2. 若出现需求变更,则优先排到下次迭代,特殊情况需特殊处理「确保本次迭代可以按时完工」;
  3. Scrum Master 将迭代中的需求分解为任务,每个任务只能有一个任务负责人,且不超过一个人天「确保每日任务可评估」;
  4. 让 Product Owner 直接与相关开发人员确定需求,Scrum Master 需一同参与「确保需求与实现不会发生偏差」;
  5. 每日定时站会,时长不超过 15 分钟,规模不要太大「确保任务完成情况与计划保持一致」;
  6. 每日进行一次代码评审,由 Scrum Master 负责,并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」;
  7. 各个团队的 Scrum Master 保持每日沟通一次,时间不要超过 15 分钟「确保项目管理不会出现风险」;
  8. 每次迭代结束,让大家稍微放松一下,可提供一些团队活动,比如聚餐「确保团队能够更加凝聚」;
  9. Scrum Master 需要给团队一些承诺,比如项目奖金或特殊福利等「确保团队更加有激情」;
  10. 对于情绪异常的员工,Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」;

此外,作为项目管理者,需要不断在团队中加强以下 6 点文化:

  1. 方向一致
  2. 当面沟通
  3. 全情投入
  4. 充分信任
  5. 说到做到
文章节选自:http://blog.csdn.net/lifuxiangcaohui/article/details/48342315,如需阅读完整访谈内容,请移步大神博客。