趋势从传统到敏捷

趋势从传统到敏捷第1页，课件共61页，创作于2023年2月趋势1970年软件开发瀑布模型发布 1975年《人月神话》第一版1984年SEI成立 1987年《人件》出版

1991年CMM体系发布 1991年Scrum首次命名1995年ISO/IEE12207发布 1995年Scrum论文首次发表1996年RUP首次提出 1996年第一个正式XP项目1999年准CMM2.0完成－未发布

2000年持续集成方法被提出2002年CMMI1.1发布 2001年敏捷联盟成立第2页，课件共61页，创作于2023年2月CONTENTS软件项目管理Scrum框架介绍》》行业和市场变迁自组织项目团队和敏捷第3页，课件共61页，创作于2023年2月软件项目管理项目管理起源：第4页，课件共61页，创作于2023年2月传统项目管理代表性技术：关键性途径方法（CriticalPathMethod）和项目评估和反思（PERT）技术。CPM美国杜邦公司和兰德公司，1957年联合研究提出它假设每项活动的作业时间是确定值重点在于费用和成本的控制。PERT美国海军特种计划局和洛克希德航空公司，1958年用概率的方法进行估计的估算，重点在于时间控制被主要应用于含有大量不确定因素的大规模开发研究项目。软件项目管理第5页，课件共61页，创作于2023年2月1986年11月，美国卡内基.梅隆大学软件研究所（SEI）受美国国防部的委托1987年9月开发了一套软件能力成熟度框架和一套软件成熟度问卷，用来评估软件供应商的能力。1991年，SEI自己总结了软件过程能力成熟度模型（CapacityMaturityModel-CMM）成熟度框架和初版并以此为基础推出CMM1.0版。1992年4月，SEI举行了CMM一个的研讨会，参加研讨会的有大约200名富有经验的软件专家。1997年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM）1997年11月，CMM2完成改进版，99年完成准CMM2.0，1999年，美国国防部办公室要求SEI推迟发布CMM2.0版本，而要先完成一个更为紧迫的项目CMMI。（即能力成熟度集成模型，他们想把现在所有的以及将被发展出来的各种能力成熟度模型集成到一个框架中去2002年，CMMI1.1发布软件项目管理－SEI的研究7/27/2023第6页，课件共61页，创作于2023年2月软件项目管理－能力成熟度模型第7页，课件共61页，创作于2023年2月软件项目管理－能力成熟度模型CMM中的关键过程域第2级(可重复级)，6个过程域

需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)、软件质量保证(SQA)、软件配置管理(SCM)第3级(定义级)，7个过程域

组织过程焦点(OPF)、组织过程定义(OPD)、培训程序(TP)、集成软件管理(ISM)、软件产品工程(SPE)、组间协调(IC)、同级评审(PR)第4级(管理级)，2个过程域

定量过程管理(QPM)、软件质量管理(SQM)第5级(优化级)，3个过程域

缺陷预防(DP)、技术变更管理(TCM)、过程变更管理(PCM)第8页，课件共61页，创作于2023年2月软件项目管理9项目计划WBS分解工作量估算、规模估算关键路径设定业务类子计划：架构、开发、测试；过程类子计划：配置、质量保证；协作类子计划：评审、沟通、……项目跟踪持续度量、纠偏工作量投入、产出变更项目总结项目度量项目考核和评价第9页，课件共61页，创作于2023年2月CONTENTS软件项目管理Scrum框架介绍》》行业和市场变迁自组织项目团队和敏捷第10页，课件共61页，创作于2023年2月IT行业的变化－80年代前信息技术（InformationTechnology）传感技术这是人的感觉器官的延伸与拓展，最明显的例子是条码阅读器；通信技术这是人的神经系统的延伸与拓展，承担传递信息的功能；计算机技术这是人的大脑功能延伸与拓展，承担对信息进行处理的功能。主要客户

大型企业和政府：军工、制造、能源、金融、政府管理核心价值

缩短信息处理时间

减少信息处理的人力投入

提高信息处理的准确率信息的创造者和使用者：

政府机构人、企业人7/27/2023第11页，课件共61页，创作于2023年2月IT行业的变化－00年代后互联网技术（internetTechnology）硬件技术－主要指数据存储、处理和传输的主机和网络通信设备；软件技术－搜索、网络传输、网络安全、通讯、流媒体、网站部署、电子交易……主要客户

客户和用户分离

向用户提供软件和服务；并销售用户访问流量

典型例子：搜索引擎，向所有人提供无差异的搜索服务，并向所有客户出售广告位。核心价值

消费信息－－普遍的、无差异的信息服务－－长尾经济信息的创造者和使用者：

自然人、法人、社会人、机器人、……长尾(TheLongTail)：图中所示黄色的部份第12页，课件共61页，创作于2023年2月软件供应商的变化－业务领域7/27/2023定制信息服务

为单一/相似客户提供信息化实现服务，依托计算设备硬件更新、提供配套软件，改善企业或机构数据处理效率。

以项目/施工形式运作，一揽子交付制度（客户安装、调试、培训、观察和稳定、附送维护期）

典型例子：美国国防部70年代广泛的不靠谱项目为行业提供解决方案

当信息计算在各企业普及后，为某个明确的领域或行业提供广泛的技术解决方案 IBMPC和WindowsPS的大量普及，软件供应商在定制服务中积累了大量行业知识，结合各专业领域研究机构的理论，逐渐形成全行业通用的解决方案、IT技术和方法得以大规模复制。

典型例子：依据生产管理理论提出的MRP、ERP等解决方案第13页，课件共61页，创作于2023年2月软件供应商的变化－角色定位销售许可

为企业/行业提供业务逻辑、计算、存储等方案，以软件销售为主要业务。

典型案例：WindowsOS、MSOffice、OracleDB基础设施即服务（InfrastructureasaService，IaaS）

向客户提供处理、储存、网络以及各种基础运算资源，部署与执行操作系统或应用程式等各种软件。

典型案例：域服务、云存储、电子邮件等软件即服务（SoftwareasaService，SaaS

）

向企业、行业提供远程计算、信息存储、数据交易等服务，按照使用时间或次数等收费费用。不需要安装，客户直接注册购买服务。

典型案例：

S第14页，课件共61页，创作于2023年2月软件开发团队的变迁（一）从作坊到车间

作坊：人数较少，简单的组织结构、粗放的管理方法，以项目为驱动，缺少工程方法支撑、过程控制基本没有。

车间：人数增多，从单一开发工程师，逐渐分离出测试人员，设定了一定的规则，引入测试缺陷管理工具等，从游击队到正规军

游击队：开发工具简单，作业流程就是拿到需求开发，工程师在战斗中学会战斗，都是自学成长型战士，缺乏组织系统化的培训，团队整合靠缘分。组织方式以职能部门为主。

正规军：组织使用专业工具、专人维护，具备稳定的作业流程、组织有明确的工程师职业培训制度，注重工程师的绩效和激励，项目管理制度化、系统化。组织方式以矩阵制为主。第15页，课件共61页，创作于2023年2月软件开发团队的变迁（二）大规模软件集成开发

决策：决策周期相对更长，考虑更多，更保守

分工：规模越大、专业越细分、单一职能工程师类型越多

组织：管理层金字塔结构明显，管理岗位增加

工具化：更广泛使用专业工具，更严密地过程控制

矩阵：职能管理者掌握更多人力资源，项目管理者需要持续争取资源

团队：通常距离市场都非常遥远，向行政上级汇报的趋势明显第16页，课件共61页，创作于2023年2月互联网时代的挑战不谈技术

无论客户、还是用户，对技术的关心越来越少，对他们而言，提供什么样的服务比使用了什么样的技术更靠谱耐心有限

可供选择的产品和服务越来越多

所需要投入的学习和转换成本越来越低

不再关注功能是否足够多

比质量更重要的是更新速度第17页，课件共61页，创作于2023年2月CONTENTS软件项目管理Scrum框架介绍Scrum实践之旅》》行业和市场变迁自组织项目团队和敏捷第18页，课件共61页，创作于2023年2月探索的趋势企业关注的

标准：尽可能让工程师做有标准的工作，这样看起来更容易评估成果。

数据积累：更多的数据积累有助于形成标准，并进而为管理提供易操作的判断依据。

效率：从管理要效益，采用合适的管理方法，帮助管理者更透明的了解团队的工作，并做出最佳决策。团队关注的

战斗力：保持持久的团队战斗力，不干扰团队成员的工作，不当的管理会影响战斗力。

经验：有经验的工程师可以更快的解决问题，他们的经验上升为把握风险的直觉，工程师有能力判断风险并采用自己的方法来避免更出现更糟糕的结果

效率：采用更新的技术工具和方法，把工程师从简单劳动中解放出来，做有价值的事情，避免管理活动上消耗工程师精力第19页，课件共61页，创作于2023年2月趋势－传统VS敏捷传统

命令型

显式知识（依赖文档）

计划驱动

自上而下

控制为主要手段敏捷

自组织

隐式知识（经验）

变更驱动

自上而下

应变为主要手段敏捷不是新鲜事物第20页，课件共61页，创作于2023年2月趋势－20年软件工程标志性事件摘录1970年软件开发瀑布模型发布 1975年《人月神话》第一版1984年SEI成立 1987年《人件》出版

1991年CMM体系发布 1991年Scrum首次命名1995年ISO/IEE12207发布 1995年Scrum论文首次发表1996年RUP首次提出 1996年第一个正式XP项目1999年准CMM2.0完成－未发布

2000年持续集成方法被提出2002年CMMI1.1发布 2001年敏捷联盟成立第21页，课件共61页，创作于2023年2月敏捷宣言22第22页，课件共61页，创作于2023年2月敏捷宣言个体和交互

胜过

过程和工具可以工作的软件

胜过

面面俱到的文档客户合作

胜过

合同谈判响应变化

胜过

遵循计划服务的对象始终是用户责任导向成果导向第23页，课件共61页，创作于2023年2月敏捷的意识《人月神话》-1975第5章画蛇添足在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。

在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。

第二个系统是设计师们所设计的最危险的系统。

第15章另外一面面对那些文档“简约”的程序，我们中的大多数人都不免曾经暗骂那些远在他方的匿名作者。因此，一些人试图向新人慢慢地灌输文档的重要性：旨在延长软件的生命期、克服惰性和进度的压力。但是，很多次尝试都失败了，我想很可能是由于我们使用了错误的方法。第24页，课件共61页，创作于2023年2月敏捷的意识《人件》－1987第5章重新研究帕金森定律帕金森定律表明：只要还有时间，工作就会不断扩展，直到用完所有的时间。帕金森定律认为给一个项目多少时间，它总能将之消耗完。这个定律给了他们（经理）可能最坚强的信念：把工作做好的唯一方法是制订一个不可能的、乐观的交付时间。帕金森定律几乎肯定不适用于你的员工。当一个项目完全不合理或不现实的时候，不能再加班加点。项目组的成员会产生愤怒的情绪并在内心滋生一种挫败感——并且士气会降到谷底。——卡帕斯·琼斯（CapersJones）公司繁忙的工作有膨胀填满工作日的趋势。注：帕金森定律（Parkinson'sLaw）是官僚主义或官僚主义现象的一种别称,源于英国学者C.N.帕金森所著《帕金森定律》一书的标题第25页，课件共61页，创作于2023年2月敏捷的意识《人件》－1987第6章苦杏仁苷软件管理的七个不真实的期望：有使你的生产力剧增的新诀窍，你已经错过了。其他经理的成效是正100%、200%或者更多。技术正飞快发展，而你正在被淘汰。改变语言将使你收获巨大。因为待做的项目堆积如山，你需要立即加倍地提高生产力、其他任何事情你都顺其自然，是不是你对手下的软件开发人员也放任自由。如果将你手下的人置于很大的压力下，他们会工作得更好。第26页，课件共61页，创作于2023年2月敏捷的12条原则（一）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意；我们欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化；经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；业务人员和开发人员必须相互合作，项目中的每一天都不例外；激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标；不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；第27页，课件共61页，创作于2023年2月敏捷的12条原则（二）可以工作的软件是进度的首要度量标准；敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续；坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强；以简洁为本，它是极力减少不必要工作量的艺术；最好的架构、需求和设计出自自组织团队；团队定期地反思如何能提高成效，并依此调整自身的行动。第28页，课件共61页，创作于2023年2月自组织团队特征（一）开放性

作为自组织团队，体现开放性的最基本活动是与外界的信息交换，信息互动沟通的模式和效果，不但影响自组织团队的工作效率，而且会决定自组织团队的演变过程和涌现结果;自主性

自组织就是没有外界特定的干涉。换句话说，就是自己决定自己的事情，不需要外界的干预。作为自组织团队，其行为决策完全由自己决定，而不受外界干预;适应性

自组织团队具有适应性，是指它能够与外界交流，通过交流来学习或积累经验，并利用学到的经验改变自身的结构和行为方式，推动团队的发展和进步。7/27/2023第29页，课件共61页，创作于2023年2月自组织团队特征（二）复杂性

“适应性造就复杂性”。从自组织团队定义、自组织团队形成过程、自组织团队演化方面呈现出复杂性；非线性

非线性表现在团队成员之间的相互关系上，使团队成员形成复杂的关系网络，非线性也使团队中的成员能够依一定规则或程序而相互制约和相互监督，使团队中每一个成员不至于做出超越管理权限的行为而损害整个组织。动态性

动态性是指自组织团队从形成、成长、成熟到消亡的整个生命周期过程是动态变化的，即使在每一个阶段，也是动态变化的。远离平衡态，新情况和新问题随时都可能发生。如果没有变化，该团队就离消亡不远了7/27/2023第30页，课件共61页，创作于2023年2月自组织团队VS管理惯性1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式 2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间第31页，课件共61页，创作于2023年2月CONTENTS软件项目管理Scrum框架介绍》》行业和市场变迁自组织项目团队和敏捷第32页，课件共61页，创作于2023年2月什么是SCRUMScrum是唯一的敏捷项目管理方法Scrum是一个框架，在这个框架中人们可以应对复杂的适应性问题，同时也能颇有成效地和具有创造性地交付最高价值的产品。Scrum是：轻量级的容易理解的极难驾驭的Scrum框架包括角色事件工件规则第33页，课件共61页，创作于2023年2月SCRUM框架第34页，课件共61页，创作于2023年2月SCRUM框架角色ProductOwnerDevlopmentTeamScrumMaster第35页，课件共61页，创作于2023年2月SCRUM角色ProductOwner负责最大化产品以及开发团队工作的价值是管理产品待办事项列表的唯一责任人。清晰地表达产品代办事项列表条目对产品代办事项列表中的条目进行排序，最好地实现目标和使命确保开发团队所执行工作的价值确保产品代办事项列表对所有人可见、透明、清晰，并且显示Scrum团队的下一步工作确保开发团队对产品代办事项列表中的条目达到一定程度的理解第36页，课件共61页，创作于2023年2月SCRUM角色DevlopmentTeam开发团队包含了专业人员，负责在每个Sprint的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。开发团队由组织构建并授权，来组织和管理他们的工作。所产生的协同工作能最大化开发团队的整体效率和效力。开发团队有以下几个特点：自组织的跨功能的每个成员可以有特长和专注领域，但是责任归属于整个开发团队开发团队不包含如测试或业务分析等负责特定领域的子团队。第37页，课件共61页，创作于2023年2月SCRUM角色ScrumMaster负责确保Scrum被理解并实施。帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的。通过改变这些交互来最大化Scrum团队所创造的价值第38页，课件共61页，创作于2023年2月SCRUM角色ScrumMaster之对于PO找到有效管理产品代办事项列表的技巧清晰地和开发团队沟通愿景、目标和产品代表事项列表条目教导开发团队创建清晰简明的产品代表事项列表条目在经验主义环境中理解长期的产品规划理解并实践敏捷按需推动Scrum事件第39页，课件共61页，创作于2023年2月SCRUM角色ScrumMaster之对于DevelopmentTeam指导开发团队自组织和跨功能教导并领导开发团队创造高价值的产品移除开发团队进展过程中的障碍按需推动Scrum事件在Scrum还未完全被采纳和理解的组织环境下指导开发团队第40页，课件共61页，创作于2023年2月SCRUM角色ScrumMaster之对于组织领导并指导组织采用Scrum在组织范围内计划Scrum的实施帮助员工及干系人理解并实施Scrum和经验性产品开发触发能增长Scrum团队生产力的改变与其他ScrumMaster一起工作，来增加组织中Scrum应用的效力第41页，课件共61页，创作于2023年2月SCRUM框架Scrum事件SprintSprint计划会议每日立会Sprint评审Sprint回顾第42页，课件共61页，创作于2023年2月SCRUM事件SprintScrum的核心是控制在一个时间盒单元中，产出“完成”的、可用的、潜在可发布的产品增量。Sprint在整个开发过程中的周期一致。新的Sprint在上一个Sprint完成之后立即开始。Sprint包含并由Sprint计划会议、每日例会、开发工作、Sprint评审会议和Sprint回顾会议构成。Sprint中不能做出影响Sprint目标的改变开发团队的组成和质量目标是不变的随着知识的增加，产品负责人和开发团队可以澄清或者重新商谈开发范围第43页，课件共61页，创作于2023年2月SCRUM事件Sprint计划会议分成两部分第44页，课件共61页，创作于2023年2月SCRUM事件每日立会保证24小时内的计划立会不是进度汇报不超过15分钟每人描述三个问题，保证增量目标从上次会议到现在都完成了哪些工作；下次每日例会之前准备完成什么；工作中遇到了哪些障碍。第45页，课件共61页，创作于2023年2月SCRUM事件Sprint评审会检验增量交付引发反馈主要因素产品负责人确定哪些工作“完成”了，哪些工作没有“完成”开发团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的开发团队演示“完成”的工作并解答关于所交付增量的问题产品负责人和与会人员按现实情况讨论产品待办事项列表，并基于当前的进度推测可能的完成日期整个团体就下一步的工作进行探讨，这样，Sprint评审会议就能为接下来的Sprint计划会议提供了有价值的信息。第46页，课件共61页，创作于2023年2月SCRUM事件Sprint回顾会Scrum团队检验自身并创建下个Sprint改进计划的机会Sprint回顾会议的目的是：对前一个Sprint周期中的人、关系、过程和工具进行检验识别并排序做得好的和能潜在改进的主要条目创建实施改进Scrum团队工作方式的计划第47页，课件共61页，创作于2023年2月SCRUM框架Scrum工件ProductBacklogSprintBacklogIncrement(增量)第48页，课件共61页，创作于2023年2月SCRUM工件ProductBacklog字面意思：积压的工作、待办事宜PO负责ProductBacklog的维护和更新常见的待办事宜包括但不局限于需求，可能的类型：功能特性缺陷技术工作知识获取Backlog的维护只要产品活着，Backlog就会持续更新仅仅就已知的事情来组织Backlog不假装知道“我们了解产品所有的需求”第49页，课件共61页，创作于2023年2月SCRUM工件ProductBacklogScrum中主流的方法是用户故事作为……（角色定位）我希望…………（诉求和期待）这样可以……（目的和价值）用户故事类型史诗：产品重要的里程碑主题：若干个Sprint完成的一组功能策划故事：产品功能，一个Sprint周期内实现第50页，课件共61页，创作于2023年2月PRODUCTBACKLOGProductBacklog史诗级：作为一个手机控我希望能够很方便地使用手机制作、收藏、分享gif文件这样本身就很有趣第51页，课件共61页，创作于2023年2月PRODUCTBACKLOGProductBacklog故事级：作为一个手机微博控我希望能够很方便地把