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