I would say it's the amount of development effort required. Taking a team of six developers:
Small project - up to 6 months
Big project - 6-18 months
Very big project - 18+ months
Everyone will have a different opinion though.
Edit
I was thinking about how those values would change for a 1 developer "team". I think they would be along the lines of:
Small project - up to 1 month
Big project - 1-3 months
Very big project - 3+ months
This seems to suggest that for small numbers of developers the rule of thumb for project size might be:
Small project - up to 1 month per developer
Big project - 1-3 months per developer
Very big project - 3+ months per developer
I doubt this scales beyond 6 or so developers though as the number of communication channels starts to drag on the potential development time of each person. Effectively leading to less work done per month per developer the more people you have in your team.
I wouldn't begin to know how to estimate the lines of code expected on a project. Documentation... what's that ;) So for me, none of those things.
I would probably count the major functional areas, and look at a rough idea of the number of screens/pages and also a rough idea of the number of database tables. The database complexity might be a good indicator on a lot of projects I think.
发布评论
评论（7）
我想说的是所需的开发工作量。 以六名开发人员组成的团队为例：
但每个人都会有不同的意见。
编辑
我正在考虑对于 1 名开发人员“团队”来说，这些值将如何改变。 我认为它们将遵循以下原则：
这似乎表明，对于少数开发人员来说，项目规模的经验法则可能是：
我怀疑这个规模是否会超过 6 个左右的开发人员，尽管沟通渠道的数量开始拖累潜力每个人的发展时间。 团队中的人员越多，有效地导致每个开发人员每月完成的工作就越少。
I would say it's the amount of development effort required. Taking a team of six developers:
Everyone will have a different opinion though.
Edit
I was thinking about how those values would change for a 1 developer "team". I think they would be along the lines of:
This seems to suggest that for small numbers of developers the rule of thumb for project size might be:
I doubt this scales beyond 6 or so developers though as the number of communication channels starts to drag on the potential development time of each person. Effectively leading to less work done per month per developer the more people you have in your team.
我会说时间和人力。
I would say Time and Manpower.
我通常会根据完成项目所需的时间来衡量项目的规模，但其他人可能会有所不同。
I would usually measure the size of a project on the time it would take to complete, but other people may be different.
学习曲线 - 新开发人员在可以做一些有用的贡献之前熟悉代码所需的时间。
The learning curve - The amount of time a new developer takes to get acquainted with code before he can do something useful to contribute to it.
它可能是多种因素的组合：
以上将决定项目规模 - 人数决定时间表并增加复杂性
It could be a combination of things:
The above would determine project size - the number of people determine timeline and add complexity
我不会开始知道如何估计项目所需的代码行数。 文档...那是什么；）所以对我来说，这些都不是。
我可能会计算主要功能区域，并粗略地了解屏幕/页面的数量以及数据库表的数量。 我认为数据库复杂性可能是很多项目的一个很好的指标。
I wouldn't begin to know how to estimate the lines of code expected on a project. Documentation... what's that ;) So for me, none of those things.
I would probably count the major functional areas, and look at a rough idea of the number of screens/pages and also a rough idea of the number of database tables. The database complexity might be a good indicator on a lot of projects I think.
这是一种左翼想法，但当我在做一个项目时，我设想它是
1) 房子 = 小型项目
2) 超市 = 中型项目
3) 机场 = 大型项目
你有点被人们所知道您周围的情况、您和他们正在做的事情以及您在这三者中的哪一个取得成功的机会。
It's a kind of left idea, but when I'm working on a project I envisage it as being
1) A house = small project
2) A supermarkert = medium size project
3) An airport = big project
You kind of know by the people around you, what you and they are doing, and your chances of success which of the three you're on.