共享代码和界面的一些社会和技术解决方案是什么？

Question

背景：

我是一家中型虚拟主机公司的产品经理，除了虚拟主机之外，我们还提供各种补充服务。

今天，我们公司有大约12个3-6个开发团队，每个团队都在从事虚拟主机的不同方面的工作(即DNS注册、共享主机、云计算、专用服务器、转售等)。

我们已经非常有机地成长，因此，用户界面很大程度上反映了我们公司的组织结构，而不是我们的客户会觉得直观的内容组织。

除了这个问题之外，许多后端系统属于每个团队的域，但也需要由其他团队使用。例如，DNS注册服务需要由共享主机团队在他们的面板上使用。另一个例子，虚拟主机功能，如一键网络应用程序安装程序是由共享主机团队开发的，但我们也希望将其提供给专用主机客户。

仅供参考，我们有一个非常专注于敏捷方法和极限编程(XP)的编程环境。

问题：

对于那些拥有与我类似的公司工作/编程环境的人，您有什么解决方案/建议来使这种安排工作，以便我们可以改善用户体验以及代码的协调和共享，同时还允许团队保持独立？

这里有没有人用过Scrum的Scrum。如果是这样的话，你对实现它有什么建议？

对于scrum的scrum有什么替代的解决方案吗？

Answer 1

我遇到过一些CSM，他们成功地运行了Scrum，但这可能很难管理，除非您已经有使用Scrum的经验。

Answer 2

在编写代码之前，应该清楚地定义接口。如果需要，可以在以后更改接口定义，但这应该只在为该接口开发和使用该接口的所有团队的协作下完成。拥有一致的、定义良好的接口有助于封装系统的各个部分，并且可以使重用公共组件或库变得更加容易。良好的封装和模块化是独立团队之间有效重用代码的必要前提(我假设使用了某种版本控制系统)。

必须能够轻松访问最新的文档。对于agile/XP环境，我个人的建议是设置一个项目wiki作为中心文档中心。在创建或修改特性/接口/函数时，开发过程的一部分应该是创建或更新该组件的文档。一个开发人员花半个小时来充分记录一些东西，可以为其他六个开发人员节省半个小时，每个开发人员都试图自己弄清楚。对文档使用wiki可以使快速编辑变得更容易，允许对单个页面使用多个编辑器，并确保每个人都在使用最新的文档(没有可能过时的文档的本地副本)。

我们已经非常有机地成长，因此，用户界面很大程度上反映了我们公司的组织结构，而不是我们的客户会觉得直观的内容组织。

当接口未被视为单独的模块化组件时，可能会出现这种情况。接口应该插入到它下面的功能中，但不一定代表底层组织的结构。我经常看到这样的事情，当一个界面是由“黑客”构建的时候；也就是说，一个开发人员构建了一个新功能，并修改了UI，使其足以支持他们的功能，然后下一个开发人员做同样的事情，以此类推，直到整个UI被拼凑在一起，没有总体设计目标或原则。不要低估用户界面的重要性，也不要低估创建高质量、一致的界面的难度。从客户的角度来看，让工程师(如果是大型项目，则是小团队)来设计和维护用户界面可以极大地提高产品的价值。由于客户通常看到的是用户界面，而不是内部工作，因此界面应该比团队1%的劳动成果更多。

如果您让所有单独的团队都在同一轨道上，那么实现"scrum of scrum“结构是相当容易的。每天，每个小组/团队举行一次简短的状态报告/ scrum会议，之后每个小组指定的“领导者”在下一级“食物链”上举行另一次scrum会议。由于这可以在许多层次上重复，因此当小组scrum在早上第一件事发生时效果最好，并且每个scrum级别都有严格的时间限制(通常是15分钟，或者每个人2-3分钟就足够了)。时间限制有助于防止一个团队超时，并延迟他们的领导参加下一级的scrum会议，等等。

Answer 3

：“对于scrum中的scrum，有什么替代方案吗？”

是。一个建筑师。

架构师的工作--在此上下文中--不是规定体系结构。

架构师的工作是协调团队之间的关系。定期与每个人见面。参与scrums，在需要帮助的地方提供帮助。

最重要的是：

• 作为变更请求的治理。
• 在各个团队之间建立了一个共同的愿景。

这需要技术深度来理解正在发生的一切，以及确保每个人的声音都被听到的政治技能。

最后，它需要管理层的支持来执行决策。例如，如果所有开发团队的共识是技术X，并且一个团队坚持技术Y，那么可能是时候让一个团队在不同的公司找到一份新的工作了。