趋势从传统到敏捷幻灯片.ppt

趋势从传统到敏捷第1页，共61页，编辑于2022年，星期二趋势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页，编辑于2022年，星期二CONTENTS软件项目管理Scrum框架介绍行业和市场变迁自组织项目团队和敏捷第3页，共61页，编辑于2022年，星期二软件项目管理项目管理起源：第4页，共61页，编辑于2022年，星期二传统项目管理代表性技术：关键性途径方法（传统项目管理代表性技术：关键性途径方法（CriticalPathMethod）和项目评估和反思（）和项目评估和反思（PERT）技术。）技术。CPM美国杜邦公司和兰德公司，1957年联合研究提出它假设每项活动的作业时间是确定值重点在于费用和成本的控制。PERT美国海军特种计划局和洛克希德航空公司，1958年用概率的方法进行估计的估算，重点在于时间控制被主要应用于含有大量不确定因素的大规模开发研究项目。软件项目管理第5页，共61页，编辑于2022年，星期二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的研究10/7/2022第6页，共61页，编辑于2022年，星期二软件项目管理能力成熟度模型第7页，共61页，编辑于2022年，星期二软件项目管理能力成熟度模型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页，编辑于2022年，星期二软件项目管理9项目计划WBS分解工作量估算、规模估算关键路径设定业务类子计划：架构、开发、测试；过程类子计划：配置、质量保证；协作类子计划：评审、沟通、项目跟踪持续度量、纠偏工作量投入、产出变更项目总结项目度量项目考核和评价第9页，共61页，编辑于2022年，星期二CONTENTS软件项目管理Scrum框架介绍行业和市场变迁自组织项目团队和敏捷第10页，共61页，编辑于2022年，星期二IT行业的变化80年代前信息技术信息技术（InformationTechnology）传感技术这是人的感觉器官的延伸与拓展，最明显的例子是条码阅读器；通信技术这是人的神经系统的延伸与拓展，承担传递信息的功能；计算机技术这是人的大脑功能延伸与拓展，承担对信息进行处理的功能。主要客户主要客户大型企业和政府：军工、制造、能源、金融、政府管理核心价值核心价值缩短信息处理时间减少信息处理的人力投入提高信息处理的准确率信息的创造者和使用者：信息的创造者和使用者：政府机构人、企业人10/7/2022第11页，共61页，编辑于2022年，星期二IT行业的变化00年代后互联网技术（互联网技术（internetTechnology）硬件技术主要指数据存储、处理和传输的主机和网络通信设备；软件技术搜索、网络传输、网络安全、通讯、流媒体、网站部署、电子交易主要客户主要客户客户和用户分离向用户提供软件和服务；并销售用户访问流量典型例子：搜索引擎，向所有人提供无差异的搜索服务，并向所有客户出售广告位。核心价值核心价值消费信息普遍的、无差异的信息服务长尾经济信息的创造者和使用者：信息的创造者和使用者：自然人、法人、社会人、机器人、长尾长尾(TheLongTail)：图中所示：图中所示黄色的部份黄色的部份第12页，共61页，编辑于2022年，星期二软件供应商的变化业务领域10/7/2022定制信息服务定制信息服务为单一/相似客户提供信息化实现服务，依托计算设备硬件更新、提供配套软件，改善企业或机构数据处理效率。以项目/施工形式运作，一揽子交付制度（客户安装、调试、培训、观察和稳定、附送维护期）典型例子：美国国防部70年代广泛的不靠谱项目为行业提供解决方案为行业提供解决方案当信息计算在各企业普及后，为某个明确的领域或行业提供广泛的技术解决方案IBM PC和Windows PS的大量普及，软件供应商在定制服务中积累了大量行业知识，结合各专业领域研究机构的理论，逐渐形成全行业通用的解决方案、IT技术和方法得以大规模复制。典型例子：依据生产管理理论提出的MRP、ERP等解决方案第13页，共61页，编辑于2022年，星期二软件供应商的变化角色定位销售许可销售许可为企业/行业提供业务逻辑、计算、存储等方案，以软件销售为主要业务。典型案例：Windows OS、MS Office、Oracle DB基础设施即服务（基础设施即服务（InfrastructureasaService，IaaS）向客户提供处理、储存、网络以及各种基础运算资源，部署与执行操作系统或应用程式等各种软件。典型案例：域服务、云存储、电子邮件等软件即服务（软件即服务（SoftwareasaService，SaaS）向企业、行业提供远程计算、信息存储、数据交易等服务，按照使用时间或次数等收费费用。不需要安装，客户直接注册购买服务。典型案例：S第14页，共61页，编辑于2022年，星期二软件开发团队的变迁（一）从作坊到车间从作坊到车间作坊：人数较少，简单的组织结构、粗放的管理方法，以项目为驱动，缺少工程方法支撑、过程控制基本没有。车间：人数增多，从单一开发工程师，逐渐分离出测试人员，设定了一定的规则，引入测试缺陷管理工具等，从游击队到正规军从游击队到正规军游击队：开发工具简单，作业流程就是拿到需求开发，工程师在战斗中学会战斗，都是自学成长型战士，缺乏组织系统化的培训，团队整合靠缘分。组织方式以职能部门为主。正规军：组织使用专业工具、专人维护，具备稳定的作业流程、组织有明确的工程师职业培训制度，注重工程师的绩效和激励，项目管理制度化、系统化。组织方式以矩阵制为主。第15页，共61页，编辑于2022年，星期二软件开发团队的变迁（二）大规模软件集成开发大规模软件集成开发决策：决策周期相对更长，考虑更多，更保守分工：规模越大、专业越细分、单一职能工程师类型越多组织：管理层金字塔结构明显，管理岗位增加工具化：更广泛使用专业工具，更严密地过程控制矩阵：职能管理者掌握更多人力资源，项目管理者需要持续争取资源团队：通常距离市场都非常遥远，向行政上级汇报的趋势明显第16页，共61页，编辑于2022年，星期二互联网时代的挑战不谈技术不谈技术无论客户、还是用户，对技术的关心越来越少，对他们而言，提供什么样的服务比使用了什么样的技术更靠谱耐心有限耐心有限可供选择的产品和服务越来越多所需要投入的学习和转换成本越来越低不再关注功能是否足够多比质量更重要的是更新速度第17页，共61页，编辑于2022年，星期二CONTENTS软件项目管理Scrum框架介绍Scrum实践之旅行业和市场变迁自组织项目团队和敏捷第18页，共61页，编辑于2022年，星期二探索的趋势企业关注的企业关注的标准：尽可能让工程师做有标准的工作，这样看起来更容易评估成果。数据积累：更多的数据积累有助于形成标准，并进而为管理提供易操作的判断依据。效率：从管理要效益，采用合适的管理方法，帮助管理者更透明的了解团队的工作，并做出最佳决策。团队关注的团队关注的战斗力：保持持久的团队战斗力，不干扰团队成员的工作，不当的管理会影响战斗力。经验：有经验的工程师可以更快的解决问题，他们的经验上升为把握风险的直觉，工程师有能力判断风险并采用自己的方法来避免更出现更糟糕的结果效率：采用更新的技术工具和方法，把工程师从简单劳动中解放出来，做有价值的事情，避免管理活动上消耗工程师精力第19页，共61页，编辑于2022年，星期二趋势传统VS敏捷传统传统命令型显式知识（依赖文档）计划驱动自上而下控制为主要手段敏捷敏捷自组织隐式知识（经验）变更驱动自上而下应变为主要手段敏捷不是新鲜事物敏捷不是新鲜事物第20页，共61页，编辑于2022年，星期二趋势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页，编辑于2022年，星期二敏捷宣言敏捷宣言22第22页，共61页，编辑于2022年，星期二敏捷宣言敏捷宣言个体和交互个体和交互 胜过胜过过程和工具过程和工具可以工作的软件可以工作的软件 胜过胜过面面俱到的文档面面俱到的文档客户合作客户合作 胜过胜过合同谈判合同谈判响应变化响应变化 胜过胜过遵循计划遵循计划服务的对象始终是用户责任责任责任责任导向导向导向导向成果成果导向导向第23页，共61页，编辑于2022年，星期二敏捷的意识人月神话人月神话-1975第第5章章画蛇添足画蛇添足在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。第二个系统是设计师们所设计的最危险的系统。第第15章章另外一面另外一面面对那些文档“简约”的程序，我们中的大多数人都不免曾经暗骂那些远在他方的匿名作者。因此，一些人试图向新人慢慢地灌输文档的重要性：旨在延长软件的生命期、克服惰性和进度的压力。但是，很多次尝试都失败了，我想很可能是由于我们使用了错误的方法。第24页，共61页，编辑于2022年，星期二敏捷的意识人件人件1987第第5章章重新研究帕金森定律重新研究帕金森定律帕金森定律表明：只要还有时间，工作就会不断扩展，直到用完所有的时间。帕金森定律认为给一个项目多少时间，它总能将之消耗完。这个定律给了他们（经理）可能最坚强的信念：把工作做好的唯一方法是制订一个不可能的、乐观的交付时间。帕金森定律几乎肯定不适用于你的员工。当一个项目完全不合理或不现实的时候，不能再加班加点。项目组的成员会产生愤怒的情绪并在内心滋生一种挫败感并且士气会降到谷底。卡帕斯琼斯（Capers Jones）公司繁忙的工作有膨胀填满工作日的趋势。注：帕金森定律（ParkinsonsLaw）是官僚主义或官僚主义现象的一种别称,源于英国学者C.N.帕金森所著帕金森定律一书的标题第25页，共61页，编辑于2022年，星期二敏捷的意识人件人件1987第第6章章苦杏仁苷苦杏仁苷软件管理的七个不真实的期望：有使你的生产力剧增的新诀窍，你已经错过了。其他经理的成效是正100%、200%或者更多。技术正飞快发展，而你正在被淘汰。改变语言将使你收获巨大。因为待做的项目堆积如山，你需要立即加倍地提高生产力、其他任何事情你都顺其自然，是不是你对手下的软件开发人员也放任自由。如果将你手下的人置于很大的压力下，他们会工作得更好。第26页，共61页，编辑于2022年，星期二敏捷的12条原则（一）1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意；2.我们欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化；3.经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期；4.业务人员和开发人员必须相互合作，项目中的每一天都不例外；5.激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标；6.不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；第27页，共61页，编辑于2022年，星期二敏捷的12条原则（二）7.可以工作的软件是进度的首要度量标准；8.敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续；9.坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强；10.以简洁为本，它是极力减少不必要工作量的艺术；11.最好的架构、需求和设计出自自组织团队；12.团队定期地反思如何能提高成效，并依此调整自身的行动。第28页，共61页，编辑于2022年，星期二自组织团队特征（一）开放性开放性作为自组织团队，体现开放性的最基本活动是与外界的信息交换，信息互动沟通的模式和效果，不但影响自组织团队的工作效率，而且会决定自组织团队的演变过程和涌现结果;自主性自主性自组织就是没有外界特定的干涉。换句话说，就是自己决定自己的事情，不需要外界的干预。作为自组织团队，其行为决策完全由自己决定，而不受外界干预;适应性适应性自组织团队具有适应性，是指它能够与外界交流，通过交流来学习或积累经验，并利用学到的经验改变自身的结构和行为方式，推动团队的发展和进步。10/7/2022第29页，共61页，编辑于2022年，星期二自组织团队特征（二）复杂性复杂性“适应性造就复杂性”。从自组织团队定义、自组织团队形成过程、自组织团队演化方面呈现出复杂性；非线性非线性非线性表现在团队成员之间的相互关系上，使团队成员形成复杂的关系网络，非线性也使团队中的成员能够依一定规则或程序而相互制约和相互监督，使团队中每一个成员不至于做出超越管理权限的行为而损害整个组织。动态性动态性动态性是指自组织团队从形成、成长、成熟到消亡的整个生命周期过程是动态变化的，即使在每一个阶段，也是动态变化的。远离平衡态，新情况和新问题随时都可能发生。如果没有变化，该团队就离消亡不远了10/7/2022第30页，共61页，编辑于2022年，星期二自组织团队VS管理惯性1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间第31页，共61页，编辑于2022年，星期二CONTENTS软件项目管理Scrum框架介绍行业和市场变迁自组织项目团队和敏捷第32页，共61页，编辑于2022年，星期二什么是SCRUMScrum是唯一的敏捷项目管理方法Scrum是一个框架，在这个框架中人们可以应对复杂的适应性问题，同时也能颇有成效地和具有创造性地交付最高价值的产品。Scrum是：轻量级的容易理解的极难驾驭的Scrum框架包括u角色u事件u工件u规则第33页，共61页，编辑于2022年，星期二SCRUM框架第34页，共61页，编辑于2022年，星期二SCRUM框架角色角色ProductOwnerDevlopmentTeamScrumMaster第35页，共61页，编辑于2022年，星期二SCRUM角色ProductOwner负责最大化产品以及开发团队工作的价值是管理产品待办事项列表的唯一责任人。清晰地表达产品代办事项列表条目 对产品代办事项列表中的条目进行排序，最好地实现目标和使命 确保开发团队所执行工作的价值 确保产品代办事项列表对所有人可见、透明、清晰，并且显示 Scrum 团队的下一步工作 确保开发团队对产品代办事项列表中的条目达到一定程度的理解 第36页，共61页，编辑于2022年，星期二SCRUM角色DevlopmentTeam开发团队包含了专业人员，负责在每个 Sprint 的结尾交付潜在可发布的“完成”产品增量。只有开发团队的成员才能创造增量。开发团队由组织构建并授权，来组织和管理他们的工作。所产生的协同工作能最大化开发团队的整体效率和效力。开发团队有以下几个特点：n自组织的n跨功能的n每个成员可以有特长和专注领域，但是责任归属于整个开发团队 n开发团队不包含如测试或业务分析等负责特定领域的子团队。第37页，共61页，编辑于2022年，星期二SCRUM角色ScrumMaster负责确保Scrum被理解并实施。帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的。通过改变这些交互来最大化Scrum团队所创造的价值第38页，共61页，编辑于2022年，星期二SCRUM角色ScrumMaster之对于之对于PO找到有效管理产品代办事项列表的技巧清晰地和开发团队沟通愿景、目标和产品代表事项列表条目教导开发团队创建清晰简明的产品代表事项列表条目在经验主义环境中理解长期的产品规划理解并实践敏捷按需推动Scrum事件第39页，共61页，编辑于2022年，星期二SCRUM角色ScrumMaster之对于之对于DevelopmentTeam指导开发团队自组织和跨功能教导并领导开发团队创造高价值的产品移除开发团队进展过程中的障碍按需推动Scrum事件在Scrum还未完全被采纳和理解的组织环境下指导开发团队第40页，共61页，编辑于2022年，星期二SCRUM角色ScrumMaster之对于组织之对于组织领导并指导组织采用Scrum在组织范围内计划Scrum的实施帮助员工及干系人理解并实施Scrum和经验性产品开发触发能增长Scrum团队生产力的改变与其他ScrumMaster一起工作，来增加组织中Scrum应用的效力第41页，共61页，编辑于2022年，星期二SCRUM框架Scrum事件事件SprintSprint计划会议每日立会Sprint评审Sprint回顾第42页，共61页，编辑于2022年，星期二SCRUM事件SprintScrum的核心是控制在一个时间盒单元中，产出“完成”的、可用的、潜在可发布的产品增量。Sprint在整个开发过程中的周期一致。新的Sprint在上一个Sprint完成之后立即开始。Sprint包含并由Sprint计划会议、每日例会、开发工作、Sprint评审会议和Sprint回顾会议构成。Sprint中不能做出影响Sprint目标的改变开发团队的组成和质量目标是不变的随着知识的增加，产品负责人和开发团队可以澄清或者重新商谈开发范围第43页，共61页，编辑于2022年，星期二SCRUM事件Sprint计划会议计划会议分成两部分第44页，共61页，编辑于2022年，星期二SCRUM事件每日立会每日立会保证24小时内的计划立会不是进度汇报不超过15分钟每人描述三个问题，保证增量目标从上次会议到现在都完成了哪些工作；下次每日例会之前准备完成什么；工作中遇到了哪些障碍。第45页，共61页，编辑于2022年，星期二SCRUM事件Sprint评审会检验增量交付引发反馈主要因素u产品负责人确定哪些工作“完成”了，哪些工作没有“完成”u开发团队讨论在 Sprint 中哪些工作进展顺利、遇到了什么问题、问题是如何解决的 u开发团队演示“完成”的工作并解答关于所交付增量的问题 u产品负责人和与会人员按现实情况讨论产品待办事项列表，并基于当前的进度推测可能的完成日期 u整个团体就下一步的工作进行探讨，这样，Sprint 评审会议就能为接下来的 Sprint计划会议提供了有价值的信息。第46页，共61页，编辑于2022年，星期二SCRUM事件Sprint回顾会Scrum团队检验自身并创建下个Sprint改进计划的机会Sprint回顾会议的目的是：对前一个 Sprint 周期中的人、关系、过程和工具进行检验 识别并排序做得好的和能潜在改进的主要条目 创建实施改进 Scrum 团队工作方式的计划 第47页，共61页，编辑于2022年，星期二SCRUM框架Scrum工件工件ProductBacklogSprintBacklogIncrement(增量)第48页，共61页，编辑于2022年，星期二SCRUM工件ProductBacklog字面意思：积压的工作、待办事宜PO负责Product Backlog的维护和更新常见的待办事宜包括但不局限于需求，可能的类型：功能特性缺陷技术工作知识获取Backlog的维护只要产品活着，Backlog就会持续更新仅仅就已知的事情来组织Backlog不假装知道“我们了解产品所有的需求”第49页，共61页，编辑于2022年，星期二SCRUM工件ProductBacklogScrum中主流的方法是用户故事作为（角色定位）我希望（诉求和期待）这样可以（目的和价值）用户故事类型史诗：产品重要的里程碑主题：若干个Sprint完成的一组功能策划故事：产品功能，一个Sprint周期内实现第50页，共61页，编辑于2022年，星期二PRODUCTBACKLOGProductBacklog史诗级：作为一个手机控我希望能够很方便地使用手机制作、收藏、分享gif文件这样本身就很有趣第51页，共61页，编辑于2022年，星期二PRODUCTBACKLOGProductBacklog故事级：作为一个手机微博控我希望能够很方便地把我制作和收藏的gif文件，用于我的微博上这样我的微博能够有更多表现力，我的创造性也能体现第52页，共61页，编辑于2022年，星期二PRODUCTBACKLOGProductBacklog主题级：作为一个手机微博控。我希望能搞出好玩的场景这样会有更多乐趣第53页，共61页，编辑于2022年，星期二SPRINTBACKLOGSprintBacklog在一个固定TimeBox中的待办事项必须足够具体可以实施在Sprint内尽可能避免把ProductBacklog的内容添加进来禁止把不在ProductBacklog中的东西放到Sprint。第54页，共61页，编辑于2022年，星期二SPRINTBACKLOGSprintBacklog每天计算剩余工作量不要尝试用太小的时间粒度来度量Team内尽可能不要采用类似“完成了80”这样的表达方式Scrum不考虑已经花在Sprint待办事项列表上的工作时间。我们只关心剩余工作和日期这两个变量。必须足够具体可以实施第55页，共61页，编辑于2022年，星期二Increment(增量)Increment(增量)增量是一个Sprint及以前所有Sprint中完成的所有产品代办事项列表条目的总和。每一个Sprint结束，新的增量被确认完成即使不正式发布，增量是必须是可用的、可演示的Sprint1Sprint2Sprint3Sprint4Sprint5Sprint6Increment第56页，共61页，编辑于2022年，星期二SCRUM框架Scrum的框架归根结底是两个的框架归根结底是两个PDCA1、每、每24小时小时2、每、每Sprint第57页，共61页，编辑于2022年，星期二SCRUM价值观承诺承诺：乐于对目标做出承诺。：乐于对目标做出承诺。Scrum为人们提供实现承诺所需的所有权限。为人们提供实现承诺所需的所有权限。专注专注：做自己的工作。把所有精力和技巧专注于你所承诺的工作上。：做自己的工作。把所有精力和技巧专注于你所承诺的工作上。不用担心其他事情。不用担心其他事情。开放开放：Scrum中与项目相关的每件事对所有人都是可见的。中与项目相关的每件事对所有人都是可见的。尊重尊重：背景和经验塑造出不同的个体。对团队中不同的人保持尊重非常重：背景和经验塑造出不同的个体。对团队中不同的人保持尊重非常重要。要。勇气勇气：有承诺的勇气、行动的勇气、开放的勇气和期望得到尊重的勇：有承诺的勇气、行动的勇气、开放的勇气和期望得到尊重的勇气（气（Schwaber和和Beedle2001）。）。第58页，共61页，编辑于2022年，星期二SCRUM应用第59页，共61页，编辑于2022年，星期二没有银弹敏捷不是，SCRUM也不是第60页，共61页，编辑于2022年，星期二谢谢第61页，共61页，编辑于2022年，星期二