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