实现发布计划

Question

我工作的公司正在努力实现一个发布时间表，我希望从那些在比我更好的结构化环境中工作的人那里获得一些建设性的反馈。

我们有一个产品已经完成，并被几个客户使用，但我们还有4个额外的产品在工程中-并积极地进行市场营销，就好像他们已经完成了一样。(想象一下！)

我们是一家非常小的公司，工作速度非常快(是的，有时也很草率)，有紧迫的最后期限和紧张的预算，所以我们没有奢侈的书面需求，系统的QA过程等。基本上，公司的所有者带着想法来找开发人员(我们3个人)，我们实施它们。然后，主题专家测试这些功能，以确保应用程序可以完成它应该做的事情。

我知道最后一段让我接受了各种各样的“你不能这样做”类型的反馈，但我不需要这些。我明白这种方法是多么错误。我一度建议业主聘请一名项目经理和一名QA人员，但不久之后，由于收入损失，两人都被解雇了。我们现在所处的位置，在这一点上没有改变文化。

我想要做的是管理期望。我们有一个长达一英里的请求功能列表，这是我提出的建议。

我们将按季度发布我们的成品生产。第一个版本将在10月份发布。我们不会试图根据高/中/低优先级来管理从现在到那时要做的事情，而是根据现在到9月之间可以完成和不能完成的功能来管理功能。在这一点上，我们将停止所有的功能开发，并专注于测试和修复缺陷，以便为下个月的发布做好准备。我们将在每个季度重复此过程。基本步骤如下所示：

1)根据其重要性，将所有突出功能放入未来版本中。2)在本季度对这些功能进行改进。3)当请求新特性时，将它们放入特定发布周期的“队列”中。4)如果该功能必须进入当前版本，则将其他功能移至下一个版本。5)在周期中的某些点上，评估哪些功能可能无法进入当前版本，并进行相应的调整。6)至少提前30天停止功能开发，专注于测试和修复bug。7)把某件事推到预定的生产日期，然后为没有完成我们一开始约定的所有事情而承担责任(嘿，我是realistic...the，我为之工作的人不是)。

哦，还有，如果你打算告诉我“找个新工作”，那就别费心回答了。目前，这不是一个选择。

如果你对这个提议的方法有任何建议，或者有任何资源链接可以帮助我更好地理解如何构建这个过程，我将不胜感激。

提前感谢您的帮助。

达维斯

Answer 1

很简单，考虑到缺乏明确的过程，没有太多机会成功实现一个可靠的发布时间表。这不是悲观主义，只是悲观主义()，尽管我愿意承认这是悲观主义。

就像成功在很大程度上是基于努力工作和一点点运气一样，可靠的、可重复的发布计划是基于过程的；拥有功能规范和设计规范等内容对于能够按照一致的、可靠的计划发布非常关键。(你知道人们有这样的规范是有原因的，对吧？)这并不是说你不能在没有这些东西的情况下达到你的时间表和发布期望；你很有可能做到。但是，这样的过程会极大地增加你达到期望的机会，至少部分是因为它确保了当你还在实现的时候，期望不会漂移到“不合理”的领域。

再说一次，这并不意味着您不能完成上面描述的工作；老实说，如果您所处的环境非常反对这样的流程，那么您可能正在以最好的方式来实现您所需要的工作。我并不是说完全悲观；听起来你已经很好地掌握了如何尝试完成这些事情；对于你要做的工作，听起来你已经有了一个合理的过程。但我几乎可以保证，如果你只得到两件事，你最终会变得更好: 1)来自管理层的功能规范，描述他们希望软件做什么，以及2)来自工程的设计规范，描述你将如何让软件做他们想要的功能规范。我认为您甚至可以将此放入您的流程中；功能规范不需要很复杂；它们的关键是它们是用写成的，这可以防止为管理层所要求的内容而争吵；它就在那里。设计规范也不需要花费很多时间；快速的一页让管理层知道你将如何(在高层次上)实现他们需要的东西，这会让他们放心，你已经听到了他们的意见，并且可以帮助他们理解所涉及的复杂性(但不要太深入，否则你会冒着让他们感到厌烦并失去他们注意力的风险)。

Answer 2

考虑到缺乏项目管理，组织等-我认为你会遇到问题，试图迫使自己进入一个季度(或任何固定的日期)发布周期。如果你有任何“大”的功能需要超过2个月的开发时间，这将是特别正确的。

我的建议是做一个基于功能的发布周期。只需建立你的特性队列，决定你认为你可以在特定的时间框架内合理地完成哪些特性。实现这些特性，给自己一个月(或其他)的时间进行测试，然后发布。移动到下一组功能。如果需要2个月而不是3个月，那就太好了。如果需要4个，也没问题。

话虽如此，我还是会把重点放在尽量缩短，而不是更长。在这种情况下，拥有更多、更小的版本实际上会对你有所帮助，特别是因为你没有正式的程序(和人员)来处理QA等。保持灵活性将帮助你修复将进入版本中的问题……

Answer 3

尽早发布，并经常发布。

我经常发现，用户不知道他们想要什么，直到我们向他们展示。在我们的设施中，我们有一个轻量级的QA/测试系统。让用户尝试新事物。当用户同意我们的想法时，我们将它们转移到生产中。这让我们可以在不破坏生产代码的情况下，一直从事新的工作，测试接口，添加数据库表和列。

唯一的“诀窍”就是不断提醒客户，测试平台不是生产平台。