客户协作困难的敏捷开发

Question

敏捷宣言指出

合同谈判中的客户协作

我的问题是，当开发人员和用户之间存在距离时，您如何有效地完成这项工作？

我目前在一个维护大型企业系统的“瀑布”团队中工作。顾客在一个不同的国家，但我们确实有很多人在国外旅行。不过，一旦到了现场，你就能与终端用户交谈，因为它是一家大公司，有好几层“业务”。因此，距离不仅仅是地理上的，而且也不会是同一个人每周外出。

我知道敏捷可以帮助我们更快地扭转局面，但我想想象一下，今天我们如何用通过客户协作得到充实的短用户故事来替换这些笨重的文档。我们确实在编写规范时进行协作，但是会议必须组织起来，通常要有很多人参加，这听起来不太灵活。

我也不知道产品的主人会在哪里。这是一个大型系统，客户对系统的每个部分都有不同的联系。但是，开发都是一个大团队，每个版本都将是被开发的teh系统的不同部分。

我曾在另一家公司的scrum团队工作过，但我不确定它是否非常敏捷。在那里，BA为每个故事编写了一个规范，然后开发人员将从规范中编写代码。这种方法似乎缺乏协作，而且文件很重。它至少将事情分解成更易于管理的小块(没什么坏处)，但它似乎没有达到敏捷宣言中规定的基准。

Answer 1

敏捷开发的主要原则之一是客户是团队的一部分。采用敏捷需要双方的努力，因此：

步骤1

先让顾客站在你这边，然后再继续。敏捷不是关于你的团队，而是关于你的团队和客户之间的协作。

其次，敏捷是一种方法论，它不是完美的，它不是万灵药，它只是另一种做事的方式，恰好适合小型团队，客户坐在他们旁边。

步骤2

学习敏捷方法，并确定它是否真的能使事情更快，并将其应用于您的客户。大型企业客户很难参与到项目中来，他们往往步履蹒跚，需要平淡无奇的老瀑布的安慰。

步骤3

可能回到第一步，因为您的客户仍然不清楚什么是敏捷以及他们为什么需要敏捷。与大型企业客户合作6年的经验。

您将要面对的一些问题：

• 客户多年来一直在与瀑布一起工作，并且不愿意改变，因为瀑布给了他们预先设定时间表的安全感(虽然在项目结束时，时间已经超出了300%，但似乎没有人看到这一点)
• 客户端不明白敏捷是如何工作的，并同意它，然后立即要求在下周下周一之前提供一个L1估计。
• 您的团队不知道什么是敏捷，而过程将是一个持续的斗争，把人们联系在一起，同时也试图让客户参与进来。我知道敏捷可以帮助我们更快地扭转局面，但我想想象一下，今天我们如何用通过客户协作得到充实的短用户故事来替换这些笨重的文档。

您将花费大量时间试图将客户端转换为使用敏捷，这样用户故事的质量就会非常低。

--我认为正确的行动方向：

1. 您知道什么是敏捷，以及如何非常好地应用它。
2. 你花时间教你的公司客户加班，同时帮助他们雇佣几个喜欢敏捷的人。
3. 成为客户方面的产品所有者，并开始有效地与您的团队合作。
4. 您将您的团队划分为客户系统中每个区域的较小组，每个团队都有自己的BA作为产品所有者。

如果您可以远程执行敏捷，这也是值得怀疑的。我见过一些球队这样做，而另一些球队则惨败。

结论:慢慢来，慢慢改变。选择一个适合你和你的客户的混合流程。与客户合作，不要百分之百地坚持一个方法。在有人的地方，就需要作出调整，以提高效率。不要努力切换到敏捷，因为“所有酷的孩子都这么做”。

Answer 2

虽然提供了重要的支持动机和解释，但核心问题似乎是：

...how :当开发人员和用户之间存在距离时，您是否有效地完成了这项工作？

对我来说，这个挑战并不是Scrum独有的。地域分散的个人之间的有效合作是一个共同的挑战。虽然这一挑战对协作至上的scrum的影响可能更大，但潜在的解决方案仍然是相似的。它们包括：

• 实物旅行(如你所述)
• 电话交谈和电话会议(我想你也会这么做，但没有提到)
• 简单视频会议
• 更复杂的在线协作环境，共享白板等。

不管您在多大程度上采用了敏捷实践，利用上述一些常见解决方案可能是有益的。