敏捷培训PPT

敏捷团队培训敏捷实施项目’sclientSeptember2017PwC|page2议程敏捷工作机制12敏捷团队角色及职责3敏捷团结架构*名词解释我们在敏捷项目管理中常见的一些名词：PO、SM、TEAM、Sprint、ProductBacklog等1.敏捷工作机制PwC|page5敏捷开发模式*敏捷原则同样适用于产品和项目管理敏捷Scrum使所有关键利益相关者定期合作，提供高品质的工作，提高可见度和适应性专注于应对不断变化的客户需求。与Scrum相比，XP团队的工作时间通常较短不是过程框架，而是通过增量改进来改变的一种模型。结构比Scrum少一个由7个重要原则组成的迭代增量过程，重点在于每个步骤中较长的生命周期和迭代精益消除非增值活动，增加客户价值。FDD是一个模型驱动的短迭代过程ExtremeProgramming(XP)KanbanAgileUnifiedProcess(AUP)Lean,FDD,DSDM,etc.Scrum极限编程(XP)Kanban敏捷统一流程(AUP)精益,FDD,TDD,etc大型组织实施不同框架（或者不同框架的不同部分）的组合，以实现企业级别的敏捷敏捷是一种有时间约束的、迭代的开发软件的方法。它可以在业务优先级确定之后的短时间内提供潜在的可交付的工作代码，同时提供处理不确定性并适应不断变化的需求的能力。它是从项目开始逐步构建软件，而不是在交付期将至时尝试一次性交付。PwC|page6Scrum工作机制PwC|page7每个Sprint的活动12345678910Sprint计划会议SprintDemoSprint回顾会议每日站会Backlog梳理会议PwC|page8Sprint会议安排事件迭代计划会需求梳理会每日站立会迭代评审会迭代回顾会迭代协同会频率每个迭代1次每个迭代1-2次每天1次每个迭代1次每个迭代1次每周一次时间120分钟90分钟15分钟60分钟60分钟30分钟主要议程•确定在即将到来的冲刺中可以交付哪些用户故事•创建冲刺待办事项（从产品待办事项中来的用户故事）•将用户故事分解成任务（“如何”），并包括时间预估和人员分配•完整的用户故事（使之达到“准备好”的状态）•昨天我做了什么帮助团队达到冲刺目标？•我今天要做什么帮助团队达到冲刺目标？•有哪些阻碍我达到目标的障碍？•向产品负责人展示“完成的”工作•请产品负责人提供审阅意见（同意或拒绝）•评估整个冲刺过程的人员，关系，流程和工具方面的进展情况•提出问题和改进建议•我们团队对外部团队有什么样的依赖关系？•我们团队对哪些团队有具体什么样的期待？•我们团队有哪些问题和风险也会存在其他团队中？参与者敏捷教练产品负责人开发团队技术架构师传统项目敏捷联系人图例必须参与选择性参与不必参与PwC|page9每日工作围绕用户故事展开什么是用户故事•描述高级的功能•代表一小部分终端用户功能•是合作书写的结果•是对未来的承诺，是“更为详细的”语言•包含书面文字、口头叙述、图片等•包含了用户故事的验收标准的边界例子:叙述：作为一个…手机银行的用户我想要…查看我的账户信息所以…我可以了解我的账户活动情况验收标准:给定……我已经登录系统当……我选择在我的手机银行账户查看账户信息时然后……我能根据所选择的账户（账户名称、投资理财方案、外汇购买等）查看账户细节PwC|page10故事大小——运用分数进行估计•选择一个中等故事，给出5分•评估与此相关的其他故事：与此相关的其他故事-一半大-两倍大-大一点•使用下面范围的值阶段用户故事–几个Sprint之后用户故事,接近Sprint0.512358132040100∞PwC|page11估分流程Thislooponlytakes15minutesThislooponlytakes35minutesPwC|page12我们怎么追踪进度？——看板为什么使用看板？•看板促进流动的概念，以持续为客户/最终用户提供价值•通过可视化工作流程，我们可以为每个人都看到任务，活动和瓶颈•正在进行中的工作（WIP）确保我们专注于提高质量，增加对任务的关注，并确保我们停止启动并开始整理主要原则：•可视化工作•限制正在进行的工作（WIP）•管理流程•明确制定流程政策•实施反馈回路•协同改进，实验演变看板是一个“拉拽”的系统，通过优化“系统”中的工作流程，提供重点，可持续发展和频繁交付2.敏捷团队角色及职责PwC|page14敏捷团队角色角色职责产出产品负责人设定产品愿景和业务重点确保工作优先级在backlog中体现参与需求预估引出并充分记录功能和非功能性需求代表开发团队和业务交流，代表业务和开发团队交流促进团队的协作产品backlog产品级别的需求和优先级用户故事grooming需求文档和SME(SubjectMatterExperts)互动用户故事验收标准ScrumMaster促进团队互动消除障碍开展会议保护团队不受干扰，并消除团队进步的障碍推动团队不断改进开发参与需求预估帮助需出要求并定义最佳设计提供业务的功能和非功能性要求，同时遵守编码标准开发单元测试和重构代码软件开发，代码交付对需求提出开发层面的专业建议，并对未来的设计架构提出建议测试帮助定义需求并协助估算定义测试用例，脚本和步骤，以完全测试根据需求交付的软件定义和准备测试数据，进行手动和自动测试与团队沟通，提供诚实的反馈项目交付质量保证记录缺陷测试用例和测试数据方案架构师在业务和IT领域之间的沟通，以支持架构师和指导技术协助规划和估计活动确保应用程序/技术与路线图一致确保应用程序套件内的开发流程负责在开发过程中保持对质量控制的纪律负责确保NFR测试技术负责人协调敏捷团队内部和整个敏捷团队的开发人员和测试人员向团队提供技术专长协调环境，代码升级和环境刷新技术负责人应该是开发组长开发与测试协调保护开发团队不受干扰审查代码以确保符合解决方案架构师的标准PwC|page15敏捷团队角色角色职责产出敏捷实践领导提供企业框架指导，以支持整个企业的敏捷实践担任顾问，培训师和顾问，以帮助敏捷团队保持一致，不断改进整个企业的敏捷实践帮助敏捷教练，敏捷团队和支持团队采用企业敏捷框架作为敏捷教练团队的导师敏捷教练提供有关敏捷实践，敏捷角色和责任的指导提供企业框架指导，以支持敏捷的采用担任培训师和顾问，帮助团队采用和改进敏捷实践帮助团队采用和改进敏捷实践PwC|page16ScrumMaster敏捷团队角色及职责促进团队互动（团队，产品负责人和利益相关者）消除障碍主导会议代表团队对交付日期和预算的承诺促进敏捷价值观，原则和最佳做法不是决策者，不分配任务仆人领袖PwC|page17产品负责人（ProductOwner）敏捷团队角色及职责有时被称为“客户的唯一声音”设定产品愿景和业务优先级确保业务和客户优先级在积压内得到反映代表项目利益相关方;迅速作出或获得决定代表（或是）客户推广产品愿景和目标确定要构建的内容和顺序确保价值交付和投资回报率18角色与职责–Team(团队)•以迭代的方式，增量地交付可工作的软件，保证交付的质量•积极响应来自PO的高优先级业务和变化•协助PO维护产品特性清单，细化需求和验收测试场景•进行工作量的估算•基于最新的产品特性清单和优先级，考虑团队实际产能，合理得做出迭代交付承诺•在迭代中进行自我管理，全力以赴地完成承诺的内容，达到DoD标准•在迭代结束，将完成的成果向PO进行演示，获得反馈•自我回顾，提高技能，积极寻求更有效的交付实践，持续提高团队产能•遵守和维护团队纪律PwC|page19产品负责人（ProductOwner）敏捷团队角色及职责产品负责人通常是系统的主要用户，或者是对用户、业务以及当前开发的系统或系统类型的未来趋势有深入了解的任何人。职责产品负责人开发团队最大化投资回报率√×明确工作边界以满足业务的优先级√×定义早期版本-如MVP√×与stakeholders沟通√×根据功能/可交付水平对backlog定义优先级√×决定“候选的用户故事”的工作×√*收集/理解非功能性工作×√将阶段/用户故事切片为可开发的大小×√准备好用户故事到可以开发的程度×√在开发过程中与团队合作×√验证/接受团队完成的工作×√*参与计划会议×√参与每日站会×√参与迭代回顾会√√√*有授权PwC|page20开发团队敏捷团队角色及职责拥抱“全部成功或者全部失败”每个加入团队的成员都有一个角色（开发、测试、架构等），所有人）3.敏捷团队架构PwC|page22敏捷团队构建为了扩展和拥有多个团队，我们应该考虑关于构建团队和开发用户故事的指导原则产品代办列表敏捷交付团队A(9)(专用)ScrumMaster(1)分析(1)开发(3)测试(2)产品负责人(1)方案架构师*敏捷交付团队B(8)(专用)ScrumMaster(1)分析(1)开发(2)测试(2)产品负责人(1)方案架构师*敏捷交付团队C(7)(专用)ScrumMaster(1)分析(1)开发(3)测试(1)产品负责人(1)敏捷交付团队D(9)(专用)ScrumMaster(1)分析(1)开发(3)测试(2)产品负责人(1)方案架构师*迭代代办列表速度:X速度:Y速度:Z速度:K迭代代办列表迭代代办列表迭代代办列表PwC|page23基于特征的团队优势优势描述增加价值吞吐量专注于提供客户或市场价值最多的产品增加学习个人和团队学习由于更广泛的责任而增加，并且由于与各方面专家的同事共处-对长期改进和加速至关重要;减少未充分利用的人的浪费简化规划通过向团队提供一个全面的功能，组织和规划变得更加容易-例如，不再需要在单一专业功能和组件团队之间进行协调减少切换浪费由于整个功能团队全部工作（分析，设计，代码，测试），切换显着减少少等待更快的周期时间-减少了等待的浪费，因为切换被消除，并且因为完成客户功能不必等待多方，每个人都在连续地进行部分工作自我管理；提高成本和效率Scrum团队不需要项目经理或矩阵管理功能交付，因为协调是微不足道的。团队负责端到端的完成，并与他人协调工作。数据显示管理人员与发展生产力之间存在负相关关系，而且内部和外部焦点的团队更有可能成功更好的代码/设计质量在共享组件上工作的多个功能团队产生压力，以保持代码清洁，格式化为标准，不断重构，并被许多单元测试包围，否则将无法使用。另一方面，由于熟悉程度很长，组件团队只能使用混淆代码才能理解更好的动机研究表明，如果一个团队觉得他们对一个工作项目有完整的端到端的责任，而当目标是以客户为导向的话，那么有更高的动机和工作满意度是生产率和成功的重要因素。简单的界面和模块协调一个人或团队更新接口的两侧（主叫和被叫），并更新所有模块中的代码;因为功能团队在所有组件上工作;不需要团队间协调。变化更容易要求或设计的变化（我们知道这是罕见的，但我们听到它发生在某个地方一次）被一个团队吸收;不需要多团队重新协调和重新规划。Source:ScalingLeanandAgileDevelopmentPwC|page24基于架构的敏捷团队角色变化瀑布项目经理业务负责人商业分析师开发测试重视项目管理的指标和期限对不确定性感到不舒服，而且依赖于文档前期定义了所有范围在发布周期结束时看到成品为开发团队提供SME是很有限的不怎么与开发人员合作专注于写作要求，同时外推尽可能多的细节过多思考组件和模块方面的开发把代码放在墙上进行测试偶尔有'停机'独立于开发人员进行测试对一周的代码执行测试以有限的测试自动化手段进行手动测试敏捷ScrumMaster产品负责人商业分析师开发测试非常支持团队提高生产力的需求消除障碍并解决风险确保开发团队坚持敏捷原则和做法提供了一个恒定的反馈路径，以确保技术解决方案与商业价值