1、知识分享：敏捷开发方法知识分享：敏捷开发方法目录Catalog敏捷开发简介敏捷开发方法敏捷开发的注意事项IT Craftsmanship关注：技术编程和技术管理能力孤军作战，没有协作零星、偶发的自动化与革新It Industrialization关注：流程IT管理与服务管理能力以同事为客户，没有对外协作有效率的服务与解决方案It Digitalization关注：业务模式强调数字化领导力以同事为合作伙伴，参与对外协作数字化商业创新、新型价值IT系统开发演变的三个时代敏捷概念的提出项目为什么失败？软件工程试图解决这些问题：1)对用户需求理解得不清楚，甚至有错误；2)用户需求变化；3)软件很难维护
2、或扩展；4)在项目后期阶段发现很严重的设计缺陷；5)软件质量或性能不合格；6)Test - Build - Release过程的可操作性、可维护性很差；7)人员流动； 1)为了规范化开发过程，引进传统工程的概念（瀑布型）；2)为了理解需求，提出原型法；3)为了提高设计开发的效率和扩展性，提出重用和面向对象等思想；4)为了让开发过程更灵活，提出了开发框架的概念；5)为了降低风险，提出了风险评估、成本控制和增量开发等思想；如何走出困境？当我们面临速度、创新或面临诸多不确定因素瀑布式开发熟知的供应商强大的管理模式最小化的风险技术化团队敏捷式开发规模小但有创新精神的合作伙伴轻装有效的管理模式管控可控的
3、风险更强大团队传统开发模式非线性模式可靠性目标灵活性依据结果定价价值收益、品牌、客户体验以计划为导向、基于审批的管理以经验为导向、基于流程的企业供应商长期交易采购小型、新型供应商短期采购擅长传统流程和项目才能擅长新型和未知项目长期的（月）周期短期的（天/周）敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法。q子子项项目特征目特征 - 各个子项目的成果都经过测试各个子项目的成果都经过测试 - 具备集成和可运行的特征具备集成和可运行的特征 - 小项目相互联系小项目相互联系在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可
4、运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 双模式可以用来开发不同的应用系统变化change管理Governance-+-创新型系统差异型系统记录型系统Systems of InnovationSystems of DifferentiationSystems of Record传统模式敏捷模式目录Catalog敏捷开发简介敏捷开发方法敏捷开发的注意事项敏捷方法 XP -eXtreme Programing极限编程: 思想源自Kent Beck和Ward Cunningham在软件项目中的合作经历。 SCRUM：
5、 是一种迭代的增量化过程，用于产品开发或工作管理 。 水晶方法Crystal: 由Alistair Cockburn在1990年代末提出。把不同类型的项目采用不同的方法。 FDD特性驱动 Feature Driven Development， 由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。 DSDM-Dynamic System Development Methodology， 它倡导以业务为核心，快速而有效地进行系统开发， 在英国等欧洲国家比
6、较流行。 ASD-Adaptive Software Development， 由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive） XP方法l极限的含义：软件开发中的优点发挥到极致(Kent Beck).lXP：给程序员提供了明确的方法，使得程序员尽管面对需求的改变，却能够从容应对，即使着重变化发生在项目的后期，仍然能够编出代码。lXP核心：沟通、简明、反馈和勇气 lXP重视沟通，客户、开发人员、管理者共同组成团队。Extreme ProgrammingXP的关键实践结对编程测试驱动开发重构简单设计代码集体所有编码标准稳定高速的步伐持续集成隐喻现场
7、客户完整的团队小规模发布计划游戏编程方法小组实践交付和管理XP特点1完整的团队l所有的小组成员应在同一个工作地点工作。l成员中必须有一个用户代表（On-site User）,由他/她来提出需求，确定开发优先级，把握开发的动向。l通常还设一个教练（Coach）角色，来指导XP方法的实施及与外部的沟通协调等。l小组每个成员都应围绕用户代表，充分贡献自己的技能。 XP特点2计划游戏XP特点3现场客户 客户是Team成员，在开发现场和开发人员一起工作。 传统的客户任务一般是讲解需求，运行验收测试，接收发布的系统。XP新增加的任务： (1) 写User Story (2) 评估User Story的商业
8、优先级 (3) 为每个User Story定义验收测试 (4) 计划开发内容 (5) 调控开发过程 (6) 建立商业模型，把隐藏在客户需求下的原则传授给开发人员 (8) 程序员分担任务的过程支解了对他们商业模型的理解 (9) 参加设计过程 (10)和程序员一起找出Metaphor，导引设计方向 (11)在Metaphor的帮助下，定义更有效更实际的功能测试，给程序员的设计制定了规范XP特点4小规模发布降低开发风险。 保证客户有足够的依据调控开发过程(增加、删除或改变User Story)。客户使用发布的系统，可以保证频繁地反馈和交流。 发布过程应该尽可能地自动化、规范化。不断地发布可用的系统可
9、以告诉客户你在做正确的事情。低风险智能化适应调整频繁交流知会客户频繁发布经过验证 随着开发的推进，发布越来越频繁。 所有的发布都要经过功能测试。Scrum方法Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队（7人以下）高效的工作。【Scrum开发流程中的三大角色】产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指
10、定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 流程管理员（Scrum Master）主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。 开发团队（Scrum Team）主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在510人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。Scrum流程图如何进行Scrum开发？1、确定Product Backlog（按优先顺序排列的一个产品需求
11、列表）：这是由Product Owner 负责的Scrum Team根据Product Backlog列表，做工作量的预估和安排；2、 Sprint Backlog：通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是14个星期，然后把这个Story进行细化，形成一个Sprint Backlog；每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）3、Daily Scrum Meeting（每日站立会议）：每次站立会议控制在15分钟左右，每个人都必须发言，
12、并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；4、每日集成：也就是每天都要有一个可以成功编译、并且可以演示的版本；支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存，中间有任何失败，都会用邮件通知项目管理人员；5、 Srpint Review Meeting（演示会议）：当一个Story完成，也就是Sprin
13、t Backlog被完成，这时要进行评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；6、Sprint Retrospective Meeting（回顾会议）：也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；Scrum开发中的产品BackLogScrum开发中的Sprint BacklogScrum开发中的Daily Scrum Meeting目录Catalog敏捷开发简介敏捷开发方法敏捷开发的注意事项敏捷开发的误区误区一：
14、敏捷是一个”过程误区二：敏捷仅是个软件过程误区三：敏捷是反文档的误区五：重做就是重构误区四：为了敏捷而敏捷敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷价值观，遵循敏捷的原则。最高目标是能持续地、及早地向客户交付软件；拥抱变化；频繁地发布可运行的软件；客户和开发人员在一起工作；以人为本；最重要的衡量开发过程的手段，是可工作的软件；稳定的开发速度；敏捷高效的设计；简单有效；重视Teamwork；积极的调整。误区一：敏捷是“一个”过程敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。 涉及到人的问题，就已经
15、不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍： 把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。 把人的能动性调动起来，给动力而不是给压力。要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。 没有绝对的权威，每个人都有可取之处。 误区二：敏捷仅是个软件过程文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟
16、不同的人重复表述同样的想法，那样更是低效的。 应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。 文档不是目的，有效沟通才是目的。 误区三：敏捷是反文档的“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录： Q：“我们现有的过程很好，不知道怎么用敏捷改进?” A：“既然很好，那就不要用敏捷”。 做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。 误区四：为了敏捷而敏捷重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。 误区五：重做就是重构谢谢!
