敏捷开发感想总结_项目总结感想 - CSDN
  • 三名海军上将谈论起什么是真正的勇气。德国将军说:"我告诉你们什么是勇气。"说完他召来一名水手。"你看见那根100米高的旗杆了吗?我希望你爬到顶端,举手敬礼,然后跳下来!"德国水手立即跑到旗杆前,迅速爬上顶端...
    		2007年04月15日 23:37:00	

    Author:袁琳
    MSN:testwin@sohu.com

    什么是勇气?

    三名海军上将谈论起什么是真正的勇气。
    德国将军说:"我告诉你们什么是勇气。"说完他召来一名水手。
    "你看见那根100米高的旗杆了吗?我希望你爬到顶端,举手敬礼,然后跳下来!"
    德国水手立即跑到旗杆前,迅速爬上顶端,漂亮地敬个礼,然后跳了下来。
    "呵,真出色!"美国将军称赞说。接着他叫来一名美国水兵命令道:"看见那根200米高的旗杆了吗?我要你爬到顶端,敬礼两次,然后跳下来!"美国水兵出色地执行了命令。
    "啊,先生们,这真是一次难忘的表演。"英国将军说,"但是我现在要告诉你们,我们皇家海军对勇气的理解。"
    他命令一名水手:"我要你攀上那根300米高的旗杆顶端,敬礼三次,然后跳下来!"
    "什么,要我去干这种事?先生你一定神经错乱了!"英国水兵瞪大眼睛叫了起来。
    "瞧,先生们,"英国将军得意地说,"这才是真正的勇气!"

    勇气源于什么?

    勇气并非源于内心对某种事物的恐惧,而是源于自信、知识、情绪、环境等各种因素的综合评估决策。

    有勇气的人

    愿意提出自己的观点,哪怕这些观点并不受人欢迎。不会为了规避冲突而屈服于压力或他人的观点。能够坚持自己认为是正确的东西。能够根据现实的状况,对自己的想法与思考方式做出改进。能够承认自己所犯的错误,愿意对自己的行为与想法承担责任,并对此错误进行深入的探讨。

    敏捷 & 勇气

    1、有勇气主动挑战工作,并承担责任。

    2、有勇气只进行简单的设计,并相信它能够满足客户需求。

    3、有勇气编写测试代码,并相信测试代码能够满足需求。

    4、有勇气拥抱变化,积极适应变化,响应客户需求。

    5、有勇气在需求变化时重构代码。

    6、有勇气不断采用新的开发技术或方法,不断改进,以提高用户满意度。

    7、有勇气对自己的阶段工作进行回顾,总结自己错误的行为并及时纠正。

    8、有勇气面对各种困难和风险,鼓励并带领伙伴一起齐心协力、克服困难、渡过难关。

    9、有勇气向客户承诺并达到它。

    10、有勇气对用户说"不"。尊重用户价值,对用户负责,不欺瞒用户。

    11、有勇气挑战权威,表达自己正确的见解并用实践证明。

    12、有勇气接受任何成员的好建议并改进之。

    ... ...



    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1565871


    展开全文
  • 敏捷开发实践总结

    2017-12-03 20:21:15
    敏捷开发实践总结 前言 敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和...
    敏捷开发实践总结

    前言
    敏捷开发它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

    什么叫敏捷开发?
    敏捷开发(Agile Development)是一种以人为核心迭代循序渐进的软件开发方法。敏捷开发作为CMM神话崩溃后被引入的一套新的软件开发模式。

    对概念的理解:
    以人为核心:敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。而瀑布开发模型,它是以文档为驱动的,整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据。
    迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    敏捷开发的4句宣言
    1,个体与交互 胜过 过程与工具
    2,可以工作的软件 胜过 面面俱到的文挡
    3,客户协作 胜过 合同谈判
    4,响应变化 胜过 遵循计划

    我对这4句宣言的理解:
    产品结果大于形式,先把产品做出来,然后再整理出完善的文档
    在互联网软件产品开发过程中,需求是不断发生变化的,需要对原有的计划及时更改,应对变化。

    为什么要使用敏捷开发模式?
    敏捷开发注重人与人之间的交流和合作,可以快速实现功能,以小步快跑的形式,不断试错,不断调整方向,不断完善产品。总结起来就是:适应变化,不断迭代。

    scrum流程图:


    scrum 开发中的三种角色:
    1,product owner:产品负责人,确定大家要做什么(一般产品经理)。
    2,scrum master:scrum的推动者,掌握大节奏的人。
    3,team:一般由多个developer组成,开发的主力。

    scrum 开发中的三大神器
    1,production backlog(产品待办事项列表)
    2,print backblog(详细任务列表)
    3,sprint burn down(计划走向和实际走向组成燃尽图)

    scrum 开发中的四个会议:
    1,sprint计划会(理解需要做什么,然后讨论怎么做)
    2,每日站会(昨天做了什么,今天打算做什么)
    3,sprint 评审会(大家评审sprint产出,然后对待办事项做相应调整)
    4, sprint回顾会(讨论哪里完成好,哪里需要改进)

    SCRUM敏捷开发流程是什么?

    1、Product Backlog(产品需求列表)我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
    3、Sprint Planning Meeting(Sprint计划会议)有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
    4、Sprint Backlog(迭代任务列表) Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
    5、Daily Scrum Meeting(每日站立会议)在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
    6、Daily Build(每日集成) 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
    7、Srpint Review Meeting(评审演示会议) 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
    8、Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
    9,重构 因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。
    10,TDD(测试驱动开发)。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

    下面是crum开发流程中的一些场景图:
    上图是一个 Product Backlog 的示例,产品需求列表

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

    上图就是任务看板了,任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)。

    作为客户端开发人员在实际的迭代开发过程中,有以下感想和总结:
    1,每日的站会迫使人去对昨天的工作做一个小总结和今天的工作计划,无形中让让人做事更加的积极
    2,及时是敏捷开发,也要尽可能的有详细的需求
    3,在实际的开发过程中也需要写api文档,并且尽可能写上注释,以便于其他人的理解
    4,严格按照开发流程去走,但不要流于形式,否则就是浪费时间
    5,坚决杜绝以下问题的出现:
    需求拍脑袋随意改动,叫快速试错迅速响应用户需求;
    代码质量低劣不停出更新版本,叫快速迭代中;
    不写正规设计文档,叫降低沟通成本和最好的文档是代码;
    领导站身后指挥码农写代码,叫结对编程;
    产品质量不靠设计靠测试的,叫测试驱动研发;


    参考:


    展开全文
  • 敏捷开发的主旨: 一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值直接聊宗旨有些抽象了,举些栗子就会发现这...

    敏捷开发的主旨

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

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

    以下内容为转载: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:所有的模式都不应该是教条的模式,先进的模式并不是好的模式,适合自己的才是最好的。套用一句俗话:不管黑猫白猫抓得住耗子的才是好猫。

    展开全文
  • 昨天参加了了一个敏捷开发培训,现在还有印象的几个 1. 向已经delay的项目增加没有经验的人手,通常会进一步增加delay 2. 通常说来,一个人同时工作在多个任务上,会造成人的过载及任务的延时,其原理可用M/M/1/ ...

    昨天参加了了一个敏捷开发培训,现在还有印象的几个

    1. 向已经delay的项目增加没有经验的人手,通常会进一步增加delay

    2. 通常说来,一个人同时工作在多个任务上,会造成人的过载及任务的延时,其原理可用M/M/1/ 排队论来解释

    3. pair coding vs. code inspection

    通常的code inspection模式:

    a) 作者写code/design

    b)其他人进行inspection/review

    这样的效果通常不如pair coding

    第一、三轮pair coding 的代价160%, 120%,但是缺陷率降低超过10%

    4. 通常一个scrum团队合作4年后,能够达到效率最高的状态

    5. 不恰当的工作方式,除了造成自己的低效外,也浪费了别人的时间,降低了效率

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15073326/viewspace-608310/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/15073326/viewspace-608310/

    展开全文
  • 敏捷开发学习心得

    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、硬盘、主板……这属于颗粒太细,虽然得到了自己想要的东西,但是不能马上用,还需要自己组装之后才可正常使用。

    展开全文
  • 敏捷开发学习

    2019-08-19 23:17:55
    何为敏捷项目管理 顾名思义,“敏捷”代表快速响应,快速行动。“快”即它的核心,而敏捷项目管理在很多方面都很好地诠释了“快”。当面对项目范围不明确,且相关方需求快速变化的环境时,敏捷项目管理的理念显然是...
  • 个人作业week7——前端开发感想总结 1. 反思 首先要谈谈在这次团队项目的工作中,我这边出现过的较为严重的一个问题:我和HoerWing (后端担当)合作时,最初因为我没有使用github(始终连不上,最后才确认是宿舍...
  • 敏捷实践感想记录

    2012-06-19 13:00:10
    09年写在博客园的文章,现在转过来 Scrum计划会: 目前我们进行了两轮Sprint,每个Sprint3周。第一个Sprint比较仓促,大家也就是混囵吞枣,照葫芦画瓢。提前选出了Story,感觉不是太好,没有关注大家的意见...
  • 我曾经管理和经历过使用所谓“敏捷开发”的两个相对比较大的项目。之所以是“所谓的敏捷开发”,掺杂了不少了自己的实现和理解,见笑了。  第一个所谓的敏捷开发的项目是迫不得已的,因为项目前期投入大而且人事...
  • 最近看了一本书关于极限编程的,对于计划的设置那部分看后有一点体会。对于软件项目的时间估计,是个难点。文中提到,将任务功能划分成要素,根据每个要素需要的时间来...对于陌生的开发环境和语言,开发延期的风险较
  • 2010年我对个人管理进行了自 己的一些思考,在2011年提出敏捷个人概念,并且在线上、线下进行了多次交流,在一些大会上也做过分享。现在,已经有很 多IT和非IT的敏友们知道并在践行敏捷个人,帮助自己更快的成长。我...
  • 敏捷开发感想

    2019-07-27 20:24:32
    敏捷开发是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间...
  • 上一篇浅谈敏捷开发及Scrum(一)概念与理解写了一些关于敏捷开发和Scrum的相关概念及个人理解,这里来说说实施与遇到的一些困难。 如何实施 敏捷开发的实施,我们是用的Scrum迭代开发,关于Scrum的一些介绍上一篇...
  • 拥抱变化 敏捷开发

    2008-08-27 17:26:12
    二弟的一篇介绍 敏捷的文章,希望有机会在 GBS 的系统实施中能够早日用上 敏捷 关于敏捷 2008-08-27 10:02 | (分类:默认分类) 今天写实习总结,描述了一下这几个月的收获。截取其中的一段关于敏捷感想。...
  • 团队之敏捷开发

    2009-02-28 12:30:35
    进入公司差不多有3年的样子了,大大小小的项目参与了不少,... 这段时间,“敏捷开发”变的很时髦,似乎不“敏捷开发”就落伍了,那么到底什么是“敏捷开发”呢?简而言之,敏捷是一种新的软件开发的思想,通过迭...
  • 20169205实验三 敏捷开发与XP实践 实验内容及步骤 (一)敏捷开发与XP基本知识 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 一项实践在XP环境中成功使用的依据通过XP的法则呈现,...
  • 敏捷开发核心思想

    2013-08-07 13:50:32
    敏捷开发中心思想:迭代式开发、自组织团队。 自组织团队必须具备素质: 1.必须是一个团队:构架师、需求人员、开发人员和测试人员组成的是一群人 2.团队的核心目标:团队共同的工作理念与文化形成一个基本的...
  • 以传统的瀑布式开发,抛砖引玉出敏捷开发。两种方式以漫画的形式,产生出对比。用通俗的语言简短介绍了敏捷开发特点。对敏捷开发众多分类中的SCRUM重点阐述了,详细的流程。 一、漫画形式说明敏捷开发 使用两...
  •  1)短期的迭代目标: 传统的开发方法,整个软件开发完成后才发布,周期长所以收到客户反馈的时机晚。 XP的做法是按照需求的优先级,持续制定短期的开发目标(或小版本),完成一个小周期就发布一次,尽早取得客户...
1 2 3 4 5 ... 20
收藏数 680
精华内容 272
关键字:

敏捷开发感想总结