敏捷开发感悟_项目经理在敏捷开发中的作用敏捷开发 - CSDN
  • 一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值

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

    敏捷开发的主旨

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

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

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







    展开全文
  • 敏捷开发感悟

    2006-07-17 12:58:00
    敏捷开发的精髓在于快速响应。响应什么?相应变化。谁的变化?需求的变化。 如果我们能够每隔一秒钟就从用户那里重新获得需求,然后进行分析、设计、编码、测试,那么我们就不会抱怨用户的需求总是变化了。因为在这...

    敏捷开发的精髓在于快速响应。

    响应什么?相应变化。

    谁的变化?需求的变化。

     

    如果我们能够每隔一秒钟就从用户那里重新获得需求,然后进行分析、设计、编码、测试,那么我们就不会抱怨用户的需求总是变化了。因为在这一秒钟的时间段里,用户的需求没有任何变化。但是显然,这不可能。

     

    不可能的地方有两个,一是我们不能每一秒钟就重新获得一次需求。二是我们不可能每次都对用户的需求重新分析、设计。

     

    但是我们可以找到一个相对平衡的时间段和需求块,尽管不是完美的平衡。时间段有多长?取决于用户需求变化的速率。需求变化得越快,那么获取的频率应该越高。每次对多少需求进行分析和设计?这取决于我们拥有多少时间以及我们的工作效率。(对这句话我还不是特别肯定)。

     

    为什么需要重构?因为它会使代码更灵活,拥有更好的反应能力。

    为什么要拒绝腐化的代码?因为死人是永远不会做出响应的。

    展开全文
  • 一 引言 近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,实施敏捷开发大哥们们请教. 感觉是个好东西.它是...

    一  引言
      
          近来,在BOSS系统团队敏捷开发熏陶和感染下,对敏捷开发求知是蠢蠢欲动. 心动不如行动. 咱也不能被动接受挨打吧. 这几天向战斗在BOSS一线具体参入人员问了卷,
    实施敏捷开发大哥们们请教. 感觉是个好东西.它是对传统的以瀑布模式为主的项目管理一次抽取精华和改进(个人认为,PMB项目管理的理念,敏捷开发中具体方法都有它的影子,只是浓缩精华).但觉得脑子里只是一些零散的概念,没有对敏捷开发系统理解。没有整体把握,底气不足,作为敏捷开发中注重以人为主,团队自管的思想, 咱也提不出好的改进意见 . 不利于敏捷持续发展. 于是利用中午和晚上时间在网上下载一些敏捷开发文档学习 , 赶快来武装自己。与时俱进,落后就要挨打哦!
     
       系统学习了敏捷中两个方法(极限编程和Scrum),结合以前学习的pmb以传统的过程为主,强调文档:一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。
    有点像工厂流水线作业. 这一综合,思想就有点火化了。感触敏捷开发体现了一些我们平常生活、人生哲理。就不再太罗嗦,言归正卷了。
     
        
    二  敏捷开发所体现的哲理
     
        1、与时俱进,不断改进,不断完善理想
     
           敏捷开发中一个重要的思想就是要在具体项目中不断改进。主张要不断完善,发现问题,勇于针对具体的问题,引起敏捷方法实践
         勇于重构代码。这些理念在我们生活中也同样受用。古人云:知错就改,人无完人。也是要求我们要勇于承认自己的不足,只要我们有勇气
         发现问题,分析问题,勇于改进。这样我们才能够前进。哲学上讲矛盾的原理也是一样的。
     
        2、集中力量解决重点问题,小步前进,稳扎稳打,步步为营
          
          敏捷开发注重迭代开发,增量的进行工作,小步前进,不停的思考、反省和总结,不停地进行自我调整、完善、改进. 这种方法很明显是能够
        及时发现问题、总结问题,降低项目中的需求风险和开发进度风险(需求列表排了优先级,前期就可以把客户确认的重点需求投入精力做好,
        后面迭代sprint周期能够根据前一个周期srpint情况来及时调整和改进).
     
        3、注重以人为本的思想,注重参入、沟通、反馈
     
            敏捷开发中的极限编程方法论中实践原理中很多体现了这些理念。如:让客户编写user Story,让客户参入具体的功能需求编写过程中;sprint周期
        中定期加强为客户的沟通;客户与开发人员尽量在一起办公;开发人员集中办公,及时沟通;结对编程;隐喻(一些好的规范,专业术语提前在团队
        中集成共识) ,代码共用,晨会等.
            
             这些方法在我们实际生活同样实用.毕竟任何东西还是要由人来做的。因此在各个场合都会存在调动人的积极因素来影响环境和事物。
     
         4、简单原则
     
              极限编程体现跟踪客户的需求变化,既然需求是变化的,所以对于目前的需求就不必过多地考虑扩展性的开发,讲求简单设计,
         实现目前需求即可。简单设计的本身也为短期迭代提供了方便,若开发者考虑“通用”因素较多,增加了软件的复杂度,开发的

         迭代周期就会加长。简单设计包括四方面含义:

                      1、通过测试。2、避免重复代码。3、明确表达每步编码的目的,代码可读性强。

     

           简单哲理在我们生活中也是无处不见,感觉最明显是我们穿的衣服更简朴和舒适,更适合我们个性展示;还有大家经常说复杂问题简单化,简单生活,

        快乐生活等都体现对人生豁达、快乐的态度.

     

         ......

     

    三  建议

     

        1、民主参入度有待加强

          

           这几天我问了近十几位一线参入BOSS和CRM敏捷开发人员(大部分是合作方)。主要涉及对敏捷的认知,参入度,参入角色等。发现大家基本还是认同敏捷,

          但是对一些具体的实践方法还是存在模糊的认识,甚至抵触心理。比如:结队编程 (实际上结队编程在运用时是要根据实际情况而定,有一定边界条件。

          像对新员工,对核心关健业务,对sprint迭代检查过程中发现大家编程问题等,这时可以实施结队编程).其次有就是对敏捷基本都没有一个完整的概念。如:

          敏捷中的基本思想,敏捷中几个主要方法,敏捷每个方法用途和使用的条件等。最后,就是参入访问的人基本都没有接触过敏捷开发软件,对一些天天写在墙上的

          “燃尽图”都不知道,缺少参入意识(写这个时,徐志明发Mingle的使用知会,希望大家在使用这个软件时对敏捷起到加深理解作用。应早该一点发给我们啊!) 。

     

            a  敏捷开发人员是以人为本,着重的实施还是得靠大家,需要大家共同的参入、支持和理解。希望领导在具体实施过程中让更多的人参与进入。

                 参入过程中要加强PL的职责和引导大家作用。让更多一线工作人员,特别是合作方,有一个认同感,尊重感。调动他们的积极性和主动性

            b  加强团队组织建设,落实负责人责任制。现在感觉BOSS团队上层参入讨论敏捷很活跃,根据实际的项目运用了敏捷开发中权限编程、Scrum和传统方法结合,

               政策和方向都是正确的,但是到下面pl下一级具体落实下,需要pl对敏捷开发能够灵活运用,引导本组人员进行敏捷开发学习,讨论、参入.

     

        2、 每日晨报内容要根据具体的情况而定

     

           我们进行的晨报大家现在都认可了,大实现中也取得一定效果。但是感觉有些组还是基于它所表现的三种基本的形式(今天做了什么,明天做什么,所遇到困难).

           个人觉得晨报的内容要根据项目、各个小组具体的情况而定,不可一概而定,基于形式。

     

              a、 根据sprint周期后总结中发现问题,针对性在下一阶段的sprint周期中引入晨报内容。如:在sprint周期总结中发现大家编程不规范,在Daily Scrum meeting

                  注重检查编码规范问题;如:上次CRM团队检查代码质量时发现一些问题,在下几个Daily Scrum meeting中注重检查代码质量问题,至到问题解决为至。

             

              b、 根据项目开发不同阶段制定Daily Scrum meeting;

     

             个人认为引为这个东东,还是为了解决问题。在过程中不断改进。

     

        3、 技术专家人员支持、重视有待加强

     

             来华为两年了,感觉这边是很重视业务的,不注重技术。毕竟BOSS业务比较复杂,业务重要是不言而遇。但是在实际的BOSS维护中,发现很多的二线问题、bug单

           都是由技术引起。而一些有经验的老员工,管理人员很少参入到技术当中把关。以至BOSS一些问题单每月每天循环出现。虽然现在引入了测试驱动开发、持久集成等

           方法,但是一些核心业务还是需要技术专家来监督。

     

           a 、 对一些核心代码,关键业务,除了要进行测试外,更重要是专家技术人家承担起负责,对其功能指导、监督、检查,

                必要时可结队编程;

           b、  在团队内部要形成一种气氛和文化,技术和业务都重要。甚至在待遇方面要落实;

     

        .............

     

         看见BOSS团队根据我们实际出发引入敏捷开发,甚感高兴,有喜的事,现在已取一定成果。愿我以上的感悟对我们团队有所帮助和启发

    展开全文
  • ... 什么是勇气? ...三名海军上将谈论起什么是真正的勇气。德国将军说:“我告诉你们什么是勇气。...我希望你爬到顶端,举手敬礼,然后跳下来!”德国水手立即跑到旗杆前,迅速爬上顶端,漂亮地敬个礼,然后跳了下来。...
    
    

    Author:袁琳
    MSN:testwin@sohu.com

    什么是勇气?

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

    勇气源于什么?

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

    有勇气的人

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

    敏捷 & 勇气

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

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

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

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

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

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

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

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

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

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

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

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

    ... ...

    展开全文
  • 个人理解的敏捷开发特别强调的几个重要原则 勇气、信任、责任、尊重、简单、主动、自律、沟通、反馈、分享
  • 敏捷开发的优势

    2017-03-06 14:50:35
    敏捷开发方式能给企业和用户带来以下好处: 1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法...
  • 在此记录一下自己地感悟,如果有朝一日自己去领导一个敏捷开发团队,要尽量想办法避免和解决这些问题。 背景介绍: 公司的开发进度是大概每5-7周发布一个小版本,这里面包括了1周的各种测试时间和1周的上过渡...
  • 再次参与敏捷开发项目2年多了,期间有敏捷教练的指导,也有实践的一点感悟:由于从事的岗位,站的角度偏向于从开发人员的角度、开发负责人角度的一些总结:Part1:遵从的理念:尽快交付有价值的东西。敏捷开发尽快...
  • 敏捷开发学习心得

    2014-02-15 22:03:03
    过年放假这几天读了一些敏捷开发方面的书籍,基于自己对敏捷开发的理解总结出以下几点。本文内容还会进一步整理,暂时先贴出来,权当作是一份备忘吧。也希望对阅读过本文章的挨踢人有些许启发,如果能留言进行进一步...
  • 对于敏捷开发,我最大感悟是对于设计的可扩展,特别是对于项目需求变化大的项目,软件设计过程中灵活的利用设计模式来设计你的软件,最大的提高软件的可扩展性,提高软件的对于需求变化响应能力。 进行项目设计的...
  • 简要介绍《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后,成功向敏捷开发转型的故事。 作者通过4个迭代开发过程,展现了主人公是如何从一个敏捷开发的新手...
  • Agile testing(敏捷测试)基本上是伴随着敏捷开发的概念成长起来的,但在受关注程度上,远远不及敏捷开发本身。自然,开发队伍从数量和活跃度上来讲大于测试队伍,是其中的一个原因;除了这个原因之外,“敏捷测试...
  • software development),又称敏捷开发,是一种从上世纪九十年代开始逐渐引起广泛关注的一些新型软件开发方法,它是应对快速变化的需求而产生的。它的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",共同...
  • 很久没有写博客了,前面一直有接触敏捷开发的项目,也算是有些理解和感悟,这篇也是我在工作生活中有感而写的入门解释,作为理解一些相对抽象概念的通用思维方法,也借敏捷开发为例做下知识总结。后面可能还会对敏捷...
  • 敏捷开发

    2018-03-08 11:40:42
    背景过去我们用合同死死地...这就是本期要讲的敏捷开发。敏捷的起源硬件领域有摩尔定律,即每隔18~24个月,每1$能买到的电脑性能将翻翻一倍以上。而软件行业却没有相应的规律。那么软件行业如果提高生产率、质量、...
  • 敏捷没有固定的招式,不同公司适用于不同的方式,很可能我在A公司可以达到目的的方法在B公司就根本行不通,所以我们还是需要更多的感悟和更广泛的视角,如果没有的话就多读书吧。 与敏捷相关的书太多了,随便一抓都...
1 2 3 4 5 ... 20
收藏数 2,535
精华内容 1,014
关键字:

敏捷开发感悟