Project management webframework工作量估算

如何将功能点中的工作量估算值转换为特定的web框架（如django）？或者工作量估算完全依赖于web框架的体系结构？任何提示或指导都会有所帮助

编辑 你会限制我的思维吗？比如说，这是我的框架，比如django，让我考虑一下如何将我的需求转换为模型和模板

---

或者我可以泛泛地说，这些是我的需求，现在这些是我的功能点（任何泛型估计技术），我可以将其转换为django框架的约束，并进行工作量估计

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

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

---

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

我喜欢Scrum的velocity概念，从规模估算到进度估算，并已成功应用多年

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

从这个规模估计到进度估计，你要应用速度：团队在给定时间内完成的功能的价值多少点，比如n周的冲刺（迭代），其中n在1到4之间。所以，如果你有一个速度，比如说每两周300点的冲刺，你有500点的用户故事要在你的待办事项中实现。因此，你需要两周的冲刺来完成它们。但通常情况下，它是以另一种方式应用的：给定一个固定持续时间的sprint，哪些故事可以实现最大价值，哪些故事应该推迟

你如何得到速度数？首先你得猜一猜。但是在第一次冲刺之后，您将为您的团队获得一些历史速度数据。开始根据这些数据估算速度，而不是猜测。你对数字的调整越少，随着时间的推移，它们就越精确

<> P>这样，问题大小不必考虑问题本身。团队特征（如经验、果冻等）表现在速度上

这是一个很好的论据