敏捷开发的实践

L/O/G/O敏捷开发AgileDevelopment内容敏捷在时代敏捷在华为敏捷与精益敏捷的实践保障何为敏捷标题关键问题•甚么是敏捷？•为什么要敏捷？•如何敏捷？–只有理解敏捷的概念，才能确定是否真正需要它，才能对比目前所面临的问题确定如何去实施它。在敏捷实践以外，我们是否还需要别的方式或者流程来帮助我们进行进一步的改善？敏捷？团队方法论工具•敏捷宣言人和交互重于过程和工具。可以工作的软件重于求全责备的文档。客户合作重于合同谈判。随时应对变化重于循规蹈矩。•核心价值观沟通，简单，反馈，勇气，尊重区别1周期短周期开发，提供及早的、具体的、持续的反馈。增量增量开发。迅速地提出总体计划，并在项目生命周期中不断演化。反应灵活安排功能地实现，以对变化的业务需求作出反应。自动使用由程序员和测试人员编写的自动化测试来监控开发进度，支持系统演化，并尽早发现缺陷。区别2交流通过口头沟通、测试和源代码来交流系统的结构和意图。设计渐进式的设计过程贯穿整个系统生命周期。协作依赖于能力普通但能积极参与的程序员之间的紧密协作。实践各种实践兼顾项目成员的短期直觉和项目的长期利益。解决开发中的风险1-提倡短周期发布，这样任何延迟的范围都是有限的。-一个发布周期内，计划许多小任务以保证团队可以在该周期内解决问题。-提倡优先实现高优先级的功能。-最小发布必须是满足最大商业意义的，选择团队中面向业务的成员来承担。-自动化测试，每次代码改动后运行，确保质量底线。-保证系统处于可部署状态，不允许出现问题的积累。进度延迟项目取消系统恶化-既包含每个函数的单元测试，也包含专门测试人员的功能测试。缺陷率解决开发中的风险2-业务人员成为团队人员，项目规格说明在开发过程中不断改进。-由于缩短了发布周期，因此极大减少变更带来的影响。-拥抱变化，利用重构解决变更带来的技术问题。-坚持只解决最高优先级的任务。业务误解业务变更错误特性太多-团队开发模式，鼓励新成员承担越来越多的责任，互相帮助。-要求程序员自己估算自己的工作时间并完成。人员流动基本实践基本富含信息的空间坐到一起迭代结对编程完整团队增量设计持续集成测试先行编程扩展实践扩展团队连续性真实客户参与单一代码库共享代码增量部署代码和测试敏捷与精益(lean)•甚么是精益？–站在终端用户的角度观察生产线，视任何未生产的增值活动为浪费，并通过持续地消除浪费达到快速交付，高质量和低成本地结果。•丰田精益制造理念的产生？–市场小，客户需求多变。–通过减少浪费节约成本，“最大的浪费就是生产过剩的浪费”精益的思考1•看板？故事墙？–全面了解任务，充满信息的空间。–变PUSH为PULL。•零件只是零件吗？–可以先生产零件吗？会增加甚么费用呢？–还知道些什么呢？•团队负责？–团队来负责最终产品质量。生产线上任一环都需对质量负责。–都不做？价值观，配对，standmeeting。•脆弱的流程？–流程的持续改进需要它是脆弱的。–事务是变化的，需求、团队、目标。–不等于不高效，不顺畅。–流程是可以被测量的。精益的思考2•软件中的浪费？–很快就荒废了的臃肿的需求文档。–从未用过的精心构思的架构。–完成很久都没有在产品环境中集成，测试和执行的代码。–直到无关轻重或是会引起误解时才被人阅读的文档。•举例–拥有更精细的需求获取过程是不会改进需求获取的。–通过缩短需求细节的产生与其相应的软件部署之间的路径是可以改善需求获取的。–这意味着需求获取不是产生一份静态文档的阶段，而是贯穿开发整个过程的。再谈精益•1.以人为中心–强调每个人在生产中的积极参与性和主动性，强调员工之间的协调优化，用激励的手段来激发人的主动性和协作性，最大限度地发挥员工的个人能力和群体智慧。•2.降低库存、消除浪费–将生产中的一切库存视为浪费，出发点是整个生产系统，认为库存掩盖了生产系统中的缺陷。•3.严把质量关–产品质量是创造出来的不是检验出来的，认为“一切生产线外的检查、把关、返修都不能增加附加价值，反倒是增加了成本，是一种无效与浪费”。一次通过率。•4.拉动管理–强调以最终用户的需求为生产起点。组织生产线依靠看板(Kanban)传递需求的信息。用后道工序开始按反工艺流程向前道工序，环环相连，层层连接，把生产紧密地联系起来，生产与市场需求数量一致的产品。敏捷与传统的比较传统思维•是员工的问题•尽量优化各部门的工作•快速交付和高质量意味着多花钱•流程应”强壮“一些，把所有的保险都打开，“小”问题会被吸收•针对个人进行考核•激励并管理员工•谁犯的这个错•了解并做好你的工作•为了更好的预测，做个全面的分析•大而集中能提高效率精益思维•是流程的问题•系统思考，优化整体•快速交付和高质量互为手段目的•流程应”脆弱“一些，任何小问题都可以迫使它终止•针对流程进行考核•清除员工面临的障碍，开发员工•是甚么让错误发生了•我的工作如何配合其它部分•只有频繁的预测才是可依赖的方法•小而灵活才是美CMMI？1流程强壮，保险众多，持续改进成本高，人力浪费严重。2很多文档是浪费的，不能为下阶段的开发提供帮助。好比生产的库存零部件。3没有办法保障的流程是无用的。如华为的电脑准入制度。4流程本身没有问题，但倾向于让人产生惰性，僵化，形式主义。华为困境1需求分解困难，对外可见度低，定制需求多。2偏重于流程，CMM5级。3公司围绕着市场转，市场不以公司的标准为转变。4CMM5，RUP，迭代，XP，SCRUM华为经验1•认同。–自上而下驱动的公司，主管对敏捷的认同是至关重要的。•进度不紧张？–没有进度不紧张的项目，OK，let’s敏捷。•质量和进度冲突？–决策和压力都在主管身上，员工不需要承担市场压力，只负责产品质量。•教练？–教练很重要，参与项目，协调沟通，编程。华为经验2•持续。–在原则上持续坚持，在形式上持续改进。•Codereview–代码复查很重要，通过PAIR实现。•TDD–单元测试很重要，很多员工先写代码再写测试，需要TDD。–当版本升级，以前的单元测试会废掉，TDD不会。•机器–能让机器做的事情就不要让人来做，人只作创造性的工作。做事方式1小粒度，快速反馈，迭代。2简单设计（即使在电信级项目中），复杂问题简单化。3自动化，持续集成，测试自动化。4随机应变，响应变化，自适应计划。做事理念1以人为本，自我驱动，持续改进（个人和组织）。2不能凡事都是主管在想，这不能达到很高的高度。3敏捷是方法论所保障的理念和思想。时代敏捷启动前提-领导支持很重要，我们与华为都是之上而下驱动的公司。-认识是反复的，过程是反复的。-专业的咨询公司是成功的保障。-通过敏捷培训。-通过一周实践的敏捷项目，理解并应用敏捷。领导支持教练熟悉敏捷-需要建立完善的软件工程工作组。-需要在试点项目中尽量建立完善的团队角色。人员调整技能需求1•1持续集成。–精通cruise功能和配置；–熟悉和编写各种脚本语言：xml，JavaScript等；–熟悉和配置各种语言的编译脚本：ANT，Makefile等。•2单元测试。–熟悉C语言，掌握常用的mock框架用法；–熟悉和理解各种软件设计模式，熟悉和理解重构；–掌握TDD编程实践。•3功能测试。–一定的软件开发经验，熟悉软件开发过程；–可以和开发人员进行需求和功能的探讨；–熟悉测试流程和理念。•4自动化工具。–熟练使用各种高级语言编程；–熟悉各种脚本语言编程；–熟悉网络编程。技能需求2•5软件配置管理。–深入理解软件版本管理思想;–精通subversion和clearcase等工具的使用;–可以根据不同的软件开发指定不同的软件管理策略。•6编码规范和代码检查。–熟悉风格和命名：ANSI，K&R，Linux，GNU，Java，Win；–熟悉和理解MisraC－2004规范；–根据不同的软件产品，指定适用于我们的编码规范；–熟悉各种代码检查工具的使用，以及和各种IDE的融合。•7静态和动态检测。–有一定的编程经验，熟悉嵌入式系统编程；–熟悉各种知名静态和动态检测工具；•8敏捷实践。–精确理解和掌握敏捷思想和各种实践，熟悉CMMI；–丰富开发经验，具备项目管理能力以及一定的领导能力；–思维开拓，善于总结经验，发掘新的适用于我公司的实践。组织架构工具组软件工程组敏捷实践测试组单元测试功能测试持续集成自动化工具编码规范和代码检查静态和动态测试软件质量部技术中心软件配置管理L/O/G/OThankYou!