实施发布计划
我工作的公司正在尝试实施发布计划，我希望从那些在比我更好的结构化环境中工作的人那里获得一些建设性的反馈。
我们有一个产品已经完成并被多个客户使用，但我们有4 个其他产品正在开发中 - 并正在积极营销，就好像它们已完成一样。 （想象一下！）
我们是一家非常小的公司，工作速度非常快（是的，有时很马虎），并且期限很紧，预算也很紧张，所以我们没有书面要求、系统的质量保证流程等。公司所有者向开发商（我们三个人）提出想法，我们将其实施。 然后，主题专家测试这些功能，以确保应用程序能够完成其应有的功能。
我知道最后一段让我接受各种“你不能这样做”类型的反馈，但我不需要那样。 我明白这种做法是多么错误。 有一次，我说服业主聘请了一名项目经理和一名质量检查人员，但不久之后，两人都因收入损失而被解雇。 我们就在我们现在的位置，目前文化还没有改变。
我想做的是管理期望。 我们有一英里长的请求功能列表，这就是我所提议的。
我们将每季度发布成品的生产情况。 第一个版本将于 10 月发布。 我们不会尝试根据高/中/低优先级来管理从现在到那时将要完成的工作，而是根据从现在到 9 月之间可以完成和不能完成的工作来管理功能。 届时，我们将停止所有功能开发，并专注于测试和修复缺陷，以便为下个月发布产品做好准备。 我们将每个季度重复此过程。 基本上步骤如下：
1）根据重要程度将所有突出的功能放入未来版本中。 2) 在本季度内研究这些功能。 3) 当请求新功能时，将它们放入特定发布周期的“队列”中。 4) 如果该功能必须进入当前版本，则将其他功能移至下一个版本。 5) 在周期的某些时刻，评估哪些功能可能不会进入当前版本并进行相应调整。 6) 在计划投入生产之前至少 30 天结束功能开发，并专注于测试和错误修复。 7) 在预定的日期将一些东西投入生产，然后因为没有完成我们一开始同意的所有事情而承受压力（嘿，我很现实......我为之工作的人不是。）
哦，另外，如果你打算告诉我“找一份新工作”，那就不用费心回答。 目前这不是一个选择。
如果您对这个提议的方法有任何建议，或者任何可以帮助我更好地理解如何构建这个流程的资源链接，我将不胜感激。
在此先感谢您的帮助。
达尔维斯
The company I work for is trying to implement a release schedule and I want to get some constructive feedback from people that work in better structured environments than I am in.
We have one product that is finished and being used by several customers, but we have 4 additional products in the works - and actively being marketed as if they are finished. (Imagine that!)
We are a very small company working very quickly (and yes, sloppy at times) and with tight deadlines and tight budgets, so we don't have the luxury of written requirements, systematic QA process, etc. Basically the owners of the company come to the developers (3 of us) with ideas and we implement them. Then the subject matter experts test the features to make sure the app does what it is supposed to do.
I know that last paragraph opens me up to all kinds of "you can't do it this way" types of feedback, but I don't need that. I understand how wrong this approach is. At one point I was able to convice the owners to hire a project manager and a QA person, but after a short time both were laid off due to loss of revenue. We are where we are and there's no changing the culture at this point.
What I'm trying to do is manage expectations. We have a list of requested features a mile long and here's what I have proposed.
We will do quarterly releases to production of our finished products. The first release will be in October. Rather than trying to manage what will be done between now and then based on High/Medium/Low priorities, we will manage features based on what can and cannot be finished between now and September. At that point we will stop all feature development and focus on testing and fixing defects in order to get the product ready for release the following month. We'll repeat this process each quarter. Basically the steps will be like this:
1) Place all outstanding features into a future release based on how critical it is.
2) Work on these features during the quarter.
3) As new features are requested, place them into a "queue" for a particular release cycle.
4) If the feature has to go into the current release, then move other features to the next release.
5) At certain points during the cycle, evaluate which features may not get into the current release and adjust accordingly.
6) End development of features at least 30 days before scheduled push to production and focus on testing and bug fixing.
7) Push something to production on the scheduled date and then take the heat for not having everything finished that we agreed to in the beginning (hey, I'm being realistic...the people I work for aren't.)
Oh, also, if you plan to tell me to "get a new job" then don't bother answering. That's not an option at the moment.
If you have any advice regarding this proposed approach, or any links to resources that might help me better understand how to structure this process, I would greatly appreciate it.
Thanks in advance for your help.
Darvis
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
鉴于缺乏项目管理、组织等——我认为你会遇到试图强迫自己进入季度（或任何固定日期）发布周期的问题。 如果您有任何“大型”功能，并且需要比您允许的开发时间多于 2 个月的时间来开发，则尤其如此。
我的建议是进行基于功能的发布周期。 只需列出您的功能队列，决定您认为可以在特定时间范围内合理完成哪些功能。 实现这些功能，给自己一个月（或其他时间）进行测试，然后发布。 转到下一组功能。 如果需要 2 个月而不是 3 个月，那就太好了。 如果需要4个，那也没关系。
话虽这么说，我会集中精力尝试让这个时间更短，而不是更长。 在这种情况下，拥有更多、更小的版本实际上会对您有所帮助，特别是因为您没有正式的程序（和人员）来处理质量检查等。保持灵活性将帮助您解决发布中出现的问题......
Given the lack of project management, organization, etc - I think you're going to run into problems trying to force yourself into a quarterly (or any fixed date) release cycle. This will be especially true if you have any "large" features which will take more than the 2 months to develop that you're allowing for development time.
My suggestion would be to do a feature-based release cycle. Just make your queue of features, decide which ones you think you can reasonably do in a specific time frame. Implement those features, give yourself one month (or whatever) for testing, then release. Move to the next group of features. If it takes 2 months instead of 3, great. If it takes 4, that's fine too.
That being said, I'd focus on trying to make this shorter, not longer. Having more, smaller releases will actually help you in this case, especially since you don't have the formal procedures (and personnel) to handle QA, etc. Staying flexible will help you fix problems that will get into your releases...
很简单，由于缺乏定义的流程，成功实施可靠的发布计划的机会不大。 这不仅仅是悲观主义，尽管我很乐意承认这一点。
就像成功主要基于努力工作和一点运气一样，可靠、可重复的发布计划也基于过程； 拥有功能规范和设计规范等内容对于能够按一致、可靠的时间表发布确实至关重要。 （你知道人们有这样的规范的东西是有原因的，对吧？）这并不是说没有这些东西你就不能达到你的时间表并释放期望；而是说你不能完成你的计划并释放期望。 你很可能可以。 但是，实施这样的流程会大大增加您满足期望的机会，至少部分是因为它确保了在您仍在实施时期望不会陷入“不合理”的领域。
再次强调，这并不意味着您无法实现上述操作所需的目标；而是意味着您无法实现上述操作所需的目标。 老实说，如果您所处的环境积极反对实施所描述的此类流程，那么您可能正在以最佳方式工作来实现您需要的目标。 我并不是要完全悲观。 听起来你已经很好地掌握了如何尝试完成这件事； 对于你必须处理的事情，听起来你已经制定了合理的流程。 但我几乎可以保证，如果你能得到两件事，你最终会过得更好； 1) 来自管理层的功能规范，描述他们希望软件做什么；2) 来自工程的设计规范，向管理层描述如何使软件完成功能规范中他们想要的功能。 我认为您甚至可以将其纳入您的流程中； 功能规格无需复杂； 关键是它们被写下来，这可以防止对管理层的要求发生争吵； 它就在那里。 而且设计规范也不需要花费很多时间； 一个快速的单页程序，可以让管理层知道您将如何（在高层次上）实现他们所需要的内容，这可以让他们放心，您已经听到了他们的意见，并且可以帮助他们理解所涉及的复杂性（但不要去太深入，否则你就有可能让他们感到无聊并失去他们的注意力）。
Quite simply, given the lack of defined process, there's not much chance of successfully implementing a solid release schedule. This isn't just pessimism, although I'l readily admit that it is.
Much like success being based largely upon hard work and a little luck, solid, repeatable release schedules are based upon process; having things such as functional specifications and design specifications are really critical to being able to release on a consistent, solid schedule. (You know there's a reason why people have such specification things, right?) And that's not to say that you can't hit your schedule and release expectations without such things; you very possibly can. But what having such process in place massively increases your chances of being able to meet expectations, at least partially because it assures that expectations don't drift into "unreasonable" territory while you're still implementing.
Again, this doesn't mean you can't achieve what you need to doing what you described above; to be honest, if you're in an environment that is actively hostile to having such process as described in place, you're probably working in the best way to achieve what you need to. And I don't mean to be completely pessimistic; it sounds like you've got a good grasp on how to attempt to get this stuff done; for what you've got to work with, it sounds like you've got a reasonable process in place. But I can virtually guarantee that you'll end up being better off if you can just get two things; 1) a functional specification from management that describes what they want the software to do, and 2) a design specification from engineering describing to management how you're going to make the software do what they want in the functional specification. I'd think you could possibly even fit this into your process; functional specifications don't need to be complicated; the key thing about them is that they are written down, which prevents bickering about what management asked for; it's right there. And design specifications don't need to take a lot of time either; a quick one-pager to let management know how (at a high level) you're going to implement what they need provides them with reassurance that you've heard them, and can help them understand the complexity involved (but don't go too deep into it, otherwise you run the risk of boring them and losing their attention).
尽早且频繁地发布。
我经常发现，在我们向用户展示之前，他们并不知道自己想要什么。 在我们的工厂中，我们有一个轻量级的质量保证/测试系统。 让用户尝试新事物。 当用户认可想法时，我们会将其投入生产。 这使我们能够始终致力于新事物、测试接口、添加数据库表和列，而不会破坏生产代码。
唯一的“窍门”就是不断提醒客户测试平台不是生产平台。
Release early and often.
I often find that users don't know what they want until we show them. In our facility, we have a light-weight QA/test system. Let users try new things. As users approve of ideas, we move them to production. This lets us always be working on new things, testing interfaces, adding database tables and columns, without breaking production code.
The only "trick" is constantly reminding the customer that the test platform is not the production platform.
您使用什么进行源代码控制？
我们使用 SVN，并且可以根据需要灵活地创建各种不同的分支，具体取决于下一个版本要部署的内容。 如果版本a1、a2和a3被设置为发布，我们可以将这些更改合并到生产分支中。 如果 a2 的优先级降低，我们可以仅回滚 a2 的更改，或者如果存在重叠，则只需创建一个新分支并仅合并 a1 和 a3，将 a2 留给以后的版本。
所有者在给定版本发布之前重写规范的可能性有多大？ 在我工作的地方，这种情况经常发生，因此如果需要的话，切换齿轮和回滚/重新合并的能力非常有帮助。
What are you using for source control?
We use SVN and have the flexibility to if necessary create a variety of different branches depending on what's to be deployed as of the next release. If releases a1, a2, and a3 are set to be released, we can merge these changes into a branch off production. If a2 becomes less of a priority we can roll back only a2's changes or if there's overlap just create a new branch and merge only a1 and a3, leaving a2 for some later release.
How likely are the owners to rewrite a specification prior to a given release? Where I work this happens frequently, making the ability to shift gears and rollback / re-merge if necessary very helpful.
我的公司也因功能请求而陷入困境。
我们所做的是检查所有功能并估计实现它们所需的时间。 然后，我们将其留给我们的“变革委员会”（我们的首席执行官、团队领导等）来为我们提供将在下一个冲刺期间完成的功能。
这样，我们就不会被赋予不合理的大工作量，并且最终用户对完成的内容有一定的发言权。
My company also gets bogged down with feature requests.
What we did is go through all the features and give an estimate of the amount of time they will take to implement. Then, we leave it up to our "change committee" (our CEO, team leaders, etc.) to give us the features we will be completing during the next sprint.
This way, we aren't being given unreasonably large work-loads, and the end user has some say in what's completed.