跳过主要内容

保存的文章

敏捷释放规划踢 - 开始敏捷收养

Doug Brophy |领导敏捷
Doug冰野
读: 敏捷释放规划踢 - 开始敏捷收养

采用敏捷

刚开始采用敏捷的组织急于看到结果。在组建了合适的敏捷团队并接受了敏捷基础知识的培训之后,他们就可以开始实践了。但是采用敏捷的第一步是什么?应该从哪里开始?敏捷发布计划就是答案。

敏捷采用:发布计划

敏捷释放规划使团队能够加快他们的敏捷收养。它将利益相关者聚集在一起,专注于开发软件要求,并计划逐步和迭代地开发软件。在规划中确定并解决了风险,问题,依赖关系和假设。

这次踢 - 启动敏捷采用实践,使团队能够快速开始提供结果,并将其设置为释放成功。最近的一个辅导订婚提供了一个很好的例子。

一个敏捷开发团队已形成以构建资源和操作计划工具套件的下一代平台。需要一个具有单个,共同的数据库和用户界面的新平台,以更好地集成并呈现产品产品,符合产品视觉和路线图。经过多年的临时发展,遗产平台已经过度负担技术债务,并使支持和扩展成本昂贵。

新的队伍在它的形成阶段.在对下一代平台需求的理解上存在着相互冲突的观点和分歧。现有的平台架构和代码库既庞大又复杂,对于如何利用它们,以及如何利用它们,存在着强烈的意见分歧。

大多数新团队来自遗留平台开发团队。但是产品负责人(PO)和产品经理(PM),两个开发人员和一个测试人员来自不同但相似的产品套件。该PO最近是其他产品套件的一个类似平台提升计划的一部分,并且有开发人员背景。因此,PO对如何执行这个项目有很强的意见,包括架构和代码重用的主题。他强烈主张用一个新的干净的架构重新开始,因为,例如,现有的平台有许多与UI紧密耦合的业务逻辑。亚博vip9通道

但遗产开发团队成员非常关注这样做。他们正在努力重新使用很多遗留代码(和架构)。在他们的思想中,这将是完成该项目的最快方法,因为他们在遗留平台的发展方面非常经验。

敏捷采用:发布计划研讨会

为了克服这些问题,我们举行了发布计划研讨会。来自产品管理、开发和其他涉众的代表出席了会议。我们的研讨会从回顾业务目标和相关的产品远景和路线图开始,作为讨论架构、史诗、特性和故事的先驱。亚博vip9通道这让产品管理部门很快明白,他们还没有完全准备好以这种方式讨论平台需求。

在研讨会的第一天,我们能够识别一些史诗/特性和故事,但这主要是一个培训练习,让团队了解我们发布什么以及如何发布计划,以改进他们的敏捷采用。有了这个新的理解,产品管理要求用一周的时间去“做他们的功课”,为下一次尝试敏捷发布计划做充分的准备。

敏捷采用:结果

一周后,我们再次召开会议,讨论发布计划的“第二阶段”。这一次我们取得了快速的进展,完成了发布计划的目标。值得注意的结果包括以下几点。

1)开发终于理解并接受了产品管理想要一种新的,简化,解脱耦合的架构 - 不仅仅是现有架构的重构。这将是正常化如何在新的公共平台上运行的产品/功能完成数据输入,处理和演示文稿的基础。

2)当项目进展时,交货日期将是可以谈判的。开发一直在假设9-12个月后会有固定的截止日期,他们将被迫接受,即使承诺到遥远的交货日期会有很高的风险。但产品管理没有确定固定的截止日期。相反,获取他们设想的新平台是他们的优先事项。它们可能灵活地了解最终完成日期。

3)产品管理确实希望看到进步的增量里程碑,幸运的是,这正是敏捷释放规划旨在提供的。该计划是为了开发,为每季度,内部,逐步和迭代地构建平台的每季度发布,导致最终产品发布。

4)有了一个整洁的发行版计划安排,团队就可以开始计划和执行sprint,并衡量他们的速度。这反过来可以在项目进行时细化发布计划。

5)团队在第二次冲刺结束时交付了一个演示,之后的每一次冲刺都是如此。他们最近完成了第一个季度发布里程碑。

敏捷采用:总结

对于一个在发布计划之前只接受了基本敏捷培训的新开发团队,我们在两周内就达成了一个可行的发布计划,使团队能够开始执行与第一个季度发布相一致的sprint。他们已经学会了如何将产品需求作为用户/角色和目标为中心的史诗,特性和故事,创建验收标准,在相对的故事点评估故事,并且他们已经为第一次sprint计划和执行做好了准备。

如果没有良好的敏捷释放计划,团队经常尝试使用一个清晰​​的深层积压开始冲刺,没有明确的方向,可以在释放目标上交付。这可能导致浪费的时间和努力(金钱),遗产习惯,以及敏捷和敏捷采用失望。

下一个;GQM:你如何知道你的参数是好的

留下你的评论

您的电子邮件地址将不会被公布。必填字段已标记