敏捷开发 笔记_敏捷软件开发-原则、模式与实践读书笔记 - CSDN
  • 敏捷宣言:  个体和交互 胜过 过程和工具  可以工作的软件 胜过 面面俱到的...以上的宣言比较抽象,基于该理念,以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践: Iteration  迭代开发。迭代计划会议。每个迭代

    敏捷宣言:
       个体和交互 胜过 过程和工具
       可以工作的软件 胜过 面面俱到的文档
       客户合作 胜过 合同谈判
       响应变化 胜过 遵循计划
       虽然右项也有价值,但是我们认为左项具有更大的价值。

    Iteration
            迭代开发。迭代计划会议。每个迭代启动时,召集整个开发团队,召开迭代计划会议,所有的团队成员畅所欲言,明确迭代的开发任务,解答疑惑。
    Story Card/Story Wall/Feature List
            在每个迭代中,架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发,交付提前测试(Pre-Test)。当一个迭代中的所有Story开发完毕以后,测试组再进行完整的测试。在整个测试过程中(pre-test,test),基于Daily build,测试组永远都是每天从配置库上取下最新编译的版本进行测试,开发人员也随时修改测试人员提交的问题单,并合入配置库。
    敏捷开发的一个特点是开放式办公,充分沟通,包括测试人员也和开发人员一起办公。基于Story Card的开发方式,团队会在开放式办公区域放置一块白板,上面粘贴着所有的Story Card,按当前的开发状态贴在4个区域中,分别是:未开发,开发中,预测试中,测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card,更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
    在开发人员开始开发一个Story时,需要找来对应的测试人员讲解Story功能,以便测试人员有一致的理解,同时开始自动化系统测试脚本的开发。
    Standup Meeting
             站立会议。每天早上,所有的团队成员围在Story Wall周围,开一个高效率的会议,通常不超过15分钟,汇报开发进展,提出问题,但不浪费所有人的时间立刻解决问题,而是会后个别沟通解决。
    Pair Programming
            结对编程是指两个开发人员结对编码。结对编程的好处是:经过两个人讨论后编写的代码比一个人独立完成会更加的完善,一些大的方向不至于出现偏差,一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程,可以促进新手的成长,保证软件开发的质量。
    CI/Daily Build
            持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中,自动化编译程序每天至少一次自动从配置库上取下代码,执行自动化代码静态检查(如PCLint),单元测试,编译版本,安装,系统测试,动态检查(如Purify)。以上这些自动化任务执行完毕后,会输出报告,自动发送邮件给团队成员。如果其中存在着任何的问题,相关责任人应该及时的修改。
    可以看到,整个开发组频繁的更新代码,出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉,取决于自动化单元测试和系统测试能力是否足够强大,特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作,则新合入代码的隐患将很难被发现,并遗留到项目后期,形成大的风险。而实际上,提升自动化测试的覆盖率是最困难的。
    Retrospect
            总结和反思。每个迭代结束以后,项目组成员召开总结会议,总结好的实践和教训,并落实到后续的开发中。
    ShowCase
            演示。每个Story开发完成以后,开发人员叫上测试人员,演示软件功能,以便测试人员充分理解软件功能。
    Refactoring
            重构。因为迭代开发模式在项目早期就开发出可运行的软件原型,一开始开发出来的代码和架构不可能是最优的、面面俱到的,因此在后续的Story开发中,需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代,每个跌倒由拆分成很多Story,从架构的角度看,这些Story必须在是有很强的继承性,是可以不断叠加的,不至于后续开发的Story完全推翻了早期开发的代码和架构,同时也不可避免的需要对代码进行不断完善,不断重构。
    TDD
            测试驱动开发。正如上面讲的,迭代开发的特点是频繁合入代码,频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。
    
    方法反思:
            1、对于全新的软件,在项目早期测试人员就参与并实现自动化测试脚本,但实际上软件的界面等非常不稳定,导致测试人员返工的工作量很大。
            2、对于全新的软件,资料人员过早参与,后期返工工作量大,原因同第一点。
            3、自动化系统测试工作量大,测试人员投入大量的精力在使测试自动化起来,而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样,自动化系统测试脚 

                  本 也多流于形式,测不出深层次的问题。
            4、代码动态检查工具执行不理想,流于形式。没有人对Purify有深刻的理解和应用经验,报告中查出来很多告警,但不知如何消除。
            5、由于快速搭建原型,没有在架构上进行严谨的设计,导致后期一直堆砌代码。
            6、异地开发模式下无法实现快速构建、快速交付,团队普遍感觉很疲惫。
            7、敏捷开发不提倡加班,但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

    展开全文
  • 什么是敏捷开发敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。我理解它仅仅是一种开发方法,更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。敏捷提倡以人为核心,敏捷...
    天天在用着敏捷的思想,但是今天面试的时候让讲敏捷,又不知从何说起,今天记录下 ,部分内容也有参考网上优秀的易理解的说法。

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

    我理解它仅仅是一种开发方法,更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。
    敏捷提倡以人为核心,敏捷注重的是人与人之前的,面对面的交流。
    敏捷的核心假设就是:需求是变化的。
    它以一种局部演进,逐步交付,小批串行的方式更快速的进行交付和保证产品质量。


    开发测试过程图 借用几张图来说明


    测试活动
    测试系统图

    敏捷的核心假设是:
    需求是持续变化的
    敏捷12条准则/原则
    1.Customer satisfaction by rapid delivery of useful software
     对我们而言,最重要的是通过尽早和不断交付有价值的软件满足客户需要
    2. Welcome changing requirements, even late in development 
    我们欢迎需求的改变,甚至在开发的最后阶段
    3.Working software is delivered frequently (weeks rather than months) 
    经常交付可以工作的软件(从几星期到几个月)
    4.Working software is the principal measure of progress 
    可以工作的软件是进度的主要度量标准
    5.Sustainable development, able to maintain a constant pace 
    敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏
    6.Close, daily co-operation between business people and developers 
    业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
    7.Face-to-face conversati最好的架构、需求和设计都源自自我组织的团队
    12.Regular adaptation to changing circumstances 
    每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为
    on is the best form of communication (co-location) 
    在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈
    8.Projects are built around motivated individuals, who should be trusted 
    围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务
    9.Continuous attention to technical excellence and good design 
    对卓越技术与良好设计的不断追求将有助于提高敏捷性
    10.Simplicity 
    简单。——尽可能减少工作量的艺术至关重要
    11.Self-organizing teams 
     
    敏捷的价值观:
    个体与交互 重于 过程与工具
    可用的软件 重于 完备的文档
    客户协作 重于 合同谈判
    响应变化 重于 遵循计划

    敏捷的一些特点和问题
    Ø 前期投入变多了
    Ø 对人的要求变高了
    Ø 常常在项目未完时就显现出的商业价值
    Ø 成功项目管理类,互联网类偏多
    Ø 项目成功但可维护性不佳
    Ø 给人感觉流派比较多
    Ø 有一些极端敏捷的思路和主张,无文档等
     
    敏捷最佳实践:
    XP、SCRUM、水晶体系、动态系统开发方法DSDM、适配性软件开发、FDD等
    SCRUM
    SCRUM是遵循敏捷方法的一个软件开发框架。在SCRUM框架中,融入敏捷开发的精神和思想。
    Scrum方法是一种偏重管理的优秀实践组合:
        它通过组建客户参与的团队,确定客户与开发团队的一致目标;
        分里程碑,按商业价值排序的需求列表;
     Scrum框架核心内容:3-3-3
    “3”个角色(Role)
    产品主管(Procuct Owner):负责项目的商业价值
    Scrum师傅(Scrum Master):他负责团队的运转和生产
    自组织的团队:目标一致的团队
    “3”个会议
    迭代计划会议
    每日晨会
    迭代回顾会议
    “3”个工作组件
    待开发任务列表(product backlog)用来排列任务的优先级和跟踪任务
    迭代任务列表(the sprint backlog)
    进度图(burndown chart)
     
    客观的认识敏捷
    敏捷是一个新生的、飞速成长的方法论
    ① 敏捷基于文化和价值观的特点让其实框架宽泛,兼容性好,同时灵活性大导致施难度加大
    大家对敏捷的理解各不相同,优秀实践百花齐放;敏捷的优秀实践个异性较强,直接学习风险大
    ② 敏捷提倡的紧密互补的工作方式,对人的要求高
    ③ 敏捷强调的价值观理解不到位,容易让人忽略某些东西,其结果会给人带来误解
    ④ 没有万能、完美的开发方法,适合的才是最重要的


    展开全文
  • 敏捷开发笔记整理

    2019-01-07 21:14:45
    敏捷开发宣言: 1.个体和交互胜过过程和工具 2.可工作的软件胜过面面俱到的文档 3.客户协作胜过合同谈判 4. 响应变化胜过遵循计划,从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化。 敏捷...

    敏捷开发宣言:
    1.个体和交互胜过过程和工具
    2.可工作的软件胜过面面俱到的文档
    3.客户协作胜过合同谈判
    4. 响应变化胜过遵循计划,从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化。
    敏捷宣言》背后的12准则
    我们遵循以下准则:
    1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
    2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
    3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
    4、项目过程中,业务人员与开发人员必须在一起工作。
    5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
    6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
    7、可用的软件是衡量进度的主要指标。
    8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
    9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
    10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
    11、最佳的架构、需求和设计出自于自组织的团队。
    12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
    如果用一段话来简单明了的描述一下SCRUM,应该是这样的:
    1、我们需要把人进行分割,所以我们建议会组建一些小的团队,人数最好是在3-7人。
    2、我们需要把任务切小,拆分成故事卡。
    3、团队在一个sprint周期内权利冲刺去完成计划的故事卡。
    4、做持续集成去从整体上把握任务的完成情况和风险。
    相比较而言,看板的具体实践就没有那么多的限制,看板主要强调以下几个方面:
    1、流程的可视化。
    2、限制并发。(在制品的数量)
    3、优化交互时间。
    相对于一个需要转型的团队来讲,SCRUM是相对比较激进一些的,因为这个框架告诉了你说SCRUM需要在迭代周期内开几个会,且时间盒(迭代周期)内完成的故事卡尽可能在开了计划会承诺交互会,就在迭代周期内完成(否则团队响应变化的能力就会变弱),且迭代周期内要完成的事,在这一个迭代周期就尽可能保持不变,以免引发一起不必要的浪费。而看板是一个比较渐进式的变革,它一开始的时候可能没有那么多的条条框框,是一个更加轻量级的方法,但真正在现实的应用中,想要把看板方法实践得很好,反而是比SCRUM更加困难的一件事情。
    下面就着重的讲一下SCRUM相关的一些知识:
    从整体上来讲,SCRUM这个框架里面包含了这几个核心的要素:
    1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。
    2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。
    3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。每一个会议都有自己的时间盒,其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候,超出了这个时间盒或者召开某个会议的时候出现一些问题,也是一种有问题的信号。一个团队在冲刺的周期内,去充分的暴露问题,然后在回顾会上去分析问题,再进行改进。在每日立会上比较强调的是,根据昨天完成的情况来做出新的调整,我们每日立会上所描述的,一定是对有助于完成当前sprint目标的事情。同时,特别需要强调的是,在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。
    4、5个价值观:公开、专注、勇气、承诺、尊重。
    另外,还讲到了SCRUM最重要的时间盒,这个是我之前所理解的SCRUM里面,没有发现它竟然是如此重要的。还学到一个新的理论:番茄工作法是一个人的SCRUM,SCRUM是一群人的番茄工作法;理解到跨职能是团队层面的概念,而一专多能是每个团队成员层面的概念。现在回过头来看,发现曾经团队在尝试SCRUM的过程中,对有些方面是理解得不够的,包括为什么最终团队放弃了SCRUM转向看板,其缘由也不完全是曾经以为的迭代周期的问题,需要系统的来看待这个问题。不管一套理论是如何的完善,结合到实际的工作中的时候总会遇到这样和那样的问题,但抓住最本质的东西才是最重要的,抓住其精髓的部分,然后再加以灵活应用,以问题为出发点,能够真正的解决实际的问题才能给大家带来信心。
    最后,分享一下SM的一些相关知识:
    一、SM应该在团队承担的几种角色:
    1、引导者,就像一个出租车司机,需要去哪儿,是由团队来决定的,作为引导者,带领团队到达他们想去的地方。引导团队建立团队规则,维护团队和指导团队外部成员遵守团队的规则。作为引导者需要特别注意的是,不能把自己的价值观强加于团队,让团队成员尽量表述自己的意见。
    相信大众智慧—得到“最佳方案”
    相信大众参与—得到“最佳执行力”
    2、教练:指导团队和PO遵循SCRUM的价值观。教练作为一面镜子,在每日立会和回顾会等会议上,只陈述事实,在日常工作中尽量多去收集一些数据,通过陈述事实和提问让团队去思考,通过这种方式让问题的解决达成一致。(如果当前的陈述让团队意识不到问题的存在,那么建议继续守望,继续收集数据,再陈述事实,通过反射让团队去发现问题)
    3、移除团队障碍。
    二、SM的几个发展方向:
    1、敏捷/教练:推荐《敏捷开发的艺术》和《用户故事与敏捷方法》。
    2、技术(CI、TDD、重构等):最重要是去做周计划,去与别人结对或者做练习。
    3、业务(PO):帮助团队的PO去切分故事,推荐《精益创业》和《用户故事与敏捷方法》。同时,建议QQ邮箱PO的千百十工作法:得到1千个用户反馈,选一百客户进行沟通,再从中选择10个沟通结果作为下一个迭代的故事。这样做,既有广度也有深度,能够持续不断地保证团队做对用户最后价值的事情。
    4、转型:从A----B点,往往SM需要考虑,不止一种方法,需要多种方法,灵活运用。
    5、教练:推荐《敏捷教练》,这一项要坚持实践PDCA,做周计划,比如:回顾会、心情曲线、跨团队指导等实践活动。
    6、导师。
    7、引导。
    8、演讲。
    后三者都是属于纯实践型的活动,需要多演练。大家可以基于目前的现状对上述8个维度进行一个打分,形成当前的雷达图,然后再做短中期计划,三个月后再去绘制新的雷达图,每一个短周期内,建议是集中精力对某一项进行实践和提高。做周计划是一个非常好的实践技巧,比如:阅读一本书,可以精细到每周阅读多少页。这样比起做月度计划,会让你的可操作性和跟踪性,能有更短的一个反馈周期,更容易实践下来。
    如何让敏捷落到实处,下面是我理解的敏捷。
    小功能点代码设计,以及小的功能点的代码开发,开发自测。
    小的功能点测试设计,测试开发,测试执行。
    敏捷包含结对编程,结对测试,结对工作。
    包括测试设计时交叉执行,交叉设计,交叉评审。
    保证分组开发过程中,各组工作对接上,所以各小组一起开发,统一意见。
    持续部署。
    测试驱动开发。先写测试用例,在开发功能代码之前。
    鼓励项目开发着,QA,非技术人员之间的协作,包括验收测试和客户测试驱动。
    持续集成。

    展开全文
  • 敏捷开发笔记

    2010-10-20 22:58:00
    敏捷开发 在敏捷开发中采用演进式架构设计,在敏捷开发的生命周期中,我们通过每一次迭代来丰富与更新我们的设计方案,以使其最大限度地符合客户对系统的需求。这里所指的需求,包括功能性需求和非功能性需求。敏捷...

    敏捷开发

       在敏捷开发中采用演进式架构设计,在敏捷开发的生命周期中,我们通过每一次迭代来丰富与更新我们的设计方案,以使其最大限度地符合客户对系统的需求。这里所指的需求,包括功能性需求和非功能性需求。敏捷开发过程的方法很多,主要有Scrum,Crystal,Feature Driven Development(FDD),Adaptive Software Development(ASD), Rational Unify Process(RUP),Test Driven Development(TDD),以及最重要的eXtreme Programming(XP)等。

      一、极限编程
      极限编程(XP)是敏捷方法中最箸名的一个。它是一种经历过实践考验的轻量级软件开发方法学。由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。从具体开发的角度来看,XP内层的过程是一个基于TDD的开发周期。

      XP的生命周期是一个持续迭代的过程,每次都是一个个特征的定义、估量、选择和开发的迭代。它的增量过程如图:

     

    XP的十二条惯例和规则

    1. 现场客户(On-Site Customer)

    2. 计划项目 (Planning Game)

    3. 频繁地小规模发布软件 (Small Releases)

    4. 简单设计 (Simple Design)

    5. 测试驱动开发 (Test Driven Development)

    6. 持续集成 (Continuous Integration)

    7. 集体拥有代码 (Collective Code Ownership)

    8. 编程规范 (Coding Standards)

    9. 重构 (Refactoring)

    10. 系统隐喻 (System Metaphor)

    11. 结对编程 (Pair Programming)

    12. 平稳的工作效率 (Sustainable Pace)

     

     

     

    XP是最轻量级的开发流程,其最主要的精神是『在客户有系统需求时,给予及时满意的可执行程式』。

    它开发流程的基本步骤为:

    1.开发人员随时可以和客户进行有效沟通,撰写user stories以确认需求。

    2.简易快速的系统设计,撰写独立的验证程式以解决特殊困难的问题,找出演算法即可丢弃验证程式。

    3.规划多次小型阶段的专案计划,以最快速度完成每一阶段的程式交付客户,客户负责Acceptance tests;

    4. Coding前必须完成Unit Test与Acceptance tests程序,所有模组整合前都须经过Unit Tests;

    5.开发人员必须快速回应Bug与需求变更;

    6.要求二人一组使用一台电脑设计程式,当一人coding时,另一人负责思考与设计;

    7.程式必须符合程式规范,并常做程式的重整(Refactoring)。

     

    二、Scrum开发流程

        SCRUM开发流程是Agile Process的一种,以英式橄榄球争球队形(Scrum)为名,基本假设是『开发软体就像开发新产品,无法一开始就能定义Final Product的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功』。 Scrum将软体开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,碓保每天、每个阶段都朝向目标有明确的推进,因此SCRUM非常适用于产品开发专案。

        SCRUM开发流程通常以30天为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部份,开发团队必须尽力于30天后交付成果,团队每天用15分钟开会检视每个成员的进度与计画,了解所遭遇的困难并设法排除。

     

    三、RUP开发流程- Rational Unify Process

        RUP为IBM Rational公司经过多年的研发与经验所提出的软体开发流程,其内容含盖Business modeling, Requirement Modeling, Logical Design, Implementation, Testing, Deployment等软体开发生命周期的直接工作,与Project Management, Change & Configuration Management,Environment support等支援性工作。 RUP的内容非常丰富,不同的专案需要不同调整,IBM Rational提供RUP workbench工具,方便调整RUP,并公布于Web,方便专案成员遵循统一的流程规范进行工作。

    RUP的主要精神为:

    1.专案进行采用Iterative程序分阶段渐进地完成专案功能;

    2.广泛使用Visual Modeling于商业需求分析、系统分析与系统设计;

    3.强调架构设计;

    4.对每项工作所需要的技术、工具、做法、范本、检查项目均有详细的定义,架构完备且具有可调整的弹性。

     

    展开全文
  • 敏捷开发知识体系整体框架敏捷开发工程实践项目管理 迭代开发 风险价值生命周期 多级项目规划 完整团队 每日站立会议 任务板 燃尽图 需求管理 需求订单 业务流程草图 用例驱动开发 用户故事 架构 演进的架构 演进的...
  • 敏捷开发笔记

    2019-06-25 19:46:07
    敏捷开发笔记一 做了一些项目后,自己也有一定的积累了。自己所担心的问题也开始变了,逐渐由原来的担心能否成功开发出来,到了现在担心项目是能在规定的时间内完成和代码是否精炼。带着问题,去看了《敏捷开发》一...
  • Scrum敏捷开发笔记

    2017-08-04 10:21:59
    2. 敏捷开发注重沟通,对需求、变更积极 3. 个体和交互重于过程和工具,可工作的软件重于面面俱到的文档,客户合作重于合同谈判、响应变化重于遵循计划 4. Scrum是一个增量、迭代的开发过程。整个开发过程分成...
  • 敏捷开发学习笔记

    2017-06-11 16:26:28
    一、什么是敏捷开发敏捷开发(Agile Development)不是指某一种具体的方法论、过程或框架,而是一组价值观和原则。怎么理解呢?首先,敏捷并不是一门具体的技术,而是一种理念或者说是一种思想。它可以指导我们更加...
  • 在移动电子设备如此普及的今天,看着琳琅满目的...在这种情况下,敏捷开发就变得尤为重要。 那么何谓敏捷开发呢?敏捷开发,简单的说,就是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构...
  • 读书笔记--精益和敏捷开发大型项目应用指南>   【摘要】 3月份的时候,根据教练和其他多为项目经理的推荐,开始阅读这本书;本书共三大部分、12个章节,第一部分:思考工具,第二部分:组织工具;第三部分...
  • 敏捷开发笔记(一)

    2019-07-06 14:40:51
    我对敏捷开发的感觉有以下几点: 一.在开发过程中强调人以及人与人之间关系的作用。不但要求开发团队要有一个积极向上的氛围,同时强调成员与成员之间的合作和交流。例如:每两名成员组成一对,共同开发一个功能,...
  • Scrum 敏捷开发 笔记

    2020-06-06 08:47:07
    Scrum 为什么有效 在工作中,常常会出现冲突,但是大部分冲突都是可以避免的。 一般有三个因素会引起冲突: 信息的不透明 价值观不同 在事情之外的冲突 (如性格) 透明 公开信息是解决冲突或问题的开始。...
  • 思想: 解决开发和运维之间的鸿沟,增添个开发和运维的沟通和交流。 关键点:全局观,自动化 精益管理原则 1. 消除浪费 2. 增强学习 3. 延迟决策 4. 快速交付 5. 团队授权 6. 内置完整性 7. 考虑全局 ...
  • 敏捷开发笔记1

    2010-08-08 21:40:00
    敏捷开发一直是我很欣赏的工作指导,可惜工作这么多年,都没有哪一个项目可以说“我们的项目正在敏捷开发”,原因?领导通常比较相信CMMI这样庞大,但是产出详细的过程(大家都觉得最详细的是文档,呵呵)。 以下...
  • 描述 子类型必须能够替换掉他的基类型 遵守规则的设计 从使用者的角度靠看一个模块 ,一个模块如果孤立的看,并不具有真正的有效性 。模型的有效性只能通过他的客户程序表现。...IS - A 的关系是针对模块行为而言...
  • 描述 对于程序的扩展是开放的 对于程序牵一发而动全身的更改是封闭的 实现 模块可以操作一个抽象体。由于一个模块依赖一个固定的抽象体,所以抽象体对于更改是关闭的。但是他可以通过派生来达到扩展其行为的...
  • 敏捷开发笔记(二)

    2019-07-06 14:40:59
    敏捷开发的最重要的意义之一在于:防止软件的腐化。 需求就像女人的心一样多变。需求的一次简单变更就可以轻易破坏代码的优雅和原有的结构。 代码的腐化可以从以下几个角度来定义:僵化性、脆弱性、牢固性、粘滞性...
  • 敏捷开发笔记 - 部署

    2019-07-26 18:27:03
    开发人员要提前思考自动化部署 测试人员要测试部署过程 adapter早期就缺少自动化部署,针对不同环境的部署 转载于:https://www.cnblogs.com/yuankui/p/3680032.html...
  • 敏捷开发笔记(一)

    2019-06-14 21:36:35
    2019独角兽企业重金招聘Python工程师标准>>> ...
1 2 3 4 5 ... 20
收藏数 10,758
精华内容 4,303
关键字:

敏捷开发 笔记