敏捷培训

敏捷培训敏捷之路敏捷开发流程敏捷带来的挑战EVC敏捷实践案例EVC敏捷实践误区讨论敏捷之路•回顾传统的CMMI流程•为什么我们要采用敏捷模式？在传统的CMMI流程项目中需求变更、人员技能提升、提高客户满意度都面临挑战，CMMI项目强调机械化流程、人员可替代、项目笨拙、周期长、需求变更影响大、无法快速响应客户业务要求，面对这些问题，敏捷模式提供了很好的解决方法。敏捷模式帮我们解决什么问题•最明显的表现是提高了团队的整体效率，包括开发效率、沟通效率；•打通部门墙，开发测试资料融为一体，不再象原来CMM的分开串型介入，开发测试对立，现在我们可以端到端的完成STORY开发交付任务；•按STORY开发，每个人需要了解所有模块的实现方式，打通模块间技能壁垒；•跳出原来CMM的条条框框，团队可以自主调节开发流程。为了高效的目标我们可以原创出有意思的活动，如串串烧。引导团队成员多思考，我们每两周组织大家进行讨论回顾，理清问题制定措施，自主对项目中各种问题进行优化改进；•将庞大的需求功能分成若干个迭代来完成，可以按一定周期频繁交付可工作的软件，也可以适应和迎接需求变更；•测试包含更多内容，包括静态检查、自动化测试用例、手工用例、UT用例，不单保证功能正确性也保证了代码函数的键壮性；•计划不需要做详细的计划，只要求做个简单适当的计划，后期可不断调整改进；•敏捷模式提供了一个自由发挥的舞台。PM可以通过晨会、需求澄清、讨论等等活动对每个成员充分了解。对做得好的以激励，做不好的以鼓励；•引入优秀实践和自动化管理工具使开发提高效率，使原来复杂的工作变成简单而轻松。概而言之，敏捷即根据实际项目量体裁衣，创造性的探索一条可经常性高质量快速交付并适合于我们项目的敏捷开发模式！敏捷开发流程迭代前准备迭代0迭代1SDV迭代NSDV下一迭代团队组建办公场地敏捷培训工具培训持续集成权限申请开发环境STORY输出迭代计划开工会规格评审STORY认领及估计...单个STORY开发流程:STORY澄清会议ALL开发测试资料测试点AT简单设计文档资料编写ST测试细化用例CODEShowCase开始执行测试用例用例加入CI结束集成测试需求评审用例评审串串烧回顾会议验收测试跟下一个迭代并行验收测试敏捷模式给我们带来的挑战•目前存在的问题–开发人员缺少专家，TDD和重构工作很难开展；–缺乏自动化测试用例积累，用例覆盖率低。自动化测试用例生产率不能满足开发进度要求；–测试人员缺乏设计能力，在需求阶段提不出问题，不能跟开发进行对等讨论；–业界的敏捷提倡的是测试驱动开发，目前测试人员还达不到这一水平，而且传统的开发、测试人员的对立面较难消除；–人员自我管理能力缺乏，大部分人还停留在接受任务阶段。缺乏自我工作计划、不能识别工作中的风险、STORY的执行力和推动问题解决的能力不够。•资料开发–资料开发有自己的一套资料开发流程，作为合作项目，如外审、翻译这些流程是需要时间也是必须的。这对资料开发模式就产生了新的要求。–资料测试，敏捷模式带来了密集型的测试,SDV,在只有一周的SDV时间里，开发测试要优先保证整个项目的功能，如何抽出时间来测试资料。（特别是安装指导，在几个迭代的验收测试中每次都有问题单）•验收流程–原来的阶段验收是按CMMI流程来操作的，敏捷项目如何来做验收是一个新的课题，按敏捷思路指引，SRS、CODE阶段验收在STORY开发中按检视来操作，接口人一起来保证质量。–验收测试阶段和下一个迭代开有一段共存阶段，这个阶段要投一部分人力分析、修改问题单和归档。EVC敏捷实践案例敏捷工程实践之一每日晨会敏捷工程实践之二结对开发敏捷工程实践之三持续集成敏捷工程实践之四多次迭代敏捷工程实践之五UserStory敏捷工程实践之六状态墙敏捷工程实践之七串串烧敏捷工程实践之八SHOWCASE敏捷工程实践之九迭代回顾会议敏捷工程实践之十一体化团队敏捷工程实践之一每日晨会•晨会又称站立会议，我们每天早上9点准时进行晨会。会议由项目成员轮流组织。–要求所有成员在会前做准备，围绕状态墙上的STORY反馈昨天做了哪些工作？–STORY的进度如何？质量如何？–今天要做哪些工作？有什么困难？–每个人发言控制在20秒内。所有人发言完后，PM进行简单总结，敏捷教练也会提出指导意见。晨会完后PM将成员提出的困难汇总，并协调解决。•敏捷教练提出PM在发言时尽量不要用命令式的口吻，在项目组内营造平等、和谐氛围,强调大家的自我管理能力。•发言的顺序按STORY划分，先由STORY负责人介绍STORY的整体情况（质量进度困难），再由STORY的开发、测试、资料进行发言。这样大家可以对一个STORY情况完整的了解。敏捷工程实践之二结对开发•结对的对策：–要区分哪些STORY或模块需要结对，哪些不需要，原则是一些比较复杂的STORY我们采取结对。–由于我们新员工较多，所以我们采用以老带新的结对模式。•结对实施:–从STORY分析、方案设计、编码、测试连吃饭也在一起（引导一组人要一起去吃饭），通过这种频繁的交流让新员工能够充分吸收养氛，使他们能够快速成长，让我们团队的家底厚实一些。•结对结果：–通过这种结对方式我们的新员工能够快速成长起来，能独立胜任一些STORY的开发工作。强弱结对在培养新员工方面优势明显，但是在质量和效率方面不及强强结对有优势。•结对目标–通过三、四个迭代让团队所有人都成为团队骨干，有更多人可以进行强强结对，为我们项目质量保驾护航。敏捷工程实践之三持续集成•持续集成是敏捷项目的基础，首先需要一台独立PC服务器做持续集成服务器，然后根据项目情况制定持续集成管理。•我们的策略：–支持自动编译、自动部署、执行自动化测试用例、进行静态检查并及时向相关人反馈编译、静态检查、自动化测试用例的执行结果；–代码和自动化用例要测试OK才能提交到配置库；–建立纪律：设定了CI协调员，如果有问题负责协调相关人及时解决问题；–SMOI模块自动化用例覆盖率要达到90%；业务模块补充主要功能：充值、转帐的自动化测试用例；后台用例要求手工加一部分自动化用例；–关于历史欠债问题：用静态检查会发现大量FINDBUG、PCLINT、复杂度问题。由于交付压力，我们策略是保证新增代码不增加问题数和复杂度。做清理计划，优先解决问题级别高的问题。•持续集成的期望：持续集成能帮我们做ST，提交代码后就可以进行自动化测试，我们只用手工补测几个用例就可以完成测试工作。敏捷工程实践之十一体化团队•团队组建：–我们是一个22人大团队，首先需要对所有成员进行敏捷培训，让大家了解敏捷思想，解答大家疑惑。我们强调以人为本和以沟通为中心、持续改进。–如何组建团队：首先需要得到领导支持，人力是最头痛的事情，我们是新启项目，没有班底，协调人力阻力大。合作方PM人选要有能力、善于沟通、不断改进。每个模块至少保证一名骨干，人员配置是1老带N新的模式。所有新员工必须经过面试（要求有学习能力、思维清晰、稳定）。–办公场地、环境：需要有集中办公的场地、开发环境，这些工作需要领导协调解决。•一体化团队主要体现在STORY开发过程中。开发、测试、资料并行开发，对需求理解一致，共同高效的保证STORY的质量和进度。•三个要：–我们要有一致的目标并且为结果负责；–我们要齐心协力、密切配合、充分沟通和交流，一次做对事情；–我们要利用成员性格和技能互补性构筑团队最强战斗力。敏捷工程实践之四多次迭代•迭代的意义在迎接需求变化，将一个长周期的项目分成若干个迭代开发并进行发布，来满足经常性发布用户可用的版本。•迭代计划制定由SE、PM、项目骨干参加，从需求列表中按有价值、风险、稳定、复杂、紧急进行排序，把排在前面的需求放在当前迭代来做。•认领STORY确定STORY责任人，估计工作量（开发和测试），合理安排计划和人力。•迭代计划时间计划一个迭代周期设定为5周，前4周进行STORY开发，后一周进行SDV测试。在STORY开发阶段，可以将4周分为4个阶段，每周完成一些STORY尽可能减少进度风险。•根据估计的工作量和迭代周期，调整需求列表。敏捷工程实践之五UserStoryStory计划列表显示Story优先级、Story名称、涉及模块，估计，责任人，时间、进度，每天进展；利用这个工具呈现燃尽图，每天看到项目进度情况。Story划分遵循独立、可讨论、有价值、可估计、足够小、可测试的原则。一般根据规格中的AR进行Story划分，这样可以快速划分Story。一个Story会涉及多个模块，可将涉及的模块视为Story的Task。唯一的缺点是有些STORY粒度较大。敏捷工程实践之五UserStoryStory要点Card用来承载客户的需求；开发团队和用户之间澄清细节；记录和传递细节的测试信息，用来确定Story是否开发完成。Story卡敏捷工程实践之五UserStory•在STORY开发流程的基础上保留了SRS这便于以后维护和测试（虽然业界的敏捷是强调测试驱动开发，但是由于技能水平的限制，目前测试仍然依赖SRS写测试用例）。•STORY开发的关键活动1、需求澄清--帮助各角色熟悉STORY要实现哪些功能，各模块的处理；2、需求评审--细化STORY的处理，统一意见；3、测试用例评审—保证测试对功能的覆盖率；4、串串烧--了解相关模块是如何处理对接的，在白板上讨论;5、SHOWCASE--每个STORY完成联调后，做一个SHOWCASE活动，在SE、各角色面前演示;•沟通方式Story强调面对面交流。最高效的方式就是在白板前面交流，可以快速理清问题根因找到解决方案。STORY是由多个模块组成的（人员众多），以往项目模块之间都相对独立，联调了才会一起测试。我们的要求是在开发过程中各模块开发、测试、SE、资料要达到理解一致。这种白板交流模式能很好降低交流成本。效率流行度文档录制的视频录制的音频邮件沟通白板沟通电话沟通敏捷工程实践之六状态墙STORY开发阶段状态墙状态墙关键字：STORY、需求、开发、测试、联调、完成。敏捷管理实践状态墙•SDV阶段状态墙敏捷工程实践之七串串烧•串串烧活动由于EVC采用的是分模块开发，各STORY也是由多个模块构成的,为了使各模块之间接口更加清晰，用一个活动将所有模块串起来,我们称为串串烧.•活动内容–时间:通常活动时间在晚上或下班前半小时–地点:在白板前–人物:STORY的相关人(SE、开发、测试、资料)–组织方式：首先由web模块在白板上讲述界面处理,然后SMOI如何调用,如何触发业务,成功返回什么值,失败返回什么值,返回到界面是什么.后台怎么处理.目的让STORY清晰化,让每个人更加理解STORY并及时提出意见.敏捷工程实践之八SHOWCASE•单个STORY的SHOWCASE–目的：SHOWCASE主要为了保证STORY基本功能正确性，做冒烟测试，参与人对STORY发表意见。–时间点：开发完成功能测试后，转ST测试前。–硬件：专门一套环境，每次SHOWCASE重新加载运行包和数据；为了保证环境干净，装好环境后备份环境和数据库，每次SHOWCASE前覆盖。–SHOWCASE用例由测试提供；由开发人员操作；参与人STORY相关人（SE、开发、测试、资料）；成功则转测试；失败则请相关人喝酸奶。•整个迭代STORY的SHOWCASE–主要对外演示整个迭代的STORY，参与人员为SE、客户、敏捷教练、QA、团队骨干。大家对STORY提出意见，看看是否满足客户要求。–演示人员为开发人员，需要提前准备相关数据使SHOWCASE顺利进行（最好预先跑通所有STORY）。•作用提前展示成果，增强开发人员信心；及时得到客户或SE以及测试的反馈意见；SHOWCASE完成后，测试放心接包测试。敏捷工程实践之九迭代回顾会议•目的帮助项目组发现成绩、发现问题并找到解决方法，并持续改进。•参与人全体团队成员、敏捷教练、QA•实施–会议前团队成员按照四个维度（做得好的、不好的、点子、困难）把写好的贴纸提交给PM，PM提前贴在白板上，大家投票选出每个维度TOP5的问题