团队开发过程中的一点感想

以前还不觉得单人开发和团队开发的区别有多大,以为顶多就是把一个人的任务分给了多个人而已,但是其实不然。

我也是在经历过团队开发之后,才感觉到了单人开发与团队开发之间的重大区别(大致情况在后面说明),并不仅仅是将任务划分一下就完了。

而在之前我之所以任务他们之间的区别不大,只要是因为我忽略了一个问题,在团队中中的每一个人都是一个独立的个体,每一个独立的个体都会拥有一种不一样的思想。

一个独立的人思想是可以根据自己本身的需求和意向而改变的,但是如果是一个团队,团队里面同时存在着多种独立的思想,思想与思想之间是会发生碰撞的,有了碰撞之后就极有可能产生争议,一旦产生争议,就是问题的开始。

如果没有一个能够拍板的人,那么整个团队将会伴随着越来越多的争议而走向消亡。

特别是如果在一个团队中,存在着那种非常固执任性的,不服从指挥,坚持我行我素的人,那么这个团队消亡的速度就会愈发的快了。

算了,不叨叨这多了,开始正题!

首先先了解一下开发的大致步骤。

▍开发步骤

1、需求分析

2、页面原型设计

3、数据库建模

4、架构

5、类设计

6、编码

7、测试与调试

8、部署

▍项目前期

第一个也是最重要的:找好领头羊,不是每个人都适合作为领导者,这个领头人一定要在团队中有威信,有公信力和领导力。

另外如果自己自身在团队中没有威信,领导力不够,那么最好不要当这个领头人,乖乖的当个小组员,做好自己的本职工作就好。

当一个无法让众人信服的组长是一件很头疼的事情(这个我刚刚吃过亏!!!原以为当个领头人是个很简单的事情,结果发现,自己很难在组长中建立威信,布置的任务总是拖延或是敷衍了事,根本达不到要求,很多时候都想自己把全部的事情给做了算了。弄得我现在头疼得很)。

团队互补是很重要的,好的搭配才是精彩的开始,糟糕的人员搭配只会让事情变得很糟。

组队的时候不能只看个人能力,还要看个人的沟通表达能力,有时候个人的性格脾气也会对整个项目的进度产生影响。

人员分工一定要合理,包含两点:第一好钢要用在刀刃上(不要让不熟悉相关工作的人做相关的事情),第二每个人的工作量尽量做到最好的“均分”。

▍需求分析

单人完成!

主要分析这个系统是干什么的,需要哪些功能,用户主要是哪一类人群。

在需求中需要有完整的用例图和用例表,不只是做到“差不多”,而是要做到用例全覆盖。以下为单个用例表实例:

在需求中要指出变量、函数、类等的命名规范。

确定页面缓存方式,哪些表格是按照整个表格缓存,哪些表格是按照单个字段缓存。

需求文档一定要完整清晰,发现其中有欠缺的地方要及时完善补充。

▍页面原型设计

单人完成!多人同时提供设计思想会导致页面始终难以确定。

如果其他人有任何意见,可以在设计完成后提出,如果最后关于某个问题争执不下,那么就团队投票表决或者是组长做决策,不要在一个小问题上纠结太久。

▍数据库建模

单人完成!

在数据库表的设计上要保证科学合理,数据表的构建一定要符合3NF范式。

每张表必须有一个自增id作为主键,不做其他用处,只是用来标识数据的数量。

▍架构

架构构建的时候,尽量使用当前流行且成熟的框架,保证架构的实用性与牢固性。

▍类设计

类设计就是要设计出有哪些类,这些类中又分别有哪些方法, 每个方法是做什么用的,然后这些方法之间又是怎么连接在一起的。

▍编码

我个人认为编码应该分为两个小的阶段:

第一阶段前后台独立编码,前台完成页面的制作,后台根据页面原型图敲定大体上会用到的函数以及函数以及所涉及到的变量,这段时间内前后台是互不影响的,可以独立同时进行的;

然后前后台独立工作完成之后,就可以进行整合了,第二阶段前后台整合,前台在后台中找到所要请求的函数,如果有并且正确,那么就直接调用这个函数,如果后台没有考虑到这个函数,或者函数的参数与返回值不满足前台的请求方式,那么就需要对后台进行微调,这个时候前后台人员的交流就要多一些了。

不要想着能一次性写好,这是不可能的事情,或者说是做梦。。。

如果是前后等后台完成之后再动工,或者是后台等前台完成之后再动工,那样的话中间等待的时间就会被浪费掉。

我的队员就犯了这样一个错误,我做前台,他做后台,我把前台页面做好之后,问他后台的编码工作完成没有,结果他说他在等我前台的变量名定好之后再动工,我简直要气死了。

离提交时间就只有这么短了,他竟然告诉他还没有动工!!!

不过要说怪的话,也怪我没有事先说好编程阶段的时候怎么做,没有把我的看法拿出来跟他们交流(我以为他们应该跟我想的一样)。

团队中的每个个体都需要有良好的编程规范,多写注释。

网站或者软件在开发过程中,必须要使用版本控制器进行版本控制(小型团队使用SVN学习||SVN的正确打开姿势,大型团队使用GitGit简洁教程-本地项目推送到GitHub),否则会做很多无用功。

▍测试与调试

这一步骤是为了保证程序能够正常跑起来。测试是为了找出Bug,而调试是为了找出出现Bug的原因,然后修改程序修复Bug。

团队之间肯定会存在方式思路不同的时候,调试过程中,当我们觉得队友的代码或者处理逻辑有所欠缺或不足时,在没有与原始编码人员商讨的情况下,不得擅自修改,防止出现“交叉版本”。

▍部署

运用不同工具开发的项目,其发布的方式也可能会有相应的区别。

比如如果是普通的web项目,有两种方式:第一种在编辑工具中配置服务器(例如在eclipse中配置tomcat),然后启动配置在编辑工具中的服务器,项目就可以跑了;第二种是将web项目打包成war包,然后放在放到服务器中运行。

▍项目后期

项目完成之后,要看到这些文档:

需求分析文档

项目总体设计报告

项目详细设计报告

项目进度报告

项目测试报告

项目使用说明书

项目风险评估报告

▍注意事项

项目过程中要有定期会议,每次会议要有会议记录。



作者:颜值界扛把子
来源:CSDN
原文:https://blog.csdn.net/i_dont_know_a/article/details/80560821
版权声明:本文为博主原创文章,转载请附上博文链接!

原文地址:https://www.cnblogs.com/hmms/p/10496550.html

时间: 2024-10-10 01:20:41

团队开发过程中的一点感想的相关文章

niosii dma实验中的一点感想

1,使用nios给出的驱动函数的顺序一般为1,清中断2,写控制寄存器,3,写参数寄存器4,中断注册,5,开始工作.因为开始工作控制位在控制寄存器中,所以会想到到最后一块写,省事,但是在dma试验中发现copy后的数据开头几个都是0,而且copy不完全.将写控制寄存器和开始工作分开则问题消失. 2,中断注册需要:1,中断控制器id,我发现不是0就是-1,0是有中断的外设的中断控制器id,-1是没有中断的外设的中断控制器id,2,中断号,3,中断处理函数,4,传递给中断函数的参量,可以为null,5

开发过程中的一点领悟(2)

随着开发的项目.功能.组件越来越多,对于代码的“可维护”性感触越来越深~ 在这次的开发中,有一个地方需要用到分页条,于是我理所当然的就开始按照UI设计画好了页面,而当要写js的时候,脑海里还是飘过“要不要写成组件?”, 很好!这个想法是对的,然而这个分页条仅仅只有一个地方要用,“那么我为何要写成组件呢?”,这种“懒惰”的,“不聪明”的想法又出现了,伴随着项目开发时间的紧缩,我居然毅然决然地放弃了将这个分页条写成组件~ 项目一点点地做, 时间一点点地走, 暴风雨前的安静总是这么让人惶恐~ 但是要来

开发过程中的一点领悟(1)

今天在学些一些新的框架,然后我自己就尝试做了点东西,一个简单的页面切换,其实用纯的js(jquery)来完成更加简单. 所以一开始我就很苦恼,为什么要开发这种框架!!! 当我“大彻大悟”之后,我才明白,大部分的框架其实并不是用来开发一些简单的功能的,而是给“大”项目用的, 比如alert一下,还需要用很复杂的框架吗?不用... 所以用“大型框架”开发简单的功能是不合适的~有时候还不如不用~

软件开发过程中如何避免争吵?

软件开发过程中,对一个问题有不同意见是很正常的,不同思想的碰撞可以带来进步,但是如果沟通不当,引发争吵,从而延误项目开发进度,就会得不偿失了. 要做到避免争吵,首先得自我反思,自己是不是哪里做得不对,问题没考虑清楚.问题还没明白就去和别人争,就是你的不对了. 其次,要站在别人的角度先想一想问题.是不是PM有难言之隐,公司的压力过大,不能采纳我的建议? 设计师看问题的角度是不是和我不一样?我的代码编写是否规范,有没有给复审测试人员带来麻烦?项目有没有充分考虑并达到用户的需求?在和别人争论前,必须充

node.js项目开发问题集锦(不定期更新,随时把开发过程中遇到的问题加上)

1.用express开发站点时,怎么定义通用的头部和尾部 方案1:用类似asp时代的include添加,如ejs模板: <% include ../header.ejs %> <h1 class="page-header"> 这里是内容. 注:..表示header.ejs在上一级目录,ejs扩展名可以去掉,直接写:include ../header </h1> <% include ../footer %> 方案2:用类似于MVC的lay

读《少有人走过的路》的一点感想

这本书是美国心理医生斯科特*派克写的,不属于励志类书籍,但对人的启迪感觉比励志类的要好.心理疾病在我们国家属于极端被鄙视的一种病之一,骂人"神经病"也属于比较恶毒的一类.其实心理疾病在我们国家很普遍,因为我们的文化和社会环境更为容易滋生这类疾病,而且由于讳病忌医的缘故,造成了很多的人间悲剧.最为常见的一种心理疾病就是抑郁症.而得抑郁自杀的其实每年都有很多,其实这里面很多人,如果能够得到必要的治疗,是完全可以避免悲剧发生的. 作者的观点是人生就是苦难重重的,既然人生是苦难重重的,那么就应

团队开发中Git冲突解决

正常来说我们团队协作开发过程中,冲突是常有的事,下面介绍下本人在开发中的解决办法. 冲突的主要原因就是由于我们开发人员在分支的同一位置写入了不一样的代码,然后合并到主干上导致我们冲突. 方法: 当冲突发生时,我们可以选中冲突的代码 ---->点击鼠标右击 ---->Compare with ----->HEAD Revision进行两个窗口的代码比较即可,删除冲突的代码即可 解决冲突办法:删除冲突的代码,然后在add to index就可以了,然后我们在commit提交到本地即可.

(第三周)团队模式中对交响乐团模式的理解

今天看书的时候,看到了团队模式中的交响乐团模式,有些许看法,在此写一下,首先,顾名思义,对于交响乐我们都不陌生,交响乐的特点是家伙什多,门类齐全:各个表演者各司其职,各自有专门的场地,演奏期间没有聊天走动的现象:还有就是演奏都靠谱,平时看指挥:再者演奏的都是经过多次练习的曲目,重在执行,交响乐是人类音乐文化的高级形式,这里说到了交响乐团模式,整个团队中的成员对于整体而言自然不可或缺,但是还有一点就是个人的成功并不是整个团队的成功,我觉得这种模式是软件开发团队必须要有的基本素质,如果在项目中只想着

关于web前端开发过程中SEO优化的注意点

SEO优化通俗点说就是为了让网站在各大搜索引擎中更容易的被搜到,即提高搜索排行,从而提高网站流量的一个技术手段 在写web页面的时候,为了让网络爬虫更容易的搜索到页面,需要注意几个点: html语义化 刚接触web前端开发的时候很奇怪,既然html标签可以通过css进行更改它的内置属性,为什么还有这么多的标签存在 <div>,<h1>,<span>,<strong>.... 而现在,随着对前端的不断深入,才逐渐明白它的用处 语义化的html可以让开发者更容易