我的团队开发公司内其他开发团队使用的 .net 组件。
通常情况下，这些团队需要紧急改进，他们现在就想要。为了保持我团队的理智，我想让计划更具可预测性，并建议发布频率不少于一个月。我很好奇其他人是如何解决这类问题的。
举个具体的例子，假设我们正在开发自己的 Grid 类。当其中一个团队需要排序但我们的下一个版本是 3 周后。让他们将我们的 Grid 包装在自己的代码中并自己提供所需的功能是一个好策略吗？
如果不是，让我们的用户自己增强组件的好策略是什么？您能否推荐一些解释维护内部框架的不同策略的文献？
【问题讨论】：
标签： .net architecture frameworks maintainability
首先，您不能对其他团队说“嘿，坚持 3 周”。想想他们有压力及时完成事情，他们也有生命和最后期限。
您可以提供两种解决方案： a) “好的，我们可以做到，但由于内部议程，我们无法在 3 周之前完成” b) “如果你等不起 3 周，你可以自己包起来，做所有艰苦的工作”
也许还有第三种解决方案：
c) “如果您可以节省开发人员的时间，我们可以指导他实现它，当然，他需要一些时间来编写代码并开始做一些真正的事情，但我们最终都会受益”
这不是您问题的答案，而是为您绘制的场景提供建议。
现在答案：
你真的能预测其他团队的需求吗？ 如果你说是，现在停止努力，去维加斯，你可以通过使用超能力赚很多钱。
将其他团队视为客户。您通常无法预测（对新功能的）需求，除非它们太明显了，如果没有它就发布是错误的。
您可以尝试与其他团队的架构师进行一场头脑风暴，甚至在开始浪费时间在任何没人会使用或关心的花哨组件上。
从这里你将开始对你需要构建什么有一个更具体的想法。现在你已经有了一些“客户”。停止做其他组件（无论如何它们只会制造更多“新功能”压力）并专注于交付一些不能完成工作的东西，至少是它应该完成的所有工作。
在没有与您的“客户”达成某种协议的情况下创建组件，您可能会浪费时间创建没有人需要的东西（即使是非常好的东西），并迫使您的“客户”寻找他们发现的其他一些不错的（免费？）组件在谷歌上搜索。
在纯技术问题中，组件的可维护性与任何其他应用程序没有太大区别。让它松耦合（依赖注入可能是个好主意），你会没事的。
【讨论】：
似乎您需要分支（和合并）...这是一个很好的起点： http://msdn.microsoft.com/en-us/library/gg475908%28v=vs.100%29.aspx
【讨论】：