[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
少尉skystary
2018-11-29 21:40:13 显示全部楼层

马上注册,玩转Robomaster!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 skystary 于 2018-11-30 05:58 编辑

趁此官方推出知识共享平台之际,我们想分享一下关于线上协作那些事儿。

第一阶段(技术改项目)
随着Robomaster赛季的发展,机械、电控、视觉的固有架构已经根深蒂固,但是我们也发现了很多问题,从资源分配,任务分配,进度管理三个方面,按照兵种划分远比技术划分要好得多,因此当我有了这个不成熟的想法之后,战队就多了很多群,这种头像可以说是一种很前卫的设计风格了,优点略过几百字,打开QQ的一瞬间,会有一种自己已经掌握一切的错觉。

XZWHCMA@BB8AL{UDQ[B[3YB.png

但是,分布式的群管理带来了新一轮的管理混乱,首先,技术组和项目组共存,他们是交叉分组的关系,这时候需要上一张官方图:
8G%JLRNRC3]JTO[(DO5A65U.png

一开始就说了,这是不成熟的想法,我们这样分组的时候,机械电控视觉依然有技术组,并且在技术方案上有很强的话语权,新建机器人组之后,强拧的味道大于实际的意义。这一块,是想法不成熟的问题,可以解决。

但“分布式”的群管理,让战队的信息交流成本变大了,所有信息都分散在这么多群里,信息不对称的问题依然存在,然后我认清了一个事实,整个战队的研发的重要信息,依然是战队关键的几个人把握着。这个无解。所以,建多个群管理的模式失败了。

第二阶段(技术组惨遭被砍, 战队成员集中在一个群里)
从2019赛季开始,西电机器人队不再划分技术组,也没有技术组长了,参考赛季规划。这样做的最初灵感,来自西交的“大小会”制度,于是我们就完全按照兵种去划分了,战队开大会,兵种开小会,每个兵种组设一个兵种负责人去当几个人的leader。从资源分配,任务分配,进度管理,也都顺理成章地过渡到了兵种项目组。

在赛季规划当中,我们也有所体现,即Office Project(后来6个负责人几乎都没学会怎么用这个东西,慎重考虑,一方面没有那么多老队员来做管理,另一方面新队员在技术上投入更多,没心思去做专门做管理)

mmp.png

另一个变化是又回归了一个战队总群的模式,(古人云:合久必分,分久必合)
其实,QQ群一直有协作上的不足,比如发个重要通知,被刷上去了,等等。
此时,团队协作软件呼之欲出。
需求就是:能够汇总整个战队的信息,消除信息上的不对称。

第三阶段(试用期)
不同的协作软件其实千差万别,TeambitionTower、明道、日事清。。。。但是他们都收费(捂脸),而且几家软件越做越大,功能越多,上手的成本太高了,面面俱到不是好事。打卡啊、会议啊?签到,像钉钉这样的带有社交和群聊,真的是我们需要的吗?我觉得不是。

这就像有的作家擅长文笔,有的作家擅长写故事,有的作家擅长构建世界观。这是完全不一样的事情。

社交已经有QQ了,习惯改不掉的。打卡/会议/甚至视频?报表!对我们来说也不需要,我甚至萌生了自己开发软件的想法。

第四阶段(leangoo看板)
以下略去上百字的介绍,但是leangoo可以满足汇总整个战队的信息的需求,本身零上手成本。

leangoo.png

Leangoo看板就是块电子白板嘛,所有的东西,都需要自定义,完全的自定义(因为它真的简单到一张白纸,而且简陋到没有手机app,就一个网页,但是好用啊)

整个战队40人同时工作在看板上,拥有一样的编辑权限,按照“泳道”分配兵种、“列表”划分全部任务,如果1个人1个周完后1个任务,那就是4个任务,40个人就是160个任务卡片,这已经趋于极限了,因此,我们一个月换一张新看板,上个月没做完的任务可以结余到下个月。

看板任务透明化+战队总群信息交流,我觉得真香。

但是之后,也暴露了一些问题,连续使用了3个月之后,一张看板40个人同时鬼画符~信息量太大了,因为保密关系很抱歉不能上图,但是你可以脑补一下,你从一个这么大的看板上,找到一个任务要花多久,完全看花眼的感觉。

另一个致命问题,看板无法形成一个完备的研发流程,任务的分派、执行、审定的边界开始模糊。。。。当队员们过于发挥“主人翁”的意识也是一种混乱。

因此,线上协作仅仅是满足同步信息的需求是不够的,该明确的战队的角色还是要明确,需要引入研发流程。

第五阶段(TAPD)
经历了leangoo看板,我又开始考虑更重的在线软件。最后,我选了一个界面最丑的,操作最反直觉的,但是确实真香的平台——TAPD

工作台.png

为什么说它反直觉呢?因为确实相比流行(更容易被百度到)的平台相比,TAPD的上手体验并不好。但是看了今天官方推的ONES.AI,两个平台相似度达到90%以上。感觉是时候来分享一波人生经验了(来蹭电机了)

正文开始(官方专用粉)

什么是迭代?
需求分析、方案讨论、开始研发、测试,这一套流程是官方推荐的(你需要在赛季之初就做规划,然后做设计报告,然后。。。)这个难度太大了,尤其是新队员,他对做一辆车花多少钱花多久,心里根本没有B数,这也是为什么需要老队员来带。

这里的迭代是PATD/ONES.AI里的迭代,通俗来说,就是一个周期/一个Group of 需求/缺陷,更通俗的说,我不知道我最后要实现成啥样子,走一步看一步,但是我规划眼前的肯定没有问题。这一轮迭代解决XXX,到了下一轮迭代有了新的需求,新的问题,我再重新规划下一轮的迭代,这算一个基本思想了吧。

以机器人为例,任务分配是以周为单位的,那么根据我们的经验,一轮迭代是以月为单位的,之前的leangoo看板,我们也是一月一换。

Then,以步兵机器人为例,10月份,你要设计第一版底盘,首先你要定个小目标,月底要实现哪些功能,不实现哪些功能。这个轻重缓急,我相信老队员都能做到。然后10月份一轮迭代完成,11月份的迭代是建立在10月份基础之上的,计划赶不上变化嘛,10月没做完继续做or放弃?10月新出现的bug需要不要优先考虑?然后下一轮迭代。

瀑布 VS 敏捷
啥是瀑布可以参考ms project(很难规划和上手),而迭代是敏捷中引出的概念,大多数RM战队研发的过程,都是呈现周期式的,只不过这个周期可能界定得很模糊,可能是一代车,可能是老队员给新队员的阶段性DDL,并不像提交赛季规划和设计报告那样事无巨细的考量。这其实已经是一个敏捷开发的雏形了。

需求池 & 规划到迭代
一开始使用TAPD/ONES.AI,你可能会搞不懂一大堆状态和各种很难上手的设置,继续分享我们的做法,我们会把任务(以头脑风暴的方式也好,长远布局的方式也好)都安排在需求池,需求池要汇总那些对比赛有贡献的技术需求,有的需求因为优先级不高or难度太大,可能是一直躺在需求池里,而手里要做的something,我们会规划到迭代

需求分为没有规划到迭代已规划到迭代两种状态,需求迭代会有一个从属关系,例如10月步兵迭代,会有8个需求,但步兵的其他需求还没有规划进来。随之而来的进度跟踪,各位项管自行探索。

规划到迭代.png

需求 & 缺陷
两者是并列关系,并且都可以规划到迭代,一轮迭代是由N个需求和N个缺陷组成的。缺陷,是源于测试种发现的问题,这种解决临时问题的需求单独出来,叫缺陷

有的需求和缺陷一轮迭代没有完成,需要反复规划进下一轮迭代,这些技术点一般都是像卡弹这类老生常谈的问题。

发起需求 & 缺陷
这里是最混乱的地方,需求可以从各种地方的创建,缺陷也是,甚至缺陷可以从正在迭代的需求中创建。推荐划分用户组权限,不然真的会选择困难。

理解2个概念,有助于上手:
1. 表单
需求和缺陷都是一种表单,不再是看板的卡片那么单纯。该表单的创建人和验收人默认是一样的,而执行者另有其人。需求会捆绑项管研发2个角色,而缺陷会捆绑研发测试2个角色。

由项管发起需求,研发工程师实现需求,由测试工程测试,然后发现bug,反馈给研发。

理想的是这样,但是我们实践之后发现不存在的。第一,RM战队没那么多人。第二,研发太惨了,要面对各种甲方。这一块完全取决于各战队自身情况,至少在我们这里,研发也是可以提需求的,发挥一下主观能动性~而缺陷也是由研发自查发现的。

2. 状态流转
在PATD中,需求被安排之后,是To-do状态,执行人可以选择接受/拒绝这个需求,从接受需求(表单),到已完成,这个过程是流转。有个故事墙的东西,我们用PATD时是屏蔽了的,感兴趣的可以观察一下故事墙是怎么随着表单状态变化而变化的。

流转.png

代码关联与DevOps
创建/规划到迭代了一个需求or从需求/当前迭代发现缺陷,这个是常规操作,为了防止大佬们漫无目的地写代码,代码是可以关联的。
提交格式:
--story=[storyid] -- user=[user name]
--bug=[bugid] -- user=[user name]
--task=[taskid] -- user=[user name]

例如:git commit -m" 修复了串口发送不同步的问题。 --bug=100036 --user=Alex"

可以从git提交记录看到关联了哪个需求/缺陷,也可以从需求/缺陷表单中查看git提交记录。好处,显然易见。

但是这里有个问题,代码是所见即所得的嘛?

DevOps是针对互联网的说法,对于RM研发来说,完成需求/弥补缺陷代码,只是Dev阶段,上车测试了,才是Ops阶段。

参考:https://github.com/hackath/AutoCar,使用的是Travis CI,关联的是TAPD平台。

最后,打个标签~ 万一比赛崩了,你喊个30秒技术暂停~ git pull到之前一个稳定的代码版本都可以 (只要现场网好),这就是代码要做交付的意义。

代码关联.png

正文结束

最后是对线上软件的思考:

不使用协作管理,团队人数超过20人就会奔溃(当年每天私戳队员追进度心里有阴影了)。使用看板or其他类似软件,团队人数只能约束在30~40人,而使用TAPD/ONES.AI工具,可以轻松管理比40人多很多的人,至少上限要高很多。

对于我们RM战队,项目经理、研发工程师、测试工程师的角色都是难以划分的,核心队员少于10人的RM战队可能在人数上撑不起来这些更繁重的平台。

本质上,是工具和人的一种平衡。

跳转到指定楼层

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
上士Big_uncle
2018-11-29 22:53:45 显示全部楼层
66666,强啊!
回复

使用道具 举报

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
上士单曲循环地听歌
2018-11-29 23:08:43 显示全部楼层
点个赞!!!
回复

使用道具 举报

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
中尉whl970831
2018-11-30 10:57:13 显示全部楼层
好文章,值得我们新队伍学习学习,楼主辛苦了>_<

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
版主快拆小分队
2018-12-13 20:02:29 显示全部楼层
这个有人学习吗?

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
中士wanglh1999
2019-1-13 14:12:18 显示全部楼层
超棒的,疯狂打call!!!(好吧我只是来蹭金币的)

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
下士华师机甲HSRM
2019-8-16 21:54:38 显示全部楼层
真是宝啊,老哥写的太好了~

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
上等兵咸鱼少女贼不甜
2019-8-31 20:27:39 显示全部楼层
找到宝了!
回复

使用道具 举报

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
上等兵17602357904
2019-9-1 13:26:02 显示全部楼层
蹭金币+1
回复

使用道具 举报

[项目类] 【干货】西电在线协作平台经验分享

[复制链接]
中士AlvinCui
2019-9-1 15:09:52 显示全部楼层
厉害厉害,学到了

本版积分规则

触屏版 | 电脑版

Copyright © 2019 RoboMasters 版权所有

快速回复 返回顶部 返回列表