笔记:敏捷开发1

  敏捷开发,即以用户的需求为核心,采用迭代、循环渐进的方法进行软件开发的一种方式,换言之,就是将一个大的项目分为多个相互联系的,也可以独立运行的小项目,并分别完成,且在此期间软件一直处于可使用状态的一种软件开发模式。相较于以前依靠个人单打独斗或墨守成规按部就班的开发模式,敏捷开发无疑是一种在现在十分流行且有效的开发模式,并且受到越来越多的软件开发团队的青睐。

  敏捷开发的主要目标是提高开发效率和响应能力。现如今随着技术的发展,软件的体量日益庞大,过去个人凭靠出色的编程能力开发软件的时代已经一去不复返,取而代之大多数的软件开发都是依靠一个团队来实现的,因此团队之间的合作的质量往往决定了软件开发的成败。在敏捷开发中,“沟通”是一种重要的价值观,团队之间的彼此之间的信任是建立在团队成员之间无数次的沟通与磨合的基础上的,在软件开发的过程中,没有“我”的代码这一说,只有“我们”的代码,虽然敏捷开发将一个软件的开发分成了若干个不同的小项目,但项目之间的关系不是彼此孤立的,一个小项目的成败最终会影响到软件整体开发的成败,因此沟通在团队开发中就显得至关重要。初此之外,“简单”亦是敏捷开发的重要价值观,画一张或两张图表来代替数十行甚至上百行的代码来简化软件开发中的模型构建的过程是一种十分简单且有效率的做法,因为它可以更加直观的阐述你的看法,方便团队成员之间的沟通,并且易修改。当然“反馈”在敏捷开发的过程中也是十分重要的价值观,软件开发是一个团队工作,各种项目之间是彼此紧密相连的,因此及时的反馈可以避免很多错误,而用图表来反馈自己的意见想法在敏捷开发中是一个不错的主意,这不仅方便他人理解你的想法,也有助与团队之间的沟通。

  敏捷开发强调简单,并且要求开发团队在软件开发的过程中积极拥抱变化。需求随时在改变,因为客户其实对自己的需求的了解也是一个动态加深的过程,在传统的软件开发过程中,变化往往导致软件开发的推到重来,而敏捷开发则强调对变化的适应。在开发中团队中的某个成员会时时刻刻关注客户对软件的需求变化,并将这种这种变化及时的反馈给团队中的其他成员,从而使软件的功能随客户需求的变化而不断地调整,并最终达到客户的理想需求。同时敏捷开发强调软件的可持续性,即软件的扩展性,如今需求是随时间在不断动态变化的,满足客户的一时需求并不代表软件的成功,因为客户的需求可能会随着时间的推延而不断增加,这是就需要软件开发团队将客户新增的需求添加到已有的软件上,因此软件的可扩展性在现今的软件开发中也是十分重要的。

时间: 2024-08-04 23:11:55

笔记:敏捷开发1的相关文章

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

[读书笔记—程序员]《高效程序员的45个习惯:敏捷开发修炼之道》- 苏帕拉马尼亚姆,亨特

虽然不记得阅读本书用了多久,但是整理本书的读书笔记用了两个小时的时间,因为本书的大部分内容对于笔者来说都是新知识,很难进行归纳总结 本书所讲的是程序员应具有的工作态度和在团队中作为开发者和领导者具备的各种"敏捷的"习惯.虽然本书对于程序员的硬实力(本书讲解的编程语言是面向对象类语言,但是讲解的代码非常少)帮助不大,但是对于程序员应该具备的软实力的培养和提高有极大的帮助,是每位程序员都应该反复阅读的书籍. 第一章 敏捷-高效软件开发之道 什么是敏捷开发方法? 2001年2月,17位志愿者

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

《精益和敏捷开发》读书笔记

对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧. ======================我是读书笔记的分割线================== 如果在同一个办公区域, 你记不清所有人的名字, 那么这就是一个大型团队了 产生非最佳决策的原因是错误的假设和不充分的理由 守破离法则 第一步,

《构建之法—现代软件工程》读书笔记之——敏捷开发

敏捷开发是一系列价值观和方法论的集合.在敏捷的大旗下,我们可以看到好几种软件开发的方法论,我们在这里主要分析Scrum这个方法论. 从Scrum方法论中分析,敏捷开发一共分四步: 第一步:找出完成产品需要做的事情--Product Backlog Backlog翻译成"积极的工作","待解决的问题","产品订单".产品负责人主导大家对于这个Backlog进行增删改的工作.每一项工作的时间估计为天. 第二步:决定当前的冲刺需要解决的事情--Spri

高效程序员的45个习惯-敏捷开发之道 读书笔记

1. 做事在软件出了bug之后,应该首先根据现象找到问题的根源,而不是去找到当时编写这段代码的人,去痛骂一顿,指责是不能解决bug的.2. 欲速则不达  2.1 不要急于修复一段自己没有看懂的代码,另外,在修正时,要投入时间和精力保证代码的整洁和可阅读性  2.2 代码阅读的时间是远大于编写的时间,所以在编写的时候指的花点功夫让他阅读起来更加简单  2.3 如果在修正他人的bug时,发现难以理解,可以与其沟通商量,了解细节,同时自己也花时间理解一下,如果理解之后,代码比较难以费解,个人认为可以和

敏捷开发学习笔记-Agile development(AM)

以人为核心,迭代,循序渐进 项目被切分为多个子项目,每个子项目都经过测试,具备集成和可运行的特征 5个价值观:沟通.简单.反馈.勇气.谦逊 敏捷模型与瀑布模型的区别 相对于瀑布模型,提高开发效率和响应能力 瀑布模型以文档为驱动,敏捷开发只写必要的文档,尽量少写文档,注重人与人之间面对面的交流,强调以人为核心. Scrum '争球' 15-30天一个冲刺 提交一个增量(新特性) 产品需求(pruduct backlog)->优先级排序->选择需求->冲刺会议(需求评审)-> 冲刺过程

敏捷开发阅读笔记

通过在网上学习有关敏捷开发的知识,我了解到敏捷开发是一种应对快速变化的需求的一种开发软件能力.它们的具体名称.理念.过程.术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用. 他的开发宣言是: 个体和交互 胜过 过程和工具: 可以工作的软件 胜过 面面俱到的文档: 客户合作 胜过 合同谈判: 响应变化 胜过 遵循

读书笔记 -《高效程序员的45个习惯-敏捷开发修炼之道》

<高效程序员的45个习惯-敏捷开发修炼之道> 一本2010年出版的书,当时敏捷还只是在国外开始流行,像我这种菜鸟级根本听都没听过.这次通读了这本书,受益良多,回顾自己的职业生涯,多是漫无目的的瞎混,为了生活而生活而已.通过这本书才算对敏捷有了初步的了解,并有意向敏捷进行实践.愿此文可结识更多敏捷的先行者,带领我进入敏捷的世界. 第一章. 敏捷--高效软件开发之道 名言:  不管路走了多远,错了就要重新返回   -- 土耳其谚语 敏捷开发宣言  个体和交互 > 过程和工具 可工作的软件 &