敏捷开发自己的一些感想_敏捷开发感受 - CSDN
  • 敏捷开发学习心得

    2014-02-15 22:03:03
    过年放假这几天读了一些敏捷开发方面的书籍,基于自己敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步...

    过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步的讨论交流就再好不过了。


    我认为敏捷开发应该围绕如下几点进行:

    1、出了现了一个问题或发现了一个bug,第一重要的事情不应该是想办法确定这个问题是谁造成的,而是应该试图去想办法解决这个问题。因为去争论这个问题是谁造成的没有任何意义,有意义的是如何去解决,让系统能正常的工作起来。

    2、发现一个bug,并且时间紧迫,如果不去了解真正的原因就进行快速修复确实能解决它(在最后添加一行代码或者是对结果进行简单的偏移运算)。但是要知道,千里之堤毁于蚁穴,这样的修复日积月累下来就会使项目代码变得凌乱且晦涩难懂。如果在这样的项目之上添加新功能或者进行其他的改动,将会很难下手。所以,未雨绸缪。建议不要孤立的进行编码,要经常阅读团队中别人写的代码(包括单元测试)。自己要对每个功能写好单元测试,写单元测试能帮助代码进行分层,方便别人阅读与理解。这样,不管是你在修改别人的bug还是别人修改你的bug,会相应的顺手一下。这样坚持下去,即可最大限度的保持项目的保持整洁与清晰。

    3、在设计或者代码中遇到了奇怪的问题,应该花时间去理解代码为什么会是这样的。如果找到了解决方法,但是代码仍然不好理解,那么就鼓起勇气去重构它,使它变得容易理解。如果没有马上理解那段代码,就不要轻易的否定和重写它。那不是勇气,那是鲁莽。

    4、养成立会的习惯。顾名思义,立会即站立着开会,参与者不允许在会议中就坐,这样能保证会议的快速进行。因为一个人坐下之后,会由于感到舒适而使会议持续更长的时间。立会可以在每天十点准时举行,每人发言时间控制在三分钟内,会议内容围绕昨天有哪些收获、今天准备做什么、当前面临着怎样的障碍这三个方面来进行叙述。各项问题不进行深入讨论,防止延长会议时间。如果有深入的必要,可以在会后进行。这样的立会可以让团队成员达成共识,并能保证会议短小精悍不跑题。

    5、要寻找深藏不露的程序bug,进行正式的代码复查其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知的方法。代码复查由项目团队中的成员来完成,可采用交换复查的方式。代码复查在团队中某一个成员即将提交代码时进行。代码复查内容包括代码能否被读懂和理解、是否有明显的错误、代码的改动是否会对项目其他部分造成影响、是否存在重复的代码、是否存在可以改进和重构的部分。

    6、和客户讨论问题的时候,准备几种可以让客户选择的方案。从业务角度而不是技术角度向客户介绍每种方案的利弊,以及潜在的成本和利益,以及和他们讨论每个选择需要的时间和预算。如果事后他们又想要其他的东西,可以公正的就时间和成本重新进行讨论。

    7、搭建一个演示服务器,每添加一个新的功能或者是对系统进行优化之后,告知客户访问最新的系统。这样系统每一次迭代都能获取客户的反馈意见,这样也基本保证了项目始终是沿着客户的需求进行开发的。保持项目随时可发布很重要。

    8、很多项目都是因为程序代码失控而陷入困境。修复一个bug导致更多的bug,从而又导致了更多的bug修复。这时我们需要一个频繁的反馈,虽然可能不会使代码更好。但是也不会使代码变坏,至少还是像昨天那样可以运行。此处,使用单元测试就是一个非常不错的选择。单元测试应该在增删改某个功能的时候来运行,至少应该在提交代码的时候运行。单元测试中用来测试的数据应该包含边缘数据(比如11:59:59,0:00:00都是比较好的边缘测试数据),并不能放过任何一个失败的测试。

    9、建议采用先测试再实现的方式进行开发,也就是“测试驱动开发”。总是在有一个失败的单元的测试后才开始编码,测试总是先于代码编写。通常这种测试失败的原因是测试的方法不存在或者是方法的逻辑还不足以让测试通过。先写测试,就会站在用户的角度来思考,而不仅仅是一个单纯的实现者。这样做和先编写后测试有很大的区别,你会发现因为自己要使用它们所以才设计了他们。这种方式能让接口的设计更有效。除此之外,还有助于消除过于复杂的设计,可以专注于真正需要完成的工作。

    10、并不意味着单元测试在自己的机器上能运行,就一定能在其他的机器上能运行。不同的环境可能会有不同的结果。这个和操作系统环境有关,甚至可能和硬件环境有关。

    11、在系统开发中辛苦的编写单元测试用来获取代码的反馈,却往往容易忽视了最终用户的反馈。不仅需要和真实的用户进行交谈,还需要耐心的倾听。即使他们说的内容是一些让你觉得非常直观,非常简单的问题。因为每一个用户的抱怨背后都隐藏了一个事实,我们要做的是找出真相,修复真正的问题,而不是对用户发出嘲笑。

    12、用户在使用系统的过程中如果出现什么错误,不要只是简单的弹出一个错误对话框。应该告知用户发生了什么错误,方便用户进行有效的反馈。如果出于保护代码底层的原因不想让用户知道具体的错误信息,也可以在系统后台给技术支持人员发送一份问题的详尽错误报告。

    13、编写能够清晰表达意图的代码,这样的代码清晰易懂,仅凭小聪明写的那些晦涩难懂的程序很难维护。注释虽然能帮助理解,但是有可能会对理解造成干扰。其实,这里也不是说注释不用写,只是不能让别人完全通过注释才能理解所写的代码。最好是采用规范的命名、清晰的流程、简单的编码等方式来达到代码既是注释的效果。

    14、在代码编写或项目开发的时候应使用增量式的开发方法,即每完成一个功能或者方法的时候确保其对应的单元测试能正确通过。这样,在编码的过程中也能实时不断地获取来自代码的反馈。提交代码之前需要保证所有的单元测试能完全通过。

    15、应具有一个自动化测试环境,每天固定的时间开始从svn检出最新版本的源代码进行单元测试。测试完成之后会生成一份测试报表。这样,每天早上就能获取一份关于最新代码的测试报告。时刻了解项目目前的状况。

    16、编写具有内聚的代码,做到一个方法只做一件事情,一个类只包含他自己所应该包含的方法,一个包只包含应有的模块。这样有利于维护。但是内聚的颗粒不能太粗也不能太细,要拿捏的恰到好处。这样有助于对代码的理解,也降低了项目维护的难度。举个例子:当需去储物室寻找一台电脑的时候,打开们一看,里面乱七八糟的什么都有,后来费了很大的气力才把电脑找出来,这就属于颗粒太粗,没有分好类;当需要去储物室寻找一台电脑,打开门一看,里面大大小小的箱子盒子收拾的井井有条,一眼就看见了一个盒子上面写的电脑二字,打开盒子一看,里面是内存、CPU、硬盘、主板……这属于颗粒太细,虽然得到了自己想要的东西,但是不能马上用,还需要自己组装之后才可正常使用。

    展开全文
  • 敏捷开发的一点感受

    2014-11-30 21:13:12
    用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。  从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触...
        用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。
        从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触,理解的不好还请读者见谅。
        一、从技术角度看:传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档,导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化,甚至产品完成后早已和时代脱节,失去了其本应产生的作用。造成的后果很明了:用户不满意,而且耗资很大。
        而敏捷开发显得更为轻灵多变一些。首先,轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录;另外,对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
        二、从组织管理角度来看,1、我们传统的团队开发很可能存在以下现象。如:部门之间不协调,缺乏充分的沟通,人际交流成为一纸空谈;小组内各成员也常常是各自开发自己的部分,对项目整体或与自己相关的部分也不很了解;沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题,甚至引发矛盾。
         这些问题的根源就来自于缺乏相应的机制进行组织和交流,把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
         2、在项目把控上,传统的开发都是定义好的,根据计划把整体的任务都一次性定好,缺乏灵活性,难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题,使得在项目需求有较大变化时通过先急后缓的方式充分应对。
         3、在部门划分上,敏捷开发提倡按产品划分,而不是部门。把编码和测试人员绑定在一起,使整个开发的过程成为一个流畅的整体,避免了出现相互争资源;把单元测试放到每一个Sprint阶段之后进行,减轻了集成测试的压力,缓和了测试人员由于不理解需求,测试不彻底或描述不准确与程序员产生分歧。
        三、从学习角度看,我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划,在应对变化上要做到灵活,给自己预留足够的缓冲时间。
         做好人际交流,了解集体状况、优秀的或与自己紧密相关的个人的状况,这是自我调整的强有力参考。
         最后,要做好选择,找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上,我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
        
        
    展开全文
  • 感觉从大佬们那里偷学了很多的知识,所以现在才会迫不及待的开始记录下自己学习的心得吧,下面先来看看什么是敏捷开发吧 一、敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代、循序渐进...

    前言

    最近公司搞了一个敏捷开发的平台,需要我们开发需求人员熟悉怎么操作,说实话在这之前虽然也或多或少的知道一点敏捷开发,但是对其没有更加深层次的理解,而且每家公司的要求也是不一样的,另外今天在开会的时候也是受益匪浅,感觉从大佬们那里偷学了很多的知识,所以现在才会迫不及待的开始记录下自己学习的心得吧,下面先来看看什么是敏捷开发吧

    一、敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    上面的这句话是从百度百科上面摘抄下来的,其实随着现在微服务架构的兴起,同时也是未来的趋势,他是将大服务拆分成很多小的服务或者叫做微服务都行,这样做的一个很大的好处就是服务与服务之间的耦合性越来越低了,部署起来也是越来越灵活,其实对于开发人员来说也是一种福音,至少我们开发的时候关注的点更加细致了,更加明确了,所以我认为敏捷开发是对微服务架构的一种补充,或者可以说是相辅相成吧。

    二、平台

    其实上面说了这么多最终的目的还是怎么让开发的流程更加的专业化,首先对于公司来说开发的流程更加专业化,从需求提出到开发到测试到验收的一整套流程在这个平台里面都可以很好的展现,并且还有各种各样的提醒和统计,同时也为公司人员的KPI衡量提供了一个很大的参考,对于个人来说你的需求也变的更加的专业化,有了这一套东西的存在,你的需求变得更加的稳定,从某种程度上来说对程序员也是一种保护。所以好好的用好这个工具是当前的一个重要任务。

    三、规划

    在开会的时候的时候大佬也跟我们分享了一下怎么使自己进步,一个人进步的最大标志就是不会单打独斗了,开始学会怎么去带领一个团队,不管是一个人还是几个人的团队,这是需要我们考虑更多的,大佬说了,你们在需求讨论后定计划的时候是怎么样去计算开发时间的呢?可能很多的人都是随便估计一个时间,有的根本就不知道需要多少时间,所以就胡乱说了一个数字,其实这个时间是可以比较准确的计算出来的,你可以从以下几个方面去入手:1.需要创建几张表或者几个字段;2.需要写几个接口(前后端分离开发);3.有没有逻辑特别复杂的需求;4.加上改bug的时间;5.另外在前面的基础上增加一点“意外”时间。通过上面的几点的分析你基本上就能够比较准确的知道这个需求需要的开发时间了,然后将自己的排期弄好,这样就能够不慌不忙的把事情完成了。

    四、成长

    还有一个问题就是很多人都是喜欢做专一的事,这个我不是很反对,对于年轻人来说更多的是深度,特别是对做技术更是这样,只有你的深度有了之后,然后再去追求广度的事,当然如果你希望成为专家,那就另当别论,更多的发展到最后还是需要走向管理岗的,那么这个时候就是需要你得广度了,因为专的那一部分其实已经有人在帮你在做了,其实这个时候的你也没有时间来做专的事了,所以在我们的日常工作中需要在各个方面去学习,不管是是自己的事还是不是自己的事,我说的是留心,不是抢别人饭碗啊,记得头条的张一鸣就说过自己年轻的时候不管是什么事基本上都是主动去干的,所以成功的人绝对不是偶然。所以需要处处留心,处处学习,这样才能有所收获,最后来一句共勉:不要在该奋斗的年龄选择了安逸!

    展开全文
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 大家都知道,创业公司刚开始需要研发出...

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

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

    我们技术团队人员是这样的配置: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敏捷团队
    展开全文
  • 最近一直在从事DevOps项目,并且公司层面也是敏捷开发的推动者之一,所以对于DevOps和敏捷有了一些自己感受: 今早看了王晔倞在CSDN上发问《为什么都敏捷开发了项目还会延期?》,我有感而发。 敏捷开发的根本是...

    敏捷开发与DevOps的一些随想

    这是笔者第一次在 CSDN上发文章,估计可能读者寥寥。无妨无妨。

    最近一直在从事DevOps项目,并且公司层面也是敏捷开发的推动者之一,所以对于DevOps和敏捷有了一些自己的感受:

    今早看了王晔倞在CSDN上发问《为什么都敏捷开发了项目还会延期?》,我有感而发。

    敏捷开发的根本是满足的灵活性,而非效率的提升。或者换句话说:业务需求和人员投入始终是成正比的,换了啥方式都是一样的,不是说敏捷成了银弹。这是产品经理或业务人员需要明白的问题。所以对于产品需求的取舍、用户倾向的试探就显得尤为重要,或者换句话说,码农们是产品实现的工具,是手和脚,但真正要去哪、干些啥、怎么干还需要产品经理这个大脑来决策。

    敏捷开发来满足快速交付,但只是软件生产全流程中的一段,即:由idea到安装介质包的阶段(可能只作为单元测试,或者单元测试都还没做过)。离产品上线产生价值还远了去了。所以接下来的加速,就需要DevOps以及云的助力,例如:云的编排模块能不能做到自动资源供给,DevOps能不能实现各个环境的自动化部署,能不能将自动化回归测试一并结合进来,等等。

    所以总结下个人观点:

    1. 工具做好工具的事情,但工具只能帮助决策,不能替代决策;
    2. DevOps在传统企业落地,极有可能是Dev和Ops分期来实现,时机成熟时,才串起全流程;
    3. 敏捷、DevOps确实是天生一对,但要一起上,还得看时机才成,但无论是敏捷、DevOps都需要持续的度量、反馈、优化、改进,对流程、对工艺、也是对产品都是一样一样的。
    展开全文
  • 敏捷开发一些问题 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,...
  • 敏捷开发初学体会

    2016-07-25 21:24:00
    刚接触敏捷开发一词时,难以理解它。总觉得它是一种新的项目管理方式,以为它有一套解救我们程序猿的完整方法。所以看书时越看越迷惑,总觉得每本书都没说到点子上,只说一些思路和概念。 这周参加了公司的敏捷培训...
  • ThoughtWorks的敏捷开发

    2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 敏捷开发的主旨: 一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值直接聊宗旨有些抽象了,举些栗子就会发现这...
  • 公司所有开发组目前都在提倡敏捷开发,我所在的开发组也没有out,刚刚发版的产品我们就引入了敏捷开发一些概念--虽然还比较粗糙,但整体感觉还是蛮好的。发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松...
  • 敏捷开发实践总结

    2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
  • 敏捷开发学习心得,自己通过实际的项目总结的经验。
  • 我大概是在2003年接触敏捷软件开发这个...这不是一篇介绍敏捷开发的入门文章, 而是我学习、实施敏捷的一些感想, 如果你没有实践过敏捷软件开发, 不妨到文末看看书籍推荐。 我大概是在2003年接触敏捷软件开发这...
  • 敏捷开发是个啥

    2019-04-01 10:18:32
    今天来篇正经的,从软件工程的角度来聊一聊敏捷开发模式,文章分两部分: 第一部分通过举例和对标其他行业聊聊软件开发模型的发展演进。 第二部分聊聊敏捷的核心思想。 敏捷开发是互联网界比较流行的软件开发模式...
  • 昨天参加了了一个敏捷开发培训,现在还有印象的几个 1. 向已经delay的项目增加没有经验的人手,通常会进一步增加delay 2. 通常说来,一个人同时工作在多个任务上,会造成人的过载及任务的延时,其原理可用M/M/1/ ...
  • hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思。 09年12月,hursing开始在自己的团队推行晨会。当时...
  • 敏捷开发学习

    2019-08-19 23:17:55
    何为敏捷项目管理 顾名思义,“敏捷”代表快速响应,快速行动。“快”即它的核心,而敏捷项目管理在很多方面都很好地诠释了“快”。当面对项目范围不明确,且相关方需求快速变化的环境时,敏捷项目管理的理念显然是...
1 2 3 4 5 ... 20
收藏数 11,922
精华内容 4,768
热门标签
关键字:

敏捷开发自己的一些感想