码农的日常

        很长时间没写纯技术之外的文章了,做技术这一行,什么都偏理性,一定要有个所以然,写出的文章感觉都是像写代码那样,一定要跟前面接得上。我觉得初中就应该可以开始学编程了,因为我觉得政治课本的那些句子,没有一句跟它前面的那句话有关联的。

        回到正题,本来想写一篇文章谈谈如何团队合作,想了一下,自己资质不够,而且这并不是我想表达的,所以我觉得我写自己作为一家CMMI5的公司当工程师,我的一天是怎么过的,以及,关于我的团队是如何协同工作的。

公司属于弹性上班,我们这个team基本都是恰好避开上班高峰期的十点上班七点下班,每天早上8:37出门,在全家买了早餐,9:40左右到公司。


第一件事:查看邮件

查看是否有未读邮件,有一些需求文档,任务分配,培训课程,会议,或者团队成员请假的信息等等通过邮件的方式能收到,任务分还会有pmt跟进。


第二件事:查看skype信息

我们部门内部沟通还有跟客户沟通都是通过skype的,所以必须要查看skype的聊天信息,可能是测试组报了bug需要跟进,或者team leader给你分配了临时优先级比较高的任务,或者在channel上客户反馈了一些问题需要得到我们这边的响应,或者在分享的channel上有同事分享了好的文章,或者别人需要跟你讨论技术问题或者某一类问题的解决方案。


第三件事:登陆PMT查看任务

一般我们的工作都依赖于pmt上面的task,客户的每个需求以及每个bug,我们都会在pmt上有对应的ticket给我们跟进。比如测试报了一个bug,那么测试人员会在对应的parent ticket下面创建一条子ticket,然后分配跟某一个工程师去跟进,比较棘手的会直接assign给team leader。


第四件事:填写worklog

我们属于弹性上下班的,但是我们会严格记录自己每天花多少时间做了什么事,也就是每天都要填写worklog。填在你跟进的那条PMT ticket下面。比如说我今天改某一个bug,花了一个小时,那么我得在这条ticket下面写明fixed bug,时间是1h。而且还要区分你这一小时是RA(需求分析),还是UT(测试),还是coding,还是其他的,这样做的目的是为了在做post review的时候做统计,如果一条ticket的开发时间是4个小时,测试报了bug你还花2小时coding,那就说明效率有问题了。


第五件事:准备好开发环境

从SVN update代码到本地,打开IDE,打开Citrix登录到远程服务器,打开本地数据库管理工具以及远程服务器数据库管理工具,文件比较工具,workbook(也就是需求文档),打开有道云笔记(有些重要的东西需要记录)


第六件事:写代码

根据PMT的任务的优先级,开始coding或者改bug,同时要切换时间support channel上的问题。一天基本上都是这样,或者teamleader有临时任务给你,或者有培训要去,或者要开会讨论需求。


第七件事:提交代码

自己的代码UT没问题之后,要提交到svn,同时要写comment,comment一般是你coding对应的那条ticket。比如我这段代码是改一个bug,这个bug的ticket是CWRL-0001,那么我提交代码的时候comment就写这个ticket号,同时也可以写一些其他你觉得很有必要要说明的comment。


这个是我在公司基本每天都铁定要做的一些流程,可能还会有一些我忘记了。而对于团队如何合作呢,我也说一下。
从大的方向说呢,其实就是一条线,用户给了一个需求,开发人员开发,最后用户验收。详细点呢,就下面那样:

RA

RO

Design

Coding

UT

Testing

Release to Stage

Support Test team

Release To UAT

BA Feedback

Release To Production

Post Review


BA收集用户需求,做需求分析;
team leader把需求具体化,实现这个需求需要考虑到哪些方面;
team leader跟developer一起做design,把需求细化到可以让开发人员去coding,这个时候也会在PMT上创建对应的ticket,ticket上面会说明solution,大一点的会要求权利更大的领导去review。
开发人员根据ticket开始coding,并且UT(开发人员自己测试的话,我们公司内部叫UT)。
开发完成之后发布人员发布到Staging上面,然后测试组的同事进行测试,报bug,每条bug都会在pmt上体现;
开发人员跟进bug,并且support channel上的问题;
测试完成之后发布到UAT环境,这个环境是给真实客户测试用的,正常来说,代码上了uat之后,不能有新需求之外的其他bug,上UAT需要发release note,也就是需要领导审批;
我们的客户在UAT上测试之后,如果没有反馈,那么就会根据原先的计划发布到Production,这个也是要发release note的。

如果Production上的代码出现问题,优先级是最高的,我们一般叫adhoc,很多都是需要马上处理的。


代码注释 ==》关联PMT

代码审查==》至少两人互相review
TBC
时间粒度==》按小时分配工作
TBC
发布流程==》版本号规定,配置步骤,发布工具的开发
TBC