敏捷开发模型_项目管理《敏捷软件开发原则模式与实践》与《敏捷项目管理》 - CSDN
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的...

    谈谈敏捷开发模型
    我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些兴趣。从那时开始有了迭代开发的概念。随着项目经验的增加迭代的重要性也越发觉得明显。随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。

    但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了一些应用,那个阶段我的主要做法是:

    1、项目中开始划分更短的制品交互周期,而不是以前那样等待产品开发完毕后发布各种测试版本。
    2、更充分与市场人员交流,在市场人员进行需求交底时,让更多的甚至全体成员参与会议,了解产品的原始业务及需求。并且在过程中有问题也及时的解答及沟通。
    3、加强沟通力度,开发测试都在一起每天都会开个小会,通报每日的工作成果,将自己的问题说出来。
    4、不同以往的发布频率,测试从项目开始便要切入到产品生产过程,而不是等到最后所有功能都完成后。从而大大减少变动对计划的影响。

    在做这些工作的时候我并不知道敏捷开发这个东西,直到在2010年进入一个公司非常提倡敏捷开发,已经有了迭代周期、backlog、站立会议、周例会等等,在这个团队中对开发过程有各种规章要求,完全是制度化的,这在我加入的初期非常的不适应。事实上回头想想,那种方式已经变的不敏捷了,完全是一种教条式的应用。

    后来自己有机会回到了老东家,开始自己带团队,很巧老东家被收购后开始推广敏捷开发,只不过因为不是总部,所以这次没有范本,完全由我自己来组织及控制。很高兴这个小团队几个月下来,个人觉得比较成功,当然后面也得到了公司的认可。

    下面就敏捷开发分享一些应该着重注意的点,解决这些问题我想对任何开发团队都会有很大的帮助。

    需求在开发中的重要性

    大量的开发过程告诉我,需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析,这个过程对于一些正规的团队会产生大量的文档,而后交由开发展开产品生产。

    然而,事实却不是想象这么简单,无数的例子说明了一点,仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们,需求是会变的,变的原因很多。在极端的情况下,有些客户签字的需求在开发完后,有需要变更也很正常。

    所以需求是影响软件开发的第一重要因素,需求来源于业务,我们开发的产品不就是因为这些业务才去做的吗?如何需求都无法把握好,还谈什么开发出好用的产品?

    然而如何做好需求呢?我想首先要确立需求的地位,然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

    强调人与人的交流

    不管怎么样开发过程中主要还是靠人的,而且软件开发是个复杂的团体工程,一个小些的产品也会涉及到各类人:客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情,有一方没有处理好结果肯定就会有问题。

    有这样一个例子:客户提出了一个会员管理功能需求,需求人员了解后组织了解决方案,于是交付了开发实现。而经过二个月无尽的黑夜之后交付,需求一看有个模块做的有偏差,但是已经来不及修改了。交给客户看后,发现这不是他们要的会员管理功能相差较大,另外在功能开发的这一段时间,客户又有了新想法,要对原先需求做调整。

    这种例子可能大家经常经历吧?

    这种问题在敏捷开发方法中提出了解决方法,就是通过不断的交付可用的制品。看起来很抽象,其实很简单。同样是上面的例子:
    Ø 客户提出会员管理功能需求
    Ø 需求人员在了解需求后与开发负责人商量,确定一个快迭代的开发计划,每二周向客户演示一次,并将这个计划与客户确认
    Ø 确认后需求人员向全体成员讲解需求背景故事
    Ø 开发负责人组织并确定迭代计划内容,明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
    Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
    Ø 后面就是每二周向客户演示一次产品,并获得客户的反馈
    Ø 根据客户的反馈调整下个迭代计划,并继续下一个迭代
    Ø 直到产品交付

    通过上面的步骤,就不至于在开发完成后才知道用户的真实想法,因为很多用户对软件开发是没有概念的,他只知道自己有某种需求,但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型,这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内,这样一来可以大大的减少软件返工的情况,自然就不会拖延计划了。

    而这个过程中,需求已经完成了一个真正的过渡,不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的,在开发不断的交付制品时,需求也更加及时的了解到产品的进度,把握开发人员开发的功能是否符合需求。
    当然这并不是一个标准做法,不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去,及时的与客户沟通交流,了解到客户的真实想法。

    强调文档的作用

    我觉得很多对敏捷开发的一个误解就是不需要文档,敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中,特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理,最痛苦的是不好维护,文档需要随着变化而变化,比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性,太难了。特别是对于一些无法进行有效管理的开发团队就更加明显,经常是软件已经几个版本了,文档却是两年前的。

    但敏捷真的不需要文档吗?我想不是的,如何把文档做到好维护我想才是最重要的。文档到底指的指的什么?什么样的算文档?

    提出上面两个问题,我们先想想经常说的文档的作用是什么?不就是一个传播工具吗?可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题,比如wiki系统。维护一个wiki系统,可以随时写,随时维护,可以方便的查找。嗯,多方便。

    另外一个问题就是什么样的工作需要形成文档呢?

    记得在前一家公司,维护一个10多年的老系统修改一个公式计算的BUG,但是怎么也不知道这个复杂的公式是什么意思,问过了公司大部分的人也无人可解。这时想,如果当初有那么一份文档,谢天谢地。

    像这种关键的内容有份文档还是很重要的,否则随着时间推移,谁也不能保证能记得住当时为什么会这么干。

    记得多年前一次记笔记的经历,我看了一篇文章了解了DELPHI实现单实例模式的方法,这种方法很酷。于是整理成了笔记写在了wiki上,第二天就得到了回复,帮助到了别外产品开发组的同事。

    嗯,文档就是这样他具有传播性,你不可能跑去跟所有人说出你的想法,但是文档却更容易达成。他也有传承性,有些文档也许10多年后又起了重要作用。

    团队协作

    1、减少对开发人员的干扰

    曾经接手一个产品的开发,最初遇到一个很头痛的问题,原先写好的迭代计划,而且工作量也较大,大家都在忙着。即便在这样的状态下,客服人员却经常跑来找某个程序员A维护各种系统问题,程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力,而每天的这些问题又不得不解决,加之新版本又有很重的开发任务无法完成,最终导致整个开发计划变更。

    我无法再忍受,找到了需求及客服的负责人,沟通后发现这些问题很多都是重复性的,主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能,并交付给了客服人员,之后就没有再来找过这位程序员A。后续我又找到了客服负责人,要求不能直接找开发人员解决这类问题,并与负责人约定了处理过程。

    这是个例子,在实际情况中还有很多这种事情,甚至有很多开发人员要直接面对客户。我想对于职能型团队来说,开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

    大部分的人都不是超人,在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点,尽量让开发人员有比较好的工作进度环境,通过外界的方式来解决一些开发团队的干扰。

    我接触过的很多程序员都很反感这种干扰,虽然有些人在这种全面的工作强度下成长很快,但是并非所有人都适应,长期下来会有怨恨和不快,工作效率会下降。心情舒畅还是很重要的,记得有一次迭代总结时,有个程序员总结说:发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

    2、不要忽略测试人员在开发阶段的作用

    曾经多少次在项目发布前加班到深夜2点的情景还历历在目,那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了,产品却迟迟未集成完成,测试只能干等着上网聊QQ。就在下班前的一刻发布了,测试开始了紧张的测试,在屏幕闪动中,一个个的BUG提交,直到流程都无法都走不下去,测试无奈了。第二天就要发布,实施人员就等着制品第二天出差。只有不断的改,再发布,无尽的循环。直到大家都憔悴的看着老大,终于老大说:还剩下的这几个问题无关紧要,大家回去吧。

    几个月的开发过去后在总结会上,只能抱怨测试资源不足,时间太短,需求更改太多,需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

    上面的这个例子很多人应该经历过,真的测试只有最后一刻才能体现价值吗?我想不是的。

    在后面的项目中我总结了这个问题的,针对每个开发任务要求进行测试验证。而测试如何验证呢?他需要知道这个开发任务的需求是如何,提前做好测试计划及测试用例,在接到开发制品后测试并提交BUG,这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量,可以大大减少后期集成的错误量。

    另外根据敏捷开发的思想,测试团队在开发过程中也需要加强与开发团队的交流,甚至有必要组成虚拟团队,位置调整到一起,这样可以及时快速的交流,参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度,反过来把握测试计划及测试内容。

    特别是测试从另一个角度来审视需求,这样也可以一定程度上发现或者改善需求上的不足。

    3、发挥团队人员的潜力

    敏捷开发比较提倡开发任务由开发自己评估并认领工作任务,这样可以激发开发的潜在动力。

    之前在做一个新产品时,需要使用java,而我们团队是使用C#的,面临转型问题。而有一位同事很感兴趣,于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高,我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时,这位小伙已经成为了团队的大牛,大家有问题都找他解决。也正是因为这个过程,这位小伙被全面激活,也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

    所以充分发挥好每个人员的特点,让人能够在自己感兴趣的工作中,效果会很多。减少指派方式的任务的分配,充分发挥个人的主动性,这个团队精神面貌也会好很多。

    4、管理者不要离团队太远

    作为团队的Leader要参与到团队的工作中去,比如一个开发主管一定要写写代码,参与架构等对项目有关的事情,而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

    特别是有些开发主管在带队后离团队越来越远,有时对于开发进度不如意时就说:“这么个简单功能怎么会搞了这么久?”,其实每天都在加班的同事心里想着:“有本事你来?”,即使这个小组长有这个能力,但对于团队来说也不是一件好事,因为大家都抱有怨恨之心,还谈什么好好工作呢?这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因,并且自己要加入到解决问题的工作中去,而不是在边上抱怨别人。

    5、小组织不要搞太多的官

    中国几千年的文化,官本位一直影响着我们,大家都想坐在那指挥,自己啥事也不用干,想想都惬意。在我们这个行业是不是发现也很类似?大家都想着干几年当个小组长,然后升个部门经理,当上CTO迎娶白富美。

    团队的管理基本是事与人的管理,非常的伤脑和心。如果一个组织内,特别是小组织内“官”太多,协调就会非常的难,大家就会经常性的扯皮。

    结束

    与敏捷开发结缘也有几年,从开始的抵触到后面的认可经历了许多,这个过程并不是一蹴而就的,需要花时间花精力,特别是要去实践、总结。

    还有我觉得是不能太教条,很多事情都要有怀疑的心,然后去实践总结,找到合适自己团队的方式方法。

    展开全文
  • 文章目录敏捷开发的定义应用场景和特点开发宣言开发原则 敏捷开发的定义 以用户的需求进化作为核心,采用迭代、循序渐进的方法进行软件开发。 换句话说就是把一个大的项目分为多个相互联系,但也可以独立运行的小...

    敏捷开发的定义

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

    换句话说就是把一个大的项目分为多个相互联系,但也可以独立运行的小项目(story?
    ),并分别完成,在这个过程中软件一直处于可使用的状态。

    应用场景和特点

    在软件项目的构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。

    开发宣言

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

    注:虽然右项也有价值,但是我们认为左项具有更大的价值。

    开发原则

    1. 快速迭代
    2. 让测试人员和开发者参与需求讨论
    3. 编写可测试的需求文档
      开始就用“用户故事”(user story)的方法来编写需求文档。
    4. 多沟通,尽量减少文档
    5. 做好产品原型
      建议使用草图和模型来阐明用户界面,并不是所有人都可以理解一份复杂的文档,但人人都会看图。
    6. 及早考虑测试。
    展开全文
  • 敏捷开发模型

    2019-09-24 15:25:24
    目录 Agile Unified Process Process of AUP Methology of AUM domain model use case model actor use case abstract use...

    Agile Unified Process

    敏捷开发模型

    Process of AUP

    1) Identifying requirements
    2) Deriving use cases to satisfy the requirements
    3) Allocating use cases to increments
    4) Carry out each increment
    4.1) Use case modeling
    4.2) Domain modeling
    4.3) Interaction modeling
    4.4) Derive design class diagram
    4.5) Implementation and deployment

    Methology of AUM

    在这里插入图片描述

    domain model

    use case model

    actor

    use case

    abstract use case

    high level use case

    ASIM - expanded use case

    OIM

    scenario table

    sequence diagram

    DCD

    参考:
    《Object-Oriented Software Engineering》David C. Kung
    Software Design Pattern, USTCSSE, David C. Kung

    转载于:https://www.cnblogs.com/ChengzhiYang/p/11360097.html

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

    2019-05-31 10:49:56
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美...

    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。

    在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    是谁这么厉害,提出了敏捷开发思想?是一位名叫 Martin Fowler 的美国大叔。

    大叔不但是敏捷开发的创始人之一,还在面向对象开发、设计模式、UML 建模领域做出了重要贡献。目前担任 ThoughtWorks 公司的首席科学家。

    敏捷开发模式的分类
    敏捷开发的实现主要包括 SCRUM、XP(极限编程)、Crystal Methods、FDD(特性驱动开发)等等。其中 SCRUM 与 XP 最为流行。

    同样是敏捷开发,XP 极限编程 更侧重于实践,并力求把实践做到极限。这一实践可以是测试先行,也可以是结对编程等,关键要看具体的应用场景。

    SCRUM 则是一种开发流程框架,也可以说是一种套路。SCRUM 框架中包含三个角色,三个工件,四个会议,听起来很复杂,其目的是为了有效地完成每一次迭代周期的工作。在这里我们重点讨论的是 SCRUM。

    SCRUM 的工作流程

    学习 Scrum 之前,我们先要了解几个基本术语:

    Sprint:冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要 2-6 周时间。
    User Story:用户的外在业务需求。拿银行系统来举例的话,一个 Story 可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。
    Task:由 User Story 拆分成的具体开发任务。
    Backlog:需求列表,可以看成是小目标的清单。分为 Sprint Backlog 和 Product Backlog。
    Daily meeting:每天的站会,用于监控项目进度。有些公司直接称其为 Scrum。
    Sprint Review meeting: 冲刺评审会议,让团队成员们演示成果。
    Sprint burn down:冲刺燃尽图,说白了就是记录当前周期的需求完成情况。
    Release:开发周期完成,项目发布新的可用版本。
    在这里插入图片描述
    如上图所示,在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份 Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的 Sprint Backlog,再细化成一个个 Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行 Daily meeting,根据情况更新自己的 Task 状态,整个团队更新 Sprint burn down chart。

    当这一周期的 Sprint backlog 全部完成,团队会进行 Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的 Release,并且进行 Sprint 回顾会议(Sprint Retrospective Meeting)。

    那么,现实中的 Scrum 是什么样的情景呢?看看下面的照片就知道了:
    在这里插入图片描述
    敏捷开发与 DevOps
    DevOps 是 Development 和 Operations 的合成词,其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢?需要我们的项目做到持续集成、持续交付、持续部署。

    时下流行的 Jenkins、Bamboo,就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • 敏捷开发 模型讲解

    2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 传统的开发模式敏捷开发模式的对比? 敏捷开发scrum的实施。 什么是敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中,软件项目在构建初期被...
  • Scrum (英式橄榄球争球队), 软件开发模型敏捷开发的一种,在最近的一两年内逐渐流行起来。Scrum的基本假设是:开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,...
  • 敏捷开发

    2018-07-29 20:20:08
    敏捷开发遵循软件自底向上生长的过程,不断地进行迭代增量开发,最终交付符合客户价值的产品。 1、“个体和交互”强调的是团队的作用,这个团队一定是包含设计、开发、测试、质量、PO,一起参与到开发过程中...
  • 传统开发模型与敏捷开发模型的区别(!!!重点) 传统开发模型有: 瀑布模型, 螺旋模型, 增量迭代模型. 瀑布模型适合 "需求相对稳定或需求变更少"的项目 螺旋模型适合 "复杂度高, 风险大, 规模大"的项目 增量迭代模型...
  • 敏捷开发模式,往往传统以功能测试为主的测试难以适应新的角色,而敏捷团队也面临着产品质量和快速市场的压力,需要通过快速的迭代抢占市场,但另外一方面质量的问题,又可能导致市场丢弃,这时,测试应尝试调整...
  • 敏捷开发模式

    2020-07-29 14:20:06
    敏捷开发思想理解,Scrum开发方法理解,Scrum与CMMI差异
  • 一、敏捷开发/测试的特征  1. 敏捷开发提倡迭代式和增量式的开发模式,并强调测试在其中的重要性。  敏捷开发模式的三个特点:依赖客户的参与、测试驱动以及紧凑的迭代开发周期。  2. 敏捷测试是协同测试的一...
  • 敏捷开发模式,实质是一种以人为本的开发理念,重视团队沟通,重视客户反馈,重视产品迭代。 根据Agile的思想,我们主要有Scrum和XP两种开发实践,XP中又以TDD较为流行。 Scrum 项目经理从客户(产品经理)获取...
  • SCRUM(敏捷开发模式)演讲PPT,SCRUM(敏捷开发模式)演讲PPT
  • 敏捷开发模式的修炼之道 CSDN:请问你是如何接触到敏捷开发的?你如何理解敏捷开发? 黄勇:曾经我们开发项目都是采用传统的“瀑布式”流程进行开发,即需求、设计、开发、测试、上线等阶段,其中每个阶段都...
  • 瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 因为笔主经历过瀑布开发模式敏捷开发模式这两种开发模式,所以存在有一些自己的见解跟大家交流。 下面所以我们这边先来简单介绍下这两种模式: 瀑布开发模式: 瀑布开发模式是由W.W.Royce在1970年最初提出的...
  • 主要有:1)测试团队在敏捷开发模式下的价值非常有限;2)开发人员只顾自已写代码,没有任何文档,测试人员无从下手,3)由于进度的原因,测试人员测试的时间非常有限,上线后出现很多问题;4)由于测试人员得不到...
  • 引言 随着计算机的普及,软件工程成为了计算机产业中特别重要的一个产业。自从瀑布式开发模式提出之后,软件工程就走上了规范化的道路。...本文从传统开发与敏捷开发模式出发,对比敏捷开发与传统开发,浅析现...
  • 敏捷开发流程模型图当中可以看出,在敏捷实施过程当中,有四种会议,分别是计划会,每日站会,回顾会,评审会,其中数计划会最为重要。应该来说会议是有点多的,不是流传一种说法嘛,不开会的团队的一定不是一个好...
1 2 3 4 5 ... 20
收藏数 82,216
精华内容 32,886
关键字:

敏捷开发模型