敏捷软件开发开题报告.ppt

适应变化，通过迭代计划不断调整以适应需求变化 良好软件架构是适应变化的基石 软件的特点是庞大、复杂、生命周期长，因此需要良好架构来保证长期的演进，避免大规模的返工； 优秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷； 良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集成计划，使分层分级的持续集成更加容易实施。 软件架构需要尽早验证和持续维护 新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定； 增量开发需识别影响架构的需求，优先实现，规避架构风险； 通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。 敏捷实践概览 敏捷软件开发典型场景 敏捷工程实践：结对编程 Thank you。 * * * 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill)，重量级方法更强调文档(documentation)，过程(process)和正式(formality) understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分 　　discipline是指个人主动的完成工作，process指个人根据指令完成工作 　　skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作 随着敏捷开发（Agile Development）的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。 2001年2月由17位世界轻量级方法学家提出了一份敏捷联盟宣言，这个宣言只是简单的四句话，但却是敏捷方法的精髓，在谈敏捷方法之前就必须先对敏捷宣言有所理解。 * * * * * * * * * * 围绕价值流消除浪费：产品开发中消除不增值的活动、消除和减少不必要的等待（排队）。 价值指什么呢？在敏捷宣言中体现为可以工作的软件以及客户合作。 敏捷开发方法的原则是“刚刚好”(Light and Sufficient) n 工作的软件是首要的进度度量标准。 n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。　　 n 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 n 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 * * 巴比伦塔的管理教训 1. 清晰的目标？是的，尽管幼稚得近乎不可能。而且，项目早在遇到这个基本的限制之前，就已经失败了。 2. 人力？非常充足。 3. 材料？在美索不达米亚有着丰富的泥土和柏油沥青。 4. 足够的时间？没有任何时间限制的迹象。 5. 足够的技术？是的，金字塔、锥形的结构本身就是稳定的，可以很好分散压力负载。 那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。 * * 《人月神话》写成于1975年，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则：1/3计划1/6编码1/4构件测试和早期系统测试1/4系统测试，所有的构件已完成 * * 精益原则 　　和精益制造原则的概念相近，精益开发也可以总结为如下七条原则： 1、消除浪费 　消除浪费原则，最初是由大野耐一的理念所采用的。 Taiichi Ohno（丰田生产方式之父，也被称为“日本复活之父”和“生产管理教父”。他所创造的丰田生产方式（又称精细生产方式，或精益生产方式） ，是对曾经统治全球工业的福特式生产方式的重大突破，在全世界产生了深远的影响。丰田生产方式（TPS）是提高企业生命力的一整套概念和方法的体系。它是丰田公司通用的制造方法，其基本思想是“彻底杜绝浪费”，通过生产的整体化，追求产品制造的合理性以及品质至上的成本节约。【我认为只要杜绝浪费，生产效率就有可能提高10倍。这种想法，正是现在丰田生产方式的出发点。“彻底杜绝浪费”是丰田生产方式的基本思想,而贯穿其中的两大支柱就是： （1）准时化（JUST IN TIME）；（2）自働化。 2.尊重一线人员　　　 3.增强学习 　　 4.尽量延迟决定 　　　 5.嵌入质量 6.快速交付 7.整体优化 　　 如果发生了问题，找出的原因不充分的话，解决的对策也就没有什么意义。丰田在处理这种情况时，一般都是把5W1H。你对于一种现象连续问五个“为什么”了吗？这样做，说来容易，做起来就难了！比如，一台机器不转动了，你就要问：　　(1) “为