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