沈阳网站设计制作公司,网站建设手机端,wordpress 支持mkv播放器,seo是一种利用搜索引擎作为一家专注于软件开发的公司《智创有术》#xff0c;我们致力于为客户提供创新、高效和可靠的解决方案。通过多年的经验和专业知识#xff0c;我们已经在行业内建立了良好的声誉#xff0c;并赢得了客户的信任和支持。 支持各种源码#xff0c;网站搭建#xff0c;APP我们致力于为客户提供创新、高效和可靠的解决方案。通过多年的经验和专业知识我们已经在行业内建立了良好的声誉并赢得了客户的信任和支持。 支持各种源码网站搭建APP小程序小游戏所有开发 我们的团队由一群充满激情和技术专长的专业人士组成他们不断追求卓越并始终保持对新技术的敏锐洞察力。我们深知每个项目都是独一无二的因此我们采用个性化的方法来满足客户的需求确保项目的成功实施。 在我们的全网营销中我们将利用各种数字渠道和策略来提高品牌知名度、吸引潜在客户并促进销售增长。无论是通过搜索引擎优化(SEO)、社交媒体营销还是内容营销我们都将努力为您提供最佳的网络营销解决方案。
成本、时间和质量是项目管理的铁三角项目管理的核心目标是平衡好这三者之间的关系尽量确保软件项目能够在可控的成本范围之内符合质量要求地按期交付。
这里的质量我觉得包含了两方面
功能的完成度与稳定性用户需求的满足程度。
在一些大型项目的交付过程中面对交付过程中频繁变化的需求按照既定合同内的需求以瀑布模式开发虽然能发挥瀑布开发的优势但在用户需求满意度方面肯定会有所损失更严重的会导致返工改造、验收不通过。
相对“瀑布”模式的重“敏捷开发”是一种应对频繁需求变化、快速响应的轻量开发模式在以“瀑布模式”开发的项目中将“敏捷”的理念引入发挥各自优势会对整个项目顺利的交付起到积极的作用。
本篇先讲下“敏捷开发”与“瀑布开发”的工作流程、适用场景、各自优缺点然后将二者融合谈一下在实际项目交付过程中的应用思考。
一、瀑布模式
瀑布模式是一种经典的线性开发模式在传统的软件项目交付过程中被大量使用。
瀑布模式的整个项目周期是确定的按照项目开发的时间可以分为规划阶段、需求分析阶段、软件设计阶段、编码阶段、测试验收阶段、上线阶段运维阶段等若干里程碑。
下面这张图生动地描述了瀑布开发的模式
客户需要一辆代步工具需要按照事先规划的方案经过漫长的研发最终给客户交付一辆汽车。 B端究竟需要什么样的产品经理
B端产品经理都是以提升供应侧的工作效率为目的所以B端需求主要是以业务问题为导向。 这个是B端产品比较重要的一点B端产品是服务于一个主体 ...
查看详情
前期的方案是足够好但在此过程中客户无法尽早体验产品最终交付后产品可能不是客户实际想要的从这个角度看风险很高。 一个典型的瀑布模式的产品研发流程 适用场景
瀑布模式比较适合需求比较清晰的项目开发比如签订合同的项目制交付一般情况下合同内的需求都是确定的乙方按照合同内的需求按时交付即可。
理论上需求和设计方案确定后在开发过程中需要严格执行需求变动需要执行变更流程或者另签一个补充协议。
优点
由于需求相对比较明确在前期可以对系统整体架构、扩展性进行整体、全面的设计团队的目标相对明确按照里程碑节点顺序推进向目标前进的效率会比较高易于管理和监督每个阶段投入的人力不同不同岗位的人员可以分批投入项目。
缺点
对业务需求的快速变化灵活性不足尤其是对于处于摸索阶段的新业务这种变化是不可避免。比如系统试运行、业务推进过程中会产生很多新的需求我们之前按照合同内需求规划的设计可能要推翻或者有较大的修改尤其在项目中后期很可能将会导致项目延期超出合同成本预算。由于产品从研发到上线是一个线性的推进过程在此期间客户没有真正看到过、体验过产品最后上线客户很可能对最终的产品不满意重新改造的成本较高。
二、敏捷模式
敏捷模式是针对瀑布模式太重提出的一种小步迭代、快速反馈的开发模式能有效的提高软件的开发效率应对市场的快速变化。
下面这张图生动地描述了瀑布开发的模式。
客户想要一辆代步工具为了快速满足可以出行的需求按照敏捷的理念会先提供滑板、然后通过快速迭代逐步提供自行车、摩托车、小汽车。
在此过程中将产品快速投入市场根据市场反馈调整方向虽然一开始提供的不是最优解决方案但是一直在正确的方向上前进不至于跑偏。 敏捷的核心关键词包括快速响应、迭代、增量交付、渐进式、面对面沟通、快速反馈与调整等。
敏捷项目管理通常采用Scrum敏捷框架进行实施以固定时间盒的方式快速迭代在实践中比较常用的是双周迭代的模式在一个冲刺内完成增量开发的交付。 “增量开发主要是一块接着一块地构建一个系统。一部分功能先被开发出来然后另一部分功能被加入前一部分功能以此类推。”
《敏捷宣言》中的价值观 个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划。 Scrum作为一个轻量级的团队协同工作方式一个冲刺从开始准备到完成主要由以下几个关键活动组成 1. 需求梳理挑选需求并编写需求说明
一般由产品经理在冲刺开始之前从Product Backlog(类似需求池Scrum中叫Product Backlog中按照优先级挑选在本次冲刺Sprint内需求这些需求可能为特性、用户故事、缺陷等在Scrum中被称为PBI。
产品负责人和开发团队要对当前冲刺准备实现的需求及冲刺目标达成一致意见在此期间产品负责人需要完成产品方案、编写需求说明并与需求方确认。 2. 需求澄清会冲刺计划
产品经理将当前Sprint中的需求向研发团队澄清在澄清的过程中可以根据实际情况对需求的范围、方案进行调整。
每个需求澄清完毕具体模块的研发人员可对需求的进行工作量的估算故事点、规划扑克牌具体的估算方法这里不再具体说明。
如估算的工作量过高研发人员需要说明原因最终会议结束确定本冲刺内交付范围正式开启冲刺。 3. 任务分解
一般需求澄清回后开发人员会将每个需要完成的需求特性分解成一组任务这组任务及相关的PBI组成了“冲刺列表”开发团队给出完成每项任务所需工作量的估算值通常以小时计。 4. 冲刺执行开发实施与测试
在团队冲刺的内容达成一致意见后研发团队需要根据产品方案进行技术方案的设计执行为了完成特性而所需的所有任务开发的工作。
5. 每日例会
在冲刺开始的每一天研发团队会每天早上进行站会通常不会超过15分钟。
团队成员每天轮流回答下面三个问题昨天我完成了什么今天计划做什么工作有什么障碍让我无法取得进展
通过每日站会每个人都能了解全局知道发生了什么冲刺目标的进展如何是否需要帮助团队解决一些问题实现一个冲刺内快速、流动的工作流。
6. 冲刺评审
冲刺周期的后期团队给产品负责人和其他业务需求干系人、客户演示完成的成果让各方了解已经交付的增量检视和调整产品同时业务互相交流收集反馈并及时调整。
7. 冲刺回顾会
冲刺回顾会是检视并调整过程的时机开发团队、产品负责人、ScrumMaste一起讨论在上个冲刺中哪些过程是需要改进的。
需要注意的是冲刺回顾会不是吐槽、追责的会议目的是帮助Scrum团队成长、下一个冲刺能够持续的改进。
适用场景
敏捷项目管理适用于业务需求变化频繁、比较适合创新型项目、市场需求变化快速的项目主打一个“快速迭代”在一些互联网公司、自研产品的公司比较常用。
优点
能够快速响应变化、提高客户满意度、减少项目风险同时还能提高团队协作能力、加快产品上市时间。
缺点
对于一些成熟业务由于追求快速响应前期在系统架构设计上并不一定那么完美另外对团队协作能力、敏捷理念的认可度要求比较高。
三、在项目交付过程中的思考
在实际的项目交付过程中甲乙双方立场的不一样甲方期望乙方能在合同周期内尽可能多的满足需求解决更多问题而乙方期望能控制成本如期交付迫于甲方交付验收的压力又不得不接受频繁的需求变更。
从实际经验来看有如下原因将导致成本、质量、时间陷入三难的境地。
外部原因
甲方业务比较新存在边用边发现新问题的情况合同外的、变更需求时有发生甲方不配合如不配合调研、系统使用不积极、不提供数据等等实施过程中非研发类工作耗费太多时间如数据处理、甲方汇报文件、配合业务开展等临时性工作安排、业务代运营等。
内部原因
合同签订前销售的对需求的过渡承诺初设方案的不完善系统规划设计阶段对整体应用架构、技术架构设计的不合理需求分析不合格设计出来的系统未能彻底解决甲方的问题导致重复返工、打补丁缺乏有效的项目管理流程多人协作变得混乱失控缺少风险跟踪研发过程变得脆弱导致研发效率和质量不高。
原因很多本篇仅从项目管理的角度探讨如何平衡成本、质量、时间的矛盾达到甲乙双方共赢的目的。
有一种方式我叫做“大瀑布下的小敏捷”将“敏捷开发”与“瀑布开发”相结合发挥各自的优势是一个实际可用的手段。
“大瀑布下的小敏捷”既能够按照“瀑布模式”的里程碑节点交付目标相对明确又能发挥“敏捷开发”快速响应需求的变化、持续交付的优势提升客户满意度。 在大的项目周期内有明确的启动、需求调研、系统设计、编码开发、上线交付的里程碑节点整体上看是瀑布模式的开发。
对于实际交付过程中频繁变更的新需求和合同内的老需求统一放进“产品代办清单”Product Backlog按照敏捷开发的模式拆分成一个个固定时间盒的冲刺当下的冲刺内为优先级最高的需求通过一个个冲刺完成增量产品的交付直至项目交付。
敏捷开发是为了让团队达成一种在固定时间内持续交付的共识一般一个冲刺开始时该冲刺内的需求一般不允许变更。
但有些特殊情况为了配合甲方汇报一些G端项目常见这些临时需求优先级会变得非常高。
此时研发团队可能正处在当前冲刺的开发中不得不将主要精力投入配合汇报。
无论“敏捷开发”还是“瀑布开发”流程是死的人是活的不同的公司、不同的业务可以根据实际情况灵活调整切不可生搬硬套。
