Do you think that project iteration length is related to project team size? If so, how? What other key factors do you use to recognize correct iteration length for different projects?
您认为项目迭代长度与项目团队规模有关吗?如果是这样,怎么样?您使用哪些其他关键因素来识别不同项目的正确迭代长度?
6 个解决方案
#1
1
Iteration length is primarily related to the teams ability to communicate and complete a working version of the software. More team members equals more communication channels (*s's Law) which will likely increase your iteration time.
迭代长度主要与团队沟通和完成软件工作版本的能力有关。更多的团队成员等于更多的沟通渠道(布鲁克斯定律),这可能会增加你的迭代时间。
I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.
我认为2周的迭代,无论你是否交付给客户,都是一个很好的目标,因为它可以进行非常好的健康检查。
Ultimately, the iteration length will depend on the features you wish to implement in the next iteration, and in the early phases your iterations may jump around from 1 week to 1 month as you become comfortable with the team and the technology stack.
最终,迭代长度将取决于您希望在下一次迭代中实现的功能,并且在早期阶段,当您对团队和技术堆栈感到满意时,您的迭代可能会从1周跳到1个月。
#2
0
One of the main drivers for short iterations, is easing integration between modules/features/programmers. Obviously, the bigger your team, the more integration you will have. It's a tradeoff: short iterations mean you're integrating often, which is good - BUT if its a big team you'll be spending a LOT of team on integration overhead, even without new code. Longer iterations obviously mean more integration each time less seldom, and a lot more risky.
短迭代的主要驱动因素之一是简化模块/功能/程序员之间的集成。显然,您的团队越大,您的整合就越多。这是一个权衡:短迭代意味着你经常集成,这很好 - 但如果它是一个大团队,你将花费很多团队来进行集成开销,即使没有新的代码。更长的迭代显然意味着每次更少的集成更少,风险更大。
If your team is very large, you can try branched integration, i.e. integrating small subteams often, and integrating between the teams less often... BUT then you'll be having inconsistencies between branches, and you lose much of that benefit right there.
如果你的团队非常庞大,你可以尝试分支整合,即经常整合小团队,并且不那么经常地在团队之间进行整合......但是你们之间的分支会有不一致的地方,你们就会失去很多好处。
Another key factor to consider is complexity - obviously complex, backend systems are riskier integration, simple Web-UI pages are less risky.
另一个需要考虑的关键因素是复杂性 - 显然很复杂,后端系统是风险更高的集成,简单的Web-UI页面风险较小。
(I realize I didnt give you a clear cut answer, there is none. It's always tradeoffs, I hope I give you some food for thought.)
(我知道我没有给你一个明确的答案,没有。这总是权衡,我希望我给你一些思考的食物。)
#3
0
My experience is that the length of the iterations are somewhat dependent on team size,
我的经验是,迭代的长度在某种程度上取决于团队规模,
External dependencies, like in cases where we had to integrate with in house systems that was not using a iteration based development cycle (read waterfall) where another factor we observed.
外部依赖性,例如我们必须与不使用基于迭代的开发周期(读取瀑布)的内部系统集成的情况,其中我们观察到另一个因素。
Our team were real noobs when it came to iterative development, so in the beginning the iterations where really long (12 weeks). But later on we saw that there was no need to worry, and the iterations shrunk considerably (4-6 weeks).
我们的团队在迭代开发方面是真正的新手,所以在开始的时候真的很长(12周)。但后来我们发现没有必要担心,迭代次数大幅缩减(4-6周)。
So another factor in how long the iterations are is how familiar you are with the concept of iterative development.
因此迭代需要多长时间的另一个因素是您对迭代开发概念的熟悉程度。
#4
0
I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.
我认为2周的迭代,无论你是否交付给客户,都是一个很好的目标,因为它可以进行非常好的健康检查。
2-week iterations are most comfortable for me and the kinds of projects I usually do, but I disagree that not delivering is a good outcome - the focus needs to stay on the "working software over process" side of things.
2周的迭代对我和我通常做的项目来说都是最舒适的,但我不同意不交付是一个好结果 - 重点需要留在“工作软件过程”方面。
I would consider making iterations longer if the product owner / user isn't available, even if only for a showcase every couple weeks, as the same health checks that fast iterations allow on the technical side need to happen on the side of the engagement with the business.
如果产品所有者/用户不可用,我会考虑延长迭代时间,即使每两周只展示一次展示,因为快速迭代允许技术方面的相同运行状况检查需要在参与方面进行这生意。
#5
0
Iteration length should be decided on many factors... and team size is really only part of the considerations made for the "Overhead of Iterating".
迭代长度应根据许多因素来决定......团队规模实际上只是“迭代开销”考虑因素的一部分。
This article explains many of them.
本文解释了其中的许多内容。
The important ones IMO:
重要的IMO:
- Overall Release Length
- How Long Priorities Can Remain Unchanged
- The Overhead of Iterating
总释放长度
多长时间的优先权可以保持不变
迭代的开销
#6
0
There is relation in terms of how much work can get done but there are a couple of other key factors here like what type of project are they working on, e.g. Windows Application, Console Application, or Web Application as well as how developed is the codebase in terms of size, complexity and stye compared to the current team's style, and what expertise does the team have both within the methodology and the work that they are doing as inexperience may be costly in terms of getting everyone proficient with the process.
在可以完成多少工作方面存在关系,但是在这里还有一些其他关键因素,例如他们正在进行哪种类型的项目,例如: Windows应用程序,控制台应用程序或Web应用程序以及与当前团队风格相比,在规模,复杂性和标准方面的代码库是如何开发的,以及团队在方法和工作中所拥有的专业知识因为缺乏经验可能会让每个人都熟悉这个过程。
#1
1
Iteration length is primarily related to the teams ability to communicate and complete a working version of the software. More team members equals more communication channels (*s's Law) which will likely increase your iteration time.
迭代长度主要与团队沟通和完成软件工作版本的能力有关。更多的团队成员等于更多的沟通渠道(布鲁克斯定律),这可能会增加你的迭代时间。
I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.
我认为2周的迭代,无论你是否交付给客户,都是一个很好的目标,因为它可以进行非常好的健康检查。
Ultimately, the iteration length will depend on the features you wish to implement in the next iteration, and in the early phases your iterations may jump around from 1 week to 1 month as you become comfortable with the team and the technology stack.
最终,迭代长度将取决于您希望在下一次迭代中实现的功能,并且在早期阶段,当您对团队和技术堆栈感到满意时,您的迭代可能会从1周跳到1个月。
#2
0
One of the main drivers for short iterations, is easing integration between modules/features/programmers. Obviously, the bigger your team, the more integration you will have. It's a tradeoff: short iterations mean you're integrating often, which is good - BUT if its a big team you'll be spending a LOT of team on integration overhead, even without new code. Longer iterations obviously mean more integration each time less seldom, and a lot more risky.
短迭代的主要驱动因素之一是简化模块/功能/程序员之间的集成。显然,您的团队越大,您的整合就越多。这是一个权衡:短迭代意味着你经常集成,这很好 - 但如果它是一个大团队,你将花费很多团队来进行集成开销,即使没有新的代码。更长的迭代显然意味着每次更少的集成更少,风险更大。
If your team is very large, you can try branched integration, i.e. integrating small subteams often, and integrating between the teams less often... BUT then you'll be having inconsistencies between branches, and you lose much of that benefit right there.
如果你的团队非常庞大,你可以尝试分支整合,即经常整合小团队,并且不那么经常地在团队之间进行整合......但是你们之间的分支会有不一致的地方,你们就会失去很多好处。
Another key factor to consider is complexity - obviously complex, backend systems are riskier integration, simple Web-UI pages are less risky.
另一个需要考虑的关键因素是复杂性 - 显然很复杂,后端系统是风险更高的集成,简单的Web-UI页面风险较小。
(I realize I didnt give you a clear cut answer, there is none. It's always tradeoffs, I hope I give you some food for thought.)
(我知道我没有给你一个明确的答案,没有。这总是权衡,我希望我给你一些思考的食物。)
#3
0
My experience is that the length of the iterations are somewhat dependent on team size,
我的经验是,迭代的长度在某种程度上取决于团队规模,
External dependencies, like in cases where we had to integrate with in house systems that was not using a iteration based development cycle (read waterfall) where another factor we observed.
外部依赖性,例如我们必须与不使用基于迭代的开发周期(读取瀑布)的内部系统集成的情况,其中我们观察到另一个因素。
Our team were real noobs when it came to iterative development, so in the beginning the iterations where really long (12 weeks). But later on we saw that there was no need to worry, and the iterations shrunk considerably (4-6 weeks).
我们的团队在迭代开发方面是真正的新手,所以在开始的时候真的很长(12周)。但后来我们发现没有必要担心,迭代次数大幅缩减(4-6周)。
So another factor in how long the iterations are is how familiar you are with the concept of iterative development.
因此迭代需要多长时间的另一个因素是您对迭代开发概念的熟悉程度。
#4
0
I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.
我认为2周的迭代,无论你是否交付给客户,都是一个很好的目标,因为它可以进行非常好的健康检查。
2-week iterations are most comfortable for me and the kinds of projects I usually do, but I disagree that not delivering is a good outcome - the focus needs to stay on the "working software over process" side of things.
2周的迭代对我和我通常做的项目来说都是最舒适的,但我不同意不交付是一个好结果 - 重点需要留在“工作软件过程”方面。
I would consider making iterations longer if the product owner / user isn't available, even if only for a showcase every couple weeks, as the same health checks that fast iterations allow on the technical side need to happen on the side of the engagement with the business.
如果产品所有者/用户不可用,我会考虑延长迭代时间,即使每两周只展示一次展示,因为快速迭代允许技术方面的相同运行状况检查需要在参与方面进行这生意。
#5
0
Iteration length should be decided on many factors... and team size is really only part of the considerations made for the "Overhead of Iterating".
迭代长度应根据许多因素来决定......团队规模实际上只是“迭代开销”考虑因素的一部分。
This article explains many of them.
本文解释了其中的许多内容。
The important ones IMO:
重要的IMO:
- Overall Release Length
- How Long Priorities Can Remain Unchanged
- The Overhead of Iterating
总释放长度
多长时间的优先权可以保持不变
迭代的开销
#6
0
There is relation in terms of how much work can get done but there are a couple of other key factors here like what type of project are they working on, e.g. Windows Application, Console Application, or Web Application as well as how developed is the codebase in terms of size, complexity and stye compared to the current team's style, and what expertise does the team have both within the methodology and the work that they are doing as inexperience may be costly in terms of getting everyone proficient with the process.
在可以完成多少工作方面存在关系,但是在这里还有一些其他关键因素,例如他们正在进行哪种类型的项目,例如: Windows应用程序,控制台应用程序或Web应用程序以及与当前团队风格相比,在规模,复杂性和标准方面的代码库是如何开发的,以及团队在方法和工作中所拥有的专业知识因为缺乏经验可能会让每个人都熟悉这个过程。