[Team]开发中的控场
Posted 安柏霖
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[Team]开发中的控场相关的知识,希望对你有一定的参考价值。
近期在参与一个大型模块的开发中,自己也承接了不少任务,以及大量的提交代码&讨论代码;
实际在做的feature中,代码量大约是30%,70%的时间和代码都是在重构整理(有自己直接整理,有的是交代同事直接整理);
做的时候,更多的是发乎直觉,面对一系列问题,显然应该这么去处理事情,这里进一步去总结下;
黑盒部分的优先级和局限
所谓黑盒,就是把每个人作为一个“抽象化”的标准个体,3个人做还是5个人做这种;
假设这几个人的战斗力输出的,比如按照鹅厂的3个t9战斗力怎么样。。。
进而建立目标,做人力分配,以及核查实现的结果。
这里的建立目标部分在产品层面,一部分是在技术团队(比如对未来开发的技术布局),这块工作一定是最关键的,需要优先做好。
也就是平衡团队的能力和目标的工作;
这块就是整体战略,确实非常重要,但是很多时候这块在假设团队能力固定的情况下,那么目标也是比较直接,未必那么难。
如果仅仅停留于此,个人觉得还是比较浅层;
一个团队可以有很强的成长性,而且在开发的过程中,也有非常大的弹性,同样这几个人,做得好与不好,带队得当与否都意味着不同的能力。
这个就是黑盒看待团队能力的局限,也就是团队能力是可变的,也就是“搭班子,定战略,带团队”中的带团队部分,是一个提升能力的过程。
所以黑盒定战略,平衡能力与目标,这个优先级最高,但是也有局限;
我们要白盒的看待开发的过程,动态的看待团队能力成长与培养;
白盒:开发过程中的控场
在开发过程中,几个人形成一个小team进行开发,这里就形成一个小的系统,team的战斗力就不只是简单的几个人的叠加;
其上下浮动的范围非常的大。
在team leader层面,在面对具体milestone的时候,重在开发过程中寻找整体最优,控场;
在team级别这里几件事情要做到位:
关键点 | 覆盖面 | 反例 |
---|---|---|
技术方案清晰 | 在文档上能描述清楚,更新及时 | 没有文档,技术方案已经开始混乱 |
开发实现效率高 | 整体结构健康清晰,框架和底层函数强大 | 架构落后,代码混乱,底层函数支持不足,智商280的也没法发挥了 |
代码在整体上结构健康 | 持续的进行重构整体,保持整体的健康简洁 | 代码冗长,内部出现bug的概率高,开发效率非常慢 |
代码在设计和底层模块强大 | 提供好用的底层函数模块,并且对此有足够的应用 | 扩展和实现都非常的快 |
具体同事来说,往往是实现其中一个个的小模块,那么整体最优的责任就落在了lead的头上:
在短期内,至少要保持:
- 技术方案清晰,落地到文档
- 代码在整体上结构健康
而这点:
- 代码在设计和底层模块强大
则是偏长期的建设;
sum:
- 黑盒进行开发是远远不够
- 团队能力在同样的人身上,有巨大的浮动范围
- 整体最优中的控场上的事情,落地于牵头人的身上,这个就要覆盖到方案,整体代码结构和整洁度
以上是关于[Team]开发中的控场的主要内容,如果未能解决你的问题,请参考以下文章