敏捷开发管理实践.ppt

敏捷开发管理实践 代斯 2014年11月 目录 了解敏捷 软件开发简史 CodeFix 重量级过程控制 敏捷 敏捷开发联盟 2001年初，在美国犹他州的滑雪胜地Snowbird，十七位专家聚集在一起概括出了一些可以让软件开发团队具有快速工作，响应变化能力的价值观和原则。他们称自己为敏捷联盟。在随后的几个月中，他们创建了一份价值观申明，也就是敏捷联盟宣言。 敏捷开发宣言 我们一直在实践中探索更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 也就是,说右项有价值，但我们更重视左项的价值 高于 Scrum简介 Scrum简介 需求管理 需求管理中的常见问题 用户故事（User Story） 用户故事描述了对用户、系统或软件购买者有价值的功能 对用户有价值的功能，如： 用户可以有哪些信誉好的足球投注网站职位 公司可以发布新职位 用户可以限制浏览其简历的人 不理想的用户故事，如： 这个程序用java语言编写 程序将通过连接池连接到数据库 理想用户故事特点-INVEST User Story要素 作为。。。。 我希望。。。。。 以便。。。。。 作为博客作者， 我希望通过博客发布我的照片， 以便我的读者们认识我。 作为网站管理员， 我希望统计每天有多人访问我的网站， 以便于我的赞助商们了解我的网站会给他们该来什么收益。 几种特殊的用户故事 需要修正的缺陷 探针实验（spike） 架构需求、技术改造、大型重构 验证类故事 用户故事估算----扑克牌估算法 扑克牌估算法是几个潜在的仸务承担者（如某个功能小组）共同估算的方法，他们一起听产品负责人讲解，一起估算，以达到利用集体智慧解决问题的目的。 ①每人各自估算后独立出暗牌，听口令一起开牌。 ②数值最大者与最小者PK，其他人旁听也可参与。 ③认论结束后重新出牌和开牌。 ④重复上述过程，直到结果比较接近。 扑克牌数值 估算扑克牌上的数字，有的牌是自然数排列，有些是斐波纳契数，有些则是不连续自然数。 1 2 3 5 8 13 21 34 100 1/2 ?/！ 角色与团队 Scrum角色 Scrum Master（Scrum“大师”）负责维护Scrum方法的秩序，并协劣览决非技术问题。 现实世界的Scrum Master Scrum Master的工作方式是靠领导力而非权力工作，因此首先应服务于团队。 一种人选是原来的项目经理转型，保留原有的管理和技术职能，但弱化指派仸务、下达时间点指令等内容，而增强其组细协课能力。 另一种人选是企业原有的过程改进人员，协助不太了解Scrum的项目经理按照Scrum的方法工作，可以每人负责多个项目，接近全职的Scrum Master Product Owner（产品负责人）负责产品需求的提炼、条目化、优先级排序。 现实世界的产品负责人 部门经理、产品经理、策划人员等都可能做产品负责人。 产品负责人是产品的指路人，必须对产品有长进的规划和深入了览，因此不能简单地选择销售人员甚至客户作为产品负责人。 大型产品如嵌入弅产品和网络游戏，常常使用有层级的产品负责人团队，来览决广度不深度的矛盾，如产品总监-产品经理 / 主策划-策划团队。 Team（团队）以“自组织 ”的相对扁平方式进行管理，负责完成开发工作。 现实世界的开发团队  实际团队常常不是“扁平的”，而是仍有项目经理、小组长等职位。 工作中他们以“共同估算”“跨职能工作”“共同跟进”等方式自组织工作， 而不是完全依赖层层指令。  项目经理、小组长的领导、指导、协同职能大于其指令职能。 团队中的”猪”和”鸡” 猪与鸡走在街上，鸡对猪说：咱们合伙开一家鸡蛋火腿三明治如何？猪想了想说：你当我是猪啊，我要全身心投入，你却只是偶然参与。 在敏捷开发中，不同角色各自对自己的工作内容拥有决策权，对于别人负责的事情，则只起到辅助、建议等作用 做下面事情的时候，他们是 Product Owner 定义产品功能 定义产品发布日期和功能 对产品的投入和产出比负责 根据市场情况对需求排列优先级 如果需要，在每个迭代合理调整产品特性及优先级 接受或者拒绝开发团队的工作成果 Scrum Master Scrum正常运作的守护者 激发团队的创造力 改善开发团队的外部环境 辅导团队提升运作效率 排除团队遇到的困难 保持团队紧密合作 场景一：Scrum Master该怎么办？ PO说：他不能参加Sprint计划会议，但是他不介意团队自己继续。 场景二：Scrum Master该怎么办？ 在一个Sprint中，一个经理过来，说：他需要把一个团队成员抽出来项目几天，做别的工作。 场景三：Scrum Master该怎么办？ 一个团队成员过来告诉你：PO刚刚叫他在当前的Sprin