敏捷开发管理实践.pptVIP

敏捷开发管理实践 代斯2014年11月 目录 了解敏捷 软件开发简史 Code Fix 重量级过程控制 敏捷 敏捷开发联盟 2001年初 在美国犹他州的滑雪胜地Snowbird 十七位专家聚集在一起概括出了一些可以让软件开发团队具有快速工作 响应变化能力的价值观和原则 他们称自己为敏捷联盟 在随后的几个月中 他们创建了一份价值观申明 也就是敏捷联盟宣言 敏捷开发宣言 我们一直在实践中探索更好的软件开发方法 身体力行的同时也帮助他人 由此我们建立了如下价值观 也就是 说右项有价值 但我们更重视左项的价值 高于 Scrum简介 Scrum简介 需求管理 需求管理中的常见问题 用户故事 UserStory 用户故事描述了对用户 系统或软件购买者有价值的功能 对用户有价值的功能 如 用户可以搜索职位公司可以发布新职位用户可以限制浏览其简历的人不理想的用户故事 如 这个程序用java语言编写程序将通过连接池连接到数据库 理想用户故事特点 INVEST UserStory要素 作为 我希望 以便 作为博客作者 我希望通过博客发布我的照片 以便我的读者们认识我 作为网站管理员 我希望统计每天有多人访问我的网站 以便于我的赞助商们了解我的网站会给他们该来什么收益 几种特殊的用户故事 需要修正的缺陷探针实验 spike 架构需求 技术改造 大型重构验证类故事 用户故事估算 扑克牌估算法 扑克牌估算法是几个潜在的仸务承担者 如某个功能小组 共同估算的方法 他们一起听产品负责人讲解 一起估算 以达到利用集体智慧解决问题的目的 每人各自估算后独立出暗牌 听口令一起开牌 数值最大者与最小者PK 其他人旁听也可参与 认论结束后重新出牌和开牌 重复上述过程 直到结果比较接近 扑克牌数值 估算扑克牌上的数字 有的牌是自然数排列 有些是斐波纳契数 有些则是不连续自然数 1 2 3 5 8 13 21 34 100 1 2 角色与团队 Scrum角色 ScrumMaster Scrum 大师 负责维护Scrum方法的秩序 并协劣览决非技术问题 现实世界的ScrumMasterScrumMaster的工作方式是靠领导力而非权力工作 因此首先应服务于团队 一种人选是原来的项目经理转型 保留原有的管理和技术职能 但弱化指派仸务 下达时间点指令等内容 而增强其组细协课能力 另一种人选是企业原有的过程改进人员 协助不太了解Scrum的项目经理按照Scrum的方法工作 可以每人负责多个项目 接近全职的ScrumMaster ProductOwner 产品负责人 负责产品需求的提炼 条目化 优先级排序 现实世界的产品负责人部门经理 产品经理 策划人员等都可能做产品负责人 产品负责人是产品的指路人 必须对产品有长进的规划和深入了览 因此不能简单地选择销售人员甚至客户作为产品负责人 大型产品如嵌入弅产品和网络游戏 常常使用有层级的产品负责人团队 来览决广度不深度的矛盾 如产品总监 产品经理 主策划 策划团队 Team 团队 以 自组织 的相对扁平方式进行管理 负责完成开发工作 现实世界的开发团队 实际团队常常不是 扁平的 而是仍有项目经理 小组长等职位 工作中他们以 共同估算 跨职能工作 共同跟进 等方式自组织工作 而不是完全依赖层层指令 项目经理 小组长的领导 指导 协同职能大于其指令职能 团队中的 猪 和 鸡 猪与鸡走在街上 鸡对猪说 咱们合伙开一家鸡蛋火腿三明治如何 猪想了想说 你当我是猪啊 我要全身心投入 你却只是偶然参与 在敏捷开发中 不同角色各自对自己的工作内容拥有决策权 对于别人负责的事情 则只起到辅助 建议等作用 做下面事情的时候 他们是 ProductOwner 定义产品功能定义产品发布日期和功能对产品的投入和产出比负责根据市场情况对需求排列优先级如果需要 在每个迭代合理调整产品特性及优先级接受或者拒绝开发团队的工作成果 ScrumMaster Scrum正常运作的守护者激发团队的创造力改善开发团队的外部环境辅导团队提升运作效率排除团队遇到的困难保持团队紧密合作 场景一 ScrumMaster该怎么办 PO说 他不能参加Sprint计划会议 但是他不介意团队自己继续 场景二 ScrumMaster该怎么办 在一个Sprint中 一个经理过来 说 他需要把一个团队成员抽出来项目几天 做别的工作 场景三 ScrumMaster该怎么办 一个团队成员过来告诉你 PO刚刚叫他在当前的Sprint中加了一点任务 目前 Sprint进行了1 3 场景四 ScrumMaster该怎么办 团队显得很疲惫 他们不得不每天工作到很晚 甚至在周末加班工作 来达到Sprint的目标 他们评价scrum太可怕了 逼着他们工作这么多 Team 传统团队 require development test Team 敏捷团队 通常5 9人 跨职能 跨模块人员构成成员应全职投入团队自组织管理迭代内保持团队成员稳定 团队间协同 在划分团队的时候 尽量让团队具备端到端交付价值的能力跨职能 跨模块人员构成成员应全职投入团队自组织管理迭代内保持团队成员稳定 过程 项目 Sprint0 Sprint1 Sprint2 Sprint3 项目策划 项目结项 项目 观察 调整 迭代 迭代计划1 迭代计划2 站立会议 站立会议 迭代评审 站立会议 迭代回顾 观察 调整 观察 调整 观察 调整 2h 2h 15m 15m 15m 2h 2h 迭代 2weeks Sprint0 高层业务流程梳理初始用户故事列表团队建设技术架构选择UI风格开发 测试环境准备持续集成Sprint1的UserStory和验收标准 迭代分工 角色 Sprintn 1 Sprintn Sprintn 1 ScrumMaster ProductOwner Team 确保Scrum正常运转 确保Scrum正常运转 确保Scrum正常运转 辅助开发 准备nStory 辅助开发 准备n 1Story 辅助开发 准备n 2Story 开发测试 开发测试 开发测试 迭代计划会议 Productbacklog Sprintnbacklog 创建迭代backlog任务分解 站立会议 晨会上的三个经典问题 昨天我完成了那些工作 今天我打算做什么 完成我的目标是否存在什么障碍 站立会议 晨会上的三个经典问题 昨天我完成了那些工作 今天我打算做什么 完成我的目标是否存在什么障碍 迭代验收 迭代验收的好处 通过演示可工作的软件来确认项目的进度 具有真实性能尽早的获得用户对产品的反馈 是产品更加贴近客户的需求 Scrummaster 组织PO 用户代表 验收Team 演示 真实的产品演示 收集反馈意见 调整backlog 迭代回顾 迭代回顾的好处 激励团队成员挖掘优秀经验并继承避免团队犯重复的错误营造团队自主改进的氛围 宽松自由 畅所欲言 发现分析问题 Team全员参与 领导 KPI相关不参与 记录 跟踪问题 迭代回顾 迭代回顾的好处 激励团队成员挖掘优秀经验并继承避免团队犯重复的错误营造团队自主改进的氛围 宽松自由 畅所欲言 发现分析问题 Team全员参与 领导 KPI相关不参与 记录 跟踪问题 总结回顾 敏捷方法的核心 适应性VS预见性面向人VS面向过程 预见性过程 执行 计划 预想目标 实际目标 定义性的过程 预见性过程 预想目标 实