敏捷估算 视频
Agile allows companies to deliver value to their clients earlier and to adapt to changes faster. Agile methodologies such as scrum, kanban, and XP are widely using in software development industry.
敏捷使公司能够更早地为客户提供价值,并更快地适应变化。 scrum,看板和XP等敏捷方法已在软件开发行业中广泛使用。
Recently I researched about the velocity, velocity estimation, and its benefits as prior to my final year project. I would like to share some points I found during my research about velocity estimation.
最近,在我最后一年的项目之前,我研究了速度,速度估计及其好处。 我想分享我在速度估算研究中发现的一些观点。
Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration.
速度是衡量团队进度的指标。 它是通过将团队在迭代过程中完成的分配给每个用户故事的故事点数相加而得出的。
Let’s start with iteration planning. Iteration is a single development cycle, usually measured as one week or two weeks. There are two ways of planning an iteration,01. velocity-driven iteration planning 02. commitment-driven iteration planning
让我们从迭代计划开始。 迭代是一个单独的开发周期,通常以一周或两周来衡量。 有两种计划迭代的方法01。 速度驱动的迭代计划02.承诺驱动的迭代计划
承诺驱动的迭代计划 (Commitment-Driven Iteration Planning)
Here, rather than creating an iteration plan that according to the number of story points or ideal days already completed in the prior iteration, the team is asked to add stories to the iteration one-by-one until they can commit to completing no more.
在这里,与其创建一个根据故事点数或在先前迭代中已经完成的理想日子的迭代计划,不如要求团队将故事逐个添加到迭代中,直到他们承诺不再完成为止。
速度驱动的迭代计划 (Velocity Driven Iteration Planning)
First, they identify the target velocity for the coming iteration. The team then selects an iteration goal, which is a general description of what they wish to accomplish during the coming iteration. After selecting an iteration goal, the team selects the top priority user stories that support that goal. Stories are selected as necessary for the sum of their ideal day or story point estimates to equal the target velocity. Finally, each selected story is split into tasks and each task is estimated.
首先,他们确定下一次迭代的目标速度。 然后,团队选择一个迭代目标,这是他们希望在即将到来的迭代中完成的目标的一般描述。 选择迭代目标后,团队将选择支持该目标的最优先用户故事。 根据需要选择故事,以使其理想日或故事点估计的总和等于目标速度 。 最后,将每个选定的故事分为多个任务,并对每个任务进行估算。
团队如何估算速度? (How does a team estimate the velocity?)
The commonly used assumption by most teams is that their velocity in thenext iteration will equal the velocity of the most recent iteration. By doing an industry survey we found that many teams select the velocity of the most recent iteration for as the basis of next iterations with some adjustments.
大多数团队通常使用的假设是,他们在下一次迭代中的速度将等于最近一次迭代的速度。 通过进行行业调查,我们发现许多团队选择最近迭代的速度作为进行一些调整的下一次迭代的基础。
According to many resources including [1], the most preferred way to forecast velocity is to run at least 3 iterations and then estimate velocity from the observed velocity during the one to three iterations.
根据包括[1]在内的许多资源,预测速度的最优选方法是运行至少3次迭代,然后在1至3次迭代期间从观察到的速度估算速度。
Further, the observed average velocity can be converted into a range using Cone of Uncertainty.
此外,可以使用不确定度锥将观测到的平均速度转换为范围。
![Image for post](https://i-blog.csdnimg.cn/blog_migrate/f9a989e8f5d7a91b11bf38098d83bcac.png)
If the team has run a single Iteration, the “initial product definition” milestone is considered and the corresponding range is used. If two Iterations are completed, the range corresponding to the “approved product definition” milestone is used, and so on. For example, a team has run three iterations with an average velocity of 50 during that period. For three iterations the appropriate range is 85% to 115%. This means that if the team’s average velocity is 50 after three iterations, their actual true velocity by the end of the project will probably be in the range 42–58.
如果团队进行了一次迭代,则考虑“初始产品定义”里程碑,并使用相应的范围。 如果完成两个迭代,则使用与“批准的产品定义”里程碑相对应的范围,依此类推。 例如,一个团队在该期间内运行了3次迭代,平均速度为50。 对于三个迭代,合适的范围是85%至115%。 这意味着,如果团队在三轮迭代之后的平均速度为50,那么到项目结束时,他们的实际真实速度可能在42-58之间。
导致冲刺速度波动的因素 (Factors Cause to Fluctuations in Sprint Velocity)
The factors that cause velocity can divide into two categories.
导致速度的因素可以分为两类。
01. The Friction forces are the factors that are make constant drag on productivity and reduce Project Velocity.Examples :a. Team Composition (right people with right skills)b. Process (changes to the current development process)c. Environment (interruption, noise, poor ventilation condition etc.)d. Team dynamics (Some team members may not fit well with others)
01. 摩擦力是持续影响生产率并降低项目速度的因素。 团队组成(具有适当技能的适当人员)b。 流程(对当前开发流程的更改)c。 环境(干扰,噪音,通风条件差等)d。 团队动力(某些团队成员可能不适合其他人)
02. The Variable or Dynamic Forces that decelerate the project or team members and cause the Project Velocity to be irregular.Examples:a.Team changesb. New toolsc. Vendor defects (defects in third-party tools)d. Outside responsibilitiese. Personal issuesf. Stakeholder issuesg. Unclear requirementsh. Personal issues
02.使项目或团队成员减速并导致项目速度不规则的可变力或动态力 。示例:a。团队变更b。 新工具c。 供应商缺陷(第三方工具中的缺陷)d。 外部责任 个人问题 利益相关者问题 要求不明确h。 个人问题
Apart from that, I pointed out that the high work in progress rate is caused to decrease the velocity at the end of a sprint.
除此之外,我指出,较高的进度正在导致冲刺结束时降低速度。
High work in progress (WIP)There can be issues in the sprint, which are not met the definition of done at the end of the sprint, but already committed. The commitment has already acquired the effort of the developer, but it does not consider when counting team velocity. It is very important to manage WIP amount to get an effectively delivered velocity.
正在进行的高工作(WIP)冲刺中可能存在一些问题,这些问题未达到冲刺结束时已完成的定义,但已经提交。 该承诺已获得开发人员的努力,但在计算团队速度时并未考虑。 管理在制品数量以获得有效的输送速度非常重要。
ConclusionVelocity estimation is pretty challenging as the dynamic nature of the team and outside environment. But it is still possible to do an estimation by considering historical data of past iterations and the accuracy can improve using the cone of uncertainty. Development teams should pay attention to work in progress amount at the end of a sprint as they are not captured as done velocity of a sprint.
结论作为团队和外部环境的动态性质,速度估算非常具有挑战性。 但是仍然可以通过考虑过去迭代的历史数据进行估算,并且使用不确定性锥可以提高准确性。 开发团队应注意在冲刺结束时的进度,因为它们没有被视为冲刺的完成速度。
升级编码 (Level Up Coding)
Thanks for being a part of our community! Subscribe to our YouTube channel or join the Skilled.dev coding interview course.
感谢您加入我们的社区! 订阅我们的YouTube频道或参加Skilled.dev编码面试课程 。
翻译自: https://levelup.gitconnected.com/estimating-velocity-for-iterations-in-agile-394496aed24e
敏捷估算 视频