我们可以为瀑布项目创建一个新的Scrum变体

时间:2009-06-01 13:27:12

标签: agile scrum product-management waterfall

从事产品开发的分布式离岸环境中的传统大型软件产品组织在Scrum中遵循Agile的精神并不容易,原因如下:

  1. 他们的产品开发不是迭代的。经过多轮迭代系统工程后的产品工程团队,提前,正式地确定给定版本的产品需求,产品架构和设计。对此的更改可能会发生,但不会大规模发生。

  2. 产品工程团队现在可以根据创建的规范,由离岸团队构建此产品。这些大型离岸团队无法在迭代和经验模式下工作,因为这里没有必要。

  3. 然而,产品经理可能会希望通过短期迭代请求增量交付来定期了解离岸团队对产品开发的了解。

  4. 如果这些离岸团队可以在定义的正式流程(非经验),经理管理环境(未授权)和使用增量开发方法(不是迭代和自适应)中遵循Scrum的变体,那么对他们非常有用。

  5. 在这种情况下实施的真正的Scrum方法可能看起来非常虚伪。但是,如果我们可以为传统的瀑布式场景提供Scrum的正式变体,他们可以将它用于每个人的优势。

  6. 我试图在我的博客scrumtales.blogspot.com上更详细地描述这个背景。

    我们可以这样做吗?

4 个答案:

答案 0 :(得分:1)

简短回答绝对是

虽然Scrum是一种由某些仪式和流程组成的方法,但它们的共同实现只是一个实现。对于每个流程,退后一步,寻找更高抽象级别的解决方案,这个解决方案没有您遇到的问题 - 主要是距离。 例如 - 共址。虽然通常的解释是让每个合作的人都将用户故事“完成”到一个具体的房间,​​但这不一定是唯一的房间。聊天室会做这项工作吗?虚拟现实房间会更好地为您服务吗? VOIP解决方案也可以运行。

每个月举行一到两次会议(冲刺计划和回顾会)可以在这样的虚拟环境中进行,而不会对正常下班时间偶尔工作的人造成太大的压力。

如果时区和互联网带宽无法克服,也许频繁的在线会议可以脱机。每日会议可以使用维基进行。或电子邮件。

有各种各样的在线工具,例如计划扑克(PlanningPoker.com),一些商业,一些免费:VersionOneAxoSoft OnTime,仅举几例。

Scrum的其余部分可能无论物理距离如何都可以完成 - 编写用户故事,估算和故事点没有基于位置的约束。

希望这有帮助, 阿萨弗。

答案 1 :(得分:1)

  

Scrum的正式变体   传统的瀑布式场景

这被称为“Scrummerfall”。以下是一些链接,可帮助您了解可在组织中释放的痛苦:

http://www.agileprogrammer.com/dotnetguy/archive/2006/07/08/16855.asp X http://blogs.msdn.com/nickmalik/archive/2007/06/04/waterscrum-vs-scrummerfall.aspx

答案 2 :(得分:1)

根据我在你的问题中所读到的内容,我的简短回答是否定的。

我不得不说,除非你的分布式离岸团队愿意采用增量开发,否则这根本不是一个有用的练习。如果没有增量交付,正在为这个远程团队嘲笑Scrum流程的其余部分的产品经理将会在sprint评审中寻找进展,并且团队将无法展示他们已经完成的任何事情。他们的瀑布过程。因此,对于第一部分,设计已完成,稍后将完成实施工作,最后系统和集成测试正在运行。当然,产品经理将无法在原始计划中要求进行某些更改,在此过程中团队可以做出响应并仍然满足他们正在推动的其他承诺和里程碑。为什么?因为他们不会在项目的后期提供功能。

增量开发是关键。一旦他们有了这个并且产品经理正在接受时间框审查会议,那么您就可以开始远离执行承诺的经理,让团队成员收到反馈并直接做出承诺。

一旦进行了增量开发,另一件事就是使用离岸团队经理作为产品所有者代理。它允许您的产品经理与项目中的所有团队协商依赖关系,并将其传达给代理。然后,代理可以以授权方式与其本地团队进行交互,并且仍然代表产品经理的目标和优先级。这也有助于解决分布式团队无法直接访问产品负责人时遇到的问题。拥有本地代理有助于处理团队可能拥有的有关功能的问题,而无需等待世界另一端的某人在一天后回复。

答案 3 :(得分:0)

您可能希望看看ThoughtWorks(Martin Fowler)experience进行敏捷的离岸开发。我想说,将敏捷调整到离岸开发(或者你的离岸开发到Agile)当然是可能的,但这可能是一个很大的变化。您可能还想查看Fearless Change - 了解向组织介绍新想法的模式。听起来你面临的最大困难是对变革的抵制,而不是关于敏捷实施的技术问题。