我最近加入了一家敏捷软件工程咨询公司，担任他们唯一的前端开发人员。
在我看来，敏捷流程的特点之一是您不会对功能进行前瞻性投资，但我被要求的工作方式是预先编写所有代码，从而产生大量的前瞻性投资。这导致了与团队其他成员的大量分离，并给我为服务器端人员提供功能带来了很大的压力。
我很难找到前端开发和敏捷过程之间的契合点，想知道是否有人有类似的经历以及他们是如何应对的？
从另一个角度来看待这个问题会很有趣。我不抱怨，因为我已经习惯了这样的工作（我来自代理背景），但似乎这些敏捷专家不知道如何使它与前端开发一起工作。
【问题讨论】：
Ryan，首先，这是一个非常好的话题/问题。感谢您在 Stack Overflow 上发布！
“我很难找到前端开发和敏捷流程之间的契合点，我想知道是否有人有类似的经历以及他们是如何应对的？”
嗯，过去我曾在一个遵循 Scrum 框架和敏捷原则的组织中担任前端开发人员和 Scrum Master，但幸运的是，我从未有过您描述的那种经历。但我可以想象，这对你来说一定很痛苦。 不幸的是，有些人通过建议使用敏捷和精益流程和框架作为在政治游戏中取得领先的工具，但他们真正关心的是他们自己的名字和名声，最终发生的事情是他们不遵循通过并且不公平对待敏捷和遵循它的团队。在我看来，这要么是来自更高层的政治策略，要么是缺乏对敏捷原则的理解和经验。我认为您的组织需要一个不受组织中更高权力影响的“真正的”全职敏捷教练。
“如果能从另一个角度看待这个问题会很有趣。”
在我的上一个项目中，我是一个由大约 30 名工程师组成的企业项目团队的 Scrum Master。而且我也有网络开发人员背景。我们遵循 Scrum 框架并进行了 2 周的迭代。每次迭代都有一个产品待办列表列表，这些列表不过是由产品负责人编写并确定优先级的一堆用户故事。用户故事总是需要代表产品的垂直切片而不是水平切片。想象一个多层蛋糕，如果你水平切割它，你一次只能得到一层或两层，但你永远不会得到一块中的所有层，但是当你垂直切割它时，你肯定会得到所有层，就像您的应用程序、网站或工具或任何可能的东西肯定运行在技术架构上一样，该架构必须具有多个层，如 GUI、安全层、服务器、数据库、中间件等。根据敏捷宣言，成功是通过工作软件来衡量的，工作软件不是一组没有后端的静态前端屏幕，也不是一组没有任何前端的数据库表。因此，我学到的一条您可以建议或记住的规则是始终按垂直切片工作，这样您的货架上就有潜在的可发货产品以推动生产。
简而言之 - 我认为解决您的问题的方法是拥有适当的用户故事，其完成的标准应该更多地符合最终产品的小垂直切片，而不是一次构建一个水平切片。因此，例如，它应该是基于功能的，例如构建登录功能而不仅仅是构建 login.jsp！
记住，一定要切小块垂直的蛋糕，这样更好吃！！ ;)
【讨论】：
在我看来，敏捷过程的一个特点是您不会对功能进行前瞻性投资，但他们要求我工作的方式是预先编写所有代码，从而产生大量的前瞻性投资。这导致了与团队其他成员的大量分离，并给我为服务器端人员提供功能带来了很大的压力。
你就在这里。他们的要求与敏捷背道而驰。
事实上，一个团队中只有一名前端开发人员，而其他开发人员只从事服务器端工作，这是一种灾难。
正如 sjt 在他的回复中建议的那样（我赞成），敏捷团队应该在小的垂直切片中工作。
要使其正常工作，您应该是“generalizing specialists”。团队中的每个成员可能在特定领域都有优势，但应该在各个方面做一些工作，在需要的任何领域从其他团队成员那里获得帮助。
你应该学习并做一些服务器端的工作，而服务器端的人应该学习并做一些前端的工作。
【讨论】：
您所描述的不是敏捷，而是有人想规避敏捷，因为他们不信任它。
【讨论】：
sjt 的回答非常好，请与您的 Scrummaster/团队讨论他/他们认为 DONE 和潜在可交付对他意味着什么？
您在 Scrum/XP 中的目标是在 sprint 结束之前或结束之前创建潜在的可交付产品，因此这意味着要确保您的用户故事在产品中反映垂直切片或跟踪子弹，正如 sjt 所解释的那样。
【讨论】：