频繁访问会导致400错误么
敏捷方法可以帮助团队更频繁地发布。 当团队更频繁地发布产品时,产品人员可以重新计划产品路线图。 项目组合人员可以重新计划项目组合。
并非每个团队的发布频率都足够高,可以利用经常进行的小规模计划。 每个人都沦为“太多”思考的牺牲品。 产品人员不需要创建MVE或MVP,而是需要整个功能集。 团队认为他们可以充斥一个迭代工作,并且只能在迭代结束时发布。 或者,它们仅在“所有”工作完成后才释放。
等待功能集“全部”的问题之一是:用户可能不需要该功能集的大部分。 我们所有人都使用肿的产品,这些产品每天都会使我们的生活痛苦不堪。
另一个问题发生在项目组合级别。 那些人想转到下一个重要项目,但是团队仍在以前的功能集上。
这种“过多”的思考和不频繁的发布可以为多任务处理奠定基础。 完成任何事情都是一场灾难。
团队等待发布的时间越长,发布的难度就越大,团队越倾向于通过体系结构层而不是体系结构进行工作。
还有另一个问题 在时间表结束之前,团队直到最终发布后,才收到有关其工作的反馈。 我已经看到了三个和四个星期的时间框。
团队没有演示的时间越长,任何人都无法进行重新计划。 每个人都需要制定大型计划来应对大型发行版,即“太多”的想法。 大型计划遍布组织。
“释放频率的潜力”这一想法可能会有所帮助。
如果您拥有数字产品,则可以每天学会多次发布。 也许您在内部发布是因为您的客户还不能接受。 但是,您的工作是弄清楚每天如何释放。 (如果您拥有数字产品,但又觉得自己每天都无法发布,请参阅小故事系列 。)
如果您打算每天发布,即使它是内部发布,您也会看到以下好处:
- 作为一个团队,您可以更快地学习。 每个人(整个团队,包括产品负责人,都可以看到进度并从团队的学习中学习。)
- 团队不创建任务,而是创建故事。
- 您可以更频繁地更改积压订单和路线图中的内容。
团队每天释放的能力可以帮助每个人:
- 团队可以停止大批量计划。 这意味着团队不再需要计划四分之一的时间,甚至不需要为迭代计划太多。 团队可能会转向流程而不是迭代。
- 组织可以从季度计划和年度计划过渡到更频繁的更少工作计划。 更加频繁的计划可帮助团队停止多任务处理,并使计划产品路线图和项目组合变得更加容易。
每天放些东西是从开始工作到完成工作的一种方式。
离您的发布(更频繁地发布)离去,以查看进度并更小,更频繁地计划/重新计划。
翻译自: https://www.javacodegeeks.com/2018/06/frequent-releasing-planning.html
频繁访问会导致400错误么