敏捷软件开发解读.pptVIP

适应变化，通过迭代计划不断调整以适应需求变化 良好软件架构是适应变化的基石 软件的特点是庞大、复杂、生命周期长，因此需要良好架构来保证长期的演进，避免大规模的返工； 优秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷； 良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集成计划，使分层分级的持续集成更加容易实施。 软件架构需要尽早验证和持续维护 新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定； 增量开发需识别影响架构的需求，优先实现，规避架构风险； 通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。 敏捷实践概览 敏捷软件开发典型场景 敏捷工程实践：结对编程 下期再见！ 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系统测试，所有的构件已完成 * * 上面是比较流行的业界敏捷实践的概览，敏捷实践分为两个部分：管理实践和工程技术实践。 这些实践是相关行业公司通过结合敏捷思想结合自身情况的而积累的经验。 敏捷本身对人员技能没有要求，是实践对人员技能有要求。实践是形，是有效经验固化的载体，应结合实际情况具体分析采用，盲目引入只会起到反效果。 优秀实践的不断积累是成功的、长期而持续过程改进的关键。 敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。 * * 精益原则 　　和精益制造原则的概念相近，精益开发也可以总结为如下七条原则： 1、消除浪费 　消除浪费原则，最初是由大野耐一的理念所采用的。 Taiichi Ohno（丰田生产方式之父，也被称为“日本复活之父”和“生产管理教父”。他所创造的丰田生产方式（又称精细生产方式，或精益生产方式） ，是对曾经统治全球工业的福特式生产方式的重大突破，在全世界产生了深远的影响。丰田生产方式（TPS）是提高企业生命力的一整套概念和方法的体系。它是丰田公司通用的制造