趋势-从传统到敏捷

《趋势-从传统到敏捷》由会员分享，可在线阅读，更多相关《趋势-从传统到敏捷（61页珍藏版）》请在金锄头文库上搜索。

1、趋势,从传统到敏捷,泥泥 2012.06,趋势,1970年软件开发瀑布模型发布 1975 年人月神话第一版 1984年SEI成立 1987年人件出版 1991年CMM体系发布 1991年Scrum首次命名 1995年ISO/IEE12207发布 1995年Scrum论文首次发表 1996年RUP首次提出 1996年第一个正式XP项目 1999年准CMM2.0完成未发布 2000年持续集成方法被提出 2002年CMMI 1.1发布 2001年敏捷联盟成立,Contents,行业和市场变迁,自组织项目团队和敏捷,软件项目管理,项目管理起源：,传统项目管理代表性技术：关键性途径方法（Critical

2、 Path Method）和项目评估和反思（PERT）技术。 CPM 美国杜邦公司和兰德公司，1957年联合研究提出 它假设每项活动的作业时间是确定值 重点在于费用和成本的控制。 PERT 美国海军特种计划局和洛克希德航空公司，1958年 用概率的方法进行估计的估算，重点在于时间控制 被主要应用于含有大量不确定因素的大规模开发研究项目。,软件项目管理,1986年11月，美国卡内基. 梅隆大学软件研究所（SEI）受美国国防部的委托 1987年9月开发了一套软件能力成熟度框架和一套软件成熟度问卷，用来评估软件供应商的能力。 1991年，SEI自己总结了软件过程能力成熟度模型（Capacity Ma

3、turity Model-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年，CMMI 1.1发布,软件项目管理SEI的

4、研究,9/20/2018,软件项目管理能力成熟度模型,软件项目管理能力成熟度模型,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)、技术

5、变更管理(TCM)、过程变更管理(PCM),软件项目管理,9,项目计划 WBS分解 工作量估算、规模估算 关键路径设定 业务类子计划：架构、开发、测试； 过程类子计划：配置、质量保证； 协作类子计划：评审、沟通、 项目跟踪 持续度量、纠偏 工作量投入、产出 变更 项目总结 项目度量 项目考核和评价,Contents,行业和市场变迁,自组织项目团队和敏捷,IT行业的变化80年代前,信息技术（Information Technology） 传感技术 这是人的感觉器官的延伸与拓展，最明显的例子是条码阅读器； 通信技术 这是人的神经系统的延伸与拓展，承担传递信息的功能； 计算机技术 这是人的大脑功能延

6、伸与拓展，承担对信息进行处理的功能。 主要客户大型企业和政府：军工、制造、能源、金融、政府管理 核心价值缩短信息处理时间减少信息处理的人力投入提高信息处理的准确率 信息的创造者和使用者：政府机构人、企业人,9/20/2018,IT行业的变化00年代后,互联网技术（internet Technology） 硬件技术主要指数据存储、处理和传输的主机和网络通信设备； 软件技术搜索、网络传输、网络安全、通讯、流媒体、网站部署、电子交易 主要客户客户和用户分离向用户提供软件和服务；并销售用户访问流量典型例子：搜索引擎，向所有人提供无差异的搜索服务，并向所有客户出售广告位。 核心价值消费信息普遍的、无差异

7、的信息服务长尾经济 信息的创造者和使用者：自然人、法人、社会人、机器人、,长尾(The Long Tail) ：图中所示黄色的部份,软件供应商的变化业务领域,9/20/2018,定制信息服务为单一/相似客户提供信息化实现服务，依托计算设备硬件更新、提供配套软件，改善企业或机构数据处理效率。以项目/施工形式运作，一揽子交付制度（客户安装、调试、培训、观察和稳定、附送维护期）典型例子：美国国防部70年代广泛的不靠谱项目 为行业提供解决方案当信息计算在各企业普及后，为某个明确的领域或行业提供广泛的技术解决方案IBM PC和Windows PS的大量普及，软件供应商在定制服务中积累了大量行业知识，结合

8、各专业领域研究机构的理论，逐渐形成全行业通用的解决方案、IT技术和方法得以大规模复制。典型例子：依据生产管理理论提出的MRP、ERP等解决方案,软件供应商的变化角色定位,销售许可为企业/行业提供业务逻辑、计算、存储等方案，以软件销售为主要业务。典型案例：Windows OS、MS Office、Oracle DB 基础设施即服务（Infrastructure as a Service，IaaS）向客户提供处理、储存、网络以及各种基础运算资源，部署与执行操作系统或应用程式等各种软件。典型案例：域服务、云存储、电子邮件等 软件即服务（Software as a Service，SaaS ）向企业、

9、行业提供远程计算、信息存储、数据交易等服务，按照使用时间或次数等收费费用。不需要安装，客户直接注册购买服务。典型案例： S,软件开发团队的变迁（一）,从作坊到车间作坊：人数较少，简单的组织结构、粗放的管理方法，以项目为驱动，缺少工程方法支撑、过程控制基本没有。车间：人数增多，从单一开发工程师，逐渐分离出测试人员，设定了一定的规则，引入测试缺陷管理工具等， 从游击队到正规军游击队：开发工具简单，作业流程就是拿到需求开发，工程师在战斗中学会战斗，都是自学成长型战士，缺乏组织系统化的培训，团队整合靠缘分。组织方式以职能部门为主。正规军：组织使用专业工具、专人维护，具备稳定的作业流程、组织有明确的工程

10、师职业培训制度，注重工程师的绩效和激励，项目管理制度化、系统化。组织方式以矩阵制为主。,软件开发团队的变迁（二）,大规模软件集成开发决策：决策周期相对更长，考虑更多，更保守分工：规模越大、专业越细分、单一职能工程师类型越多 组织：管理层金字塔结构明显，管理岗位增加工具化：更广泛使用专业工具，更严密地过程控制矩阵：职能管理者掌握更多人力资源，项目管理者需要持续争取资源团队：通常距离市场都非常遥远，向行政上级汇报的趋势明显,互联网时代的挑战,不谈技术无论客户、还是用户，对技术的关心越来越少，对他们而言，提供什么样的服务比使用了什么样的技术更靠谱 耐心有限可供选择的产品和服务越来越多所需要投入的学习

11、和转换成本越来越低不再关注功能是否足够多比质量更重要的是更新速度,Contents,行业和市场变迁,自组织项目团队和敏捷,探索的趋势,企业关注的标准：尽可能让工程师做有标准的工作，这样看起来更容易评估成果。数据积累：更多的数据积累有助于形成标准，并进而为管理提供易操作的判断依据。效率：从管理要效益，采用合适的管理方法，帮助管理者更透明的了解团队的工作，并做出最佳决策。 团队关注的战斗力：保持持久的团队战斗力，不干扰团队成员的工作，不当的管理会影响战斗力。经验：有经验的工程师可以更快的解决问题，他们的经验上升为把握风险的直觉，工程师有能力判断风险并采用自己的方法来避免更出现更糟糕的结果效率：采用

12、更新的技术工具和方法，把工程师从简单劳动中解放出来，做有价值的事情，避免管理活动上消耗工程师精力,趋势传统VS敏捷,传统命令型显式知识（依赖文档）计划驱动自上而下控制为主要手段 敏捷自组织隐式知识（经验）变更驱动自上而下应变为主要手段 敏捷不是新鲜事物,趋势20年软件工程标志性事件摘录,1970年软件开发瀑布模型发布 1975 年人月神话第一版 1984年SEI成立 1987年人件出版 1991年CMM体系发布 1991年Scrum首次命名 1995年ISO/IEE12207发布 1995年Scrum论文首次发表 1996年RUP首次提出 1996年第一个正式XP项目 1999年准CMM2.0

13、完成未发布 2000年持续集成方法被提出 2002年CMMI 1.1发布 2001年敏捷联盟成立,敏捷宣言,22,敏捷宣言,个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划,服务的对象始终是用户,责任 导向,成果 导向,敏捷的意识,人月神话-1975 第5章 画蛇添足 在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满

14、了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。第二个系统是设计师们所设计的最危险的系统。第15章 另外一面 面对那些文档“简约”的程序，我们中的大多数人都不免曾经暗骂那些远在他方的匿名作者。因此，一些人试图向新人慢慢地灌输文档的重要性：旨在延长软件的生命期、克服惰性和进度的压力。但是，很多次尝试都失败了，我想很可能是由于我们使用了错误的方法。,敏捷的意识,人件1987 第5章 重新研究帕金森定律 帕金森定律表明：只要还有时间，工作就会不断扩展，直到用完所有的时间。 帕金森定律认为给一个项目多少时间，它总能将之消耗完。 这个定律给了他们（经理）可能最坚强的信念：把工作做好的唯一

15、方法是制订一个不可能的、乐观的交付时间。 帕金森定律几乎肯定不适用于你的员工。 当一个项目完全不合理或不现实的时候，不能再加班加点。项目组的成员会产生愤怒的情绪并在内心滋生一种挫败感并且士气会降到谷底。 卡帕斯琼斯（Capers Jones） 公司繁忙的工作有膨胀填满工作日的趋势。,注：帕金森定律（ParkinsonsLaw）是官僚主义或官僚主义现象的一种别称,源于英国学者C.N.帕金森所著帕金森定律一书的标题,敏捷的意识,人件1987 第6章 苦杏仁苷 软件管理的七个不真实的期望： 有使你的生产力剧增的新诀窍，你已经错过了。 其他经理的成效是正100%、200%或者更多。 技术正飞快发展，而

16、你正在被淘汰。 改变语言将使你收获巨大。 因为待做的项目堆积如山，你需要立即加倍地提高生产力、 其他任何事情你都顺其自然，是不是你对手下的软件开发人员也放任自由。 如果将你手下的人置于很大的压力下，他们会工作得更好。,敏捷的12条原则（一）,我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意； 我们欢迎需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化； 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期； 业务人员和开发人员必须相互合作，项目中的每一天都不例外； 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标； 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈；,敏捷的12条原则（二）,可以工作的软件是进度的首要度量标准； 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续； 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强； 以简洁为本，它是极力减少不必要工作量的艺术； 最好的架构、需求和设计出自自组织团队； 团队定期地反思如何能提高成效，并依此调整自身的行动。,