第一讲-敏捷实践与极限编程概述.ppt

* * * 极限编程实践 隐喻 隐喻（metaphore）是所有XP实践中最难理解的 一个。 隐喻是将整个系统联系在一起的全局视图 （如：智力拼图中的整张拼图的形状）， 它是系统的未来景象，是它使所有单独模块的位置和外观（shape）变得明显直观。 隐喻通常可以归结为一个名字系统，这些名字提供了一个系统组成元素的词汇表，并且有助于定义他们之间的关系。 总结 敏捷是来源于实践的思想和方法体系，具备鲜明的实践特征。 极限编程是一组简单、具体的实践，这些实践结合在一起形成了一个敏捷开发过程。 极限编程是一种优良、通用的软件开发方法。 参考资料 《敏捷软件开发：原则、模式与实践》 《加深敏捷理解的学习指导书》 《硝烟中的Scrum和XP》 《Scrum敏捷项目管理》 Page * * * * * * Ericsson直接招聘敏捷项目经理 * * * * * * * * * * * * * * * * * * 围绕价值流消除浪费：产品开发中消除不增值的活动、消除和减少不必要的等待（排队） * * * * * * * * * * * * * * 什么是技术债务？ 有哪些技术债务 技术债务不解决带来危害 * * * * 迭代交付 将一R版本分为多次迭代。 通常情况下，一次迭代的持续时间为2至4周。 对每张故事卡都作估算。 按照客户需求对故事进行排列，并按迭代对故事进行计划。 和团队所有成员召开会议，讨论故事，进行估算，达成一致。 * * * * 敏捷关注架构。 敏捷强调简单设计，只针对确定的需求设计，不为未来可能的变化做过多假设，这不代表不关注架构。敏捷需在前几轮迭代标识出对架构影响重大和最高优先级的5-10%的需求开展架构设计，并在迭代中早期验证架构设计的正确性。在后续迭代强调架构的演进性，不断的重构“坏味道”。同时，很多敏捷实践需要强有力的架构做基础，如CI、TDD。 要强调的是架构属于系统工程，是软件产品的基础。软件开发方法学（敏捷、ＣＭＭ）不可能代替系统工程。 * * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度延迟，主管给员工的压力马上体现出来，在传统瀑布模型下，质量的反馈需要等待很长的周期，质量不能马上形成压力。 迭代开发的一个明显优势就是快速将真实的质量反馈回来，有助于形成质量优先的氛围和树立没有质量的进度，是虚假的进度的导向，从而保证质量管理建立在真实，可工作的产品的基础上。 快速反馈的另一个明显的优势就是非常有利人员的技能增长，人如果总是在最终失败的体验中是不能成长的，最好成长的过程是经过失败后马上能改进，获得快速成功，（以往的CMM项目即使在项目末进行总结，经验不能马上被利用，这就是迭代促人进步的优势所在），在迭代开发中，一轮迭代发现自己做的不足，没有关系，下一次迭代立刻就有改进的机会，只要你认真对待每一次反馈，充分把每一次反馈当做改进的机会，团队就能在不断开发的过程中成长。 反馈在迭代开发实践中无处不在，可利用的反馈机制： 1. 持续集成结果； 2. 特性片测试结果； 3. 阶段回顾会议； 4. system acut 。。。 因此，是否能充分利用这些反馈机制是区分老开发模式和新开发方法的重要标志。 * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度延迟，主管给员工的压力马上体现出来，在传统瀑布模型下，质量的反馈需要等待很长的周期，质量不能马上形成压力。 迭代开发的一个明显优势就是快速将真实的质量反馈回来，有助于形成质量优先的氛围和树立没有质量的进度，是虚假的进度的导向，从而保证质量管理建立在真实，可工作的产品的基础上。 快速反馈的另一个明显的优势就是非常有利人员的技能增长，人如果总是在最终失败的体验中是不能成长的，最好成长的过程是经过失败后马上能改进，获得快速成功，（以往的CMM项目即使在项目末进行总结，经验不能马上被利用，这就是迭代促人进步的优势所在），在迭代开发中，一轮迭代发现自己做的不足，没有关系，下一次迭代立刻就有改进的机会，只要你认真对待每一次反馈，充分把每一次反馈当做改进的机会，团队就能在不断开发的过程中成长。 反馈在迭代开发实践中无处不在，可利用的反馈机制： 1. 持续集成结果； 2. 特性片测试结果； 3. 阶段回顾会议； 4. system acut 。。。 因此，是否能充分利用这些反馈机制是区分老开发模式和新开发方法的重要标志。 * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度