常见的敏捷开发介绍.ppt

* * * 资源组 公司内最常见的“组”，按业务领域、子系统划分（比如信令组等），是长期存在的资源团队。一般同时支持多个版本开发。不能算作“项目”，只是一个资源池团队；在规模上一般也超过team。 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Ericsson直接招聘敏捷项目经理 * * * * * * * * * * * * * * * * * * * 围绕价值流消除浪费：产品开发中消除不增值的活动、消除和减少不必要的等待（排队） * * * * * * * * * 上面是比较流行的业界敏捷实践的概览，敏捷实践分为两个部分：管理实践和工程技术实践。 这些实践是相关行业公司通过结合敏捷思想结合自身情况的而积累的经验。 敏捷本身对人员技能没有要求，是实践对人员技能有要求。实践是形，是有效经验固化的载体，应结合实际情况具体分析采用，盲目引入只会起到反效果。 优秀实践的不断积累是成功的、长期而持续过程改进的关键。 * * * * 实践 (Practices) 团队根据自身情况选择合适的实践应用 组织(Organization) 组织适应产品业务架构、PMO产品管理办公室、测试、产品管理等 过程(Process) 流程、敏捷项目管理策略等 绩效度量（Performance) 业务价值、质量、过程改进 管理监控(Governance) 包括管控点设置，如投资评审和风险评估等 文化理念(Culture) 从命令控制式的管理文化转向领导协作的文化，加强透明性和实际性 技术和业务对齐(Alignment) 业务策略、IT策略、企业/产品架构、产品组合管理、合同、能力规划等对齐 * * * * * * 什么是技术债务？ 有哪些技术债务 技术债务不解决带来危害 * * * * 迭代交付 将一R版本分为多次迭代。 通常情况下，一次迭代的持续时间为2至4周。 对每张故事卡都作估算。 按照客户需求对故事进行排列，并按迭代对故事进行计划。 和团队所有成员召开会议，讨论故事，进行估算，达成一致。 * * * * 敏捷关注架构。 敏捷强调简单设计，只针对确定的需求设计，不为未来可能的变化做过多假设，这不代表不关注架构。敏捷需在前几轮迭代标识出对架构影响重大和最高优先级的5-10%的需求开展架构设计，并在迭代中早期验证架构设计的正确性。在后续迭代强调架构的演进性，不断的重构“坏味道”。同时，很多敏捷实践需要强有力的架构做基础，如CI、TDD。 要强调的是架构属于系统工程，是软件产品的基础。软件开发方法学（敏捷、ＣＭＭ）不可能代替系统工程。 * * 高度重视反馈 尽管管理者一直强调质量的重要性，但在实践中发现我司的开发人员大多数以进度优先，究其原因其实很简单，进度是马上看得到的东西，如果进度延迟，主管给员工的压力马上体现出来，在传统瀑布模型下，质量的反馈需要等待很长的周期，质量不能马上形成压力。 迭代开发的一个明显优势就是快速将真实的质量反馈回来，有助于形成质量优先的氛围和树立没有质量的进度，是虚假的进度的导向，从而保证质量管理建立在真实，可工作的产品的基础上。 快速反馈的另一个明显的优势就是非常有利人员的技能增长，人如果总是在最终失败的体验中是不能成长的，最好成长的过程是经过失败后马上能改进，获得快速成功，（以往的CMM项目即使在项目末进行总结，经验不能马上被利用，这就是迭代促人进步的优势所在），在迭代开发中，一轮迭代发现自己做的不足，没有关系，下一次迭代立刻就有改进的机会，只要你认真对待每一次反馈，充分把每一次反馈当做改进的机会，团队就能在不断开发的过程中成长。 反馈在迭代开发实践中无处不在，可利用的反馈机制： 1. 持续集成结果； 2. 特性片测试结果； 3. 阶段回顾会议； 4. system acut 。。。 因此，是否能充分利用这些反馈机制是区分老开发模式和新开发方法的重要标志。 * * * 目录 敏捷概述 正确理解敏捷 我司敏捷开发实施策略 PSST发文解读 09年敏捷实施指导 我司敏捷案例 Page * 关于敏捷推行的指导意见 华为PSST函（2009）012号 签发人：徐直军 敏捷/迭代开发已经成为业界主流软件开发方法，与瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。为了保证敏捷/迭代开发在我司有组织、有步骤、有策划的开展和推行，现明确要