我所工作的公司正在尝试实施发布计划,我希望从比我更好的结构化环境中工作的人那里得到一些建设性的反馈。
我们有一种产品已经完成并被多个客户使用,但我们还有4种产品正在进行中 - 并且正在积极地进行营销,就像它们已经完成一样。 (想象一下!)
我们是一家非常小的公司,工作非常迅速(是的,有时候马虎),并且时间紧迫,预算紧张,所以我们没有书面要求,系统的质量保证流程等等。基本上是业主公司带着想法来到开发人员(我们三个人),我们实施它们。然后主题专家测试这些功能,以确保应用程序能够完成它应该做的事情。
我知道最后一段打开了各种各样的“你不能这样做”的反馈类型,但我不需要那样。我理解这种方法有多么错误。有一次,我能够让业主委任一名项目经理和一名质量保证人员,但在短时间内两人因收入损失而被解雇。我们就在这里,现在并没有改变文化。
我要做的是管理期望。我们有一英里长的请求功能列表,这就是我提出的建议。
我们将按季度发布生产成品。第一个版本将在10月份发布。我们将根据现在和9月之间可以和不可以完成的内容来管理功能,而不是尝试根据高/中/低优先级管理现在和将来要做的事情。此时,我们将停止所有功能开发,并专注于测试和修复缺陷,以便在下个月准备好发布产品。我们将在每个季度重复这一过程。基本上步骤将是这样的:
1)根据其重要性将所有未完成的功能放入将来的版本中。 2)本季度处理这些功能。 3)当请求新功能时,将它们放入特定发布周期的“队列”中。 4)如果该功能必须进入当前版本,则将其他功能移至下一版本。 5)在循环期间的某些点,评估哪些特征可能无法进入当前版本并进行相应调整。 6)在计划推出生产之前至少30天结束功能开发,并专注于测试和错误修复。 7)在预定的日期把东西推到生产中,然后把热量没有完成我们在开始时同意的所有东西(嘿,我是现实的......我工作的人不是。)
哦,如果你打算告诉我“找一份新工作”,那就不用费心了。目前这不是一个选择。
如果您对此提议的方法有任何建议,或任何可能帮助我更好地了解如何构建此过程的资源链接,我将不胜感激。
提前感谢您的帮助。
Darvis
答案 0 :(得分:3)
由于缺乏项目管理,组织等,我认为你会遇到试图强迫自己进入季度(或任何固定日期)发布周期的问题。如果您有任何“大”功能,开发时间超过2个月,那么尤其如此。
我的建议是做一个基于功能的发布周期。只需制作功能队列,确定您认为可以在特定时间范围内合理执行的功能。实现这些功能,给自己一个月(或其他)进行测试,然后发布。转到下一组功能。如果需要2个月而不是3个月,很棒。如果它需要4,那也没关系。
话虽如此,我会专注于尝试缩短,而不是更长。在这种情况下,拥有更多,更小的版本实际上会帮助您,特别是因为您没有正式的程序(和人员)来处理QA等。保持灵活性将帮助您解决将进入您的版本的问题... < / p>
答案 1 :(得分:1)
很简单,由于缺乏明确的流程,成功实施可靠的发布计划的机会并不大。这不是只是悲观,尽管我很乐意承认它是。
就像成功主要基于努力工作和一点运气一样,稳固,可重复的发布时间表基于流程;拥有诸如功能规范和设计规范之类的东西对于能够以一致,可靠的时间表发布非常关键。 (你知道为什么人们会有这样的规范事情,对吗?)并不是说如果没有这些东西你就无法达到你的日程并释放期望;你很可能。但是,如果实施这样的程序会大大增加你达到预期的机会,至少部分是因为它确保了在你实施的同时期望不会进入“不合理”的领域。
同样,这并不意味着你无法实现上述所需的工作;说实话,如果你所处的环境对于采用这样的过程有积极的敌意,那么你可能正在以最好的方式实现你所需要的。我并不是说完全悲观;听起来你已经很好地掌握了如何尝试完成这些工作;对于你必须使用的东西,听起来你已经有了合理的流程。但我几乎可以保证,如果你能得到两件东西,你最终会变得更好; 1)来自管理的功能规范,描述他们希望软件做什么,以及2)从工程描述到管理的设计规范,如何使软件在功能规范中做他们想要的。我想你甚至可能适合你的过程;功能规格不需要复杂;他们关键的一点是,他们被写下来,这可以防止人们对管理层的要求进行争吵;它就在那里。设计规范也不需要花费很多时间;一个快速的单页面管理器,让管理层知道(在高层次)你将如何实现他们需要的东西,让他们确信你已经听过他们,并且可以帮助他们理解所涉及的复杂性(但不要去太深入了,否则你冒着厌烦他们而失去注意力的风险。)
答案 2 :(得分:0)
及早发布。
在我们展示用户之前,我经常发现用户不知道他们想要什么。在我们的工厂,我们有一个轻量级的QA /测试系统。让用户尝试新事物。随着用户对创意的批准,我们将其转移到生产中。这使我们始终可以处理新事物,测试接口,添加数据库表和列,而不会破坏生产代码。
唯一的“技巧”是不断提醒客户测试平台不是生产平台。
答案 3 :(得分:0)
您使用什么来进行源代码管理?
我们使用SVN,并且可以灵活地根据下一版本中要部署的内容创建各种不同的分支。如果将释放a1,a2和a3设置为释放,我们可以将这些更改合并到生产分支中。如果a2变得不那么优先,我们只能回滚a2的更改,或者如果有重叠,只需创建一个新的分支并仅合并a1和a3,留下a2以便稍后释放。
拥有者在给定版本之前重写规范的可能性有多大?我工作的地方经常发生这种情况,如果有必要,可以转换和回滚/重新合并。
答案 4 :(得分:0)
我的公司也因功能要求而陷入困境。
我们所做的是完成所有功能,并估算实施所需的时间。然后,我们将其留给我们的“变革委员会”(我们的首席执行官,团队领导等),为我们提供我们将在下一个冲刺阶段完成的功能。
通过这种方式,我们没有被给予不合理的大工作量,最终用户对完成的工作有一些发言权。