敏捷软件开发管理 -20160405

1、2009 敏捷软件开发管理敏捷软件开发管理IBM 高级技术顾问 孙昕2009 议程如何有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 ThoughtWorks ThoughtWorks 办公区办公区2009 思特沃克软件技术办公区思特沃克软件技术办公区2009 敏捷宣言敏捷宣言 2001年2月11-13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地-雷鸟雪场，经过两天的讨论，敏捷（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观，敏捷宣言。2009 敏捷宣言敏捷宣言Individuals and interacti

2、ons over processes and tools(人和交互重于过程和工具 )Working software over comprehensive documentation(可以工作的软件重于面面俱到的文档)Customer collaboration over contract negotiation(客户合作重于合同谈判)Responding to change over following a plan (拥抱变化胜于遵循计划 )That is, while there is value in the items on the right, we value the items

3、 on the left more.关注敏捷软件开发是因为我们认为它是一种很好的软件开发理念，能够应对现实中的软件需求经常不完善和快速变更的问题，用好它能够提高客户满意度，降低项目失败的风险。但什么时候使用它、如何很好地实施这些理念，是我们需要考虑和解决的问题。2009 敏捷宣言敏捷宣言 Kent Beck James Grenning Robert C.Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt ken Schwaber Alistair Cockburn Ron Jeffries J

4、effSutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick2009 敏捷敏捷宣言遵循的原则宣言遵循的原则我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式

5、是面对面的交谈。2009 敏捷敏捷宣言遵循的原则宣言遵循的原则可工作的软件是进度的首要度量标准。敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。坚持不懈地追求技术卓越和良好的设计，敏捷能力由此增强。以简洁为本，它是极力减少不必要工作量的艺术。最好的架构、需求和设计出自自组织团队。团队定期地反思如何能提高成效，并依此调整自身的举止表现。2009 敏捷的定义敏捷的定义(IBM)“使用持续的项目干系人的反馈，通过用例（用户需求）和一系列的较短的、稳定的、时间固定的迭代来交付高质量, 可用的代码.”This figure shows the Four Ss that des

6、cribe agile in a nutshell. 2009 议程如何有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 Scrum开发方式是敏捷方法之一Scrum一词来源于橄榄球运动，过程是迅速，有适应性，自组织的旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进 适用于需求难以预测的复杂商务应用产品的开发1995年由先进的开发方法公司提出，2001年由 “敏捷联盟”推广团队成员能够独立地，集中地在创造性的环境下工作2009 困难困难 成功的变革不是完全的自上而下或者自下而上 结束状态是不可预知的 Scrum 是无处不在的

7、Scrum 是截然不同的 变化来得比以往更快 最佳实践是危险的2009 值得值得 更高的生产力及更低的成本 员工的参与度和工作满意度增强 更快的产品上市时间 更高的质量 项目干系人的满意度提升 现在的做法不再有效2009 模型模型 意识（Awareness）：当前的过程已不能实现可接受的结果 渴望（Desire）：把实施Scrum作为一种方法来解决当前的问题 能力（Ability）：有能力成功实施Scrum 推广（Promotion）：通过分享经验来推广Scrum，从而能让我们记住并能让其他人也能看到我们的成功 传递（Transfer）：把实施Scrum带来的影响扩大到整个公司2009 Scr

8、umScrum的角色、框架和流程的角色、框架和流程ScrumMaster的角色ScrumMaster：保证团队一起顺利工作，迅速清除挡路石，团队有效地朝着目标前进。帮助团队使用Scrum。ScrumMaster所需的品质：责任：能够并愿意承担责任。ScrumMaster要对最大化团队的产出和支持团队成员实施及使用Scrum负责。谦虚：不会把自己的需求排在第一位，而是愿意去做任何能帮助团队实现目标的事情。理解全体团队成员的价值，并以身作则促成其他人达成共识。协作：ScrumMaster的工作是保证团队中存在一种相互协作的文化。确保团队成员能够把问题拿出来公开讨论。投入：要求全力以赴的投入。必须与

9、团对成员一样，对项目及其目标具有高度的奉献精神。有影响力：能够影响团队内和团队外的人。让团队相信需要尝试一项新的技术实践，如测试驱动开发或者结对编程。知识渊博：具备技术、市场和其他的专业知识，可以帮助团队实现目标。2009 ScrumScrum的角色、框架和流程的角色、框架和流程产品负责人的角色产品负责人：保证团队瞄准正确目标的人。产品负责人的职责：提供愿景：包括确定产品的愿景，做好沟通交流。向团队清楚解释它。创建、维护产品Backlog并排好优先次序来到达。提供边界:描述愿景被实现时的现实情况，一般为限制条件。产品负责人所需的品质：ABCDE。始终都在（Available）：保持随需而到的状

10、态，对项目的积极投入。懂业务(Business-savvy)：懂得产品开发的业务背景。善于沟通(Communication)：良好的沟通者，能够和各种不同的项目干系人友好相处。果断(Decisive)：当团队成员有问题找产品负责人时，需要一个解决方案。得到授权(Empowered)：一定是被授予权力做出决定并能为决策负责的人。2009 角色职责角色职责2009 划龙舟团队划龙舟团队2009 20 Scrum总体骨架总体骨架冲刺规划会议冲刺规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后

11、4小时：团队计划本Sprint的安排冲刺复审会议冲刺复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况冲刺回顾会议冲刺回顾会议Sprint Retrospective一般3个小时， ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实

12、现SCRUM及项目目标的工作中，你遇到哪些困难吗? 产品订单产品订单Product Backlog冲刺订单冲刺订单Sprint Backlog新的功能新的功能增量增量产品负责人产品负责人Scrum主管主管开发团队开发团队干系人干系人燃尽图燃尽图角色角色工件工件活动活动产品订单产品订单Product Backlog冲刺规划会议冲刺规划会议每日站每日站立会议立会议每日工每日工作作产品订单产品订单冲刺复审会议冲刺复审会议冲刺回顾会议冲刺回顾会议冲刺目标冲刺订单产品新的功能增量新的功能增量开发流程开发流程2009 21迭代迭代每30天Daily SCRUM每24小时高优先级可运行的软件可运行的软件工作

13、项分解产品订单产品订单Product Backlog冲刺订单冲刺订单Sprint Backlog新的功能新的功能增量增量冲刺规划会议冲刺规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排冲刺复审会议冲刺复审会议Sprint Review 一般4个小时，由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况冲刺回顾会议冲刺回顾会议Sprint Retrospective一般3个小时， ScrumMaster将鼓励团队在SCRUM过程框

14、架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗? 产品负责人产品负责人Scrum主管主管开发团队开发团队 Scrum总体骨架总体骨架2009 使用使用Scrum of Scrums来进行扩展来进行扩展Scrum对大型和小型的开发团队都有着良好的适应性可以增加团队的层次，比如： 几个相互依赖的Scrum团

15、队需要沟通 几个团队一起工作于一个单一的产品，并且团队间需要内部相互依赖通过多层团队的建立来拓展不确定的项目规模由团队来决定频率和是否出席和参与 Technical contributor 不需要Product Owner或者ScrumMaster, 但是他们可以协助Are you about to put something in another teams way?2009 成功的成功的Scrum需要做好准备工作需要做好准备工作有准备的 让正确的人来担当适当的Scrum的角色 具有良好的产品需求的规划以及需求的优先级的排序 开发和测试环境已经准备就绪 团队知道如何将产品需求转化为可装配和可

16、运行的产品增量扎实的 由团队来评估和估算产品需求项 产品负责人确定冲刺的目标并就相关的产品需求和团队进行讨论 由团队来决定它的可用性 ScrumMaster准备相关会议 GO! 项目已经初始化 第一个sprint计划会议可以开始启动 Well done. Good luck and enjoy!2009 Scrum项目也可能会失败项目也可能会失败 失败失败摘自维基百科, 自由的百科全书 Failure (colloquially fail, phail or flop) in general refers to the state or condition of not meeting a d

17、esirable or intended objective. It may be viewed as the opposite of success. Product failure ranges from failure to sell the product to fracture of the product, in the worst cases leading to personal injury, the province of forensic engineering. So you need to quickly identify Scrum Smells.2009 Scru

18、m的误区的误区: 丢失节奏丢失节奏不一致的Scrum每日例会Scrum每日例会被省略会议的时间老是变化不一致的Sprint周期Sprint周期在中期被武断得改变不一致的Sprint计划会议Sprint计划会议被省略 保持一致性和协调性 在Scrum当中避免混乱和杂音，专注于交付本身 明确的阐明预期 进行适当的引导和培训 求助于基本的Scrum规则节奏能够帮助我们走上正轨2009 Scrum的误区的误区: 随意讲话的鸡随意讲话的鸡项目干系人在Scrum每日例会上款款而谈产品功能的选择在Sprint计划会议之外进行 没有外部人员的肯定，团队没有办法做纯技术上的决策项目的状态分析在Sprint计划会

19、议之外进行 执行者试图干预团队产品需求调整或不被理睬 始终如一的防止狼群的骚扰 指导和培训作为项目启动的一部分 在项目启动过程中认定角色 通过回顾加固预期 把鸡从猪圈里赶出去 适当的变更会议时间和地点 或许鸡可以下蛋 成为一个称职的牧羊犬团队成员活在不恰当的技术决策的痛苦当中vs.干系人感觉被强制的为团队做决定2009 Scrum误区误区: 被遗忘的猪被遗忘的猪不清晰和明确的期望?竞争性的分配?缺乏担当?管理上的干涉?厌烦?恐惧? 角色框架 变更会议的时间和地点 解释, 说服, 和商讨 拥抱技术 改组团队 团队成员活在不恰当的技术决策的痛苦当中vs.干系人感觉被强制的为团队做决定2009 Sc

20、rum误区误区: 缺少进展缺少进展 Backlog持续的增长而不是减少手头正在做的工作太多了功能特性感觉永无止境90%完成综合症总是基于已完成的功能特性不断进行修改和修复已完成的功能正在等待未完成的项目干系人抱怨缺少进展失败得交付 需求可以尽早的看到其进展、尽早的看到其价值以及按时地完成 对于客户存在极大价值的功能特性可以很容易的构造 “零缺陷”的产品 总是对即将交付的产品保持承诺 总是愿意去问, “是否没有交付有用的可执行的代码, 有什么好处呢?” 意识到缺陷是不可避免的良好的Sprint backlog管理2009 Scrum 误区误区: ScrumMaster 超越了自身的职责超越了自身

21、的职责工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展 让团队自己掌控工作 团队自己来做任务分配 Scrum每日例会由团队参与并且最终是为了团队团队的自组织和自管理是Scrum的核心原则之一2009 Scrum 误区误区: ScrumMaster 超越了自身的职责超越了自身的职责工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展 自组织 团队自己来做任务分配 符合T型技能，即一专多能

22、 持续改进 最大限制的沟通 专注、投入 按照可持续的节奏工作 长期存在、人员稳定团队的自组织和自管理是Scrum的核心原则之一2009 Scrum 误区误区: ScrumMaster 超越了自身的职责超越了自身的职责工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展 团队决定做什么，做任务分配 团体决定如何做，如何实现目标，即团队做技术决策 需在确保目标的前提下制定行为准则 有义务保持过程的透明性 团队监控和管理他们的过程和进度团队的自组织和自管理是Scrum的核心原则之一2009 Scr

23、um 误区误区: ScrumMaster 超越了自身的职责超越了自身的职责工作是由ScrumMaster分配的，而不是由开发人员自己去认领的团队无法自己掌控工作Scrum每日例会感觉是团队成员在向ScrumMaster汇报工作进展 确保目标和愿景 团队结构、成员 提供环境和支持 授权团队 训练协作 管理层决定团队的目标，团队决定如何实现目标 管理者从微观管理转向目标驱动、授权团队的管理方式团队的自组织和自管理是Scrum的核心原则之一2009 Scrum误区误区: 明确的工作职责明确的工作职责 项目团队具有非常专一的工作角色划分和描述： 架构师, 设计人员, DBA, or 测试人员,团队包括

24、专门的测试人员Scrum团队没有“我们大家在一起”的态度Scrum团队不需要完全有多面手组成 工作由团队自己分配 Scrum每日例会可以进行工作的分配 每个专家都要对整个系统负责 “我将尽一切我所能来帮助团队”的态度“同舟共济” 的态度2009 Scrum误区误区: 来自执行者的压力来自执行者的压力执行者要求团队承诺在一个确定的日期发布一系列的所谓的“最低要求”功能项执行者参加团队会议执行者直接和团队成员沟通，并提醒他们最后期限 私下里和执行者沟通，告诉他们他们的做法和期望可能背道而驰 询问执行者到底什么是他们真正关心的，依此来指导团队 让产品负责人和执行者就产品的优先级问题进行充分的商讨支持

25、它，承诺必须来之团队2009 Scrum 误区误区: 不像一个良好的团队不像一个良好的团队 固定的角色任务是被分配的没有互相帮助没有持续的指导用户需求没有被团队广泛的达成共识，所有的工作都是并行完成的缺少协作在Scrum会议上没有互相的交流和倾听没有欢笑 相反一个合作愉快的团队总是充满欢笑 用榜样和指导者来领导，并帮助团队成员完成他们的任务 打破竖井和一成不变的角色 适当的改变团队架构来鼓励团队而不是个人英雄主义 鼓励结对编程, 代码复查等能够促进团队协作和交流的实践活动Scrum项目的效率来自作为一个整体的团队2009 Scrum误区误区: 大猩猩在房间里大猩猩在房间里一个人 (资深开发人员

26、, 技术带头人, 主管人员) 支配交流和会议大家不愿意发言直到大猩猩开口发言团队成员对大猩猩的观点言听计从 让大猩猩在每个问题的最后发言 让大猩猩多问问题而不是下结论 需要考量大猩猩是不是必须的参与者? 可以让其适当的缺席一二次会议 在某些情况下，有必要让项目干系人永远离开会议 (因为即使没有发言，他们也可以对团队产生极大的影响)团队的智慧 vs. 个人的天赋 2009 议程有效的实施Scrum第一款全面支持敏捷开发的工具成功案例分享：IBM如何实现敏捷开发2009 Rational Team Concert对于敏捷实践的支持对于敏捷实践的支持仪表盘仪表盘增量设计增量设计持续集成持续集成测试驱

27、动得开发测试驱动得开发迭代迭代/冲刺冲刺构建构建工作项工作项配置管理配置管理Backlog（需求）（需求）敏捷和适应性敏捷和适应性流程流程382009 常用工作项类型常用工作项类型 Scrum过程模版中所包含的常用工作项类型: Defect: 在项目开发的过程中在项目开发的过程中,对于缺陷的追踪管理对于缺陷的追踪管理 Story: 用户需求用户需求,通过一两句用户的业务语言所描述的文档化的需求通过一两句用户的业务语言所描述的文档化的需求 Retrospective: 在每个冲刺之后由项目组召开的冲刺回顾会议在每个冲刺之后由项目组召开的冲刺回顾会议,用来讨论用来讨论和总结这次迭代中和总结这次迭代

28、中,一些好的成功的经验一些好的成功的经验,同时还有那些不足的地方需要改同时还有那些不足的地方需要改进进.最后就在以后的迭代中如何更好的工作达成一致的建议最后就在以后的迭代中如何更好的工作达成一致的建议. A.Impediment: 阻碍和风险阻碍和风险,妨碍团队成功的达到迭代和冲刺的目标妨碍团队成功的达到迭代和冲刺的目标2009 RTC可以增强业务敏捷性和保持项目的成功概率可以增强业务敏捷性和保持项目的成功概率促进高效能团队的原则促进高效能团队的原则工作软件工作软件人员交互人员交互响应变更响应变更客户协作客户协作 透明 目的共同性 项目健康状况检查 上下文驱动 流程的灵活性 迭代的计划执行 多次发布 JIT代码审查 启动特设团队 团队感知 流程感知 特设共享 持续集成 管理团队资源 变更驱动的 已集