我想要的技术团队

从安居客出来之后来了学识堂,然后又来葡萄,突然发现自己在安居客的一年多被养的“娇惯”了许多,对公司,对自己所在的技术团队,有了很多的奢望和想法,仔细想了想发现有些东西也许不只是“我想要”这么简单,对于一个技术团队而言,有些东西真的是比较重要和有意义的,一方面吸引和留住人才,因为它可以让团队工作变得流畅简单,另一方面培养人才,因为这些东西有规范的东西时间久了就是积淀,就是教程,新手也可以有迹可循的顺着爬上前人的肩膀,从而更快速的成长为对团队有价值的存在。

一、工具

团队意味着不是一个人,意味着协作。工具于团队而言就是为了更好地协作和交流,于个人而言就是为了更简明的安排工作。

1.代码托管&版本控制 Git V.S. SVN

个人推荐Git,但是团队初期svn也是可以的。Git与SVN的差别请咨询度娘orGoogle。个人推荐它的另一个原因是,Git会有很多开源的web管理平台,譬如Gitlab,Gogs等。

这些平台一方面可以在网页上直观的进行一些浏览和操作,查看版本差异、版本历史,甚至代码内容,另一方面也可以作为一个文档分享平台来使用,他们多半对Markdown文档的展示都有很好的支持。而文档本身又是另一个很重要也很必要的工具。

2.文档库

开发团队的业务流程是有共性的,所以我离开一家公司还可以在另一家公司继续做新的工作。但是更有差异性,所以我每进入一个新的环境,都需要一段时间去适应,然后才能投入工作。

私以为,一个好的文档库是这样的:

A、新人入职的时候读一读:

(1)可以大概了解这个团队在做的事情
(2)可以大概了解这个团队做事情的流程和顺序
(3)可以知道这个团队在使用什么样的技术
(4)可以知道这个团队的团队文化是怎样的

B、接手新项目的时候读一读:

(1) 可以了解这个项目的架构是怎样的
(2) 可以了解这个项目使用了什么特殊技术
(3) 可以对这个新技术有个简单的入门学习

C、想要学一些新技术的时候读一读:

(1) 可以了解环境搭建的流程
(2) 可以简单的使用这些技术做出一些demo
(3) 可以看到团队中对这项技术使用的一些demo

D、拿到别人接口的时候读一读:

(1) 可以了解接口的调用背景
(2) 知道调用接口的各种环境下,需要传入的参数及意义
(3) 了解接口返回值的格式及意义

包括,但不限于以上。

个人习惯的是Gitlab+Markdown文档的配合。Gitlab做文档分享平台,Markdown可以给你的文档丰富样式,同时在Gitlab上的展示如同html页面一样,格式朴素而又清晰。
另外写文档的过程也如同写代码一样,这会让程序猿感觉很爽利。

3.Bug管理

对bug管理系统的认识并不是特别深,想到的先如下几条,如有其它,欢迎补充:

Bug管理流程:

1.发现BUG
2.Bug系统提出bug,说明bug问题,包括:
    (1)Bug出现场景
    (2)期望结果
    (3)当前BUG结果
3.指派给相应开发团队负责人/产品负责人
4.开发团队负责人/产品负责人指派给原功能开发人,或者其他人处理
5.处理人接收bug,标记bug状态为open
6.处理人处理bug
7.测试上线
8.处理人在BUG系统提交bug原因,描述处理方案,并将bug状态置为verified
9.bug提出方确认bug已修复,并关闭bug

需要的功能:

  • 对bug的层层指派
  • 对bug状态的标记,以方便各个流程都能清楚的知道bug是否被接收或处理
  • 对bug的处理结果和总结,以便类似bug再出现时参考处理

等等。。。。

4.排期管理

应该包含的基本内容是这样的:

  • 安排排期

    以项目为单位,对相关人员进行依次排期,比如产品、UI、开发、测试、产品验收,依次或并列排期指定时间,前后按照一个产品的产出顺序来排期。使得整个项目的流水流程清晰,这样每个阶段每个不同角色所应交付的成果也是便于检验的。

  • 查看排期

    以职能分组为单位,可以查看当前时间段内,每个人每天甚至更小的时间单位内的任务情况。

以上,
从项目角度讲,方便项目管理,安排各个流程阶段所应该做的事物;
从个人角度讲,合理安排时间,紧急事务提前,非紧急事务靠后,并合理安排时间进行个人学习提升;
从职能团队角度讲,可以查看所有人的时间安排状态,以便在新任务到来时,安排合适的人处理,避免人员闲置或者个别人员任务过重。

5.分支管理

在上文的工具中提到版本控制推荐使用git,比之svn,git很大的优势之一就是他的分支概念特别明晰,在团队开发,尤其是多团队多任务同时开发的时候,特别有意义。

做好分支管理,将分支号赋予更明确简单的意义,比如如下三个分支名:

1
2
3
master
project-2333
bug-666

很明显,master是主分支,也就是线上分支,project-2333,对应的是编号2333的项目的开发分枝,而bug-666则对应编号666的bug的修复开发分支。

每个分支上线之前进行 rebase master 操作,以保证不会与线上分支冲突

这样一来,就可以很方便的进行团队甚至多团队协作,大家都在改一个代码,做不同的项目,却不会在上线的时候因为多个团队代码之间的冲突而造成麻烦。

6.发布管理

接触过的新版本发布权限有两种分配方式,一种是:开发负责人,一种是:测试。或许还有比较奇葩的是靠运维的。。。

运维发布新版这种奇葩的实情我就不说了。。。。
第一种和第二种给你选,你怎么选?我选第二个。。。

第一个比较常见的是初创小团队,毕竟各职能部门之间分工尚不明确,可以理解,但如果一个规模化的公司还存在这种情况的话,那就不太好了。。。。

测试部门(为了区分测试这种行为,一下测试部门简称QA)虽然不做开发,但多半是技术出身,所以他们是代码上线与否的技术把关人。既然由他们把关,自然也应该由他们来做最后的上线操作不是么?尤其是一个大团队,好多小组对同一个代码库做不同的项目开发的时候,每个项目交给各自的QA来做最后的上线操作,岂不是比QA通过后再回来交给开发的负责人上线来的合理些?

有点跑题。。。。

其实我想说的,只是:一个发布版本的deploy工具。这个工具一定不是直接的svn或者git或者shell脚本,因为当发版本交给整个QA团队的所有人的时候,必然不能给他们所有人生产环境服务器的这种操作权限,因此我所谓的工具,应该是一个可视化的,比如web页面。只需要选择对应的项目或者分支,然后提交,服务器接到请求后自然会在线上执行相应的脚本,实现代码上线发布的操作。

哦对了多说一句,当网站的规模扩大之后,必然需要通过分布式服务的方式来确保网站的正常访问,这也就意味着,版本发布的操作,会同时在多个机房的多台机器上发生,这样的话就更需要非直接脚本的工具,来代替人做这些操作。

7.环境管理【开发、测试、(beta、)生产】

为了保证生产环境不会出现开发环境不存在的bug,或者换句话说,为了保证生产环境出bug的时候都能在开发环境、测试环境中重现bug,非常有必要的事情是:搭建一套与生产环境完全相同的开发、测试,以及线上测试环境。另一方面,为了在团队协作的时候对大家的开发环境也进行一些统一,需要一台这样的开发测试服务:

1.各类拓展及server版本、开发语言sdk版本、数据库版本等都与生产环境一直
2.开辟多个工作目录和测试目录,每个目录下除了域名之外其他的一切代码环境都一样
3.每个工作目录对应的是一个开发人员,每个测试目录对应的是一个测试分支
4.工作目录的可复制性,保证了新增加开发人员时,可以很方便的为他搭建一套可用环境
5.开通本地共享,大家可以再各自电脑上打开本地服务器的开发环境代码

8.其他工具
  • 定时脚本管理平台

用以部署脚本和查看脚本每次执行的结果状态

  • db平台

线上数据库除专门的数据库管理者或者dba团队外,其他团队人员理论上不应该直接接触到线上数据库,包括数据库所在机器的权限和navicat等工具查看的权限,所以一个db平台可以以web等形式,给授权用户提供一个查看部分库表结构和数据的工具性平台。

  • 内网vpn

外网下连入vpn可以访问公司内网资源,并对线上服务器设置仅允许公司网络访问,以此实现屏蔽的同时还能允许应急情况下的公司外操作。

二、良性的交流环境

1.技术是互相学习的东西

团队应当引导大家互相交流学习各自擅长或者感兴趣的东西,整个团队一起成长。

2.实践是最好的学习机会

作为一个不够主动的人,在ajk的时候感受很深的事情就是,我做业务开发,做多久下去,能接触到的都是业务开发本身的技术,而周边的包括运维/DBA/BI等部门的技术,完全接触不到,遇到的所有相关问题,抛出去自然有相关的人去处理.所以成长空间总是有限的,虽然你也可以申请转岗去做新的东西,但这种申请,并不是每个人都够主动去提出。

与此对比的,一个还是在ajk,慢查询出现的时候都是交给开发自己处理,学会了两样东西:定位慢查询的位置;优化慢查询。另一个是当年在育儿网实习的时候,南哥的态度是,交给你做你不会的东西,做完了你就会了。比如EDM邮件系统,交给了一个不会python的人,他依然用python很好的实现出来了。

所以,良性的交流环境,也需要一些识人善任的信任,我不会的东西你也交给我做,一方面我能做出来,满足你的需求,另一方面我做出来了,就学到了。

三、良性的产品流程

需求变更

1.需求变更害死人

需求变更在项目开发的过程中是很费时费力还伤感情的一件事,甚至有可能直接的导致项目失败。

要想尽可能的控制需求变更,那么就需要在最初的时候,通过多次严谨的讨论,对项目目标和细节都达成共识,然后再开始进行开发。良性的产品流程,应该是这样的:

1、需求产生
2、产品经理过滤需求,整理一份建议的需求说明文档作为PRD草稿
3、产品经理(一下简称PM)组织需求发起方、开发、QA、UED以及其他相关团队进行需求Review,对PRD草稿进行商讨,并确定最终目标及部分细节
4、产品经理根据需求Review,写出详细的PRD文档
5、产品经理组织开发、QA、UED进行排期会议,根据开发、QA的时间预估安排开发测试时间
6、UED、开发严格按照PRD进行功能开发
7、QA以PRD为依据对开发提交的项目进行测试,并将其中不符合的地方返回给开发进行bug修复【必要的时候通过bug管理平台进行】
8、提交PM验收
9、发版上线

以此流程,中间若出现任何不可控因素导致的需求变更,皆需要重新审核是否可变更,并对排期进行相应调整。

N、总结

毕竟写这些东西的我还是一个很底层的PHPer,只能根据自己的所见所闻所感去写一些我觉得有用的东西。然而没有站在过一个团队leader的位置上考虑过,就不知道这些东西到底哪些真有用,哪些知识说起来有意思但是然并卵的东西,总归还是需要自我学习和成长的。如果你恰巧读了我写的,而且又觉得哪里说错了或者可以有更好的表达的,以及更有必要的团队建设的意见,左侧有邮箱,请不吝赐教~