project-management - 网络框架工作量估算

Question

如何将功能点中的工作量估计转换为特定的 Web 框架，如 django？还是工作量估计仅取决于 Web 框架的架构？任何提示或指南都会有所帮助。

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

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

Answer 1

从规模估计到进度估计，我喜欢 Scrum 的速度概念，并且多年来一直成功地应用它。

问题、用户故事或功能是使用某种大小单位估计的：代码行、功能点、故事点、理想工作时间、口香糖等等。假设我们正在估计“点”的大小。

为了从这个规模估计到进度估计，你应用速度：团队在给定时间内完成的功能有多少点价值，比如一个 n 周的 sprint（迭代），其中 n 例如在范围 1.. 4. 因此，如果您的速度为每 2 周 sprint 300 个点，并且您有 500 个点的用户故事要在您的待办事项中实施。因此，您需要两个为期 2 周的冲刺来完成所有这些。但通常它以相反的方式应用：给定一个固定持续时间的冲刺，哪些故事可以实现带来最大价值，哪些故事应该推迟。

你如何获得速度数？一开始你必须猜测它。但是在第一个 sprint 之后，您将获得团队的一些历史速度数据。开始根据这些数据而不是猜测来估计速度。你对数字的调整越少，随着时间的推移，它们就会越准确。

这样，问题规模就不必考虑问题本身以外的任何事情。经验、凝聚力等团队特征体现在速度上。

关于该主题的一个很好的参考是Mike Cohn 的 Agile Estimating and Planning。

Answer 2

这可能取决于许多因素，例如团队对 Web 框架和 Web 技术的熟悉程度、应用程序的复杂性以及它与 Web 模型的匹配程度——一些应用程序非常适合 Web 模型，而另一些则不. 例如，当 ASP.NET 刚问世时，我曾尝试将具有多个网格的内部桌面实用程序转换为 ASP.NET。所有功能都已移植，但我无法获得用户的认可，因为与原始桌面应用程序提供的类似电子表格的可用性相比，“点击次数过多”。

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

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