敏捷开发分享篇.pptVIP

敏捷开发 注：DC7.0项目组 * 二. 敏捷核心价值原则 三. 敏捷大致流程 一. 什么是敏捷开发？ 四. DC7.0敏捷 提纲 五. 给敏捷版本的建议 * 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 一. 什么是敏捷开发？ 1. 为什么说是以人为核心、需求进化为核心？ 瀑布开发模型整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心；已需求为核心。 2. 什么是迭代？ 迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。 3. 循序渐进。强调的是持续改进，使得你的团队高效工作。 * 二. 敏捷四大核心价值 2. 可工作的软件 高于理解文档 4. 变化响应 高于计划遵循 3. 客户协作 高于合同协商 1. 个人和互动 高于流程和工具 * 二. 核心价值解读 1. 个人和互动高于流程和工具 理解： 工具和流程固然重要，只是不如高效的团队合作更重要。敏捷重在以人为本，强调互动交流的重要性。 2. 可工作的软件高于理解文档 理解： 文档工作有其实际意义：一些最终交付给用户的文档，例如，用户手册和操作说明实际上正是最终解决方案中不可或缺的部分，不过也只是一小部分而已。永远不要忘记作为IT开发团队的首要任务是开发出符合用户需求的解决方案，而不是文档。不然的话，软件开发就该改名为“文档开发”了，不是吗？ * 二. 核心价值解读 3. 客户协作高于合同协商 客户协作 == 可理解为 各种不同的项目利益相关者，包括最终用户、他们的上司、高级IT主管、公司战略负责人、运营人员、支持人员、合规审查人员以及其他各色人等 理解： 只有项目的利益相关者本人能够告诉你他的需求是什么 他们可能无法很具体地描述解决方案 他们第一次可能无法抓住重点 在他们看到你的团队的实际工作成果后，可能会改变自己的想法 * 二. 核心价值解读 4. 变化响应高于计划遵循 理解： 所面临问题的理解会不断变化，有需求的变化、有关系人期望的变化、有环境因素的变化等等，变化是必然的。 预先制定项目计划是必需的，但是项目计划必须是有灵活性的。 * 二. 敏捷12条原则 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意 理解： 规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。 * 二. 敏捷12条原则 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 理解： 敏捷过程参与者不怕变化，他们认为改变需求是好事情，因为这些改变意味着我们更了解市场需求。 （不过还是要少变点好，折腾不起） * 二. 敏捷12条原则 3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。 理解： 保证交付的软件可以很好的工作，那么交付时间越短对产品质量就更有益 * 二. 敏捷12条原则 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 理解： 软件项目不会依照之前设定的计划原路执行，中间对业务的理解、软件的解决方案肯定会存在偏差，所以客户、需求人员、开发人员以及涉众之间必须进行有意义的、频繁 的交互，这样就可以在早期及时的发现并解决问题。 （这点重点强点的是交互沟通的重要性） * 二. 敏捷12条原则 5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。 理解：只要个人的目标和团队的目标一致，我们就需要鼓舞起每个人的积极性，以个人为中心构建项目，提供所需的环境、支持与信任。 * 二. 敏捷12条原则 6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 理解：在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。 * 二. 敏捷12条原则 7、 工作的软件是首要进度度量标准。 理解：衡量这个功能是否完成