成年人之间的客套,不能信,尤其是IT行业。

最近在忙啥?一起吃个饭?
不了不了,手里还有几个项目呢,下次吧
“项目”二字,彰显的是身份,是能力不说项目多大,不谈担任什么角色,只要我能参与到这个项目中,我就是厉害
项目组的人表面上光鲜亮丽,背地里绞尽脑汁,进入项目组中,就会发现,在软件项目从0-1中,时间是按照“月”来计算的,几个月甚至几年,才能完成一个项目。
如果交给你一个软件项目,你会怎么做?
今天就带大家从0-1了解软件项目的那些事儿,初学者可以了解在软件项目工程中,主要涉及到哪些岗位以及他们的工作职责;经验者可以了解软件项目工程中,不同的岗位工作对于项目的定位是什么,如果要团队内部协作的话,有什么思路来提高认识。
项目不是一锤子买卖
项目不是一锤子买卖,所有岗位人员并行多任务操作,期间的岗位人员需要的不仅是各司其职,还需要相互和谐。
在项目开始前,首先要这明白几个问题:
梳理项目内部是如何协作的?以及为何这么协作?
软件项目中的协作流程是什么?
各个岗位在流程细节上又是如何协作的?
软件项目在产生时,经历的各个阶段,都由不同岗位人员参与,他们的定位更加明确,只有在进行项目协作时,考虑项目的生命周期、项目的迭代流程、项目的协作流程和高效协作方式,再体会不同岗位是如何项目协作的,才能营造良好的协作氛围。
项目生命周期
项目的生命周期大致分为5个阶段:调研、设计、研发、测试和运营,整个周期呈现环形,方便后续进行项目调整。

调研:多方位评估现状,探索发现最符合公司利益的方案,金点子很重要。
设计:
从产品的原型、UI界面和项目里程三个方面考虑,画大饼很重要。

研发:
根据团队人员数量和技术水平,合理拆分任务,做项目很重要。

测试:
对照产品需求文档、UI设计等因素下手,找对茬很重要。

运营:
把环境做好,等待符合要求的稳定代码的到来,发布到生产服务器中,以技术的角度,将项目维持好,维稳定很重要。

不同阶段主导团队该做什么?
调研和设计 :产品团队主导,产品原型设计师、UI设计师,项目里程根据其他团队的能力逐渐梳理出来,不要贪快做不到。
研发:研发团队主导,其他团队参与。对于设计阶段的内容,产品原型由后端研发人员来完成,UI界面由前端研发人员来完成,前后端团队间把控好数据接口的标准。
测试:测试团队主导,其他团队参与。根据实际情况,依据产品原型的功能和UI界面的效果,进行各种功能性测试和非功能性测试以及其他测试,最终保证过我收的东西是合格的。
运维:运维团队主导,其他团队参与。主要做的是环境标准化、业务流程化、操作自动化等。
就以单一的基础的项目任务来说,运维人员工作的时长,要远远的超出其他人员对于项目的付出, 能力有多大,责任就有多大。


公司组建一个团队不容易,不可能一个人干活,其他人就静静地看着,为了让大家创造出来价值,实现个人的能力升华,也为了让公司更大程度的开发员工的价值,让员工高效的工作,是我们最终的目标。
对于项目来说,一个无限循环的∞,而对于团队个人来说,进入到了一个,刚做完A就开始B,刚做完B就开始C的无限循环中,最终一个团队的所有人都在紧张而忙碌的并行工作,为了让公司开发最大的价值而努力奋斗。
前半个循环参与的部门多,所以需要一个协作机制 AGILE,保证信息的交流是精确的,后半个循环是一个部分自己内部消化的,所以无需其他的协作机制。
怎么合理的保障流程?
相关的产品人员,分析现状问题,发现梳理需求方案,确定最终方案思路,因为方案太大无法一下子搞定,所以将方案细化成一个个有趣的故事地图,为各个团队描述我们如何磨刀霍霍的一步一步将大象关进冰箱里。

拆分完成的故事地图任务很多,为了保证产品能够如期的完成,有我们的协调人员组织大家开一个计划会,群策群力,都说说自己怎么办,怎么干,需要花费多少时间,最终根据时间节点,将任务按照优先级进行排列,田忌赛马的方式,优先完成核心功能,辅助的功能随后以迭代或者其他方式来完成。

 产品人员根据梳理出来的实施内容,准确的向实施团队(开发、测试、运维)描述主旨,保证实施方向不偏,然后实施团队开始着手,圆环套圆环的方式将所有的任务列表中的内容完成,并逐步发布到生产服务器,最终完成交付产品的目的。执行过程中,每日的站会可以让大家互相周知我们彼此在干什么,协作起来有了知根知底的前提。

 产品发布前,通过回顾评审会,向产品人员演示我们的产品成果,评审成功,产品最终发布,然后进行反思大会, 积极的开展我党的批评与自我批评大会,让整个团队气质高昂起来,优点发扬,劣势规避,积极的为下一个版本的产品做好处。

这个流程简单来说,可以理解为敏捷研发的scrum:

三角色:PO、SM、DevTeam
三工件:产品地图、任务列表、完成报告
五事件:用户故事地图梳理、工作计划会、每日站会、回顾评审、反思会等。
协作流程中,开发、测试、发布紧密的结合在一起,这部分的工作是否高效,直接决定了整个项目协作流程是否能够通顺的走下去。而这部分的工作就是平常所说的持续集成和持续交付的主要核心

操作对象:永远存在代码仓库里面的“代码”
1、研发人员在自己的本地环境开发代码,开发完毕后,将代码推送到代码仓库。

2、没人敢保证自己研发的代码不会出现问题,所以为了保证代码能够在生产环境正常运行,所以将代码先后拉取到公司开发环境、测试环境、预发布环境,对代码进行不同级别的测试和验证,最终保证代码处于随时发布的稳定状态。

3、运维人员,将经过层层测试保证的稳定代码,拉到生产环境中,部署成功后,开放相关的权限,最终用户可以看到相应的效果了。

4、整个流程,纯手工来做的话,眼就瞎了,所以为了省事的同时也提高工作效率,做了如下两个动作:将所有的代码获取流程、代码的部署运行流程自动化 -- jenkins之类的持续交付工具。将所有的环境标准化、流程化、实现基础环境的快速呈现 -- Ansible、Saltstack 实现配置的统一标准化管理,Docker、Kubernetes实现业务应用环境的快速标准化。
DevOps来了
思路虽好,方案虽好,架不住团队里面有坏人,总想着有人要害朕。所以一个个部门领导要宣誓主权,导致部门之间出现各种交流障碍,最终害人害己。

因此需要一种软性的交流思路,能够打破不同部门的协作思路,推己及人,互相理解,于是DevOps来了。
用户访问流程:用大家最常见的场景作为入口,理解团队协作的时候,都干了什么。
文件查找流程:我看到的文件,是怎么找到的?他保存在哪里?
文件产生流程:我们看到的文件,都是怎么产生的,有什么区别,都是谁做的?
加速访问流程:页面效果好不好,谁说的算? 客户。那么客户对什么感兴趣?时间。
基本访问流程:用户在浏览器输入域名,通过互联网找到对应的主机,主机上的应用程序找到到处是空白窟窿的文件,通过程序机制到后端数据库获取数据,然后再空白窟窿的文件里面填充,形成完整的页面,最终返回一个完整页面数据,完整的页面数据,在用户浏览器渲染成一个完美的页面。
问题:

  • 我怎么知道要找的主机在这里?

  • 我怎么知道要找的文件在哪里?

  • 我怎么知道页面到处都是窟窿?
  • 我怎么知道可以从后端数据库获取具体的数据?

  • 我怎么知道获取到的数据,可以填补空白页面中随处可见的窟窿?

查找主机流程
  1. 根据互联网的域名管理系统,解析出来网站的服务器ip

  2. 因为群众里面有坏人,所以为了安全,不让所有人看到真实的服务器

  3. 根据用户的请求,由反向代理服务器将请求转交给真实服务器。

全球的根DNS实例1381个(截止到今天),由12个根dns运营商来管理,每个DNS实例的服务器数量未知,我们国家有37个根DNS实例(图中数据没有问题,因为它把越南的3个算到了香港的那个区域中)。
用户在浏览器输入的地址主要有三部分组成:
域名
- 解析为ip地址,目的是找互联网上的主机地址

端口
- 请求的服务在服务器上以端口的样式作为唯一入口。

url关键字
- 请求的资源到底是什么,根据这个关键字有程序来识别。

nginx web关键查找url关键字流程
通过server配置段内部的listen监听端口接收用户请求,根据location匹配的关键字,查找对应的资源对象,到root指定的目录下找index匹配的文件。

Django web程序查找url关键字流程
nginx反向代理请求给Djangoweb应用程序,应用程序的路由系统匹配路由关键字,交给后端的view视图系统,views视图系统根据request对象识别相关参数,按照内部的函数逻辑对数据进行整体处理,借助于后端的数据库引擎基于模型类从后端数据库中获取数据,根据render函数找到到处是窟窿的模板文件,然后基于context的属性将数据和模板整合为一个完整的页面。然后原路返回给nginx程序,经Nginx软件,将数据返回给用户浏览器端。

要创建页面,就要了解页面的表现样式,目前互联网上的页面样式,主要有这么三类:移动端的上中下结构,浏览器端的上中下结构,浏览器端的左右上下结构。
样式虽多,但是生产的方式主要有两种:
干脆利索:直接在后端生产完整的页面,最后统一返回给用户
方便快捷:先返回页面框架,根据实际的情况,通过大量的局部请求,逐渐获取页面中的部分数据
整合样式1:
web程序端的项目代码逻辑,先获取模板文件,经由ORM工具从后端数据获取数据,通过render函数将数据和模板整合为一个完整的页面,返回给用户,在用户端进行正常的渲染。

整合样式2:
将之前后端程序一个人做的事情,拆分为两个地方来做,前端程序和后端程序,前端程序通过axios等方式,根据情况在用户发起局部请求的时候,从后端获取针对性的数据,然后再浏览器端逐一的加载到一起,最终形成一个完整的页面。

所谓的用户体验,就一句话,用户访问的时候,越快越好,享受山大留学生的皇帝后宫式体验。网络上的用户体验策略多种多样,我们直接从页面本质上入手。

如果一个页面中的子文件对象少一点,页面加载的速度就会快很多,因为没有资源获取的等待+阻塞时间了。

 每个页面都有自己的域名地址,如果大部分的文件都在同一个域名下,后面的资源就无需重复的域名解析,使用dns缓存记录,可以大大提高文件的获取效率。

页面中的子文件对象存放在不同的主机中,如果一个在河南,一个在荷兰,那么获取的方式就很慢。但是如果所有的文件都在同一个局域网中,那么所有的文件获取的速度就会非常快。

所以基于 减少页面对象、减少域名解析、使用同构网络等方式,可以从根本上实现页面高效访问的目标。
虽然页面的优化策略非常多,但是我们主要是从页面访问流程来描述不同岗位的协助思路,所以其他的优化策略,不再我们的思考范围中。
岗位协作梳理
Q:为什么这个项目的访问流程中,没有过多的描述产品岗位和测试岗位?
A:研发出来的产品样式和流程就是产品人员设计的,研发之前产品人员已经和研发团队彻夜进行心连心的交流了。
只有研发出来的代码,才会进行代码质量测试,只要能够给用户看到的,都必须经过测试人员的火眼金睛的找茬能力校验。
因为这两个岗位的职责清晰,所以我们没有过多的描述,主要集中的体现在了研发和运维的角度。
Q:用户访问流程有什么重要的?
A:就是很重要,这个流程都不理解,我们怎么互相达成一个普遍的认知,而且这件事情就是我们做事情的根本。
Q:用户访问流程有什么重要的?
A:就是很重要,这个流程都不理解,我们怎么互相达成一个普遍的认知,而且这件事情就是我们做事情的根本。
Q:页面的查找流程,研发人员和运维人员的定位是什么?
A:主机的查找流程,涉及到 DNS的解析、TCP/IP的三握手四断开,nginxweb软件的配置、反向代理的配置、真实web服务器的部署和管理,这些都是运维人员的 核心竞争能力。
页面的查找流程,涉及到web软件的配置、反向代理的配置,这些是运维人员的岗位需求。后端django程序的页面查找是研发人员的主要岗位要求,内部代码的逻辑不通,何以通全程?

Q:页面的加速流程,不同岗位人员的定位是什么?
A:页面加速流程是一个综合性的项目维护过程,涉及到哪些页面应用需要进行加速、用户对哪些应用页面感兴趣,运维团队采集数据,产品团队进行功能梳理或者版本功能计划
Q:怎么进行页面加速策略实施?
A:运维团队采集数据,研发团队实现多种静态化的方案,最终由运维团队来落地。
Q:为什么对页面本身的业务逻辑对象来进行加速访问策略?
A:这些东西对于研发人员或者运维人员来说,都比较好入手,好处理。
Q:还有没有其他的策略可以让我们更好的完成页面的加速流程
A:有,不同的岗位都会有自己的思路来完成这个任务,但是很多人不愿意干,因为没有动作,就没有伤害。
别问我怎么走到这一步的,干任何事情,不怕慢,就怕站,只要不停,目标就不断的向我们招手,来呀,快活呀,反正有,大把时光。
好酒好菜,有机会我们继续,今天的分享就是一个大纲,里面的任何一个点,单拎出来都是一个大的话题,大家如果有兴趣的话,可以留言,你感兴趣的话题,我可以为你定制一个内容分享的课程。

运维、开发、测试、产品、安全、DevOps、云计算、人工智能,只要你敢提,我就敢讲。
来吧,我们一醉方休!
凡文中涉及的资料
均可在公众号中领取
回复关键词“项目协作”
获取下图所示的所有资料
继续阅读
阅读原文