开发流程

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。 一、Scrum的定义和目的 Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程，目的是让开发人员像打橄榄球一样迅猛并充满激情，通过团队合作，提高工作效率。通过团队间的有效交互，为企业创造价值。 二、敏捷宣言 其实，在发表《敏捷宣言》之前，很多的敏捷实践都已经存在且使用了，比如：Scrum、XP、KanBan等。之所以发表《敏捷宣言》，是因为这些实践都是在单打独斗地推进敏捷开发，而不是以一个联合体的形式，且没有一个统一的指导方针。所以17位敏捷联合创始人决定发表《敏捷宣言》，共同在全世界推进敏捷开发运动。下面是敏捷宣言的4句话： 三、Scrum中的人员角色 3个角色 Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。 产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。 ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力

一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。 【这里以一个基线产品开发过程作为流程解释基础，需要注意的是，以下说描述的各个阶段，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致】 项目启动会 项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，目标与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，考虑清楚自己的行动计划，怎么做才能更有效地完成目标，是每个人都要详情清楚的问题，否则，目标越是不清晰或是过高，都会影响项目的实际结果。 项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入 PPT（最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范），需要大家达成一致。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。 用户需求

一、 BUG处理流程图： 流程描述： 1、 测试人员发现bug提交给开发。 2、 开发人员判断是否是bug。 3、 如果是bug，进行修改，修改完成后更改bug状态为已解决。 4、 如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因，或者不能重现。 5、 开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 6、 验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 7、 测试人员需要对开发人员退回的bug进行确认。 8、 确认不是bug关闭。 9、 如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 二、 各角色应关注的状态 1. 开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需要继续修改。 2. 测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解决，要将其置为“关闭”。否则“重新打开” 无法重现

1组件化开发 组件分开发是非常重要的工程优手段。也是react开发必备技能。前端光有JS/CSS的模块化还是不够的。对于UI组件同样迫切的需求 前端组件化开发理念： 如上图所示这就是前端组件开发理念，下面我们来总结一下 1、页面上的每个独立的可视。可交互区域视为作一个组件; 2、每个组件对应一个工程目录，组件所需的各种资源(JS、Image、CSS)都在这个目录下就近维护; 3、由于组件具有独立性，因此组件与组件之间可以，自由组合; 4、页面只不过是组件的容器，负责组合组件形成功能完整的界面; 5、当不需要某个组件或者想要替换组件时，可以整个目录删除/替换 注：每二项中就近维护原则是工程化的体现。每个开发者都清楚知道，自己所开发维护的功能模块。因为代码必须存在于对应的组件目录，当前目录包函 CSS、JS、HTML、Image 根据上述描述我们将构造一个项目的基本流程 项目初期前端静态页面只包函CSS、HTML 目录名称：frontEnd less文件结构对应生成css文件 来源： https://www.cnblogs.com/pink-chen/p/11064733.html

转载自： http://blog.csdn.net/luohuacanyue/article/details/12903189 这篇文章里说的内容，其实都是老生常谈，但是里面有一点我觉得非常有道理，在做完一个项目之后，我通常想的是，这个项目中有哪些不足，而不是——“怎样把这个项目做的更好”，两者看上去没什么区别，其实有很大区别，因为出发点不同。 凡事都应该是目标导向，你所做的一切，都应该是为了实现你的目标。 下面是正文： 前言 最近一直在想自己在项目中的一些得失，在每一个项目结束都要问自己一下： 这个项目中自己获得哪些成长，下次是不是可以做到更好 。长期的项目过程往往会让人陷入一种思维的定式： 好像每个项目的工作都一样，这样很容易进入一种比较消极的状态，会忘记自己曾经给自己设置的目标 。以前看过这样一个问题： 什么才算得上有效经验？ 有些人做了三年其实只有一年的经验，因为后面基本上是前面的copy。这也是为什么有人说一个人的成长在于前面三五年，后面很有可能会遇到天花板。当遇到天花板的时候能不能突破是一个关键。下面讲一个整个项目中需要做什么。我会在介绍整个流程的同时插入自己的一些想法和思考。 更重要的是思考，思考是人的精髓所在 。 项目流程 1. 需求阶段 这是项目的最初的阶段，这个阶段主要需要明确这个项目要做什么？目标是什么？一般来讲这个过程是产品经理去做

1 ，创建项目 scrapy startproject 项目名 2 ，创建spiders爬虫文件 Scrapy genspider sipider名字 网址 ( 占位 ) 3 ，打开spider文件 - - > 将待爬取的url放到start_urls中 start_urls - - 起始url，scrapy启动之后，就开始下载start_urls里面的url。 scrapy将start_urls里面的url下载好后的response就交给这个方法来处理 4 ，更改settings . py中的配置 1 ，scrapy默认是遵守robots，将rotbos协议改为 False ROBOTXT_OBET = False 2 ，设置下载的请求头。 'User-Agent' : '' 'Accept' : '' 'Accept-Language' : '' 3 ，如果将cookie加入请求头，想要让他生效，还必须在打开一条配置 cookie_enabled = False 这条配置主要是将scrapy下载时自己的cookie关闭，就可以使用户自定义cookie了。 5 ，在parse方法中，验证response中是否有数据。 def parse ( self , response ) : print ( response . text ) 6 ，在item . py中定义要爬取的字段。

1 . 音视频处理的一般流程： 数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示 1、 数据采集： 摄像机及拾音器收集视频及音频数据，此时得到的为原始数据 涉及技术或协议： 摄像机：CCD、CMOS 拾音器：声电转换装置（咪头）、音频放大电路 2、 数据编码： 使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据 涉及技术或协议： 编码方式：CBR、VBR 编码格式 视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等 音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等 3、 数据传输： 将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输 涉及技术或协议： 传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等 控制信令：SIP和SDP、SNMP等 4、 解码数据： 使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音 涉及技术或协议： 一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等 5、 播放显示： 在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音

CICD整体介绍 一、产品上线流程 1、运营与用户进行交流与沟通，确认需求 2、运营将需求转交给产品经理，产品经理 分析需求 ， 确认需求 ，注意： 确认需求之后要进行内部会议，确认产品的可行性，并且将需求转换为具体的项目方向(用户提出的需求都是一个比较大的方向，需求提出人员要和用户进行沟通，确认需求是否满足期望) 3、需求可行性通过之后，产品经理要和设计师共同协作完成PRD（产品需求文档）和原型 4、UI根据需求文档和原型进行UI设计 5、需求和原型设计出来之后，产品经理将需求转交给相关的业务开发人员，业务开发人员首先根据项目需求进行项目可行性分析，然后并根据具体项目给出开发周期，最后将项目具体分工到开发人员 6、开发人员完成项目(保证项目可run，并且对项目进行了code review之后提交)之后，移交测试人员进行测试 7、测试人员写测试用例，编写测试文档，最后编写测试报告，通过发邮箱的方式告知开发人员，测试有BUG则告知开发人员进行修改 8、测试通过之后，移交产品经理进行验收，不通过则返回修改，通过则告知运维人员准备上线， 9、运维人员接到通知之后，进行上线准备，首先在测试环境测试完毕之后，移交预生产环境进行测试，确保万无一失之后部署项目上线生产环境，项目上生产环境之前发邮箱通知领导，项目上线完毕之后也要通知相关领导 二、项目上线流程 开发环境，测试环境，预生产环境

需求分析 1.相关 系统分析员 向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。 3.系统分析员向用户再次确认需求。 概要设计 首先，开发者需要对软件系统进行 概要设计 ，即 系统设计 。概要设计需要对软件系统的设计进行考虑，包括系统的 基本处理 流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的 详细设计 提供基础。 详细设计 在 概要设计 的基础上，开发者需要进行软件系统的详细设计。在 详细设计 中，描述实现具体模块所涉及到的主要算法、数据结构、类的 层次结构 及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或 子程序 )的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。 编码 在 软件编码 阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作

　　一个完整的开发流程应该有这四步：分析->设计->编码->测试。很多开发团队往往只有编码这边，弱化了其他步骤，他们拿到需求就开始写代码， 写着写着发现有问题，要么是遇到一个难点解决不了，要么是发现要返回修改以前写过的代码， 要么是发现有大量的重复代码，又不知道怎么封装，只能将错就错。做好了分析和设计编码时就不会有这么多问题， 做好了测试产品bug就少，产品质量才高。 下面我分别详细讲解一下这四步。 分析 　　分析的时候，我们要分析需求和难点。 　　分析需求的方法是做需求陈述处理，前面我提到过， 要区分做什么和怎么做，把这两部分独立出来，做什么是固定不变的， 而怎么做可能会经常变。我们再熟悉一下举的那个例子：我们要做一个成员列表（如图1-44），产品经理告诉我们要按姓名拼音排序。 图1-44 成员列表的例子 　　我们有时候不能直接听产品经理的，如果真写死成按姓名拼音排序就没有可扩展性了，比如某一天产品经理又告诉你需要把VIP会员提前，那么你只能再去修改排序的程序。这个需求始终不变的是排序，按姓名拼音只是排序的一种方法，我们在设计数据库时应该把排序字段设置为数字而不是拼音，再写一个拼音转换为数字的算法即可，这样在后面排序规则变化，比如VIP会员要提前，只是修改对应用户数据库的排序字段数值即可，不用大改程序。 　　我们可以用xmind做需求分析，