敏捷过程参考课件

IBM 2013.05.05太平洋保险敏捷软件交付过程参考内容目录1.角色与职责2.迭代活动与实践3.需求定义与管理4.敏捷管理工具-JIRA5.跨团队协调角色与职责章节014角色与职责 Product Owner(产品经理)对产品进行规划和业务设计对软件交付的需求负责，保证需求定义的准确性，变化的及时性和相对的稳定性管理团队的所有需求和变更，向团队解释需求细节，是交付团队所获需求的唯一来源；团队除了PO不于其它业务人员沟通，除非是其全权授权决定所有需求，缺陷的优先级尽可能多得与交付团队交流，一起工作，亲自参与迭代交付中的关键活动，包括计划，测试场景评审，故事梳理，成果演示，和迭代回顾在迭代边界根据业务需要对需求内容和优先级进行修改、调整，以此引导团队交付的方向在迭代中不轻易改变需求，给于团队足够的自主性5角色与职责 Scrum Master(团队交付经理)对软件交付的流程和团队产能负责领导团队，管理流程，组织团队活动有序高效进行建立和维持团队与PO之间的沟通渠道，促进沟通的及时，准确，完整记录，跟踪，协助解决团队遇到的障碍对团队交付进行风险管理，识别风险，采取风险应对措施引导团队进行回顾，在流程、实践、工具等方面持续改进，提高团队产能保护团队，对外拒绝会导致团队交付失败的任务和变化记录和汇报违反团队纪律的行为6角色与职责 Team(团队)以迭代的方式，增量地交付可工作的软件，保证交付的质量积极响应来自PO的高优先级业务和变化协助PO维护产品特性清单，细化需求和验收测试场景进行工作量的估算基于最新的产品特性清单和优先级，考虑团队实际产能，合理得做出迭代交付承诺在迭代中进行自我管理，全力以赴地完成承诺的内容，达到 DoD 标准在迭代结束，将完成的成果向PO进行演示，获得反馈自我回顾，提高技能，积极寻求更有效的交付实践，持续提高团队产能遵守和维护团队纪律迭代与实践章节028迭代活动与实践开始开始时点点活活动参与者参与者平均平均时长迭代开始迭代计划会议PO,SM,Team2-4小时迭代计划会议后测试场景分析Tester,BA2-3小时迭代计划会议后代码，UT分析，设计交流Developer2-3小时测试场景分析后测试场景评审PO,Team即时测试场景评审后开发代码，UTDeveloper5天测试场景评审后编写测试用例，支持自动化测试脚本开发Tester5天每天上午每日站会SM,Team15分钟开发完成后代码评审Developer即时代码评审通过后内部演示（开发向BA和测试演示）Team即时内部演示通过后构建部署到集成测试环境CM，Developer即时部署到测试环境后执行功能，集成测试，可能的性能测试；修改缺陷Tester,Developer3天迭代第二周故事梳理，故事点数评估PO,SM,Team2-4小时迭代最后一天上午成果演示（团队向PO演示）PO,SM,Team2小时迭代结束迭代回顾会议（回顾，改进计划，总结技术债务，生产事故RCA）PO,SM,Team2-3小时9迭代活动与实践 迭代计划会议参与者：PO，SM（主持），Team时间点：迭代开始议程：1.展示产品特性清单上最高优先级的故事和缺陷，以及技术债务2.可能PO对某些故事进行修改，对故事和缺陷的优先级进行调整3.团队明确自己的能力（考虑产能历史数据，人员变动，兼职，假期，生产支持，技术债务偿还等）4.按优先级从高到低，进行工作量分析，选择可以承诺交付的内容，形成迭代目标（更新JIRA，故事上白板）5.对承诺交付的内容进行任务分解，和工作量评估，构成迭代计划（任务上白板）10迭代活动与实践 验收测试驱动开发（ATDD）参与者：Tester(主导）,BA,PO，Developer时间点：迭代计划会议后议程：1.测试人员在BA的协助下，对迭代计划中自己负责的故事进行分析，列出所有需要验证的测试场景，每个场景就一句话，更新到JIRA故事2.同时，开发人员对故事涉及的代码，单元测试进行阅读分析，与架构师或技术领导交流开发方案3.测试人员，BA，开发人员与PO一起，对列出的测试场景进行评审，修改，直到达成一致；并明确每个场景对单元测试（二期引入TDD后），自动化测试脚本，和手动验证的需要4.测试人员基于测试场景列表编写测试用例，协助开发自动化测试脚本5.同时，开发人员基于测试场景列表开发单元测试（TDD后）与代码11迭代活动与实践 每日站会参与者：SM（主持），Team时间点：每天上午固定时间，固定地点，15分钟议程：每个人依次回答三个问题：昨天我做了或完成了什么任务？今天我计划做什么任务？我当前的任务中有没有遇到障碍导致无法进展或进展缓慢？在回答三个问题时，手指向任务白板上自己谈到的任务卡片，挪动其状态，并更新卡片上的剩余小时数（Remaining Hours）SM记录所有遇到的障碍（此时不讨论）12迭代活动与实践 故事梳理参与者：PO，SM（主持），Team，架构师时间点：每个迭代的第二个星期选择合适的时间议程：1.展示产品特性清单上未计划的最高优先级的故事和缺陷2.所有参与者共同对最高优先级的几个故事和缺陷进行阅读和分析，对需求上的疑问，技术上的疑问进行提问；PO，架构师，及其它团队成员对问题进行分析和解答3.在会上无法解答的问题，SM记录，确保会后找相关人员进行解答4.此过程中可能对故事和缺陷，及其优先级进行修改，更新到JIRA5.分析故事原先的点数（工作量）是否仍合理；若团队认为不合理，进行故事点数的重估13迭代活动与实践 估算故事点数参与者：PO，SM（主持），Team，架构师时间点：新的故事创建时，或迭代故事梳理时议程：1.PO阅读故事，向团队解释故事的细节和期望；团队成员思考分析故事，对需求疑问向PO提问，对技术疑问向架构师和其它成员提问；PO，架构师，及其它团队成员对疑问进行分析和解答2.每个人给出故事点数（Poker）3.给出点数最高和最低的解释理由（与基准故事比较）；团队发现问题，再次提问和讨论，解答；每个人都有发言权；耐心倾听和思考4.重复第3步，直到达成一致遵循以下原则：a.一个故事不超过3轮；b.取大不取小；c.无法达成一致，创建Spike任务14迭代活动与实践 成果演示参与者：PO，SM（主持），Team时间点：迭代最后一天的上午议程：1.团队由一代表向PO依次演示每一个完成的故事和主要缺陷可工作的成果2.对每一个演示的故事和主要缺陷，PO表示接受（符合预期和验收条件）或拒绝（不符合预期或不满足主要验收条件），给于团队反馈或意见3.SM记录接受或拒绝的结果，记录反馈意见，并更新JIRA故事4.根据PO的反馈处理故事：演示故障、重要缺陷，必须解决，否则此故事失败；不重要缺陷，若PO可接受，记录缺陷到清单；否则必须解决；改进建议（原故事验收条件不覆盖的），记录新故事到清单；部分完成且完成部分独立可拆分，若PO接受，可考虑分拆故事。15迭代活动与实践 迭代回顾会议参与者：PO，SM（主持），Team时间点：迭代结束议程：1.总结迭代成果：庆祝成功交付的；对于计划了但未达到DoD的，找出原因，总结经验；2.团队回顾哪些实践做得好，哪些做得不好，可参考此文档检查；也包括各项活动进行的有效性，工具的使用，个人的能力等各个方面3.找到一到两条（多了没意义）能够在下个迭代立刻有所改进的行动；下个迭代监督这一两条改进行动的落实执行4.总结该迭代解决了和新产生的技术债务，分析影响，记录到JIRA5.对上个迭代后发布的新版本出现的生产缺陷进行根源分析(Root Cause Analysis)，记录分析结果到JIRA16迭代活动与实践 Definition of DoneDefinition of Done（DoD）定义了Scrum流程的一个重要原则：一个迭代计划中承诺的故事，在该迭代里一定要完成。一个故事被标志为“完成（Done）”隐含着该故事已经满足了以下条件：1.完成了单元测试（引入TDD之后），功能测试，系统集成测试，性能测试，甚至用户验收测试等必要的测试（性能和UAT目前太保做不到，将来的方向）2.没有严重的，影响功能和业务逻辑的缺陷（level 4-5)3.没有不严重，但未得到PO和团队接受的缺陷（level 1-3）4.给PO做了演示，并得到PO接受需求定义与管理章节0318需求定义与管理 产品特性清单产品特性清单是一个由所有交付团队还没有实现的需求和未解决的问题构成的列表。用JIRA来维护产品特性清单一个清单通常主要包括：Epic（史诗）User Story（用户故事）-一个需求点Defect（缺陷）Technical Debt（技术债务）19需求定义与管理 用户故事用户故事代表一个具体的需求点，由三部分构成：卡片（摘要）的格式：“作为一个，我想要，这样我就能”卡片（或摘要）卡片（或摘要）会话会话验收条件验收条件一句话的摘要在迭代中写在一张卡片上，以方便阅读，记忆和跟踪一个故事大多数的细节由团队与PO的直接沟通来获得，重要的信息可记录下来用于验收一个故事是否完成的所有重要的场景和条件20需求定义与管理 需求管理团队的所有需求都来自于PO团队的BA协助PO将概要的需求以规范的形式定义为用户故事和验收条件，并且拆分到恰当的粒度；尽可能将所有需求的细节都明确，记录重要的信息。团队协助PO创建的故事都要得到PO的评审和认可。BA的故事分析，定义，拆分工作不纳入迭代，而是超前进行；但要保证当一个故事即将被实现之前，已经得到的清楚的定义。所有的故事都要有优先级，只有PO有权利设置和修改优先级；同时PO设置优先级也参考团队的意见一个好的用户故事应满足以下条件：相对独立；清晰；有价值；工作量可估算；大小合适；可测试一个故事一旦已经被团队计划到迭代中实现，对其提出的变化只要未覆盖在验收条件中，都作为新故事进入特性清单（除非是及其微小的调整）21需求定义与管理 故事周期故事周期是指一个需求（故事）从提出直到发布上生产环境所经历的周期。敏捷过程改进的目标之一是逐步的缩短该周期，达到对业务变化的快速响应，同时建立和维持一个可持续的IT交付能力。考虑当前2周一次的迭代周期与太保一个月两次的发布窗口无法完全重合：正常情况下（除了紧急故事），一个新需求的周期将会是 15 到 28+N 天。故事等待故事等待 0-N天天Next Iteration紧急故事（置换）故事定义，分拆。N 取决于优先级迭代结束（按周日）到下一个发布窗口的间隙，完成：紧急的缺陷修改可能的跨团队联调测试可能的性能，安全性测试预生产发布，验证2周周(14天天)迭代交付迭代交付发发布准布准备备 1-14天天故事提出敏捷管理工具-JIRA章节0423Greenhopper插件-支持敏捷管理的特性JIRA系统当安装上Greenhopper插件后，提供了主要以下几方面对敏捷开发的支持：提供对 Scrum 和 Kanban 流程的支持，提供不同的模板方便地的创建和管理Product Backlog，包括用户故事，缺陷，技术债务等类型的工作项，并对不同的工作项可以灵活定制其信息字段和流程以拖曳的方式，最直观得进行工作项优先级的调整方便地建立Sprint计划，并提供直观形象的看板展示Sprint中每个工作项的进展状态支持对用户故事进行故事点数的评估，对任务进行基于小时的估算能自动生成敏捷开发常用的图表，比如燃尽图，燃起图，产能图等24Scrum 模板下的 Product Backlog 和 Sprint Greenhopper 能够创建很直观的Product Backlog和Sprint，并且通过上下拖曳的方式轻松调整优先级：25Kanban 模板下的团队看板Greenhopper 能够也支持Kanban流程，提供直观的团队进度看板，并统计每个阶段的WIP（Work In Progress）数量：26工作项类型A2 项目对JIRA原有工作项类型进行了调整，更好地支持敏捷敏捷开发的需要。目前我们需要用到的工作项类型包括：Epic（史诗）Story（用户故事）Technical Story（技术性故事）Defect（缺陷）Technical Debt（技术债务）Block（障碍）27故事的流程史诗和故事是敏捷开发中最需求的定义和管理方式。Epic（史（史诗），通常是一个较笼统的业务需求，直接来自于用户或业务部门。在JIRA工具中，我们需要对其进行拆分；但同时此原始的需求也予以保留，以便于团队对业务的起源进行追溯，也能更好得对拆分出的更小的需求进行组织和归类。Story（用（用户故事）故事），是敏捷开发中定义需求的基本形式，对故事的要求参考“需求定义和管理”部分。每个故事从提出到最终交付在JIRA中要经过以下流程：Technical Story（技（技术性故事）性故事），这是一种常用的变通方法，将一些从架构的角度提出的纯技术性工作也以故事的形式进行定义，比如数据库变更，测试环境搭建，公共组件的开发等。这样团队就可以像用户故事一样对这些工作进行故事点数的评估，进行迭代计划，并将成果计入团队的产能。技术性故事遵循和用户故事一样的流程。新建已定义进展中待测试待演示 已完成已部署28故事的关键字段支持敏捷开发的Scrum流程和ATDD流程，在JIRA中的故事有一些关键字段是必不可少的：Summary（故事卡）（故事卡），即以标准的“作为,想要”的形式对故事进行的摘要Story Point（故事点数）（故事点数），对故事工作量大小的评估Acceptance（验收条件）收条件），由PO或BA从业务的角度描述的此功能的验收条件，在故事进入迭代计划之前该验收条件必须要明确清晰Technical Solution（技（技术方案）方案），开发该故事的功能相关的概要设计，技术方案，在故事进入迭代计划之前该方案必须要明确，通常由架构师或技术领导负责Test Scenario（测试场景）景），在迭代计划之后，实际开发工作开始之前，测试人员要详细列出最后验收测试该故事需要的所有测试场景，尽可能细！并和BA，开发甚至PO一起评审，达成一致29缺陷的流程对于缺陷，从Scrum的角度，原则上是所有测试中发现的缺陷在当前迭代内应该修复，使得每个承诺的故事在迭代结束能够达到 Definition of Done 的要求。但有三种情况缺陷会遗留下来：1.测试中报告的缺陷或遗留，分析之后发现其并未覆盖在故事的验收条件中。这样的问题应该新建一个故事，而不是缺陷，对需要的修改进行描述；2.确实是缺陷，但是PO和团队都认可该问题不重要，可以待以后处理；3.最后，有些缺陷涉及的改动较大，团队确实无法在迭代结束之前修复。对于后两种情况，在迭代结束没有修复的缺陷，必须要记录到JIRA中！将来和其它的故事一起，基于优先级进行计划和实施。计入JIRA的缺陷遵循以下流程（其中已解决和验证的缺陷有可能被重新打开）：新建打开已分析进展中已解决待验证已验证已部署30Version 版本（发布窗口）关联JIRA中可以定义每一个版本（Release，或发布窗口）及其发布日期，并且将团队Backlog 中的故事，缺陷，及技术债务都关联到某一个版本。这样项目经理或团队都可以方便得查看和导出每一次发布所交付的内容清单，而不再需要基于邮件和Excel的汇总。跨团队协调章节0532跨团队协调 Scrum of Scrums参与者：PM组(主持),架构组负责人，测试组负责人，每个Scrum团队的代表时间点：一周两次，每周二（上午）和周四（下午）职责：1.听取每个团队的进度，和下一阶段计划2.了解每个Scrum团队遇到的障碍，PM组对所有汇报上来的问题负责，记录，跟踪，并协助解决1.若是需求障碍，PM组下来联系业务部门（PO组）协调解决；2.若是技术障碍，PM组和架构组负责解决；3.若是测试障碍，PM组和测试组负责解决；3.讨论其他问题，如发布准备等4.周二和周四可以有不同的关注点，每个迭代开始的周二更关注新迭代的计划（给业务的承诺），周四则更关注开发测试工作的进展和困难33跨团队协调 PO组负责人：首席PO构成：各个Scrum团队的PO职责：制定整个大项目级别整体的业务和产品规划，从业务角度最大化项目的投资回报率保证跨团队需求的一致性，交付团队不会从不同的PO得到对需求的不同解释，做到 One Voice权衡多个产品子模块之间的优先级组织敏捷交付中PO技能的培训，分享等解决 Scrum of Scrums 中发现的团队遇到的需求相关的障碍34跨团队协调 架构组负责人：首席架构师构成：架构师，CM，DBA等为多个团队进行技术指导和服务的人员职责：负责制定技术方向，开发系统架构，进行技术决策负责重要的概要设计，数据库设计等负责项目依赖的基础设施的管理，配置（与相关部门协调）组织敏捷开发技能的培训，分享等负责维护和配置JIRA，和Jenkins，Sonar等敏捷管理，持续集成环境（第二阶段）参加Scrum of Scrums，帮助解决Scrum团队遇到的技术障碍35跨团队协调 测试组负责人：测试经理构成：测试经理助理，各个Scrum团队的核心测试人员职责：负责制定测试策略，测试计划，建立维护测试标准计划和协调组织跨团队联调测试，性能，安全性等测试组织敏捷测试技能的培训，分享等收集测试状态和进度数据，向PM和测试部门汇报参加Scrum of Scrums，帮助解决团队遇到的测试有关的障碍谢谢THANK YOUVersion 1.0