敏捷开发12条原则_敏捷开发的5条规划原则

敏捷开发12条原则

敏捷开发的核心原则之一是在每个sprint结束时交付可用的软件。 团队可以通过定义可靠的用户故事接受标准 ,以团队形式致力于冲刺, 自动化测试 ,演示冲刺结果以及成熟其他实践以确保代码完整并可以投入生产来实现这一目标。

采用devops惯例的组织 (包括CI / CD(连续集成/连续交付)管道 )开发了将代码推送到测试环境的自动化程序; 最先进的团队实施持续部署 ,在每次冲刺结束时或更频繁地将代码推送到生产环境中。

[ 开发最佳实践:您应采用的5种方法 如何使测试自动化与敏捷性和发展性保持一致 •InfoWorld解释了在设备开发时代的监视 究竟是什么东西? 探索如何改变软件开发 ]

问这些团队中的一些,他们下个月或即将发布的版本将交付什么,许多团队将很难回答这个问题。 询问他们如何确保优先事项对客户和最终用户产生积极影响,并且他们将承认有限的理解,覆盖范围和可见性才能充分回答此问题。

然后考虑更深层的问题:

  • 一个看起来易于实现的用户故事多久一次导致在多个sprint中执行多个故事?
  • 从产品所有者在待办事项列表中列出新功能到完全交付给客户的时间,新功能的循环时间是多少?
  • 团队在重塑方向,还是随着团队提供新功能而不断发展的标准?
  • 团队是否被诸如聘用,升级基础架构,培训以及其他需要提前至1-2个冲刺的时间来计划和执行的活动所阻塞?
  • 重要的应用程序发布的时间,范围,活动或风险会使运营团队多久措手不及?

如果您不知道这些问题的答案或已知问题,则您的组织可能需要做更多的计划。

敏捷开发团队已经在技术流程和自动化方面进行了大量投资,以实现更频繁,更可靠的应用程序发布。 关于确保所交付的物品能够带来业务价值的步骤又如何呢?

为什么敏捷团队难以计划

我已经与许多敏捷领导者谈过他们的计划实践,以及他们是否花费时间在下一个冲刺之后开发前瞻性积压

有人会说计划多个sprint并不敏捷。 他们的观点是,敏捷使产品所有者和团队能够听取客户反馈,查看通过应用程序生成的用户行为数据,并考虑其他信号以在每次冲刺开始时调整优先级。 他们的观点是“为什么要花时间去计划团队何时调整优先级?”

其他团队希望进行计划,但尚未制定实践和协作以进行有效计划。 为了使产品所有者提供有关未来优先级的足够详细信息,有些努力。 其他人则从其产品所有者那里获得了太多的优先权。 大多数人都难以获得足够明确的要求,这使得计划变得困难且可能花费巨大。

我一直从小组那里听到的一件事是,他们没有足够的时间进行计划,而且他们没有计划流程。 它们具有太多功能,用户故事, 技术债务 ,运营改进和其他开发优先级,从而使它们超载。 计划不是优先事项。

为什么企业需要前瞻性计划

成熟的公司和企业需要-而且很多都需要-敏捷团队的前瞻性计划和路线图 。 大多数组织都需要它们,以便计划与应用程序发布相关的其他业务活动。 对于软件公司,这可能包括开发营销材料,培训销售团队以及向主要客户通知新功能。 此外,如今,越来越多的企业开发满足内部和客户需求的应用程序。 这些组织还必须考虑对员工进行培训,并在新功能上更新客户支持功能。

敏捷团队还必须考虑需要更长交付时间的需求。 例如,在引入新技术时,运营团队将需要时间在云或数据中心中进行安装和配置。 如果组织需要从服务提供商处雇用员工或招募新人员,则通常需要的计划远远超出了下一个冲刺。

解决敏捷计划悖论

与敏捷团队进行计划有几个需要考虑的原则。 这五个至关重要:

  1. 组织需要前瞻性的眼光。 它可以是愿景声明,战略计划或其他交流,可以就客户或用户的需求以及目标是哪些业务绩效指标树立北极星。 与真正的北极星不同,这种通信还需要灵活,并随着客户和业务需求的发展而迭代地更新。
  2. 团队需要时间来计划。 计划不是免费的,因此,如果企业重视或需要前瞻性计划,则经理必须在团队分配时间进行头脑风暴,审阅数据,直接向客户学习,投资概念验证并在几周前记录用户案例优先考虑实际故事。
  3. 团队需要一个已定义的计划流程,该流程必须与敏捷原则和适当的敏捷积压工具保持一致。 此计划过程需要有效地利用人们的时间,并具有明确的输出以及确定的角色和职责。 组织还应该考虑规划标准,并确定团队可以在何处进行自组织以解决其应用程序和技术的细节。
  4. 计划应该与敏捷开发团队使用的主要工件保持一致,尤其是与用户故事中的需求质量, 估计用户故事的步骤以及故事是否与技术,数据,安全性,用户体验和其他标准保持一致 。 计划还应该与操作需求保持一致,以支持生产环境中的应用程序。
  5. 规划实践需要机制来衡量有效性和影响。 团队是否按计划交付? 他们通过优先计划对业务产生影响吗? 他们是否使用发布后捕获的信息和数据来重新调整实践和优先级?

这些原则可以导致广泛的规划实践。 大型组织可能会选择SAFe的PI计划流程,在创新和计划迭代期间计划计划活动。 灵活的组织应考虑持续的敏捷计划 ,其中团队致力于计划每个sprint的活动以及交付用户故事的工作。 一些组织可能还希望通过敏捷的产品和产品组合管理工具来实施计划。

没有计划就容易迷路

敏捷实践的优势在于,它们可以帮助团队专注于短期的,明确定义的交付品。 缺点是团队很容易在旅途中迷路。 团队应通过完整的故事回顾其交付历史,以评估其中期和长期绩效。

团队是否说出他们将交付的内容并交付他们所说的内容? 交货对客户和最终用户有积极影响吗? 是否存在沟通和反馈循环,以帮助确定积压工作的优先顺序并优化需求?

建立敏捷的计划实践可以帮助团队弥补差距。

翻译自: https://www.infoworld.com/article/3438726/5-planning-principles-for-agile-development.html

敏捷开发12条原则

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值