我最近加入了敏捷软件工程咨询公司作为他们唯一的前端开发人员。从前端开发人员的角度进行敏捷开发
在我看来，敏捷过程的一个特点是您不需要对功能进行投资，但我被要求工作的方式是先编写一切代码，从而创造大量的前瞻性投资。这导致了与团队其他成员的很大分离，并给我提供了服务器端人员功能的压力。
我很难找到前端开发和敏捷过程之间的匹配，并想知道是否有人有类似的经历，以及他们如何处理它们？
对此有一个有趣的看法。我不是呻吟，因为我习惯于这样工作（我来自代理机构的背景），但似乎这些敏捷专家不知道如何使它与前端开发工作。
瑞恩，首先这是一个非常好的话题/问题。感谢您在Stack Overflow上发布它！
“我很难找到前端开发和敏捷过程之间的匹配，并想知道是否有人有类似的经历以及他们如何处理它们？
好了，过去我一直是前端开发和Scrum Master的在随后的Scrum的框架和敏捷原则幸好我从来没有你描述的那种经验的组织。但我可以想象它对你来说一定是痛苦的。 不幸的是，有些人使用敏捷和精益过程和框架作为一种工具，通过暗示它的使用在政治游戏中取得进展，但他们真正关心的是他们自己的名字和名誉，而最终发生的是他们不贯彻始终，不要对敏捷和团队追随它。在我看来，无论是来自更高级别的人的政治策略，还是对敏捷原则缺乏理解和经验。我认为您的组织需要一个“真正的”全职敏捷教练，而不受组织中较高权力的影响。
“在这个问题上得到另一个观点会很有趣。”
在我上一个项目中，我是一名大约30名工程师的企业项目团队的Scrum Master。我也有一个Web开发人员的背景。我们遵循Scrum框架，并在2周的迭代中工作。每个迭代都有一个Product Backlogs列表，这些列表只是产品负责人编写和优先考虑的一堆用户故事。用户故事总是需要表示产品的垂直切片而不是水平切片。设想一个多层蛋糕，如果你水平切割它，你可能会一次只得到一层，或者两层，但是你永远不会获得一块蛋糕上的所有图层，但是当你垂直切割时，你肯定会得到所有图层，就像您的应用程序或网站或工具或任何它可能绝对运行在技术架构上一样，它必须具有像GUI，安全层，服务器，数据库，中间件等多层。根据敏捷Manisfesto的成功是通过工作软件来衡量的，一个工作软件不是没有后端的一组静态前端屏幕，也不是没有任何前端的一组数据库表。因此，我了解到您可以建议或记住的规则始终在垂直切片中工作，以便您有可能在货架上将产品推向生产。
简而言之 - 我认为您的问题的解决方案是具有适当的用户故事，其完成标准应该更多地放在最终产品的小垂直切片上，而不是一次构建一个水平切片。例如，它应该是基于功能的，比如，构建登录功能，而不仅仅是构建login.jsp！
请记住，总是切小蛋糕的垂直切片，它尝起来更好！ ;）
你所描述的不是敏捷，它是一个想要绕过敏捷的人，因为他们不信任敏捷。
在我看来，敏捷过程的特点之一是，你不要向功能转发投资，但他们被要求工作的方式是编写一切前端，从而创造了很多的远期投资。这导致了团队其他成员的很多分离，并且给我提供了服务器端人员功能的压力。
你就在这里。他们要求的是与敏捷相反的。
事实上，只有一个前端开发人员与其他开发人员一起开展服务器端工作，这是一种灾难。
正如他在回复中提到的（我已经提出），敏捷团队应该在小垂直切片中工作。
为了这个工作，你应该是“generalizing specialists”。团队中的每个成员都可能在某个特定领域拥有优势，但是应该在所有部分都做一些工作，从其他团队成员那里获得所需区域的帮助。
你应该学习和做一些服务器端的工作，服务器端的人应该学习和做一些前端工作。
sjt的回答非常好，与您的Scrummaster /团队讨论他/他们认为完成并可能向他提供的潜在方式？
您在Scrum/XP中的目标是在冲刺结束之前或冲刺结束时创建潜在的可交付产品，因此这意味着要确保您的用户故事反映了产品的垂直切片或示踪器项目符号，如sjt的解释。
您能否扩展“我被要求工作的方式是先编码一切，从而创造大量的前瞻性投资”，如果它在我阅读的时候，它肯定没有敏捷性。也许您提到的功能类型的更具体的例子，正如我所说的那样，它看起来并不敏捷。 – eglasius 2010-09-21 17:33:43