您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 项目/工程管理 > 精益-敏捷软件开发方法
精益-敏捷的应用研发部王凌宇适应人群•软件研发项目的项目经理,需求分析师,开发工程师,测试工程师等•软件研发项目的相关干系人•企业中层管理者假设与约束•对敏捷有一定的了解,有一定的敏捷SCRUM实践经验•对软件工程有一定了解•对项目管理有初步了解课程期望•了解精益的相关知识•了解SCRUM#的相关定义•了解敏捷实践中管理层的作用•促进敏捷实践的持续改进目录精益简介超越SCRUM精益-敏捷中的管理精益简介精益思想的基本原则多数错误源于系统本身,因此必须对开发的系统加以改进为了改进系统,必须尊重员工过早开始会造成浪费。只在需要的时候完成需要做的事情,这就是JIT(justintime)精益软件开发--为软件提供的原则尊重人消除浪费推迟决策创建知识品质为先快速交付全局优化精益宣言快速—灵活—机动开发过程是一条繁忙的生产流水线,凡是慢下来的流水线都会导致浪费。通过消除软件中的延误、错误、误解和等待资源等障碍,来改进过程。超越SCRUMSCRUM框架讨论关于SCRUM的认识?对SCRUM的认识观点敏捷项目开展首次工作时没有做计划。SCRUM中没有文档。SCRUM中没有架构。敏捷开发QuickStartWHYWHATWHENHOW团队环境项目团队要做哪些事?多久能做完?项目立项怎么做?WHEREWHOQuickStart对SCRUM的观念认识SCRUM的成功在很大程度上是因为由项目成员来定义如何做项目。团队要远离管理层。产品是由产品开发人员靠拍脑袋想出来的。团队应该由通才组成。检查和修改是足够的。讨论参考导致系统障碍的因素被消除。其他方法也可以实现。管理层不是障碍而是资源,是项目改进过程中的合作伙伴。产品负责人应该只是项目任务优先次序的责任人,而优质产品的开发是由整个团队负责。精益用“产品牵头人”代替“产品负责人。”产品牵头人和团队共同为产品的质量负责。更好的模型是PDCA模型。团队真正需要的是,能够以很短的时间组织起所需要的技能去完成工作,可共享的知识越多越好。对SCRUM的局限性讨论自组织团队能够超越其他团队改进软件开发的流程。每次迭代都需要向客户提供价值。切勿超越目前的迭代计划。可以使用SCRUM-OF-SCRUMS协调不同产品团队间的工作关系。可以在无须自动验收测试或单元测试前置的前提下使用SCRUM。讨论参考SCRUM团队应该被自组织,而不应该自我导向。迭代并不需要总是为客户利益服务。不要构建过度需求,要保持全局观。只关注当前的需要,不同开发速度的团队之间相互依存,需要做出计划,以确保团队工作能够得到很好地协调。杰夫.萨瑟兰在创建SCRUM时,包括这两项实践,为了使人容易掌握,被删除了。如果团队具有不同的目标、动机或驱动指标,那么就不会起作用。SCRUM与精益的观点比较主题SCRUM观点精益观点迭代结构使用时间盒迭代,发现和构建相关的小型迭代利用迭代结构类型产品方向产品负责人全权负责团队向产品负责,产品牵头人设置优先次序,并与团队一起去发现和构建需求管理倾向于将团队与管理层隔离开来管理者引领和教导团队,管理层与团队协同合作如何组织让团队工作,通过SCRUM-OF-SCRUMS协调团队工作创建适合所有工作的环境,如价值流。团队要学会如何在这些环境下工作。如何学习检查工作结果,接着去适应改善的环境应用PDCA原理需求的优先级重视客户价值重视客户和企业的价值,同时关注延误带来的成本开始的地方让团队自己去解决自己的事务在团队具备了解决问题的能力后,再将工作任务交给团队处理,重要的是对我们所做的工作尽可能地了解。SCRUM#注入了精益思想的SCRUM--艾伦.沙洛维SCRUM#的4个基本实践实践描述及时构建,使用集群所有需要的成员汇集在一起,在同一时间工作在同一需求上,最大可能缩短完成该素材的总体时间。精益方法重视项目总体周期时间而非个人生产力。定义验收测试优先于编写代码增强了客户、分析人员、测试人员之间的交流,有助于测试人员与开发人员保持同步。如果开发人员不能在测试人员制定测试方法之前编写代码,那么就需要开发人员在后期帮助测试人员,防止测试过程落后于进度迭代结束时,所有已经启动的故事点都要完成避免启动新的需求开发。询问好的、可靠的问题激发了团队成员去思考关于他们正在做的问题,并且有助于他们学会识别正在做的工作与期望完成的任务之间的差别看板软件工程根植于精益思想的软件开发方法看板模型的概念基础团队工作在适当数量的功能上直至完成开发。对功能的选择和开发的过程进行妥善管理。团队重视开发尽可能少的且可增强客户价值的功能。开发流水线上存在少量排队队列和小批量的任务,这样会使开发工作更有效。团队须获得快速反馈以保证他们在正确的工作轨道上。看板与常用的敏捷方法的不同软件开发团队中排队的队列很少。软件开发团队的重点是尽快完成功能开发,但没有时间盒制约。从形成概念到产出消费品,在整个价值流的过程中,看板让人一目了然,理想的情况是,由客户启动价值流,产品经理与团队紧密合作,利用看板在过程中对在制品的数量加以限制。直接运用看板,无需加以任何估算。看板的真正价值要求团队创建一个定义明确的规则和有限制的工作流程几种敏捷方法的对比要素SCRUMSCRUM#看板精益思想保持团队成员原封不动要求------使用时间盒是是否--为整个团队排列需求的优先级是是否--发布已完成工作的时间选定迭代的末尾选定迭代的末尾任何时候均可,取决于团队的判断--需要在一个管理层支持的背景下工作否否是是团队成员在同一地点办公没有说明使用快速-灵活-机动的原则去构建优化的工作流以适当的在制品限制去管理使用快速-灵活-机动的原则去构建优化的工作流支持产品管理组织否是部分支持是代码质量没有讨论利用工作流程提升代码质量利用工作流程提升代码质量利用工作流程提升代码质量精益-敏捷中的管理管理是把事情做对;而领导是做对的事情彼得.德鲁克你必须管理系统,因为系统本身不能对自己进行管理W.爱德华兹.戴明精益-敏捷管理重视价值流的管理和对人员的领导职责:设定结果或团队预计要达成的目标。协助工作人员改进过程并安排工作区,以方便团队完成工作。管理者最重要的任务就是帮助团队避免浪费。精益敏捷管理方法对实现目标的方法和工作授权,但仍需团队成员对结果负责。运用多种方法和工具将团队面临的挑战可视化。在组织内部构建知识,通过交叉培训项目成员来节约项目时间。找到问题的根本原因,以确保工具能够增加价值。精益敏捷的可视化控件产品愿景产品需求列表/发布计划/精益组合管理迭代列表—单一团队、多个团队故事点的单迭代燃烧图故事点的多迭代燃烧图精益-敏捷的转型战略是一个自上而下的领导过程和自下而上的实施过程多个SCRUM团队的协作场景整个团队的进度需要多个团队来实现需求团队之间的技术依赖多个团队使用通用组件需要一个团队修改代码去协助另一团队的工作团队间代码共享一个团队拥有另一个团队所需的知识产品协调小组站在更高的角度—“全局优化”来自不同团队中的成员组成为了共同的目标产品协调小组成员构成固定成员计划成员轮值成员精益敏捷的深刻见解一次只关注一个项目启动较少的项目缩短批处理时间探寻缺陷产生的根本原因知道你在哪里:最小化可发布的功能优先事项和工作进程生产力及质量跨职能团队谢谢!研发部王凌宇
本文标题:精益-敏捷软件开发方法
链接地址:https://www.777doc.com/doc-4001670 .html