很久以前,当我的公司规模小得多时,将开发工作划分为团队非常容易:
多年来,团队之间的界限变得模糊:
这一切似乎都表明,在团队中分裂并不是一个好主意。也许“通用”团队应该发展成为“软件质量”团队(定义和保护编写优质软件的规则),或者变成“软件部署”团队(定义如何部署,安装软件......)
如果您有不同的应用程序,如何将工作分成不同的团队?
请注意,混合(允许每个人在代码中的所有位置都写入)的优点是:
但是,如果没有明确的团队可以管理它,这个通用代码可能会成为任何人的责任。但是,这个通用代码可能会成为任何人的责任。
您的愿景是什么?
答案 0 :(得分:2)
当你拥有各种“应用程序”团队时,你总会得到复制的功能 - 相同类型的帮助程序类,相同的问题已经解决了几次,通常情况略有不同。
麻烦的是,没有人真的想成为“通用”或“框架”团队,并且该团队非常努力地宣传他们的代码库中可用的功能,然后确保“应用程序”人们实际上使用它。
您需要指定一些首席工程师/开发人员。这些人的角色是监督“应用程序”和“通用”团队之间的代码开发。他们还负责了解“通用”团队可以重用的功能,然后确保实际使用(而不仅仅是重新创建)。最初让一个(或几个)知识渊博且负责任的人在这方面传播知识的速度要快于团队会议并说“嘿大家,这里是一套新的API,开始使用它们”< / em>的。这些主要开发人员的角色之一是管理代码审查,部分代码审查可以确保使用适当的“通用”代码,如果没有,那么他们可以确保重构的代码片段被重构
当然,通用团队也必须做好记录他们所拥有的工作 - 如果应用程序开发人员无法在通用代码中找到他们想要的东西,他们将继续自己编写,让你的循环永久化目前有。
答案 1 :(得分:1)
我之前的一位雇主都有这个分裂开发工作的想法:
项目团队将负责长期项目,通常平均长达3-6个月,因此这些项目将是一个不会轻易完成的大型项目。
持续工程团队可以处理可能需要长达几周的短期功能,以及错误修复和其他维护工作项。关键是这个小组必须准备好在短时间内完成工作,因为他们的转变应该与项目团队大不相同。
我没有足够长的时间看到这个结果有多好,但这对我来说是一个好主意。重点是有很多小工作不能完成,但对整个公司来说可能非常有用,所以除了更大的工作项之外,这是一种完成这些小工作的方法。如果在公共区域中有足够相似的位,例如,可以检查两者之间的任何内容,或者将其分成小组用于CE团队或者包含到项目中。一组大型应用程序的服务包将是如何修复一些错误并将其包装起来供项目团队完成。