|
本帖最后由 Castelo 于 2012-6-20 00:22 编辑 摘的一些： 敏捷开发4句宣言： 个体与交互 胜过 过程与工具 可以工作的软件 胜过 面面俱到的文档 客户协作 胜过 合同谈判 响应变化 胜过 遵循计划 敏捷开发12个原则： 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势 3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7、工作的软件是首要进度度量标准。 8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9、不断地关注优秀的技能和好的设计会增强敏捷能力。 10、简单----使未完成的工作最大化的艺术----是根本的。 11、最好的构架、需求和设计出自与自组织的团队。 12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 一个人对于开发流程 的理解： 摘的，不是原创 瀑布[Waterfall Model]开发方法.相信对于大多数开发人员来说都是很熟悉的.可能很多人和Team现在依然还停留在这个开发方法中进行日常开发工作. 瀑布方法是由Winston W.Royce 博士在1970年代发表的一篇论文中“管理大型软件系统开发[Managing the Development of Large Software System]”提出的.很多人都认为瀑布开发方法都是源之于这篇论文. 其实如果你仔细的阅读这篇论文.你会发现在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式. Royce实际在论文中试图拿这种Waterfall Model开发方法来论证说明这种开发模式是存在缺陷的.而且可能导致项目失败. 而Royce没有料到的是Waterfall Model却意外的成为业界大多数软件开发的最早标准. 瀑布模型[Waterfall Model]最早强调系统开发应有完整生命周期，且必须完整的经历周期中每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’[System Development Life Cycle, SDLC]。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质 Waterfall Model瀑布开发模型强调的是软件开发周期中每一个阶段都是线性的向下进行的: 至于这个流程相信很多开发人员已经是非常熟悉了.但在实际开发流程瀑布模型存在哪些问题、>? 首先第一点不得不说的就是在瀑布模型每个步骤都必须要按照顺序执行.直到整个软件开发周期完成. 最关键的是每个阶段在完成之前不能开始下一个阶段. 每一步的执行则是完全依赖于上一个阶段. 另外相信很多人会说在瀑布模型里说明问题是需要文档来记录的. 而且文档在这个过程每个阶段都需要详细文档来维系. 很多人会问 如何在瀑布模型中保证软件质量?> 相信很多在实际项目中完整执行过该流程开发人员。应该清楚我们确定需求需要做持续做在文档做出软件概要设计和详细设计. 其实瀑布模型这样做要求在设计分析阶段尽可能多发现纰漏. 才能在开发阶段避免错误. 这有什么问题呢? 相信很多人发现.这种要求在设计分析阶段就能发现整个软件开发周期要发现所有可能出现的问题. 基本是不可能的. 而很多关键的细节如果不到具体的实现阶段是不可能发现的. 而由于这个模型.强制要求在编码开始之前要冻结规范文档. 也就是说很难在发布阶段将早起用户以及测试反馈的问题包含进来. 这样一来就降低开发团队响应客户需求的能力. 特别在发布周期要求比较高时.开发团队不能持续想客户交付有效功能点. 至于测试则是整个编码结束后拖到整个开发周期的最后. 这就是集成化测试的开始阶段.为交付有效功能点和软件质量照成一定风险. 敏捷方法之Scrum 其实对用瀑布模型这种臃肿不堪.要求严格.而无法适应软件开发周期变化开发模型.业界渐渐可是兴起向更轻型的软件开发方法演化。在90年代时提出好几种轻型方法.强调专注于软件自我管理的团队. 提倡面对面的交流. 轻型文档和迭代发布等概念. 最终这些方法论的缔造者. 其中包括Kent Beck、Martin Fowler,以及Ward Cunningham.组成敏捷联盟[Agile Alliance]。统一了敏捷软件开发的原则.从而就有了所谓后来的敏捷宣言[Agile Manifesto] 那什么是敏捷? 敏捷方法是试图通过小型的. 自我管理的团队用短小的合作发布周期来鼓励迭代式软件开发方法.软件的质量贯穿敏捷软件开发每一个阶段.且非常重要.,并提出很多关键的规则[例如: 结对编程. Test Driver Development测试驱动开发.,重构和持续集成]来保证能在每一个迭代周期内及早是的发现并及时相应消灭开发过程中出现错误. 有哪些敏捷方法? 在敏捷方法提出理念下.衍生出了很多不同敏捷软件开发方法.类似这里马上会提到的Scrum、极限编程[EXtreme Programning XP]，测试驱动开发[Test Driver Development]，重构和持续集成. Scrum大概是目前敏捷方法里面最出名. 至少也是各位实行听说敏捷方法最熟悉一个. 那什么是Scrum? 其实冲本质上来说Scrum本身并不是所谓方法论.而是一组实践和为其过程参与者制定角色框架.其实它和其他敏捷方法是殊途同归.Scrum鼓励小型的,自我管理的团队在短的开发周期完成一系列定义良好的开发任务. Scrum虽然提供了一个很有价值的框架. 但实际上和XP TDD不同的是它并没有定义明确可行的方法来管理开发出来的软件的质量.但其实这没有问题.Scrum的做法只是这个工作下放到Scrum团队每一个人.让开发团队自己决定选择实现什么样的质量控制实践. 在这一点上和XP TDD提出关注项目的框架.Scrum则淡化这一部分.而是更多对管理代码质量做出很多实践规定. Scrum周期如何执行的? 每一个Scrum项目周期都被看做一个Sprint.它用来标识完成一组功能开发所需要的时间.Sprint即从Scrum团队打算把精力放在一组功能上开始.而这组功能是由Scrum团队在源自于Product Backlog的计划阶段期间选择的. Produc Backlog其实是指一张关于软件开发所有可能功能点优先级列表. 其中在计划阶段的末尾.所有从Product Backlog里选出来的功能都会被加入Sprint Backlog里执行跟踪.Sprint Backlog表示团队要开发的具体功能的细节.或者就是需求表现出来的功能点.一旦Sprint Backlog定义完成整个Sprint周期就开始. 通畅在一个Sprint周期会持续30天.在Sprint期间团队成员会聚在一起检查工作进展并帮助每一个队员保持工作效率.而在这个Sprint末尾。在Sprint Backlog里定义的功能点将全部完成并可用. 而这个过程就如上图.Scrum优缺点在那? Scrum相对传统瀑布模型.在构建真个开发活动前.思考并记录下来真个流程.,按照具体的计划实施，保持各项事务尽可能的有组织性.另外可以从整个Sprint周期来看到.Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化.使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低: Scrum模型和传统模型的对比: 在这个过程中.,与XP（eXtreme Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践.这既是Scrum的优点. 但在实际执行中也存在缺陷缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得混乱无法达到预期效果. Scrum小结 Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的 关于Scrum 可以参考: Succeeding with Agile:Software Development Using Scrum 中文名：《Scrum敏捷软件开发》 作者：Mike Cohn 《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考 User Stories Applied:For Agile Software Development 中文名：《用户故事与敏捷方法》 作者:Mike Cohn 《用户故事与敏捷方法》：敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，亚马逊五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。 Ken Schwaber. Agile Project Management with Scrum[M]. 上海：世界图书出版公司，2007： agile敏捷实践书中.<<Agile Estimating and Planning>> 的作者mike cohn3本著作最为经典. 其中04年这本<<User Stories Applied: For Agile Software Development>>算敏捷宣言最早一个版本. 09年<<Succeeding with Agile: Software Development Using Scrum>>则是深入敏捷实践推荐. 我的导师有一些也是很喜欢瀑布的，瀑布确实有利有弊。风险驱动与瀑布结合或许好些，但治标不治本，似乎还是不能解决不同阶段交接的问题。于是IBM家大牛说垂直分配任务，平行分配任务等。 没有试过敏捷开发，感觉像是不断的迭代，基于用例精确分析的基础上。以前一直用适合比较大型软件的开发过程，因为一般就是5人组，管理上，设计上没觉得有什么不好。 不知道敏捷比起轻量级的RUP，会有什么不同，或者跟平时筒子们做项目的过程，有什么不同。说说经验？说说如何给组员分配任务？说说功能的划分等？？？ 客官，可否说来听听你的想法？  |
[技术| 编程·课件·Linux] 敏捷开发
Castelo
· 发布于 2012-06-20 00:14
· 2511 次阅读
转载文章时务必注明原作者及原始链接，并注明「发表于 软院网 RuanYuan.Net 」，并不得对作品进行修改。
