敏捷开发的感受_敏捷开发感受 - CSDN
  • 关于敏捷开发的一点总结与感悟

    万次阅读 2017-08-01 19:23:51
    一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值

    想到朱少民了,哈哈哈---

    敏捷开发的主旨

      一:个体及交互比流程与工具更具价值
      二:可用的软件比冗长的文档更有价值
      三:与客户的协作比合同谈判更有价值
      四:对变化的响应比遵循计划更有价值

    直接聊宗旨有些抽象了,举些栗子就会发现这个宗旨极恰当。

    以下内容为转载:http://www.lanceyan.com/category/tech/agile

    我们技术团队人员是这样的配置: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:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。







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

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

     

    心中的敏捷

    “敏捷是什么”,这个问题长期以来一直困扰着我。前段时间提出了敏捷问题解决方式,算是从做法(做事的方法)上对敏捷进行了一个简单的总结。最近一直在清理,这就试图描述一下我心中的敏捷。因为个人一直从事软件开发工作,所以文中的主体部分有一些与软件开发相关的经验,不能做到完全的通用化。

    我心中的敏捷

    从信仰、理论到实践与方法学,这就是我心目中完整的敏捷知识体系。

    我心中的敏捷知识体系

    敏捷信仰

    主要内容

    敏捷信仰,也可以被称为敏捷世界观,源于经验主义或逻辑实证主义。其主要内容包括:

    1. 世界是复杂的和不断变化的,人是导致复杂和变化的主要原因

    敏捷对此使用的词汇是我们不能预测未来。这看似不可知论,但其实这句话的意思是我们无法准确预测变化的影响。

    敏捷软件开发是复杂和不断变化的典型,客户、开发团队都处于不断变化中。参考彼得德鲁克的“知识工人”理论,《第五项修炼》等。

    2. 经验主义,小步前进,持续改善

    逻辑实证主义强调经验的获取是建立在实践的基础上。因此在逻辑实证主义看来,经验主义,小步前进,持续改善是应对复杂和变化的最佳方式,也是敏捷的核心。这就是“Kaizen”,持续改善文化的来源。

    对比描述

    敏捷信仰导致了敏捷与其他方式的不同,为方便理解,现进行对比。

    1. 科学主义或唯科学主义Scientism

    科学主义是一种主张以自然科学技术为整个哲学的基础,并确信它能解决一切问题的哲学观点。其主要特点是在尊重科学经验与事实的名义下,推行不可知论和主观经验主义。科学主义的流行导致了事实与价值、科学与人文的分离和对立。

    科学主义影响深远,对于计算机是工程学还是科学,现在仍在争论中,但我们在计算机发展的过程中处处均可发现科学主义的身影。科学主义极大的影响了软件开发的发展历程。

    当我们陷于优劣争论,忙于证明某种方式比其他方式更加科学的时候,已经落入了科学主义的陷阱。

    2. 非理论派与不可知论

    在问题解决过程中,还存在这种纯实践派,他们反对任何形式的理论,主张实践出真知。认为复杂问题是不可预知的,从而没有预知的必要。这是典型的两分法,在实践理论失败后反对一切理论。

    3. 中庸与太极

    敏捷看上去与中国传统的中庸和太极是如此的相似。但是敏捷本质上将没有最佳做法的含义,也不代表混沌。

    敏捷拥有严肃、完整和科学的做事方式,比我们见过的任何一种方法更加的严格。

    4. 精益思想

    精益思想的两大支柱是尊重他人和持续改善,这一点与敏捷惊人的一致,其根源在于他们都源于同样的哲学-逻辑实证主义。

    敏捷理论

    根据个人的理解,敏捷的理论根源主要源于下述理论和更多的实践证明,因为敏捷本身就是实践的结果。

    1. 复杂系统和混沌理论

    敏捷中常见的提法包括系统思考、局部优化等。

    传统软件开发中以分工为基础,更强调分解,不同角色应对分解后的简单问题。敏捷软件开发中强调系统,每个参与者都有机会获取对整个系统的认识,同时“可工作的软件”即分解后的集成在敏捷软件开发中是重中之重。

    2. 博弈论\运筹学\排队论

    敏捷大量应用了博弈论的研究,典型是将软件开发比喻成一种合作博弈。软件开发涉及的利益相关者众多,是一种典型的博弈应用,如何取得多赢,敏捷软件开发对此进行了深入的思考,并对传统软件开发的许多工作方式提出了质疑。

    3. 认知科学\知识工人理论

    敏捷应用了许多对人本身的认知、心智的研究成果。

    a) 人类擅长比较而不是量化

    敏捷软件开发中大量应用比较和趋势,取消了很多无效和成本过高的量化指标。用价值作为软件交付的结果,用计划扑克实践进行基于比较的估算与计划。“尽快交付更高的价值Deliver higher value faster”成为敏捷的目标。

    b) 人类对重复和节奏的偏爱

    c) 反馈对人类的重要作用

    敏捷价值观

    1. 承诺

    2. 专注

    3. 开放

    4. 尊重

    5. 勇气

    敏捷问题解决方式

    敏捷问题解决方式是对敏捷工作方法的总结。敏捷不仅仅是信仰,它还提供了具体的、有效的工作方式。

    1. 保持系统性

    a) 敏捷问题解决方式并未预测问题解决的最佳答案,而只是提出了一种方法框架方便经验获取。

    b) 问题经分解后仍然是问题(单位问题),保持了问题解决的系统性。

    c) 问题的检验注重问题本身的完整性和问题解决方法的系统性。

    d) 敏捷问题解决方式以产出为基准进行回顾和优化,原因在于以投入为基准进行的优化对于复杂系统(非线性)效果不佳。

    2. 沟通与合作的博弈

    a) 敏捷问题解决方式强调问题提出者的参与,增强了问题提出者与问题解决者的沟通合作。

    b) 敏捷问题解决方式通过问题分解模式的转换,对单位问题进行转移视角分解成另一类单位问题并解决,实现问题解决者内部的沟通合作。

    3. 强调人的作用

    a) 问题的解决与否基于问题提出者的主观判断,而非某种客观依据。

    b) 问题的分解基于问题提出者与问题解决者的沟通合作,而非某种预知的科学方式。

    c) 以问题的检验为导向,验证工作方法、问题分解方式的有效性。

    敏捷实践

    敏捷实践是敏捷信仰与敏捷问题解决方式应用于实践的结果。存在大量的敏捷实践,这里就不一一列举。唯一需要强调的是,单独强调某一敏捷实践的作用容易忽视系统性,应该在敏捷信仰、敏捷理论、敏捷价值观和敏捷问题解决方式的指导下,系统的应用敏捷实践。

    敏捷方法学

    敏捷方法学由一系列敏捷实践组成,但是借用XP中的一句话,这些实践结合在一起形成了一个胜于部分结合的整体。

    1. Scrum

    2. XP

    敏捷应用

    敏捷应用

    敏捷适用于解决以人为中心的问题,因此可以广泛应用于上述范围。

    展开全文
  • 敏捷开发 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敏捷团队
    展开全文
  • 敏捷开发--(1)敏捷开发入门谈

    千次阅读 2012-07-31 13:31:52
    公司所有开发组目前都在提倡敏捷开发,我所在的开发组也没有out,刚刚发版的产品我们就引入了敏捷开发的一些概念--虽然还比较粗糙,但整体感觉还是蛮好的。发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 敏捷开发学习心得

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

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

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 正式开发之前咱们先学习一下什么是 敏捷开发 和 XP 极限编程,在实际工作中我们都会采用一些 编程方法论 给我们指引方向,让我们少走弯路。 了解敏捷开发 三分钟了解敏捷开发 小灰经过千辛万苦,终于拿到了心仪的 ...
  • 敏捷开发的Scrum晨会实践

    千次阅读 2013-12-05 10:18:02
    hursing所在的公司推行敏捷开发有两年多了,其中最让人直接感受到的就是scrum晨会。从生搬硬套到过程创新,令大家由抵触变成积极响应,这个过程真的很花费心思。 09年12月,hursing开始在自己的团队推行晨会。当时...
  • 谈谈敏捷开发的误区

    千次阅读 2013-01-25 17:37:00
    今天有人做演讲有关敏捷开发的。就演讲而言,讲得非常好,吐字清晰,语速适当,穿插例子,娓娓道来,将意思表达得非常清楚到位,是个很好的演讲。但就内容而言,我却有很大的异议,当中部分观点我认为是对敏捷开发的...
  • 敏捷开发之XP

    万次阅读 2015-09-25 11:15:11
    XP是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比,其最大的不同在于: 在更短的周期内,更早地提供具体、持续的反馈信息。 在迭代的进行计划编制,首先在...
  • 摘自PM圈子网——项目管理牛人聚集地Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程。在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周...
  • 敏捷流派众多,在此做一个简单的整理与分享。 一、极限编程 极限编程(ExtremeProgramming,简称XP)是由KentBeck在1996年提出的。极限编程是一个轻量级的、灵巧的软件开发方法;同时也是一个非常严谨和周密的...
  • 笔者正在学习《软件工程-实践者的研究方法...敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行...
  • 敏捷开发——SCRUM 近二十年软件开发、软件设计、需求分析、项目管理、部门...
  • 敏捷实践总结(三)——Scrum敏捷开发

    千次阅读 热门讨论 2014-03-24 21:14:09
    最近在参与一个采用敏捷开发的项目,近几天又看了一本关于Scrum的书。在此跟大家分享一下。 敏捷开发不同于以往的瀑布模型开发。 瀑布模型中有严格的文档要求(需求、概要、详细等)、对员工的工作量也有明确的定义...
  • 敏捷开发与极限编程

    千次阅读 2010-03-16 22:57:00
    敏捷开发与极限编程简介 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟,敏捷开发...
1 2 3 4 5 ... 20
收藏数 11,084
精华内容 4,433
热门标签
关键字:

敏捷开发的感受