Pengfei-xue.GitHub.io

programming your life!

Home ~/

View My GitHub Profile

  • agile db development with sqitch

    我们使用Sqitch来管理数据库变更,目前,我们可以从任何一个线上数据库的备份,通过应用Sqitch Plan变更到最新的 状态。Sqitch提供了丰富的变更管理命令,常用的包括add, deploy, revert, verify, rebase, tag

    什么是Sqitch Plan

    Sqitch Plan包括了所有的数据库变更计划,Sqitch会根据Plan,去相应的目录(deploy, revert, verify)找数据库变更的脚本。 需要特别支出的是,变更在sqitch plan中的位置,在上线后,是绝对不能再改的。如果改掉位置,Sqitch就会不知道数据库

    目前处于什么状态。项目的Sqitch Plan位于项目的sqls目录中,sqls/sqitch.plan,里面的内容如下所示:

    %syntax-version=1.0.0
    %project=gaia
    %uri=http://git.xxx.cc/backend/gaia
    init-run 2015-09-21T15:20:55Z Pengfei.X <penhy#.com> # init run with sqitch
    create_table_shoping_cart 2015-09-22T02:50:36Z Pengfei.X <pephy#.com> # add table shopping cart
    add_installment_refund_in_service 2015-09-24T17:48:28Z Jiin.Wang <#@.com> # add xxx in api_service
    alter_table_add_wiki_in_service 2015-09-24T17:59:07Z Jin.Wang <#@.com> # add wiki in service
    add_uniq_index_for_api_shopcart 2015-09-24T15:45:35Z Pengfei.X <#@#.com> # uniq index on person_id, service_id and service_item_key
    ...
    ...
    @release-5.9.1-201603141632 2016-03-14T08:32:58Z Pengfei.X <pengphy#.com> # add tag for release-5.9.1-201603141632
    api_2016_03_16_alter_table_order_add_pay_time 2016-03-16T10:31:38Z Jin.Wang <waiabin@wsuo.com> # add pay_time in api_order
    api_2016_03_09_create_table_campaign_coupon_and_share 2016-03-09T06:32:27Z Chen <zxx@#.com> # api_2016_03_09_create_table_campaign_coupon_and_share
    

    如何写Sqitch Plan

    到Gaia目录sqls下,执行命令sqitch add your-plan-name -n "description for this schema change"。如下所示,

    Created deploy/your-plan-name.sql
    Created revert/your-plan-name.sql
    Created verify/your-plan-name.sql
    Added "your-plan-name" to sqitch.plan
    

    执行完命令后,Sqtich会在sqitch.plan中增加一行变更信息,并且在目录deploy,verfiy,revert中增加相应的 sql脚本。

    deploy/your-plan-name.sql中,编写数据库变更的具体内容,比如增加表的操作,增加字段的操作等等。

    -- Deploy gaia:create_table_api_doctorwhitelist to mysql
    -- xx名单
    BEGIN;
    CREATE TABLE `api_doctorwhitelist` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `doctor_id`  VARCHAR(100) NOT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    ALTER TABLE `api_doctorwhitelist` ADD CONSTRAINT `api_doctorwhitelist_doctor_id_ref_api_doctor` FOREIGN KEY (`doctor_id`) REFERENCES `api_doctor` (`id`) ON DELETE CASCADE;
    COMMIT;
    

    verify/your-plan-name.sql中编写,验证上述变更的脚本。

    -- Verify gaia:create_table_api_doctorwhitelist on mysql
    BEGIN;
    SELECT `id`, `doctor_id` FROM `api_doctorwhitelist` LIMIT 1;
    ROLLBACK;
    

    revert/your-plan-name.sql中,增加撤销操作,比如删掉刚才创建的表,删除新增的字段等。

    -- Revert gaia:create_table_api_doctorwhitelist from mysql
    BEGIN;
    DROP TABLE `api_doctorwhitelist`;
    COMMIT;
    

    如何变更,验证以及回滚数据库变更

    到Gaia的sqls目录下,运行sqitch deploy -t target_db,Sqtich会对比自己维护的变更记录与sqitch.plan文件中的变更,然后判断出, 自上次成功变更后,新假如的变更有哪些,然后依次运行新的变更脚本,同时运行验证脚本,确保变更成功;此期间,如果应用某个 变更失败,或者验证的时候失败,Sqitch会自动运行revert中相关的回滚脚本。

    如果是需要回滚到特定版本,那么可以使用sqitch revert --to-change target-change-name target-dbrevert命令会找到对应的回滚 脚本,并且依次应用。如果是想重新应用某个变更到最新的变更,那么可以使用rebase命令,这个命令会先应用revert然后,在运行 deploy命令。

    开发环境需要注意事项

    我们在使用Sqitch deploy命令过程中,经常会遇到can find xxxx,找不到某个变更的情况,这个是因为,我们改变了Sqitch plan中变 跟的次序,导致,Sqitch在确认数据库目前所处的状态时,发生错误。产生这个问题的最大可能是我们经常需要在多个分支做开发,避 免不了在某个分支A上加了新的变更Ca,在另外一个分支B上加了变更Cb,这个时候如果合并分支,那么sqitch.plan,文件就会产生冲突, 解决冲突的原则是,让sqitch.plan中已经应用在生产环境的变更的次序保持不变。 在测试,或者开发环境中,如果碰到这个问题,我们可以使用rebase命令,让数据回滚到最近一个没有冲突的变更点,然后重新应用 变更脚本,让数据库更新到最新的状态。需要指出的是,我们应当在自己的开发机上测试自己的Sqitch脚本,包括deploy, verify, revert。 特别是,注意自己revert脚本的正确性,如果写的不当,那么可能导致整个表,或者数据库被删,切记。

    修改完sqitch.plan之后,同步一下本地的master地址,diff master分支sqitch.plan,确认修改的内容不会影响已经部署的plan的次序

    上线过程中注意事项

    上线的时候,我们必须要先运行sqitch status这个命令,检查一下数据库的状态。在执行deploy命令时,需要使用screen或者tmux等 工具,避免出现由于ssh链接意外中断,而导致数据库变更值进行了一半的情况。 上线完成之后,我们需要给Sqtich plan加一个tag,tag的命令使用如下所示(教程):

    > sqitch tag v1.0.0-dev1 -n 'Tag v1.0.0-dev1.'Tagged "change_pass" with @v1.0.0-dev1
    > git commit -am 'Tag the database with v1.0.0-dev1.'
    [master 0595297] Tag the database with v1.0.0-dev1.
     1 file changed, 1 insertion(+)
    > git tag v1.0.0-dev1 -am 'Tag v1.0.0-dev1'
    

    打上tag之后,会在Sqitch plan中加一行,tag标记,上线完成后,我们把master分支合并回其它的分支,其它分支在开发过程中,如果 遇到冲突的情况,就知道,把新增的变更加到最近一个tag的后面(之前,我们遇到的情况是,不知道哪些变更已经应用到线上了,所以, 需要查看master分支上的文件,才能得知),然后调整相关变更的位置。

    参考

    1. http://sqitch.org/
    2. https://metacpan.org/pod/sqitchtutorial-mysql
    3. http://www.pgcon.org/2013/schedule/events/615.en.html
  • 我们是如何使用jira来管理项目的

    我们使用Confluence来管理我们的需求文档,使用Jira来管理我们的开发任务和bug。

    约定

    每篇需求文档,唯一对应Jira上的一个user story, 如果这个需求比较大,那么需要把这个 大的需求拆分成多个迭代,在多个迭代内完整这个需求,确保我们每个sprint可以按时交付。

    名词定义

    feature owner

    需求文档建立对应的Jira任务后,这个需求的负责人,具体责任见feature owner的职责

    user story

    JIRA上,产品需求在Jira上的体现。针对需求中的小功能点,我们做了详细的任务拆分,如果 同一个功能点涉及到了前端,后端和客户端,那么会在这个user story下建对应的开发任务给 我们的开发同学。

    开发完成,我们如何定义DONE

    Feature owner 确认对应的产品功能点已经完成,没有遗漏,满足产品需求。 如果涉及到上线的部署事项,需要在次版本的上线备忘中,写明。 更新JIRA user story中的Remaining时间,改为0,更新对应的状态为DONE

    Feature Owner的职责

    • 理解产品需求,确保没有偏差,开始feature开发之前,确保物料已经齐备,包括:设计图,产品文档中的疑问点已经解决等等。
    • 召集自己的虚拟团队,和虚拟团队一起拆分任务,制定技术方案,更新feature的评估时间。
    • 跟踪feature的进度,及时跟新Jira上的任务状态,确保迭代内可以完成。
    • feature开发结束之后,对照产品文档过对应的功能点,确保没有遗漏,确保实现跟需求一致。
    • 如果feature对应有上线配置,或者在上线时需要额外的步骤,在对应迭代的上线备忘中写明,确保没有遗漏。

    完整Sprint开发流程

    phase 0 相关team负责人,提前评审产品需求,以及相关设计 如果评审中,有不合理的地方,及时反馈给产品以及设计同学,讨论解决方案

    phase1 需求评审会议 评审产品需求,在Jira上建立对应的JIra user story 需求评审会时,开发所需要的物料需要齐备,包括,产品文档和设计图等 需求评审过程中,对产品需求有疑问,或者觉得不合理的地方,及时提出,产品和设计按照对应的解决方案调整 设计评审会议,这个会议中,需要明确所有涉及的UI和交互

    phase2 技术初步估时以及指定feature owner 会议中,需要对本次迭代,各个team可投入的资源做估计,同时,对每一个user story做开发时间估计,记录在jira中。 此会议需要对每一个feature确定虚拟团队的成员

    phase3 feature拆分以及技术细节会议 对应feature的owner,召集自己的虚拟团队,针对feature拆分任务,指派给对应的开发,并且制定详细的技术方案。 会议中结束时,如果虚拟小组的对此feature的评估时间有偏差,需要更新对应user story的估时。

    phase 3.5 确认提测,已经发布时间点

    phase4 开发 进入此阶段时,需要保证物料齐备。

    phase5 测试 进入测试阶段,测试部分需要指派一人,跟开发一起开早会,更新测试进度。

    phase6 发布 发布顺序为:后端先发布,预留1-2天给测试做线上回归,之后发布客户端。 安卓首发三天后,更新backend的自动更新提示信息。

    目前执行状况

    我们在执行过程中发现了一些问题,主要是产品需求文档管理,需求变更和feature owner职责。

    首先是需求文档,产品经理给的需求文档中,对于一些细节没有详细的描述,比如出错后怎么处理,输入框的 提示文案是什么以及交互的细节,导致我们开发在做的过程中,出现了理解不一致的情况,结果就是实现出来的东西 不一致。之前我们在拆分任务,评估工时的时候,没有细拆文档中的功能点,导致某些功能的预估时间跟实际的开发 时间差了很远,本次迭代我们做了细拆,在评估的时候,对功能做深入的分析,详细评估每个小的功能点。虽然最终 实现时,还是有一些偏差,但是还算在掌控范围之内。关于产品的另外一个问题是,开发过程中,形成的统一意见没 有及时更新到文档中,导致的问题是,在demo时,有的开发说当时会议是这么决定的,其它的开发说不是,在下个迭代 中,需要产品及时去更新需求文档,如果有变更,那么走我们的需求变更流程,确保对应的开发跟测试同学能形成统一 看法。

    关于需求变更的事情,在之前的文章中做了介绍,这里就不详细展开了。

    最后,谈一下feature owner的问题,目前的观察是,feature owner没有准确定位好自己的职责,上述文档中的职责 没有做到,比如在进度控制,更改jira状态等,特别是更改jira状态,几乎每天都需要吼一下,让大家及时更新各自 的jira task状态,我觉得导致这个问题的原因是,我们没有形成很好的惩罚机制,没改也就没改了,没什么大不了, 但是对于管理来说,看到一堆任务没有在doing里面,会心慌。期间也跟feature owner做了1vs1的谈话,面对面也好, 通讯工具也好,但是效果不是很理想,这个问题还是要在之后的迭代中push一把,让feature owner养成习惯,每天 同步自己负责的feautre的进度。

  • how to manage requirement change

    之前我们在迭代开始后,需求文档还是不断地在改,期间引发了很多沟通 成本,开发需要不断地去跟产品经理确认需求,在开发过程中,也经常出 线开发得过程中,发现一堆小问题,比如某个组件得提示文案不准确,动 画效果没有在产品文档中明确说明,交互细节缺失等等。产品经理在没有 通知相关得情况下变更文档是比较讨厌得事情,大家都不知道这个需求变 了,测试不知道,开发不知道,最终上线,发现有些地方不符合产品定义。 还有一些情况是,运营同学反馈问题给产品,产品觉得是bug,但最终开发 去排查的时候,却发现,产品就是这么定义的,属于产品feature,而不是 bug。

    这个过程中,没有明确定义需求变更得流程,需求变更没有任何成本,最 终是开发来背锅。最早得时候也定义过产品变更流程,并且得到了大家的 认可,可是,我发现我们得执行力不够,每次都是费了很大得力气定义流 程,大会小会开了一堆,形成流程后,大家还是不按照这个来走。开发埋 怨产品文档不够仔细,经常变更,产品委屈他们也不想。我们要让产品文 档做到100%完美也是不可能实现的任务,总会有一些小细节得修改,但是 修改需求需要走完整得流程,确保各个责任方都可以知晓这个变更,开发 经理需要确认这个变更是否会影响正常得开发节奏,到时发布不了。开发 需要知道改了哪些地方,及时处理变更;测试也需要知道,从而修改测试 用例。

    我们尝试了一些变化,我觉得比较好得几个地方是,第一重新定义了需求 得开发流程,从需求提出,到开发,到上线得整个流程,每个步骤中都有 明确得定义,比如需求评审得时候应该准备好什么,开发开始前需要具备 哪些条件等;第二是,我们定义了feature owner,他需求带大家拆分任务, 检查进度,跟产品沟通物料有哪些确实,确认产品文档中得疑问点都已经 解决等等;第三是,定义什么是完成,我们之前是觉得开发API调试ok后 就是做完了这个需求,这样导致得一个问题是,我们上线得时候出现各种 问题,比如配置不对,兼容性没有考虑周全等等,所以我们引入了完成的 定义,比如上线备忘中,必须要写明上线流程,配置变更项,feautre owner需要检查实现是否跟需求一致等。不过到目前为止,已经有两个迭代 了,我得观察是,feature owner没有起到应有得责任,尤其是进度和完成 质量方面,迭代过程中,也私聊过feature owner但是效果不是很好,这 部分还需要继续去推这个事情,feature owner还没有转角色,没有很好 地适应这个角色,希望再有一个迭代能有大得改善。

    今天发生一些事情,引起了变更,而这个原因是我自己,今天是我们产品 迭代周期里得最后一天,下午做demo演示,所以上午就一直在过产品需求, 提出自己得建议,大部分是交互和使用方面得小细节,比如点击按钮,提示 某个内容确实,但是确实内容却被输入发给覆盖了,这里比较好的交互方式 是点击按钮,收起输入法,或者直接高亮突出需要完善得部分给用户,而 不是让用户去思考,凭着刚开始进入这个页面得记忆,来找到需要完善得 内容;其它一些建议,包括文案读不通,icon没有考虑多种状态得切换等; 其中引起大家异议得是,发布帖子后跳转位置得定义,发布完帖子,我们 目前得逻辑是跳转到首页得feed流,但是,我当时手机上看到得是,跳转到 了首页,但是由于feed流在页面比较靠下得部分,所以,觉得特别突兀, 发布完成后,竟然看不到自己得发布内容,于是,给产品提议发布后跳转到 帖子详情页,并且私下跟产品建议,跟开发同学确认,如果进度有影响,放 到下个迭代中完成,但是,产品最终还是直接让开发改了,android客户端 改得比较快,iOS工程在demo得时候还没有完成,提出了异议,这个地方是 之前得版本中特意加得跳转逻辑,应该保留,而且是已经到开发接近尾声得 时候,所以不应该改。我觉得这个异议是正确得,我没有很好地控制变更, 而是默认了产品的随意变更,大家对这个问题也比反感,这点是我之后需要 注意的地方,吸取教训。

    会议中,有开发提出,产品改了这个需求,但是他不知道得情况,产品说 已经开过会,跟相关得开发已经确认过,并且修改了产品文档,QQ上也提过 了,我们现在有太多得交流工具,QQ,邮件,hipchat等等。不过,还是会 有被遗漏得情况,我没看到,我不知道这个事情,这种情况还是不断地出现, 我们需要定义并且严格执行得一个流程,来避免这种情况一而再再而三地发 生。

    开完会之后,思考了很多,关于需求变更,之前得定义都不去考虑了,现在 看起来一点可执行度都没有,提了一个想法,我觉得这个早应该提出来了, 产品在变更需求前,必须要得到feature owner,相关开发以及测试得确认, 之后才能做变更。产品文档在开发开始后,就不允许再被修改,如果有需要 修改得地方,必须要走完整得需求变更流程。关于这个提议,我自己会跟 这个事情,确保这个流程得到完整得执行,不再出现,需求变更后,大家 还不知道得情况。

  • 关于招聘

    已经不太记得一次给其他人面试的过程了,简单一句话形容就是不知道问什么, 当时好像自己特别紧张,估计比面试者还要紧张吧。究其原因就是,自己那会 还啥都不懂,去面试其他人自己心里没有底,不知道问什么。你得知道对方会 什么,自己会什么。自己问的问题需要能考察出对方的能力,同时还需要能确 定对方是否符合职位要求。

    经历多了,自己紧张这种情况就没有了,但是,还是会不确定要问什么,当时 面试的第一反应就是去网上找一下面试问题,看看面试者回答是否正确,自己 没有能从面试过程中学习到什么,比较惭愧。面试其实也是一个学习过程,面 试过程中,你可以知道如何跟面试者沟通,如何让面试者发挥出应有得水平, 如何确认面试者符合职位要求等。

    面试之前,我们最好能仔细了解一下面试者得简历,从简历制作上,我们可以 看出面试者得一些状态,简历最好简单明了,如果有自己得博客或者github地 址最好能粘贴上,这样对面试官更加全面地判断你得水平还是有好处的,我自 己收到得简历如果有面试者得这些信息,我会去仔细看看,初步了解一下面试 者得编码风格,对问题得看法等等。另外就是,尽可能提供PDF格式得简历,不 要提供doc或者docx之类得简历,这增加了打开简历得成本,有夸张得面试官估计 都不会打开看这样得简历,为了看一份简历,还要买个正版得office岂不是很 夸张(个人不喜欢用盗版软件)!

    面试时,我一般会让面试者简单介绍一下自己,其实没有太多值得参考得信息, 简历上都已经写得很清楚了,这样做得原因是,想让面试者先放松一下,不要 过于紧张,当然,如果自己因为没有时间提前看面试者得简历,那么在面试者 介绍自己得时候,可以看看简历。

    针对应届生和社招两种情况,我得关注点也不一样,对于应届生或者实习生, 那么我主要问他自己从事过得项目,如果没有实习经历,那么通常会问这位同 学一些课本上得知识,看看掌握程度,问得比较多得问题是,什么是进程,什 么是线程,他们之间有什么区别;介绍TCP连接建立过程,断开过程,为什么 建立连接得时候需要3次握手;数据库设计的基本范式等。另外,对于没有实 习经验得学生而言,可以考察他们解决问题得思考过程,看看思路是否清晰, 沟通过程是否通畅。因为写程序,其实也就是把人类得思维过程用机器可以 理解得语言表达出来,所以思路清晰是很重要的。如果面试者是有实习项目经 历得同学,那么会问一下参加过得项目主要是干什么得,自己在其中做除了什 么贡献,期间遇到了什么问题,如何解决的。面试得同学中,有很多虽然参与了实 习,但是大部分都没有真正去思考这个项目,或者甚至是根本就讲不清楚自己 在项目中做了什么,一般遇到这种情况,基本上就会被pass掉了。对于学生过 来面试,那么结束得时候,给予他们一些建议和意见是必须的,让他们有一个 机会可以知道自己如果想应聘成功,需要在哪些方面提高,我想者对他们将来 得面试会有帮助。

    如果是社会招聘,那面试得难度会提高很多,除了介绍自己做得项目外,也会 有很多基础性得问题,另外也会问一下架构得问题,还有就是考察面试者对 需求得理解能力。这些面试过程,其实可以让面试官也学到不少知识,接触很 多自己之前没有碰到过得技术,我自己经常会问一些对方简历中提及得,我很 感兴趣,但是没有深入了解过得技术。期望对方可以讲出一些自己得理解,可以 考察对方得水平,同时也能让自己有一个提高,一举两得。面试过程中,我自己 还经常问得问题,就是自己在实际开发中遇到得问题,建议大家平时收集一下这 些问题,在面试过程中,可以用这些问题,看看对方有哪些解决方案。面试者中, 比较反感得是,自己什么都不会,但是还很牛逼哄哄,有点受不了,给面试官 一个诚实稳重的感觉还是比较重要得。不知道是不是面试多了,还是自己有天生 的第六感,在面试过程中,可以很自然底感觉到对方是否是在吹牛,是否半瓶子 水晃荡响。

    最后给面试官一些建议吧,

    • 平时注意收集问题
    • 仔细看面试者得简历
    • 针对简历中描述,深入问下去,考察面试者得真实水平
    • 面试过程中,注意自我学习和提高,如果碰到自己也不会得问题,那么,事后及时查看资料
    • 如果开始10分钟觉得面试者达不到要求,那就提前结束吧
    • 面试过程中,给对方充分得发挥空间,如果对方一时卡住了,及时提醒一下对方,避免陷入死胡同
    • 对于学生,一定要耐心同时面试结束后给予正确得指导和反馈
    • 让自己team得同事也简单聊一下,看看对方是否跟自己得团队合得来
    • 故意给一些需求不清晰得题目,让面试者在回答得过程中,考虑需求范围
    • 沟通是否顺畅非常重要
    • 不要勉强录用,否则自己整个团队会遭殃
  • 近来的管理心得

    过去

    刚开始加入团队时,用户版对应的后端,只有两人,同时要面对测试,客户端。由于我们某些 人,觉得某个迭代递交测试后,开发人员的时间就都在浪费,没有产出,所以,我们在两 个迭代中间,通常都会有一周的时间是重叠的。导致的问题就是,后端人员严重不足,这个周 同时需要面对测试提出的bug,以及客户端在等待新版本的接口。有些人会说,弄个假数据,丢 给客户端不就可以了么,是的,说起来很轻松,但是,实际做的时候,你就会发现,自己被很 多事情打扰,并行的事情太多,没有完整的时间做事情。当然,当时的测试也特别幸苦,每次都 是夜里12点多,还在测试,提bug,而我自己也经常是在夜里配合测试修bug。

    当时自己会有很多时间去参与开发,而管理部分几乎没有时间去参与,所以在团队建设方面 没有任何长进,不久后团队里的一位成员就走了。走的时候,我才真正有时间去跟他坐下来 仔细聊聊。平时,对他的想法等都没有了解过,也不知道他对当前的工作安排是否满意,他 的职业发展方向是什么,期望从我这里得到什么帮助等,感到特别惭愧。之后的一段时间, 来了一位应届生,其他人给我的反馈是有潜力,很不错的孩子,但是,实际做开发下来的感觉 是比较菜,当时自己没有太多耐心去教,当然也没有那么多的时间去管这方面的事情,另外, 上司也觉得特别不靠谱,所以,在做完一个迭代后,就直接调去其它组。这个事情上来说, 我发现自己缺乏耐心,特别是对应届生,这是需要改进的,毕竟,他们进来,就是自己的组员, 作为leader需要给予足够的时间去培养他们,带他们走过那段比较迷茫的时期。

    再后来,又招了一位一年工作经验的小孩进来,也没有通知我面试,给我的反馈是,这孩子 特别靠谱,工作能力不错。于是乎,自己也没有过多地去判断,再次,做了几个任务后,发现 粗心大意的不敢恭维,代码没有逻辑可言,另外,有些代码还没有写完,就已经递交merge request给我review,当时,好在控制住,不然,如果有这个权利,估计会直接开掉。对于招聘 来讲,我觉得还是应该让对应接收组的leader面一下,最好还能有一位组员能跟候选人沟通一下, 从各个方面来考察候选人,因为招进来人后,最终是leader,以及对应组的组员对其负责, 如果候选人不符合预期,不能很好地跟同组的同事融洽相处,那么最终遭殃的还是这组的 成员。之后又出现一次这种情况,还是反馈说特别牛,结果没多长时间就被开了。从这几个事情上,可以看出来,招聘过程还是很重要的,需要严格把关,不然很多人会被拖累,面试过程中,不能只是胡侃大山,而没有去问一些可以判断候选人是否跟我们要求的能力匹配的问题。

    之前公司也做过一段时间管理,但是,现在回想起来真的是有些可笑,只是简单地跟大家开开 早会,开开周会,布置一下任务,对同事来说,除了形式上跟之前的保持一致,没有太多变化 外,没有任何帮助。我觉得,人都需要在艰苦的环境中,扛住压力,然后慢慢地去尝试改 变身边的事情,不断去学习,进步,才能适应公司的步伐,对自己的发展也更有利。

    现状

    目前,我带的后端团队,加我一共6人,另外,用户版作为单独的项目,虽然没有正式的宣布, 或者说明职权范围,但是,目前看来用户版也是我来管理。用户版的开发包括后端,前端,iOS, Android加起来差不多15-20人左右。

    后端团队对目前的需求量说来,人员还算充足,我可以有跟多时间去考虑团队建设的事情, 有新人进来也可以有时间去带。另外就是,我可以有完整的时间去做一些之前没有时间去 做的事情,比如说,重构,改善开发框架,思考如何去提高以及保证开发质量,不断完善我 们的文档等等。

    团队大了之后,有很多事情需要有专人去做,特别是一些对外沟通,屏蔽意外 干扰等。同时,也需要有人去把控整个项目的进度,监督开发物料是否齐备,归纳跟踪开发 过程中出现的问题,收集大家的牢骚等。每个人的时间都是宝贵的,作为leader更需要知道这点, leader需要给团队提供一个良好的开发环境,协调开发过程中出现的不和谐的声音,解决开发 过程中遇到的疑难杂症。

    我们最早每天都会有早会,早会的内容估计大家都可以猜的才来,就是转圈每个人都汇报自己 的工作,更多的是流水账形式,反思了一下,这个流程对大家解决问题没有太多帮助,大家在说完 自己的事情后,基本上不会再去关注其他人的事情。开早会的目的是,让大家有机会可以提出 开发中遇到的问题,只有提出问题,整个团队才能知道发生了什么事情,比如哪些开发资源还没有 准备好,哪部分进度落后了。另外一个问题是,我们的早会是所有参与用户版开发的同事一起开, 很会比较多,虽然,95%的情况下都能在15分钟内结束,现在想起来是结束的太迅速了,但是, 随着团队越来越大,以后办公室就不够地方了,:)。最后有一点是让大家不太舒服的,有些人可以 不参与早会,第一次有人提出这个问题的时候,我感觉自己很尴尬,不知道如何去回答,也不记得 自己是如何回答的了。基于这些情况,我取消了早会,改成周会,平时由feature的owner去协调 每个任务的进度。

    之前我们的一个不好的地方是,有些事情召集会议,有的时候还不是一次回忆,为了讨论一件 事情,得出一个结论,大家话费了很多的时间和精力,最终有结果后,就没有人去跟踪相关问题进度了,导致有些事情,只是说起来好听而已。

    现在来说说我们周会都包含哪些事情,首先是跟中当前迭代的进度,但不是流水账,轮流去说, 而是对照着jira上的任务状态去了解每个任务的情况;然后是跟踪上次周会中提出的问题,看 一下问题是否解决,持续地去跟踪;最后是留时间给大家吐槽。刚开始的两周,能看出大家都不 太适应这种改变,吐槽阶段,基本上没有人说话,都是自己在巴拉巴拉地提一些问题。但是, 经过这几次后,这次的周会给我的感觉非常好,已经有同事主动收集遇到的问题,对某些事情 的不满,这是我希望看到的结果,了解大家的痛点,我们才能去变得更好。(此处聊点别的, 在微信上不经意的看到过一句话,一件事情,大部分人都不认同,但是,你坚持去做了,会 有收获)。取消早会后,需要feature owner去持续跟进各功能点的开发状况,跟踪哪些物料还 没有齐备,目前来讲,feature owner还没有发挥出应该有的价值,没有负起相应的责任,需要我 不断去提醒,希望这点在将来可以变得更好。

    推荐阅读

    1. 结网
    2. 精益开发实战
    3. 硝烟中的Scrum和XP : 我们如何实施Scrum