必须非常详细地评

raselbd223

与之前的瀑布阶段类似 评估进行得很专业。我们这边的一批领导做了后续的评估 团队相信评估是正确的 就执行了任务。另一项与教科书 方法不完全一致的任务是与开发冲刺并行运行分析冲刺。 这是由于客户之前提到的要求指定确切的实施日期的结果。修复版本报告应该可以帮助解决这个问题。然而 要使用它 估待办事项中分配给该开发阶段的所有故事。 构建积压工作的一开始是架构背景和将故事链接到史诗、版本等方案中的一个重要阶段。我们知道必须仔细考虑 因为后来所有来自 的数据报告都会变得容易得多 例如 我们将能够在实质性层面上根据上下文选择给定项目 。

与集成合同相关的版本或所有故事 。 整个阶段持续了 次冲刺。 阶段 在此阶段 我们慢慢接近在项目中构建目标 模型。我们先把整个团队分成两个 然后分成三个 团队 让他们慢慢合作、沟通和自组织。 每个团队都有一组开发人员和测试人员 分析师在单独的冲刺中加入团队。与此同时 我们推出了剩下的标准 一开始主要是 会议  也开始 电子邮件数据 按照方法论来统计故事点 早期的教育最终让我们将它们与时间的衡量标准分开 。 此外 估值已经使用 计算出来 因此我们将估值的责任转移给了每个团队成员。 当我们开始 元素时 我们开始仔细查看燃尽图  燃烧图  作为控制团队最佳工作方式的基本工具。



然而 当待办事项分析允许对所有故事进行评估时 前面提到的修复版本工具变得非常有用。 能力 开发团队效率的基础 我们知道 对于特定冲刺所需的人员可用性值得提前规划。第一个也是基本的方法当然是休假 缺勤计划。另外 我们使用了简单的  显示了开发人员的可用性 毕竟他们是最先燃烧故事点的人 也是团队中的关键专家组。 他们的存在成为每个冲刺中故事点容量的决定因素。仅基于开发人员 缺席 在场的简单计算比基于前两周活动效果的冲刺计划更可靠。