Web框架工作量估算

Question

转换工作量估算如何在功能点上说出像django这样的特定网络框架？或者是努力估算完全取决于Web框架的架构？任何提示或指导都会有所帮助。

EDIT 你是否会限制思考说，这是我的框架，比如django，让我考虑将我的需求转换为模型和模板。

或者我可以说是通用的，这些是我的要求，现在这些是我的功能点（任何通用的估算技术），我可以将其转换为django框架的约束并带来努力估计。

Answer 1

我喜欢Scrum的速度概念，从大小估计到计划估算，并已成功应用多年。

问题，用户故事或功能是使用一些大小单位估算的：代码行，功能点，故事点，理想的工作时间，gummibears等等。假设我们正在估算“点数”的大小。

要从此大小估计值转到计划估算值，您应用速度：团队在给定时间内生成的已完成功能的点数，例如n周冲刺（迭代）其中n是例如在1..4范围内。因此，如果您的速度为每2周冲刺300分，那么您的积压工具中将有500分的用户故事。因此，您需要两个2周的冲刺才能完成所有冲刺。但通常它是相反的应用：给定一个固定的持续时间冲刺，可以实现哪些故事带来最大价值，哪些故事应该被推迟。

你如何获得速度数？起初你必须猜测它。但是在第一次冲刺之后，您将获得一些历史速度数据供您的团队使用。开始根据此数据进行速度估算而不是猜测。你调整数字越少，它们随着时间的推移就越准确。

这样，问题大小调整不需要考虑问题本身以外的任何问题。团队特征，如经验，凝聚等，都体现在速度上。

关于这个主题的良好反驳是Mike Cohn's Agile Estimating and Planning。

Answer 2

这可能取决于许多因素，例如团队对Web框架和Web技术的熟悉程度，应用程序的复杂程度以及它与Web模型的匹配程度 - 某些应用程序非常适合Web模型，而其他别。例如，当ASP.NET刚出现时，我试图将具有多个网格的内部桌面实用程序转换为ASP.NET。所有功能都已移植，但我无法让用户接受，因为与原始桌面应用程序提供的类似电子表格的可用性相比，“点击次数太多”。

与更传统的桌面应用程序相比，由于将工作分成（例如）数据库，DAL，BLL，WS，UI和报告层，您可能会看到内部工作的增加。另一个问题可能是由网络，浏览器和/或集中计算到服务器引起的性能问题。您也可能不得不担心浏览器兼容性。

可能真正了解的唯一方法就是在团队感兴趣的框架中尝试进行一些重要的开发，实现具有同等价值和行为的软件。