敏捷开发

敏捷开发 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 那Scrum又是什么呢？Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作。 Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。 其中

关于第六章 敏捷流程 剖析Sccrum这个方法论， 在第三步冲刺阶段 外部人士不能直接打扰团队成员。一切交流只能通过scrum大师来完成。 这一措施较好的平衡了交流和集中注意力的矛盾，有任何需求改动都留待冲刺结束后再讨论。 第一次读到这里对scrum大师这个职位不是很理解，靠一个人来交流决策会不会影响开发的软件走偏 不能满足用户需求 冲刺结束后在修改讨论是不是会耽误时间。 来源： https://www.cnblogs.com/zmcc/p/7505435.html

概述 敏捷方法论有一个共同的特点，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。 在敏捷方法论领域中，比较知名的、有影响力的，是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。 这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目（Chrysler Comprehensive Compensation）的实践中总结出了 XP 的基本元素。在此之后，Kent Beck 和他的一些好朋友们一起在实践中完善提高，终于形成了极限编程方法论。 解析极限编程 那么什么是 XP 呢？XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于： 在更短的周期内，更早地提供具体、持续的反馈信息。 在迭代的进行计划编制

请阅读我们的热门文章，这些文章着重讨论了敏捷的过去、现在和未来。-- Leigh Griffin（作者） 对于 Opensource.com 上的敏捷主题来说，2019 年是非常棒的一年。随着 2020 年的到来，我们回顾了我们读者所读的与敏捷相关的热门文章。 小规模 Scrum 指南 Opensource.com 关于 小规模 Scrum 的指南（我曾参与合著）由六部分组成，为小型团队提供了关于如何将敏捷引入到他们的工作中的建议。在官方的 Scrum 指南 的概述中，传统的 Scrum 框架推荐至少三个人来实现，以充分发挥其潜力。但是，它并没有为一两个人的团队如何成功遵循 Scrum 提供指导。我们的六部分系列旨在规范化小规模的 Scrum，并检验我们在现实世界中使用它的经验。该系列受到了读者的热烈欢迎，以至于这六篇文章占据了前 10 名文章的 60%。因此，如果你还没有阅读的话，一定要从我们的 小规模 Scrum 介绍页面 下载。 全面的敏捷项目管理指南 遵循传统项目管理方法的团队最初对敏捷持怀疑态度，现在已经热衷于敏捷的工作方式。目前，敏捷已被接受，并且一种更加灵活的混合风格已经找到了归宿。Matt Shealy 撰写的 有关敏捷项目管理的综合指南 涵盖了敏捷项目管理的 12 条指导原则，对于希望为其项目带来敏捷性的传统项目经理而言，它是完美的选择。 成为出色的敏捷开发人员的

在稍微有规模的外包公司想推行敏捷开发是一件不容易的事件！ 以下摘录： 敏捷软件开发宣言 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 虽然右项也具有价值，但我们认为左项具有更大的价值 敏捷宣言遵循的原则 1. 我们最优先要做的事通过尽早的、持续的交付有价值的软件来使客户满意。 2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 3. 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5. 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7. 工作的软件是首要的进度度量标准。 8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9. 不断地关注优秀的技能和好的设计会增强敏捷能力。 10. 简单 -- 使未完成的工作最大化的艺术 -- 是最根本的。 11. 最好的架构、需求和设计出自于自组织的团队。 12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地读自己的行为进行调整。 来源： https:/

踏入软件开发行列时间不算短了，也使用过很多项目管理软件和方法，但是在使用过程中多多少少都会遇到一些问题吧，同行们或多或少也会有相应的体验。近期试用了一下华为最新推出的项目管理工具-华为软件开发云，接触了敏捷开发，产生一些想法。以下是使用体验，仅供同行们参考。 一、敏捷开发技术的几个特点和优势： 1．个体和交互胜过过程和工具 2．可以工作的软件胜过面面俱到的文档 3．客户合作胜过合同谈判 4．响应变化胜过遵循计划 二、敏捷开发技术的12个原则： 1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 2．即使到了开发的后期，也欢迎改变需求。 3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5．围绕被激励起来的个人来构建项目。 6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 7．工作的软件是首要的进度度量标准。 8．敏捷过程提倡可持续的开发速度。 9．不断地关注优秀的技能和好的设计会增强敏捷能力。 10．简单使未完成的工作最大化。 11．最好的构架、需求和设计出自于自组织的团队。 12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 三、敏捷开发技术的适用范围 1.项目团队的人数不能太多 2

这是敏捷开发绩效管理的第四篇。（ 之一 ， 之二 ， 之三 ， 之四 ， 之五 ， 之六 ， 之七 ） 最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。 敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。 “内向型”绩效及其导向 进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。 质量：“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。 成本：“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。 功能：“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。 此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码

目录 Agile敏捷项目管理 什么是敏捷 关于Scrum和XP 常用的敏捷工具和平台 Agile敏捷项目管理总结 传统项目管理 与敏捷项目管理的区别 项目管理工具和平台 项目管理总结 Agile敏捷项目管理 什么是敏捷 敏捷的反义当然是不敏捷，但是这个“不敏捷”在软件工程里面却有个专业的术语叫做“瀑布式开发”。 所谓的瀑布式开发，其实是经典的软件工程方法为了定义出一套完备的过程规范，使得软件开发的运作就像是机器设备一样正常的运转而总结出来的项目管理方法论。这套方法论分为5个阶段：需求分析、设计、编码、测试和维护。需求分析阶段通常定义系统的需求，明确系统的目标；设计阶段通常确定系统使用什么数据库，系统模块的划分，各个模块的功能；编码阶段用编程语言实现设计阶段的任务；测试阶段主要测试功能是否实现，以及是否正确没用Bug；维护阶段是根据用户新的需求重新修改系统，使系统运行正常，更加稳定。 瀑布式开发的局限性也非常明显，比如对市场变化和用户需求的响应慢，更改成本高等，有可能出现的情况是产品一推出市场就宣告失败。 而敏捷开发则是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的一种方法。所以，在瞬息万变的互联网、移动互联网时代，大家已经渐渐体会到敏捷的优势，我们也看到越来越多的互联网产品出现了一周发布一次的快节奏，这么快的速度，就是为了迅速响应市场与用户的需求。

版权所有© 2006-2018 Jeff Sutherland 及 Scrum Inc. Scrum@Scale是Scrum Inc.的注册商标。本指南基于署名-相同方式共享许可协议4.0发布。(CC BY-SA 4.0) 简体中文版原创翻译团队：申健 Jacky Shen (CST, CTC, Agile Coach); 王洪亮 Stephen Wang (CSP, Agile Coach); 李国彪 Bill Li (CST, Agile Coach); 简体中文版授权译文链接：http://www.uperform.cn/scrum-at-scale-guide-chinese/，欢迎转载，请保留所有版权信息并遵循共享许可协议进行演绎。 Scrum@Scale指南之目的 最初在Scrum指南中描述的Scrum，是单个团队进行开发、交付和持续发展复杂产品的框架。自诞生以来，它已经扩展到需要多个团队合作来创建产品、处理过程、服务和系统。创建Scrum@Scale是为了有效地整合这种新型的团队生态系统，从而优化组织的整体策略。为了实现这个目标，它利用一个自由扩展的架构建立起一个“最小可行的官僚机构”，自然地将单个Scrum团队的功能扩展到整个组织中。 本指南包括构成Scrum@Scale框架的组件定义，包括扩展的角色、扩展的事件、企业级工件，以及将它们组织在一起的各种规则。

近来做了点东西有一点儿心德想要分享一下，也许在写的过程中有些描述的欠缺，但是也算是一点心德了，希望大家指正。 是否在项目中采用UML实际上一直是一种矛盾的事情，你说它有用吗，它真有用，你说它没有用吧，它真是一个废物。此话怎讲哪？UML对于需要求变更量不大的项目，那可是法宝一件，有种倚天即出，谁与争峰的感觉.但是如果项目中频频变更需求那么好吧乖乖，UML就是废物一个，成为项目组中人见人怕的怪物。 所以说我建议大家采用敏捷的方法开发，配合UML中常用的图例进行组员沟通与理解就不失为一种比较好的方法了，采用纯粹的敏捷开发一点儿文档也没有的话，我个人感觉前期开发人员会乐死，后期维护人员会哭死，特别是对于现今中国软件开发公司人员流动过快的现象，这种事真的是太多太多了。 做一个简单的比喻吧： 采用传统式流程式开发的兄弟们：好像是一群建筑设计院出来创业的老学究，事事讲究，什么都是理论一套一套的，一到实际盖房子的时候全部完蛋，为什么哪？主要是因为这帮学究们天天只会待在房子里研究，但是一盖房子全部都傻，没有实战过，对现场开发是一个白痴。但是奇了怪了就是这样的一帮人就能拿到大项目的单子，为什么哪？揪其根源主要在于人都是好面子的，一听你找了一个包工头子干这个项目，打死政府也不敢给你项目，所以一般都是白痴做一包，我们做二包，如果感觉不爽，你可以再找三包了。。。。 采用敏捷开发的兄弟们：这帮人一般都比较猛