敏捷开发流程与方法.ppt

* * 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 * 2001年2月11~13日，在美国犹他州Wasatch山的滑雪胜地Snowbird XP、Scrum、DSDM、ASD、Crystal、FDD等方法的代表人物17人签署了敏捷软件开发宣言： Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 教师在讲解时必须体现：价值驱动、勇气、沟通、反馈、简单的原则 ======= 　　1．个体和交互胜过过程和工具 　　人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。 　　2．可以工作的软件胜过面面俱到的文档 　　没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。 　　3．客户合作胜过合同谈判 　　不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。 　　4．响应变化胜过遵循计划 　　响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。 * * * Sustainable Pace---稳定的步伐，保持开发在一个稳定的步伐。 * Sustainable Pace---稳定的步伐，保持开发在一个稳定的步伐。 * * 新计划经济 * Consultant 的笑话，1、告诉客户他已经知道的东西；2、拿了不该拿的东西。 * 一道道地上菜。 * * 一道道地上菜。 * * 考试大纲 * * * SCRUM将软件开发团队比拟成橄榄球，有明确的最高目标，熟悉开发流程中所需要的最佳技术，具有高度的自主权，需要紧密地合作，高度的弹性解决各种挑战，确保每天、每个阶段都朝着目标推进。 * 那么接下来，我们就来介绍一下Scrum中的几个基本概念。 3个基本角色包括Product Owner, Scrum Master, Scrum Team. Product Owner的职责是利用产品的backlog(软件开发需求清单),督促团队优先开发最具价值的功能。产品负责人代表项目中每位利益开发人的权益，并为项目的软件系统负责，产品负责人规划项目初始总体要求，投资回报目标和发布计划。产品负责人将频繁的检查待开发需求的优先级次序，将最具有价值的的需求安排到下次迭代中。 Scrum Master需要对整个Scrum过程负责。向所有项目参与者讲述Scrum方法，负责实施Scrum，确保它既符合企业文化，又能预期交付利益。还需要督促全体成员遵从Scrum