敏捷开发的宣言和原则
宣言：
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
原则：
1．我们最优先做的是通过尽早、持续的交付有价值的软件来使客户满意。 2．即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 5．围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且相信他们能够完成工作。
6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7．工作的软件是首要的进度度量标准。
8．敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9．不断地关注优秀的技能和好的设计会增强敏捷能力。
10．简单----使未完成的工作最大化的艺术------是根本的。
11．最好的构架、需求和设计出自于自组织的团队。
12．每隔一定时间，团队会在如何才能更有效地工作方面反省，然后相应地对自己的行为进行调整。
（一）敏捷开发思想之简单最好
极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。
这个原则带来一个问题，那就是我们还需要设计吗？
我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。
如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客户提出需求，而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情，与其如此，还不如在事先偷懒取巧。因为需求的变化总是不可控的，根据“利益趋避原则”，自然应选择对自己更有利的一个趋向。
但这种简单并不是“简陋”，即使我们不需要考虑明天的需求，一些好的
重用原则与可扩展原则仍然需要遵循。例如，我们应尽量保证对象是高内聚、低耦合的；我们应遵循“面向接口编程”原则。
一言以蔽之，我们需要做到：
1、减少依赖；
2、合理抽象；
3、功能最简。
简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”，正是因为重构的保障。即使设计过于粗陋，合理利用重构也能够亡羊补牢。在重构过程中，我们仍然需要遵循简单原则，仅为当前的需求对系统结构进行重构。例如，我们在最初的需求分析中，只有一个功能要求发送电子邮件。那么，我们可以编写一个方法来封装发送电子邮件的实现，这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进，新增的几个功能同样需要发送电子邮件，此时就有必要利用重构技术，将原来发送电子邮件的方法独立到单独的类中。但是，基于简单原则，我们没有必要完善所有功能，例如增加发送Meet Request的功能。因为目前的需求并不需要。
“简单”并不只限于设计。在敏捷开发过程中，我们还需要保证项目计划的简单，以及文档的简单，乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证，通过对项目阶段的分解，简化项目计划。至于文档的简单，我们完全可以抛弃复杂标准的文档模板，转而书写仅仅是自己需要关注的内容。至少，项目内部的文档完全可以言之有物，而不需要注重形式。我们还可以通过对项目过程进行裁剪，来保障过程的简单性。事实上，在极限编程中，很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计，包括持续集成和代码所有权，都是为了提高开发过程的效率，这实际上也是简单的一种体现。
“简单最好”是一种心态，更是一条原则。
（二）敏捷开发思想之拥抱变化
秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。
1、拥抱变化
Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。
传统的软件开发过程由于过分强调文档的完整，重视与客户的谈判与签订合同。所以，开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字，需求就确定下来，不可更改。若要更改，必须经过需求变更委员会，走非常严格的需求变更流程。如果软件开发真能如此，倒也算是我们开发人员的幸事。但现实总是残酷的，需求总是会变化。变化的原因有以下几种：1）业务发生了变化；
2）客户对业务的理解发生了变化；
3）需求分析人员对需求的理解出现了偏差，需要修正。
对于第一点，或许我们还能够根据合同与客户讨价还价，而对于后两点，尤其是第三点，我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户
的需求，针对变化给出相应的解决方案。
如何拥抱变化呢？我想可以通过如下方式来实现：
1）现场客户
很多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法，但有了和现场客户的及时沟通，我们才能够在发生变化的初始就能够获得第一手的资讯。如果事情总要发生，早解决绝对比晚解决要好，而且要好得多。
如果在开发中，没有办法让客户成为团队的一员，那么我们也应该指定一位客户代表，退而求其次，也应该在团队中指定一位业务专家负责业务事宜，也就是Scrum中Product Owner的角色。总之，我们需要在项目开发中，能够让开发人员在对需求理解发生困惑时，能够明确地知道由谁来负责。而一旦需求发生变化，也必须有专门的角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定，也必须由这个角色指定。
2）定期迭代和小版本交付
不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint，持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。
敏捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以信心，另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了，那就是我们的客户。如果没有现场客户，则小版本的交付则显得尤为重要，因为它
给了我们及早修订错误的机会。
3）持续改进
开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。
在Scrum中，每个Sprint完成并结束了评审会议之后，都会召开一个回顾会议，即使总结优秀经验，检讨错误与教训，团队方能够从错误中成长起来。此外，回顾会议还能够帮助团队正确地认识自己，帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议，可以让客户更直观地了解团队，比提出自己的看法，有助于在后面的开发过程改善合作的质量。
（三）敏捷开发思想之自我组织
最佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估，并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。
自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的技术特长，开放的平台则能够保证协作的效率。
一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。自我组织的团队建立在团队个人能力的基础之上。它其实是一把双刃剑。
如果团队成员个人能力有限，或者自我约束能力较差，而管理人员又无法把握松散管理的度，就很可能出现一些问题。例如：
1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式；
2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；
3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间。
如何解决这三个问题？对于第一个问题，最佳方式是循序渐进，并对自我组织的方式进行改进，例如和传统的管理方式结合起来。
对于第二个问题，需要动用团队的力量。例如对任务的评估，我们可以利用计划游戏，或者设计计划纸牌对任务工作量进行估算。总之，我们应尽量让团队对任务工作量的估算不要出现太大的偏差，使任务的开发在可控的范围内。此外，及时召开回顾会议，也是杜绝这类问题的一件利器。
第三个问题需要团队的管理者建立某些准则，例如对技术问题的讨论设定时间的限制。一旦超出该时间，就应该把问题放在一边，或者由管理者利用自己的权威和经验下定结论，而不能无限制的争执下去。
自我组织的团队管理者需要因时因人而置宜。Larry L. Constantine在《人件集》中提到：“对于开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分析、设计和系统构建。”例如在Scrum中，团队角色就是一个自我组织的团队，由团队来确定
每个Sprint的工作内容。而Scrum Master就不再是控制者，而是指导者；不是上司，而是教练。他必须理解自组织团队的重要性。
自我组织是敏捷管理的精髓，也是敏捷管理成败的关键！
浅谈敏捷项目管理在软件开发中的应用 摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。 一、使用传统项目管理技术管理软件开发项目的方法 按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。 在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？ 以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但发现推
行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。 本文主要讲述处于第二个层次的软件开发组织的项目管理问题。软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。 按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程： 计划编制的经典步骤： ①建立企业和项目资源库：这个是进行项目管理的基础工作。 ②设置项目日历、资源日历。 ③设置项目的主要里程碑点。 ④在WBS（工作包）下列出工作清单（Task，Activity）。工作分解结构（WBS）和作业是进行项目范围管理的途径。 ⑤对每个Task估计工期。 ⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。
敏捷开发流程详解by yangdl 1敏捷开发流程 ?敏捷软件开发核心是迭代式开发，增量交付。 ?每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。 ?迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 ?迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。 1.1敏捷流程详解图-敏捷流程图 1.2敏捷流程三种角色及其职责
1.3敏捷开发流程详解 1.3.1流程图详解步骤 1.制定产品需求列表 ?PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表； 2.召开计划会议 ?PO召集TM和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物， ?冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工作量估算
（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6h时间； ?在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集 成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员； ?项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决， 在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM 主要是维护秩序、规则及其引导作用。 3.需求分析、设计、编码和测试： ?计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试； ?这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要 项目组根据实际情况决定，但客户要求交付的文档必须要输出； 4.冲刺任务单和燃尽图更新 每天SM需要根据每日站立会上TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。 5.迭代周期结束点 ?已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。 ?这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需 求列表中挑选优先级高的进行开发。 6.冲刺评审会议 ?TM需要召开冲刺评审会议，邀请PO、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO及其相关利益 人来参加外，TM全体成员，也可以邀请其他相关人员参加。 7.冲刺回顾会议 ?迭代输出的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭 代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：
BJUG
敏捷软件开发方法理论与实战
敏捷软件开发方法理论与实战
https://www.doczj.com/doc/ee15719309.html,/ mailto:morningspace@https://www.doczj.com/doc/ee15719309.html,
https://www.doczj.com/doc/ee15719309.html,/
BJUG
敏捷软件开发方法理论与实战
议 题
? ? ? ? 敏捷方法概述 极限编程简介 敏捷实践案例 敏捷游戏
https://www.doczj.com/doc/ee15719309.html,/
BJUG
敏捷软件开发方法理论与实战
敏捷方法概述
https://www.doczj.com/doc/ee15719309.html,/
BJUG
敏捷软件开发方法理论与实战
开场白
军事历史就是一个在装备和灵活性的相对优势之间来回摇摆 的钟摆。
—— 卡尔·冯·克劳塞维茨《战争论》
– – – –
盔甲骑士 vs. 布衣士兵 盔甲骑士 vs. 轻骑兵 坦克 vs. 轻骑兵 坦克 vs. 反坦克导弹
在IT领域，我们正好都在从装备统治一切的时代走出来。现 在我们正进入一个唯有灵活性才是至关重要的时代。
—— Tom DeMarco《规划极限编程》序
– 工程方法 vs. 没有方法 – 工程方法 vs. 敏捷方法
https://www.doczj.com/doc/ee15719309.html,/
BJUG
敏捷软件开发方法理论与实战
工程方法 Engineering Methodology
? 借鉴了工程领域的实践，有着严格而详尽的规定，强调 项目的可控性 ? 官僚繁琐，要做太多的事情从而延缓开发进程 ? 从泰勒主义，到精益制造
https://www.doczj.com/doc/ee15719309.html,/
敏捷软件开发:SRP单一职责原则 (2009-03-24 20:30:24) 转载 标签： it 这条原则实际就是体现内聚性原则的体现，一个模块的组成元素之间的功能相关性。把内聚性概念扩展一下：把内聚性和引起一个模块或者类改变的作用力联系起来。 一个类应该只有一个发生变化的原因。若Game类有2个不同的职责，一个是记录当前轮，另一个式计算分数，最后要把这两个职责分离到两个类中。为何把这两个职责分在单独的类中呢？因为每个职责都是变化的一个轴线，当需求变化会反映为类的职责的变化。如果一个类承担了多于一个职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责太多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合或导致脆弱的设计，当变化发生时，设计会遭受到预想不到的破坏。 定义职责：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，有时候我们很难注意到这点，我们习惯以组的形式去考虑职责。 public interface Modem{ public void Dial(String pno); public void Handup(); public void Send(char c); public char Recv(); } 接口包括了2个职责，第一个职责是连接管理，第二个职责是数据通信。 如果应用程序的变化方式总是导致这两个职责同时变化，那么就不要分离他们，分开他们就会有不必要的复杂性味道。仅当变化发生时，变化的轴线才有实际意义，如果没有征兆，那么应用SRP或者任何其他原则都是比明智的。 分离耦合的职责：经常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿意耦合在一起的东西欧和在一起了。然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦概念。 如果ModenImplementation implemet DataChannel,Conection。ModenImplementation看起来是一个混杂物，或者有缺陷的类，所有的依赖关系都是从它发出来的。谁都不需要依赖它，谁都不需要知道它的存在。因此，我们已经把丑陋的部分隐藏起来了。其丑陋性不会泄露出来，污染应用程序的其它部分。 持久化：如Emplyee:CalculatePay,Store,Emplyee类包括了业务规则和对于持久化的控制，这两个职责在大多数情况下绝不应该混合在一起。业务规则往往会频繁地变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也不一样。把持久化系统和业务规则绑定在一起是自讨苦吃的做法。如果发现这种情况存在了，应该使用FACADE、dao或者proxy模式对设计进行重构，分离这两个原则。 SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。
Scrum敏捷软件开发过程 目录 ?什么是敏捷软件开发？ ?敏捷方法的项目计划 ?敏捷项目管理和传统项目管理 ?为什么使用敏捷？ ?Scrum概述 ?Scrum的角色 ?Scrum实践和工作产品 ?敏捷开发中的估计方法 ?测试驱动开发 ?Scrum应用 ?支持工具和模版 ?一些常见的误解 敏捷开发方法 什么是敏捷软件开发? ?敏捷软件开发是软件项目的一个概念框架. ?有许多建立在敏捷概念上的方法，如Scrum和Extreme Programming(XP). ?与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）?最大限度地降低短期固定时间的迭代式软件的开发风险. 敏捷宣言（2001年） ?人和交互胜过过程和工具. ?Individuals and interactions over processes and tools ?可以工作的软件胜过完备的文档. ?Working software over comprehensive documents ?客户协作胜过合同谈判. ?Customer collaboration over contract negotiation ?随时应对变化胜过遵循计划. ?Responding to change over following a plan 敏捷过程的限制 ?敏捷软件开发过程包含过程、原则、工具，和最重要的-人 ?因此：诚信是基础 ?没有过程能够对诚信进行有效地约束，诚信与否是有效实施敏捷过程的最大限制
Product constantly Scope frozen new PBL items to next Sprint Backlog 使用敏捷方法的项目计划 “Sprintful” of top - priority PBL to the next Sprint Sprint More accurate estimates as man hours 8 Short term planning (commitment by May be 5 2 1 3 8 5 8 ∑32 Long term planning (best guess at the moment): Initial Size Estimates As Story Points Velocity 8 SP/Sprint 4 Sprints T arget Sprint for each PBL item set, feasible implementation Order. 敏捷项目管理和传统项目管理 ? 传统项目管理： ? 事先对整个项目进行估计、计划、分析 ? 反对变更; 变更需要重新估计、重新规划 ? 严密的合同来减少风险, 如果改变需求要走 CR 流程. ? 项目作为一个“黑盒子”，对客户与供应商的可视性差. ? 产品化和测试阶段是分离的. ? 文档和计划驱动的方法. ? 软件交付时间晚, 意识到风险的时间晚. ? 敏捷项目管理: ? 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. ? 鼓励变化, 客户价值驱动开发. ? 信任和赋予权力;合约使变更变得简单，增加价值. ? 客户和开发人员之间是紧密的连续的合作关系 ? 每次迭代都产生可交付的软件 ? 专注于交付软件. ? 第一次迭代就可交付能工作的版本，风险发现的早. 为什么采用敏捷? –预期的收益 ? 采用敏捷方法得当的话，可以： ? 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 . ? 快速交付, 每次迭代都能交付可运行的软件. ? 最高风险和最高优先级的需求，最优先进行开发. ? 改善应对变更能力, 减少大量的重计划. ? 改善项目沟通. ? 更好的客户参与, 避免错误的假设. ? 总之: ? 提高了生产率; 减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明
敏捷开发与敏捷测试 来源: cnblogs 敏捷开发：1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。2.敏捷型方法是“面向人” 的(people-oriented) 而非“面向过程”的(process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。 我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心。 敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有多。改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。” 敏捷开发提出了以下遵循的原则： ·我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 ·即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 ·经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 ·在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 ·围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 ·在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 ·工作的软件是首要的进度度量标准。 ·敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 ·不断地关注优秀的技能和好的设计会增强敏捷能力。 ·简单是最根本的。
敏捷是一个术语，用于描述软件开发的方法，强调增量交付，团队协作，持续计划和持续学习，而不是试图在接近结束时立即交付。 敏捷专注于保持流程的精益，并创建最小的可行产品（MVP），在最终结果出现之前经历多次迭代。不断收集和实施反馈，总而言之，这是一个更加动态的过程，每个人都在朝着一个目标努力。 Scrum和其他的敏捷方法 敏捷是一种思维方式，它是一套价值观和原则。敏捷是一种思考和行动的方式。敏捷就是短周期，迭代和增量交付，快速失败，获得反馈，及早向客户提供商业价值，关于人员，协作和互动。敏捷是一种关于透明度，检查和适应的心态。但是，敏捷不包含任何角色，事件或工件。这是一种心态。例如，Scrum是敏捷伞下广泛使用的框架之一，它可以帮助你变得更敏捷，但敏捷运动中有更多的框架，如看板，XP，Crystal等等，如图所示下面：
Scrum Scrum是一个框架，人们可以在其中解决复杂的自适应问题，同时有效且创造性地提供具有较高价值的产品。它用于管理软件项目和产品或应用程序开发。它的重点是适应性产品开发战略，其中跨职能团队作为一个单元在2-4周内达成共同目标（Sprint）。它由一系列价值，文物，角色，仪式，规则和较佳实践组成。 Lean (精益) 精益起源于丰田生产系统（TPS），它在20世纪50年代，60年代及以后改变了实物商品的生产。精益保持其在制造业中的地位，但也在知识工作中找到了新的应用，帮助所有行业的企业消除浪费，改进流程并促进创新。软件开发是精益方法的自然应用，因为与制造业一样，它通常遵循一个确定的过程，具有一定的接受条件，并导致有形价值的传递。指导精益方法所有实践的关键概念，我们称之为精益支柱。他们是： ·连续的提高 ·尊重人 ·轻量级领导
.、八、- 刖言 什么是软件质量？很多技术同仁都认为软件质量是软件是否存在Bug，是否性 能高，安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于 某个（或某些）人的价值；价值是指创造利润，又或是降低成本。总的来说， 软件质量是软件的灵魂和存在意义。另外，我们知道现在敏捷开发日趋流行， 其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论, 敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件 的开发。 软件质量的理解 首先，我们先来看看什么是软件产品质量？先有了软件质量定性的了解，才能 介绍如何影响、控制和改进质量。 大师温伯格在《质量?软件?管理系统思维》说到：“质量就是软件产品对于 某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包含两个层次的质量含义，即“正确的软件”及“软件运行正确”： 1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值 此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果一个软 件能够满足需求的用户群体越大、创造的利润越大或减少的成本 越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug,扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户 创造价值，则这样的软件尽管运行良好，也无任何质量可言。 2.“软件运行正确”是说软件没有或很少Bug，扩展性很强，性能良好，易 用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量 的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是 一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用， 经常出错，性能很差，这样的软件也不是一个高质量的软件。 “正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败， 后者关系到软件的好坏。在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的Bug率，性能，可扩展性，架构等），经常陷入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求），开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用但无用零质量软件。 在产品开发中，能用但无用的现象尤为明显。产品和项目不一样，项目往往是 为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是
敏捷开发 敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 相关联的关键成功因素有： 组织文化必须支持谈判人员彼此信任，人少但是精干，开发人员所作决定得到认可，环境设施满足成员间快速沟通之需要。最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的阶段。 对比其它方法 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化. 对比迭代方法 相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。 对比瀑布式开发 两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。 相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。 极限编程
1946年，世界上第一台电子计算机诞生在美国宾夕法尼亚大学的摩尔学院，由此拉开了计算机软件的发展史。从宏观角度而言，计算机软件的发展主要经历了以下三个阶段[1]。 （1）第一阶段——程序设计阶段 20世纪60年代以前还没有软件开发的说法，那时只有程序设计的概念，最多在写出程序后配有程序结构说明和使用说明。经典的程序设计方法为“程序设计=数据结构+算法”。 （2）第二阶段——软件工程阶段 20世纪70年代以来，人们认识到软件的工作不能仅限于编写程序，软件开发工作在程序编写之前和之后还有很多重要的工作不能忽略，例如需求分析、测试、维护等等。在总结“软件危机”教训后，人们认识到并建立了软件工程的思想。软件工程摒弃了认为只有充满编程技巧的程序才能高水平地发挥个人才能的观念，强调程序的可读性、可理解性、可测试性和易修改性等工程化的原则。 （3）第三阶段——软件过程阶段 从20世纪90年代开始，人们更加强调软件开发的效率、软件的质量以及与软件开发相关的管理工作，建立了“软件过程”的概念。软件过程不仅包括软件开发过程，还包括了支持性、管理性过程。 以上发展历程表明，通过实践、总结、再实践、再总结……人们对软件这门实践学科的理解正朝着更全面、更系统、更深刻的方向发展。 1.1 现代软件产业的困境 1.1.1 困境中的现代软件产业 当今，全球市场变幻莫测，用户需求日趋复杂，IT技术日新月异。软件企业组织在不断变化的市场和技术环境中能否取得成功，关键在于企业组织是否能在市场许可的期
2 限和有限资源条件下不断推出满足用户需求的产品。 然而，现代软件产业的总体情况并不理想。下面先来看一个真实的案例[14]。 Square Cal 3.0版本计划在2.0版本上市后的10个月内发布。项目经理Mickey和上司Kim讨论后决定：他们将为项目组成员提供私人办公室、最新型的计算机以及免费的碳酸饮料，并且要求开发者在前8个月按照预先设计好的接口各自开发，8个月之后进行可视化锁定，在最后2个月内完成系统集成。这是一个完美的计划。于是项目组成员各自做着自己的工作。随着可视化锁定日期的来临，他们开始进行代码集成。他们在可视化锁定最终截止日期前一天的下午两点开始工作，但很快发现程序不能编译通过，更不用说运行了。代码在编译时有数十个错误，而似乎每处理一个错误就会产生十个以上的新错误。他们一直干到午夜也没有结果，只好决定第二天再说。但测试发现问题的速度远比开发人员解决问题的速度快，解决系统某一部分的错误经常会导致其他部分的新问题。项目超期，项目组成员在巨大的压力下工作，士气逐渐低落。最后整个软件开发过程用了15个月时间，即超过了项目计划时间的50%，公司错过了最佳的产品发布日期。产品发布后，用户对Square Cal 3.0版本反映冷淡，在几个月的时间内其市场份额从第二位下降到第四位。 再看一组统计数据。图1-1[12]是根据最近一次项目调查得到的某公司所有软件项目的完成情况。从图中可以看出，出现问题的项目和中途取消的项目所占比例远高于顺利完成的项目。实际上，图1-1代表了整个现代软件产业的现状，很多软件项目最终不能交付，或者最终交付的软件项目进度发生延期、成本超出预算，而且运行经常不可靠。 因此，诸如“软件开发的滑铁卢”（Software Runaways）[2]、“死亡之旅”（Death March） [3]之类关于软件失败项目的报道不时见诸于媒体报端也就不足为奇。 53%16% 31% 中途取消的项目 出现问题的项目 顺利完成的项目 图1-1 项目完成情况图 1.1.2 陷入困境的根源 众所周知，现代计算机和因特网的性能在逐年增强，用户对运行于计算机和因特网
敏捷软件开发过程中高质量软件的开发 姓名：郑哲学号：21120233071 目录 一、敏捷开发的意义 (2) 二、敏捷开发同软件质量并无矛盾 (2) 1、沟通 (3) 2、简单 (3) 3、反馈 (3) 4、勇气 (3) 三、如何在敏捷开发过程中开发出高质量的软件 (3) 1、勇于重构 (4) 2、简单设计 (4) 3、编程规范 (5) 4、平稳的工作效率 (5) 5、每日会议 (5)
一、敏捷开发的意义 敏捷软件开发又称敏捷开发是一种从1990年代开始逐渐引起广泛关注的一 些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。并不意味着没有文档、没有设计、没有计划随意设计的万能钥匙[1]。 对于从前预见式的软件产品开发，在第一次挖成规格说明以及需求分析后，就进行软件产品的构建，并在开始阶段对所有的安排以及调度等细节活动进行安排，一般情况下不对计划做成没有预定义的变动，造成了项目计划的改动率极低。而相对来讲，敏捷软件开发并不在前期进行详细的规格说明，在开始阶段随着经验数据的出现，计划与估算的可能性才会相应增加，并通过构建反馈周期，推动自适应步骤，因此改动率较高，同时更加注重响应变化而不是一味遵循计划进行软件产品的开发[2]。 针对敏捷软件开发的目标，提出了12条的敏捷宣言： 1、最优先的目标是通过尽早地、持续地交付有价值的软件来满足客户。 2、欢迎需求变化，甚至在开发后期。敏捷过程控制、利用变化帮助客户 取得竞争优势。 3、频繁交付可用的软件，间隔从两周到两个月，偏爱更短的时间尺度。 4、在整个项目中业务人员和开发人员必须每天在一起工作。 5、以积极主动的员工为核心建立项目，给予他们所需的环境和支持，信 任他们能够完成工作。 6、在开发团队内外传递信息最有效率和效果的方法是面对面的交流。 7、可用的软件是进展的首要度量指标。 8、敏捷过程提倡可持续开发。发起人、开发者和用户应始终保持一个长 期的、稳定的开发速度。 9、简化——使必要的工作最小化的艺术——是关键。 10、持续关注技术上的精益求精和良好的设计以增强敏捷性。 11、最好的架构、需求和设计产生于自我组织的团队。 12、团队定期地对运作如何更加有效进行反思，并相应地调整、校正自己 的行为。 二、敏捷开发同软件质量并无矛盾 首先，根据敏捷项目开发的要求以及目标，我们提出四个敏捷开发的价值目标：沟通、简单、反馈以及勇气。同上一节讲到的敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性，同时拥抱市场变化，拥抱客户需求变化，采用迭代反馈的方式管理项目[3]。 我们将从这四个方面一次论证敏捷项目开发同软件质量保证之间并无矛盾。
探讨如何进行敏捷软件开发 软件工程自诞生以来,一直试图通过技术和管理的手段来降低软件项目的不确定性。在这个美好的愿望指导下,专家们发明了结构化、发明了面向对象、发明了CMM,这些新的技术和方法的确有助于“软件危机”的解决,促进了软件业的发展;然而,超支、超时、低质量的老问题并未得到根本解决多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改”(code and fix)。设计过程充斥着短期的、即时的决定,而无完整的规划。这种模式对小系统开发很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。错误故障也越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。2001年2月在美国犹他州,敏捷软件开发联盟(Agile Software Development Alliance)成立。在这之前,联盟的成员们在轻型方法的探索与实践方面做了很多有益的工作,知名的XP(Extreme Programming,极端编程)方法就是众多Agile方法论中的一种。敏捷(Agile)方法是对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。 1敏捷方法将拥有大量artifact(软件开发过程中的中间产物,如需求规约、设计模型等)和复杂控制的软件开发方法称为重型(Heavy Weight)方法,而把artifact较少的方法称为轻型(Light Weight)方法。敏捷方法(Agile Methodologies)汲取了众多轻型方法的“精华”,恰当地表达了这些轻型方法的最根本之处。首先,敏捷方法强调适应,而非预测。重型方法花费大量的人力物力,试图制订详细的计划来指导长期的工作,而一旦情况变化,计划就不再适用。因此重型方法本质上是抵制变化的,而敏捷方法则强调适应变化。其次,敏
对象持久与敏捷软件开发 软件设计白皮书 Dirk Bartels 与Robert Greene 编制：Versant中国 2009 年11月 Versant China 上海市昆明路572号B区415-419室 邮箱： info@https://www.doczj.com/doc/ee15719309.html, 电话： (021) 5172 1968 传真： (021) 5172 1967 网址： https://www.doczj.com/doc/ee15719309.html, P 001
概述 效的软件开发方法之一。敏捷软件开发方法的挑战 之一是需要将非面向对象子系统，例如MySQL ， Oralce或者其它关系型数据库管理系统（RDBMS） 与现有的，面向对象的系统集成在一起。关系型数 据库要求将源代码在对象模型和关系模型之间进行 “翻译”，也就是众所周知的“对象关系映射—— ORM”。管理对象到关系的映射不仅仅非常消耗时 间，而且关系型数据库及其Schema经常处于受 限，或者无法“敏捷开发”的状态下。而且，存储 在关系型数据库中的数据经常可能会无法与采用敏 捷开发方法的团队对应用所进行的变更相匹配。 实际上，关系型数据库的数据由于是采用独立管理、独立建模的方式，它的自成体系必然会要求开发团队将有限的开发资源分成两部分。团队的管理者不仅仅需要管理源代码的同步，而且还需要管理实体关系模型的同步，进一步还要保持二者之间映射的同步。在这种情况下，大量的资源就被浪费甚至内耗掉了。尤其是当采用敏捷开发方法，源代码处于经常性的快速变动过程中时，保持对象模型和实体关系模型的一致就是一个费时费力的工作。 这种情况不仅仅会发生在采用敏捷开发方法的团队中，而且也会大量发生系统构建原型期。由于在这个阶段系统需求无法完全明确，可能会根据系统产出有快速迭代的要求，尤其是在中国的特殊国情下更是如此。在一些复杂的、对性能要求很高或者复杂度很高的系统中，这种对象-关系维护成本造成的开发团队的注意力不集中甚至会危及整个原型产品的生命。 本文将通过检讨和比较在采用敏捷开发方法的团队中，采用关系型数据库以及集中常见对象数据库的数据持久方法，对整个开发效果所带来的不同。同时，我们将对不同的持久方法对敏捷应用开发项目的开发速度和开发质量所带来的冲击进行量化的描述。我们相信在 采用敏捷开发方法的项目中，采用真正的对象持久工具，相比较于传统的关系型数据库管 理系统，能够大大改善开发团队的财务状况，以及通过提高开发速度来提高产品抢占市场 P 002
达明咨询精品培训课程 课程名称 RDM065 敏捷软件开发与架构设计（Agile Software Development and Agile Architecture） 参加对象 企业CEO/总经理、研发总经理/副总、公司总工/技术总监、研发项目经理/产品经理、PMO（项目管理办公室）成员、研发骨干、测试、QA等。 客户需求 1、熟悉敏捷开发的流程，掌握敏捷开发关键环节活动和输出物； 2、如何有效的进行需求的管理和分析，形成产品需求； 3、如何做一个卓越的产品经理，要掌握哪些技能和工具； 4、项目经理需要哪些关键的技能，如何处理需求与产品的矛盾，业务需求与产品的矛 盾； 5、如何做到高效的测试，保证软件产品的质量，需要掌握哪些技能和工具； 6、如何构建优秀的敏捷团队，提高交付能力； 7、怎么样有效的提高项目的研发管理以及团队成员的评价和有效绩效管理； 8、如何提高异地办公研发项目管理，增强团队协作，构建统一的产品； 课程背景 21世纪是“快鱼吃慢鱼”的时代！ 现代企业的竞争就是“速度”的竞争！！ 谁能尽快开发出符合客户需求的产品，谁就是大赢家！！ 如何使产品开发周期显著缩短？如何促使企业充分利用外部资源，寻求合作设计、开发和制造的机会，让新产品上市时间更快？ “敏捷化开发”是国外最新提出的着眼于速度竞争的新产品开发管理模式，其基于一系列先进的研发管理方法，采取产品开发与市场投入的速度领先战略，以获得产品开发的时间领先优势，使企业在竞争日趋激烈的环境中获取利益最大化。 软件系统的日益复杂化和用户需求、软件更新的频繁化，加之开发团队分散的工作方式，项目的沟通和平滑管理变得越来越困难。另一方面，如何在多角色分工的情况下，紧扣用户提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发
敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践，揭示 更好的软件开发方法。通过这项工作，我们认为： 个体和交互胜过 过程和工具 可以工作的软件胜过 面面俱到的文档 客户合作胜过 合同谈判 响应变化胜过 遵循计划 虽然右项也具有价值， 但我们认为左项具有更大的价值。 C. Martin Grenning Robert James Beck Kent Mellor Highsmith Steve Mike Beedle Jim Ken Schwaber Hunt Bennekum Andrew Arie van Jeffries Jeff Sutherland Cockburn Ron Alistair Thomas Kern Dave Cunningham Jon Ward Marick Martin Fowler Brian
敏捷宣言遵循的原则 我们遵循以下原则： z我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 z即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 z经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 z在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 z围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 z在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 z工作的软件是首要的进度度量标准。 z敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 z不断地关注优秀的技能和好的设计会增强敏捷能力。 z简单——使未完成的工作最大化的艺术——是根本的。 z最好的构架、需求和设计出自于自组织的团队。 z每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
前言 什么是软件质量？很多技术同仁都认为软件质量是软件是否存在 Bug，是否性 能高，安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于 某个（或某些）人的价值；价值是指创造利润，又或是降低成本。总的来说， 软件质量是软件的灵魂和存在意义。另外，我们知道现在敏捷开发日趋流行， 其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论， 敏捷开发是追求高质量软件的方法论和过程。 本文将和大家一起探讨软件质量的含义，以及敏捷开发中如何进行高质量软件 的开发。 软件质量的理解 首先，我们先来看看什么是软件产品质量？先有了软件质量定性的了解，才能 介绍如何影响、控制和改进质量。 大师温伯格在《质量·软件·管理系统思维》说到：“质量就是软件产品对于 某个（或某些）人的价值”（某个或某些人文章中统称之为用户），这里面包 含两个层次的质量含义，即“正确的软件”及“软件运行正确”： 1.“正确的软件”是说，一个软件要能够满足用户的需求，为用户创造价值。 此处的价值可以体现在两个方面，即为用户创造利润或者减少成本。如果 一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本 越大，则该软件产品的质量越高。反之，一个产品尽管运行良好，没有 Bug，扩展性很强，性能很好，但如果没有服务的用户人群，没有为用户 创造价值，则这样的软件尽管运行良好，也无任何质量可言。 2.“软件运行正确”是说软件没有或很少 Bug，扩展性很强，性能良好，易 用性高等。这样的软件是一个运行良好的软件，但还不能称之为高质量 的软件。只有在软件符合用户的需求的基础上，运行良好的软件，才是 一个高质量的软件。当然，如果软件完全符合用户需求，但不易使用， 经常出错，性能很差，这样的软件也不是一个高质量的软件。 “正确的软件”及“软件运行正确”二者相辅相成，前者关系到软件的成败， 后者关系到软件的好坏。在现实的很多开发团队中，特别是偏技术的开发团队中，往往过分注重后者（软件的Bug率，性能，可扩展性，架构等），经常陷 入在软件开发过程的细节之中，而忽略了前者（软件需要符合用户的需求）， 开发出的软件经常能用但无用，不是最终用户期望的软件，这样的软件是能用 但无用零质量软件。 在产品开发中，能用但无用的现象尤为明显。产品和项目不一样，项目往往是 为某个客户而开展，有特定的需求来源，而产品往往是一个更广泛的概念，是 市场上某一类客户群体的价值代表，没有固定的需求来源，而且良好的产品往
敏捷开发介绍（一） 1敏捷开发知识体系简介 Agile（敏捷）一词来源于2001年初美国雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会，随后他们成立了“敏捷联盟”，并制定了敏捷宣言。 敏捷软件开发又称敏捷开发，是一种从20世纪90年代开始捉奸因其广泛关注的一些新型软件开发方法，它基于更紧密的团队协作、持续的用户参与和反馈，能够有效应对快速变化需求、快速交付高质量软件的迭代和增量的新型软件开发方法。 敏捷开发更注重人的作用，强调个人和团队协作及自组织、通过短迭代快速交付和展示价值、持续的客户参与及反馈和快速响应变化。 敏捷开发是哲学理念、价值观和一系列开发实践的综合。这种哲学理念关注持续的交付价值，推崇让客户满意和软件尽早发布。接受敏捷理念的客户和工程师有着共同的观点：唯一真正重要的工作产品是在合适时间提交给客户的可运行软件。 敏捷开发同时，又是一种轻量级的开发方法，他通过一个或多个跨职能的小型团队分多个迭代持续增量的交付价值。敏捷开发通过迭代和快速用户反馈，管理不确定性和拥抱变化。 敏捷开发恰当的保留了软件开发过程的基本框架活动：用户沟通、策划、设计构建、交付物和评估，它以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态以此推动项目朝着构建和交付发展。 敏捷开发知识体系框架可分为3层：核心价值层、敏捷开发方法框架层和敏捷实践层。核心价值层主要包括敏捷宣言和12个原则；敏捷开发方法框架层主要包括各种敏捷开发过程框架，包括XP、Scrum、精益开发和OpenUP等；敏捷开发实践层则主要包括用于指导敏捷开发的各种实践。敏捷开发知识体系层次如下图：
软件开发模式简介 1. 边做边改模型（Build-and-Fix Model） 好吧，其实现在许多产品实际都是使用的“边做边改”模型来开发的，特别是很多小公司产品周期压缩的太短。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。 在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。 这是一种类似作坊的开发方式，边做边改模型的优点毫无疑问就是前期出成效快。 对编写逻辑不需要太严谨的小程序来说还可以对付得过去，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于： 1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改； 2）忽略需求环节，给软件开发带来很大的风险； 3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。 2. 瀑布模型（Waterfall Model） 瀑布模型是一种比较老旧的软件开发模型，1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代都还是一直被广泛采用的模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型优点是严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： 1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； 2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加 了开发的风险； 3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。 4）各个软件生命周期衔接花费时间较长，团队人员交流成本大。 5）瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。