release - 实施发布计划

Question

我工作的公司正在尝试实施发布计划，我希望从那些在比我所在的结构更好的环境中工作的人那里获得一些建设性的反馈。

我们有一种产品已经完成并被多个客户使用，但我们还有 4 种其他产品正在开发中 - 并且正在积极销售，就好像它们已经完成一样。（想象一下！）

我们是一家非常小的公司，工作速度很快（是的，有时很马虎），而且截止日期和预算都很紧，所以我们没有书面要求、系统的 QA 流程等。基本上公司的所有者来给有想法的开发人员（我们 3 人），然后我们实施它们。然后主题专家测试这些功能，以确保应用程序能够完成它应该做的事情。

我知道最后一段让我接受了各种“你不能这样做”类型的反馈，但我不需要那个。我理解这种方法有多么错误。有一次，我能够说服业主聘请一名项目经理和一名 QA 人员，但不久之后，两人都因收入损失而被解雇。我们就在我们所在的地方，目前没有改变文化。

我正在尝试做的是管理期望。我们有一英里长的请求功能列表，这就是我提出的建议。

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

1) 根据其重要性将所有突出的功能放入未来的版本中。2) 在本季度处理这些功能。3) 当请求新功能时，将它们放入特定发布周期的“队列”中。4) 如果该功能必须进入当前版本，则将其他功能移至下一个版本。5) 在周期中的某些时间点，评估哪些功能可能不会进入当前版本并进行相应调整。6) 至少在预定投产前 30 天结束功能开发，并专注于测试和错误修复。7）在预定的日期将某些东西推向生产，然后因为没有完成我们一开始同意的所有事情而发火（嘿，我很现实......我为之工作的人不是。）

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

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

在此先感谢您的帮助。

达尔维斯

Answer 1

鉴于缺乏项目管理、组织等——我认为你会遇到问题，试图强迫自己进入一个季度（或任何固定日期）的发布周期。如果您有任何“大型”功能需要超过 2 个月的时间来开发，而您允许开发时间，则尤其如此。

我的建议是做一个基于功能的发布周期。只需列出您的功能队列，确定您认为可以在特定时间范围内合理执行的功能。实现这些功能，给自己一个月（或其他时间）进行测试，然后发布。移动到下一组特征。如果需要 2 个月而不是 3 个月，那就太好了。如果它需要4，那也很好。

话虽如此，我会专注于尝试缩短，而不是更长。在这种情况下，拥有更多、更小的版本实际上会对您有所帮助，特别是因为您没有正式的程序（和人员）来处理 QA 等。保持灵活性将帮助您解决将进入您的版本的问题......

Answer 2

很简单，由于缺乏明确的流程，成功实施可靠的发布计划的机会不大。这不仅仅是悲观主义，尽管我很乐意承认它是。

就像成功主要基于努力工作和一点点运气一样，可靠、可重复的发布计划也基于过程。拥有诸如功能规范和设计规范之类的东西对于能够以一致、可靠的时间表发布非常重要。（你知道人们有这样的规范是有原因的，对吧？）这并不是说没有这些东西你就不能按时完成计划并释放期望。你很可能可以。但是，拥有这样的流程会大大增加您满足期望的机会，至少部分是因为它可以确保在您仍在实施时，期望不会陷入“不合理”的领域。

同样，这并不意味着您无法实现上述操作所需的内容；老实说，如果您所处的环境对实施所描述的此类流程持积极态度，那么您可能正在以最佳方式工作以实现您所需要的。我并不是要完全悲观。听起来您已经很好地掌握了如何尝试完成这些工作；对于您必须处理的内容，听起来您已经制定了合理的流程。但我几乎可以保证，如果你能得到两件事，你最终会变得更好；1) 来自管理层的功能规范，描述他们希望软件做什么，以及 2) 从工程到管理的设计规范，描述你如何' 重新让软件在功能规范中做他们想做的事。我认为您甚至可以将其纳入您的流程；功能规范不需要复杂；关于他们的关键是他们是写下来，这样可以防止就管理层的要求发生争吵；它就在那里。并且设计规范也不需要花费很多时间；一个快速的单页纸，让管理层知道您将如何（在高层次上）实施他们需要的东西，让他们放心，您已经听到他们的声音，并可以帮助他们了解所涉及的复杂性（但不要去太深入了，否则你会冒着让他们厌烦和失去注意力的风险）。

Answer 3

尽早并经常发布。

我经常发现用户在我们向他们展示之前并不知道他们想要什么。在我们的设施中，我们有一个轻量级的 QA/测试系统。让用户尝试新事物。当用户认可想法时，我们将它们转移到生产中。这让我们始终致力于新事物、测试接口、添加数据库表和列，而不会破坏生产代码。

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

Answer 4

你用什么来控制源代码？

我们使用 SVN 并且可以根据需要在下一个版本中部署的内容灵活地创建各种不同的分支。如果将发布 a1、a2 和 a3 设置为发布，我们可以将这些更改合并到分支生产中。如果 a2 的优先级降低，我们可以只回滚 a2 的更改，或者如果存在重叠，只需创建一个新分支并仅合并 a1 和 a3，将 a2 留给以后的版本。

所有者在给定版本之前重写规范的可能性有多大？在我工作的地方，这种情况经常发生，这使得在必要时能够换档和回滚/重新合并非常有用。

Answer 5

我的公司也因功能请求而陷入困境。

我们所做的是检查所有功能，并估计实现它们所需的时间。然后，我们将其留给我们的“变更委员会”（我们的 CEO、团队领导等），为我们提供我们将在下一个 sprint 中完成的功能。

This way, we aren't being given unreasonably large work-loads, and the end user has some say in what's completed.