我看到的——自从我开始做这个30多年以来——就是日期总是更重要，而不是实际的交付成果。总是如此。只跟踪“日期”（但其实它也从未实现）。甚至通过像乔尔·斯波尔斯基的告诫这样的模糊类比来为它辩护：“你不会在不知道价格的情况下买一条牛仔裤”，而从未深入探讨一下开发软件与卖牛仔裤的不同之处。作者所提到的所有协作表面现象在我看来总是徒劳地试图满足“日期”。软件开发本身可能本质上就是不可预测的，这一点从未被考虑过，尽管有很多理由表明它确实是：根据定义，你正在开发的软件之前从未被开发过，否则你就可以直接使用已有的东西。
源讨论“协作”是胡说八道原帖 187 条评论 · 导入时统计把你的经验，加入这段讨论。
我喜欢LLM在估算方面已经像人类一样了。当被问及估算时，它们会给出一个非常宽松的周数估算。 然后它们会在30秒内实现这个解决方案。
完整原文据我所见（我也在这个行业30年了），这很少是日期，那是第二位。是预算。 如果稍微晚一点，他们可以原谅你，但如果你要更多的钱，他们会永远讨厌你。 如果有一个好的产品负责人，并且已经为这个项目的不确定性水平争取到了适当的预算，并且能够做出决策，而不是被外部力量所左右，那么敏捷方法会非常有效。其他的一切都可以协商。
完整原文> 日期总是比实际交付物更重要。总是如此。 哈！你刚刚给了我一个新方法的灵感。日期绑定的交付。 - 业务会告诉你要做什么，就像他们通常做的那样 - 业务会告诉你要在什么时候完成，就像他们通常做的那样 - 团队不会说需要多长时间。相反，他们会说他们认为在给定时间内可以交付什么。 - 随着日期的临近，更多的边缘功能会被删减 - 当日期到来时，总会有东西可以交付，不管它有多微不足道 这种方法将确保交付，但不一定是交付的内容。事后分析将不再讨论为什么某件事花了这么长时间，而是会关注为什么删减了某些功能。 如果正如你所说，日期总是更重要，那么这样的方法值得尝试吗？
完整原文斯波尔斯基的引述的自然延伸是：除非有人为牛仔裤付费。 我认为组织越小，软件项目就越有可能有真正的利益相关者。在更大、更成熟的组织中，经验丰富的员工已经安排好他们的事务，使得他们的职业发展不依赖于软件的交付：晚点、早点，或者永远。例如，我从事技术开发的“硬件”方面，我会调整我的年度绩效评估目标，使得当我能用自己编写的代码进行演示时，就满足了交付要求。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。