敏捷实战之——硝烟中的Scrum和XP.pptx

PM沙龙-Scrum实战分享;《硝烟中的Scrum和XP：我们如何实施Scrum》;敏捷软件开发宣言;12条原则;产品负责人 VS Scrum Master;进入正题——怎样实行敏捷;Step1.规划产品愿景;Backlog —— ;详尽适当的 —— Detailed appropriately 经过估算的 —— Estimated 涌现的 —— Emergent 按优先级排序的 —— Prioritized;价值 知识、不确定性、风险 可发布性 依赖性;Sprint计划会议之前，确保产品Backlog井然有序 只能有一个Backlog，一个产品负责人 所有重要的Backlog条目都已根据重要性评分 产品负责人应当理解每个故事的含义 使用JIRA（或Excel等）存放Backlog 使用敏捷过程工具（VersonOne、ScrumWorks…）;Sprint计划会议产生的成果： Sprint目标（业务术语） 团队成员名单（投入程度） Sprint Backlog 确定好Sprint演示日期 确定每日Scrum会议的时间、地点;范围—————— 估算—————— 重要性————— 质量—外部质量 —内部质量—;调整优先级 缩小故事 拆分故事;产品负责人能做什么？;Option 1;Option 2;Option 3;本能反应 生产率计算;技巧一 索引卡+便签;技巧二 计划扑克;延长时间，直到有结果？ 明天再开？ 到此为止，开始Sprint？;如果时间不够了，最后的界限在哪里？;Step5.怎样让别人了解我们的Sprint;Step6.怎样编写Sprint Backlog;Step7.怎样布置团队房间;让团队坐在一起！！;不超过15分钟 任务板前 例会结束，有人修改燃尽图;Scrum注重的是管理和组织实践 XP关注的是实际的编程经验;结对编程 测试驱动开发 增量设计 持续集成 代码集体所有权 充满信息的工作空间 代码标准 可持续的开发速度/精力充沛地工作;不能取消验收测试阶段 把验收测试阶段缩到最短?;全力提高交付代码质量 把测试人员放到Scrum团队里来 每个Sprint少做点工作 全力提高人员测试效率 好的测试人员 好的测试工具 减少开发到测试的间隔 每当开发人员开发出一个功能时，测试人员可以先测试;不需要测试时测试人员做什么？;测试人员可以做这么多事情，那么在测试人员有困难的时候，其他人员一样要帮助他完成团队里的工作。如果在Sprint的最后，突然测试人员根本没有时间测试完所有的东西，那么这个时候测试人员可以指挥 一下Scrum成员做一些事情。让他决定哪些事情自己来做。;有的团队把验收测试当成了Sprint一部分，但大部分团队没有这样做，原因如下： 如果有多个团队开发同一个产品时，那就要等所有团队把各模块集成以后再测试。而就算每个Sprint中都有测试过。到最后还是要再测试一个遍。;改良后的Sprint;;Sprint演示检查列表： 确保清晰阐述了Sprint目标 不要花太多时间准备演示 节奏要快 让演示关注于业务层次，不要管技术细节 可能的话，让观众自己试一下产品 不要演示一大堆细碎的BUG修复和微不足道的特性;确保能够进行回顾 这是做改进的最佳时机;根据要讨论的内容范围，设定时间为1~3小时 参与者包括产品负责人和Scrum Master 在一个封闭的房间中、或舒适的沙发角等任何能够在不受干扰情况下讨论的地方 我们一般不会在团队房间中回顾，会分散注意力 制定某人当秘书 Scrum Master向大家展示Sprint Backlog，在团队帮助下对Sprint做总结，包括重要事件和决策等 轮流发言，什么是好的，什么可以改进 对预估生产率和实际生产率进行比较。若差异大，分析原因 快结束时，Scrum Master对具体建议进行总结，得出下一个Sprint需要改进的地方。;Good;Step13.Sprint之间的修整时刻;Step14.制定发布计划，处理固定价格的合同;“大团队” better than “多团队” 5~9人被公认为是“最佳”团队人数 同步多个Sprint 一个产品负责人，一个Backlog;想尽办法把物理位置上分散的团队成员之间的沟通带宽增至最大;Step17.Scrum Master检查列表;每一天： 确保每日Scrum会议可以按时开始和结束 为了保证Sprint可以如期完成，需要适当地增删故事（确保产品负责人了解这些变化） 确保团队可以及时得知Sprint Backlog和燃尽图的必威体育精装版情况 障碍管理。确保存在的问题和障碍都能被解决，并报告给产品负责人以及（或者）开发主管;在Sprint结束时： 进行开放式的Sprint演示 在演示开始前一两天，就要通知