通过维基百科阅读我遇到了敏捷开发中Sprint的概念。根据我的理解,Sprint是指一组开发人员编写一定数量的功能,一旦这些功能被编程,它们就被打包并运送到客户端,然后下一个sprint启动,另一组功能被编码并运送出去,所以上...
我想知道客户端如何安装这些功能,以便它们成为包含以前功能的软件的一部分,编译后的代码是否以客户端安装的补丁的形式发布?是否重新编译整个应用程序,并且客户端使用更新的功能重新安装应用程序?使用某种框架设计的应用程序是否可以简单地将新功能插入到当前安装的应用程序中?这一切是如何运作的?
答案 0 :(得分:5)
每个sprint都没有实际部署。它们是可部署的,但并不总是部署。
“整个应用程序是否重新编译,客户端是否重新安装了具有更新功能的应用程序?”
当然。这是一个新版本。市场营销经常介入并将几个冲刺捆绑成一个大包装以供发布。
“使用某种框架设计的应用程序是否可以简单地将新功能插入当前安装的应用程序中?”
很少。
答案 1 :(得分:2)
这个想法是,在每个sprint结束时,你应该可以完全和完全地部署(实际上,甚至在sprint中)。此版本将减少功能,但它应该在部分实现的限制内完全可用。客户通常不参与Q / A部门(如果您在最终发布之前有专门的部门)。参与的是:
如果客户希望看到某些内容,您随时可以向他展示。这将使他感兴趣,给他一种进步感,安全感(你正在做某事,他可以看到渐进的改进),最终他可以为你提供有用的反馈。
答案 2 :(得分:1)
sprint的定义通常是基于优先级实现功能的固定时间量;所以时间是固定的,内容是可变的。
sprint的想法是提供潜在的可交付代码;这并不意味着必须在客户处部署这些版本。通常还有另一个流程,例如可以进行验证和部署。或者每2/3/4个冲刺中的1个是发布冲刺。
答案 3 :(得分:1)
我工作的公司(以及我认识的大多数其他敏捷公司)都在Web开发中工作,这些问题不是问题。您的sys-admin会在每个sprint结束时(理论上)部署到Web服务器。在实践中,我说我们会部署其他所有已完成的冲刺。