敏捷开发管理实践[稻谷书屋]

1、敏捷开发管理实践 代斯代斯 2014年年11月月 目录目录 了解敏捷 需求管理 角色与团队 过程 回顾与总结 了解敏捷 软件开发简史软件开发简史 Code&Fix 重量级过程控制重量级过程控制 敏捷敏捷 敏捷开发敏捷开发联盟联盟 2001年初，在美国犹他州的滑雪胜地Snowbird，十七 位专家聚集在一起概括出了一些可以让软件开发团队具有 快速工作，响应变化能力的价值观和原则。他们称自己为 敏捷联盟。在随后的几个月中，他们创建了一份价值观申 明，也就是敏捷联盟宣言。 敏捷开发宣言敏捷开发宣言 我们一直在实践中探索更好的软件开发方法，身体力行的 同时也帮助他人。由此我们建立了如下价值观： 也就是

2、,说右项有价值，但我们更重视左项的价值 高于高于工作的工作的 软件软件 高于高于 详尽的详尽的 文档文档 个体和个体和 互动互动 高于高于 流程和流程和 工具工具 客户客户 合作合作 高于高于 商业商业 谈判谈判 响应响应 变化变化 高于高于 遵循遵循 计划计划 Scrum简介简介 带球过人需要计划！带球过人需要计划！ 在球场上：每段开始都定攻防策略 在软件公司：每个迭代都计划 带球过人需要灵活应变！带球过人需要灵活应变！ 在球场上：靠平时训练中形成的素养见机行亊，达成目标。 在软件公司：具体执行的人选择如何去做。 Scrum简介简介 需求管理 需求管理中的常见问题需求管理中的常见问题 用户故

3、事（用户故事（User Story） 用户故事描述了对用户、系统或软件购买者有价值的功能 对用户有价值的功能，如： 用户可以搜索职位 公司可以发布新职位 用户可以限制浏览其简历的人 不理想的用户故事，如： 这个程序用java语言编写 程序将通过连接池连接到数据库 理想用户故事特点理想用户故事特点-INVEST Independent:独立的 I Negotiable：可讨论的 N Valuable：对客户或客户有价值的 V Estimated:可估计的 E Small：小的 S Testable：可测试的 T User Story要素要素 作为。 我希望。 以便。 作为博客作者， 我希望通过博

4、客发布 我的照片， 以便我的读者们认识 我。 作为网站管理员， 我希望统计每天有多 人访问我的网站， 以便于我的赞助商们 了解我的网站会给他 们该来什么收益。 几种特殊的用户故事几种特殊的用户故事 需要修正的缺陷 探针实验（spike） 架构需求、技术改造、大型重构 验证类故事 用户故事估算用户故事估算-扑克牌估算法扑克牌估算法 扑克牌估算法是几个潜在的仸务扑克牌估算法是几个潜在的仸务 承担者（如某个功能小组）共同承担者（如某个功能小组）共同 估算的方法，他们一起听产品负估算的方法，他们一起听产品负 责人讲解，一起估算，以达到利责人讲解，一起估算，以达到利 用集体智慧解决问题的目的。用集体智慧

5、解决问题的目的。 每人各自估算后独立出暗牌，听口令一起开牌。 数值最大者与最小者PK，其他人旁听也可参与。 认论结束后重新出牌和开牌。 重复上述过程，直到结果比较接近。 扑克牌数值扑克牌数值 估算扑克牌上的数字，有的牌是自然数排列，有些是斐波 纳契数，有些则是不连续自然数。 角色与团队 Scrum角色角色 Scrum Master（Scrum“大大 师师”）负责维护Scrum方法 的秩序，并协劣览决非技术 问题。 现实世界的现实世界的Scrum Master Scrum Master的工作方式是靠领 导力而非权力工作，因此首先应 服务于团队。 一种人选是原来的项目经理转型 ，保留原有的管理和技

6、术职能， 但弱化指派仸务、下达时间点指 令等内容，而增强其组细协课能 力。 另一种人选是企业原有的过程改 进人员，协助不太了解Scrum的 项目经理按照Scrum的方法工作 ，可以每人负责多个项目，接近 全职的Scrum Master Product Owner（产品负责（产品负责 人）人）负责产品需求的提炼、 条目化、优先级排序。 现实世界的产品负责人现实世界的产品负责人 部门经理、产品经理、策划人员 等都可能做产品负责人。 产品负责人是产品的指路人，必 须对产品有长进的规划和深入了 览，因此不能简单地选择销售人 员甚至客户作为产品负责人。 大型产品如嵌入弅产品和网络游 戏，常常使用有层级的

7、产品负责 人团队，来览决广度不深度的矛 盾，如产品总监-产品经理 / 主策 划-策划团队。 Team（团队）（团队）以“自组织 ” 的相对扁平方式进行管理， 负责完成开发工作。 现实世界的开发团队现实世界的开发团队 实际团队常常不是“扁平的”， 而是仍有项目经理、小组长等职 位。 工作中他们以“共同估算”“跨职能 工作”“共同跟进”等方式自组织工 作， 而不是完全依赖层层指令。 项目经理、小组长的领导、指 导、协同职能大于其指令职能。 团队中的团队中的”猪猪”和和”鸡鸡” 猪与鸡走在街上，鸡对猪说：咱们合伙开一家鸡蛋火腿三 明治如何？猪想了想说：你当我是猪啊，我要全身心投入 ，你却只是偶然参与

8、。 在敏捷开发中，不同角色各自在敏捷开发中，不同角色各自 对自己的工作内容拥有决策权对自己的工作内容拥有决策权 ，对于别人负责的事情，则只，对于别人负责的事情，则只 起到辅助、起到辅助、建议等建议等作用作用 做下面事情的时候，他们是 Product Owner l 定义产品功能 l 定义产品发布日期和功能 l 对产品的投入和产出比负责 l 根据市场情况对需求排列优先级 l 如果需要，在每个迭代合理调整产品特性及优先级 l 接受或者拒绝开发团队的工作成果 Scrum Master l Scrum正常运作的守护者 l 激发团队的创造力 l 改善开发团队的外部环境 l 辅导团队提升运作效率 l 排除

9、团队遇到的困难 l 保持团队紧密合作 场景一：场景一：Scrum Master该该怎么办？怎么办？ l PO说：他不能参加Sprint计划会议，但是他不介意团队 自己继续。 场景二：场景二：Scrum Master该该怎么办？怎么办？ l 在一个Sprint中，一个经理过来，说：他需要把一个团 队成员抽出来项目几天，做别的工作。 场景三：场景三：Scrum Master该该怎么办？怎么办？ l 一个团队成员过来告诉你：PO刚刚叫他在当前的Sprint 中加了一点任务。目前，Sprint进行了1/3。 场景四：场景四：Scrum Master该该怎么办？怎么办？ l 团队显得很疲惫，他们不得不每

10、天工作到很晚，甚至在 周末加班工作，来达到Sprint的目标。他们评价scrum太 可怕了，逼着他们工作这么多。 Team-传统团队传统团队 requiredevelopment test Team-敏捷团队敏捷团队 l 通常59人。 l 跨职能，跨模块人员构成 l 成员应全职投入 l 团队自组织管理 l 迭代内保持团队成员稳定 团队间协同团队间协同 l 在划分团队的时候，尽量让团队具备端到端交付价值的 能力 l 跨职能，跨模块人员构成 l 成员应全职投入 l 团队自组织管理 l 迭代内保持团队成员稳定 过程 项目项目 Sprint0Sprint1Sprint2Sprint3 项 目 策 划

11、项 目 结 项 项目 观察、调整 迭代迭代 迭代计划1 迭代计划2 站立会议 站立会议 迭代评审 站立会议 迭代回顾 观察、调整观察、调整观察、调整 2h 2h 15m 15m15m 2h 2h 迭代（2weeks） . Sprint0 高层业务流程梳理 初始用户故事列表 团队建设 技术架构选择 UI风格 开发、测试环境准备 持续集成 Sprint1的User Story和验收标准 迭代分工迭代分工 角色Sprint n-1Sprint nSprint n+1 Scrum Master Product Owner Team 确保Scrum正 常运转 确保Scrum正 常运转 确保Scrum正

12、常运转 辅助开发， 准备n Story 辅助开发，准 备n+1 Story 辅助开发，准 备n+2 Story 开发测试开发测试开发测试 迭代计划会议迭代计划会议 Product backlog Sprint n backlog l 创建迭代backlog l 任务分解 站立会议站立会议 晨会上的三个经典问题： l 昨天我完成了那些工作？ l 今天我打算做什么？ l 完成我的目标是否存在什么障碍？ 站立会议站立会议 晨会上的三个经典问题： l 昨天我完成了那些工作？ l 今天我打算做什么？ l 完成我的目标是否存在什么障碍？ 迭代验收迭代验收 迭代验收的好处： 通过演示可工作的软件来确认项目的

13、进度， 具有真实性 能尽早的获得用户对产品的反馈，是产品更 加贴近客户的需求。 Scrum master-组织 PO、用户代表-验收 Team-演示 真实的产品演示； 收集反馈意见，调整 backlog 迭代回顾迭代回顾 迭代回顾的好处： 激励团队成员 挖掘优秀经验并继承 避免团队犯重复的错误 营造团队自主改进的氛围 宽松自由、畅所欲言、 发现分析问题 Team全员参与，领 导、KPI相关不参 与 记 录 跟踪问题 迭代回顾迭代回顾 迭代回顾的好处： 激励团队成员 挖掘优秀经验并继承 避免团队犯重复的错误 营造团队自主改进的氛围 宽松自由、畅所欲言、 发现分析问题 Team全员参与，领 导、KPI相关不参 与 记 录 跟踪问题 总结回顾 敏捷方法的核心敏捷方法的核心 适应性VS预见性 面向人VS面向