我现在已经在两个不同的团队中工作过,这两个团队在过去两年中使用了Agile/Scrum方法,两个团队都渴望改进他们处理软件开发的方式.在第一个团队中,我们可以轻松地说服我们的产品所有者花时间处理内部事务,例如改进构建系统,设置更好的集成测试,更好的发布策略等.现在PO也愿意给我们时间,但是他更加努力,这是合理的,因为他也必须完成他的事情.
无论如何我现在的问题是,其他团队如何处理这个问题？你是否创造了一个改进故事并在规划期间把它放在桌面上,或者你为这些事情保留了一大堆时间？在您的体验中说服产品所有者有时间改进是多么困难？经过所有这些改进将有利于团队,但不是直接或立即产品所有者/业务.
好问题.我认为回顾展中有几种"行动项目"值得采用不同的方法.
1)解决技术债务或基础设施改进等问题的技术任务 - 比如"我们应该确保在我们的应用程序的视图层中没有数据库调用,因为这导致我们在过去的迭代中浪费时间......有人应该做一个搜索代码以确保我们不会在其他地方执行此操作."
2)流程改进(例如"人们没有准时到达立场......每当有人迟到时,我们就可以为慈善捐赠开1美元.")
第一类可能是重要的工作,也可能是直截了当的.我展示的示例非常简单......但可能会生成需要安排的其他任务(例如,在发现它们的5个位置删除数据库调用).
第二类应该由迭代管理器,项目经理,Scrum管理员等处理/驱动.我(作为Scrum Master或项目经理)通常将它们列在项目维基上并在回顾中讨论它们,当它们被检查时将它们关闭重新解决,并向团队报告状态.我点火了.
我认为第一类中的错误 - 技术任务 - 是我们没有定义验收标准.您的示例包括"改进构建系统,设置更好的集成测试,更好的发布策略".这些是非确定性的,需要用清晰的术语列举(必要时使用尖峰).因此 - 改进构建系统可能从技术任务开始,也可能是峰值来评估选项.
我们还需要分解并确定技术任务的优先级(例如,"更好的集成测试"可能从定义当前集成覆盖率的技术任务开始,或者评估可能归咎于集成故障的错误百分比来构建案例在那里投资.
设置好优先级后,您就可以传达高优先级项目的价值,并与产品所有者协商花费时间.我不是花在任何事情上的预定义桶的忠实粉丝......但是与产品所有者的对话具有清晰的要求,ROI和验收标准是关键.
与新功能相同,改进应该是sprint的一部分.团队需要向产品负责人证明这些改进是即将到来的冲刺所必需的.这可能会降低新功能的生成速度,但最终会对产品有用.
另一方面,我遇到了只包含改进的sprint问题.每个sprint都应该产生可以向产品负责人演示的输出.
京公网安备 11010802040832号 | 京ICP备19059560号-6 