指定新功能
我很好奇其他开发团队如何指定新功能。我刚刚升任领导的团队没有真正的规范流程。我刚刚使用 CI、自动部署和使用 Trac 记录所有错误来实现了正确的开发流程，现在我正在继续处理更改。
我列出了在接下来的 2 个月内要对我们的产品进行大约 20 项更改的清单。通常我只会详细说明每个更改应该做什么，但我很好奇其他团队如何处理这个问题。有什么建议吗？
I am curious as to how other development teams spec out new features. The team I have just moved up to lead has no real specification process. I have just implemented a proper development process with CI, auto deployment and logging all bugs using Trac and I am now moving on to deal with changes.
I have a list of about 20 changes to our product to have done over the next 2 months. Normally I would just spec out each change going into detail of what should be done but I am curious as to how other teams handle this. Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为我们在上一份工作中采取了成功的方法，因为我们按时交付了项目，并且在生产中只发现了几个问题。然而，只有 3 个人在开发该产品，所以我不完全确定它将如何扩展到更大的团队。
我们预先为整个产品编写了规格，但没有涉及太多细节，并重点关注用户界面。这是我们了解必须做什么和项目范围的一种方式。
当我们开始实施时，我们必须更详细地解决所有问题（并且不可避免地必须做一些与规范不同的事情）。为此，我们聚在一起制定了实现每个功能的最佳方法（有时使用原型）。我们没有更新原始规范，但我们在会议后做了笔记，因为事后很容易忘记细节。
总而言之，我的方法是将规范视为探索性工具，并在实施过程中制定出更精细的细节。根据项目的不同，随着应用程序的发展，使原始规范保持最新可能也是一个好主意（这次我们不需要这样做）。
I think we had a successful approach in my last job as we delivered the project on time and with only a couple of issues found in production. However, there were only 3 people working on the product, so I'm not entirely sure how it would scale to larger teams.
We wrote specs upfront for the whole product but without going into too much detail and with an emphasis on the UI. This was a means for us to get a feel for what had to be done and for the scope of the project.
When we started implementing things, we had to work everything out in a lot more detail (and inevitably had to do some things differently from the spec). To that end, we got together and worked out the best approach to implementing each feature (sometimes with prototypes). We didn't update the original spec but we did make notes after the meetings as it's very easy to forget the details afterwards.
So in summary, my approach is to treat specs as an exploratory tool and to work out finer details during implementation. Depending on the project, it may also be a good idea to keep the original spec up to date as the application evolves (which we didn't need to do this time).
好问题，但它可能是主观的。我想这取决于产品的策略，是否以相同的方式部署到多个客户端，或者部署到定制项目的单个客户端，这些更改对系统和彼此的影响、依赖性以及这些更改的优先级需要做出改变。
我会查看优先级和依赖性，这会自然地开始对事物进行分组？
Good question but its can be subjective. I guess it depends on the strategy of the product, if its to be deployed to multiple clients in the same way or to a single client on a bespoke project, the impact, dependency these changes have on the system and each other and the priority these changes need to be made.
I would look at the priority and the dependency, that will naturally start grouping things?