在非敏捷开发团队中，首席开发人员通常：
但是，敏捷团队的工作方式有所不同：
这将使敏捷开发团队中的首席开发人员离开哪里？在敏捷团队中是否可能有首席开发人员？敏捷团队是否需要与领导不同的职责？
Answers:
敏捷并没有改变首席开发人员的运作方式。无论采用哪种开发模型，他们都应让团队的其他成员参与系统体系结构决策和技术指导。
通过命令发布决策是任何开发团队运行的糟糕方式。敏捷只是使从团队其他成员手中获得收益的过程变得更加明确，因此首席开发人员应该一直这样做。
仅仅因为Scrum方法论中没有固定的开发人员角色，并不意味着经验最丰富的程序员的意见并不是最受尊重的。敏捷并没有让每个人都忙于自己的事情，然后试图将其整合在一起，仍然需要设定一个统一的愿景和方向。
在一个敏捷的团队中，每个人都应该将自己的自我抛在一边。
如果敏捷团队中的一个成员比其他成员具有更多的经验，则可能会发生的情况是，经验丰富的成员将参与大多数代码审查，并且人们在制定团队决策时通常会尊重该人的经验。
因此，“领先”开发人员将继续“领先”，但这是其经验的自然结果，而不是其头衔的强制性功能。
那是一个理想的世界，人们可以将自己的自我抛在一边。祝好运！
除了Ryathal的答案：
您谈论的是紧急设计和团队指导，就好像它们是从团队中完美和谐地融为一体。一群人，一群程序员特别有冲突。作为团队的领导，您在敏捷团队中的工作更多是裁判或催化剂而不是瀑布。例如，当团队在使用哪种设计方面存在冲突时，您将确保人们有平等的发言权，并坚持就优劣进行争论。当路径不清楚时，您最终将成为团队将使用哪个提议解决方案的仲裁者。
这是领导最重要的职责之一，但是要使一群人组成一个团队，还需要做很多其他事情。您仍然需要就良好的编码树立一个榜样，并经常实施（直接或通过创建一种文化来做到这一点）。您需要促进所有团队成员之间的交流，因为每天站立一次并不会减少交流。
您忽略的另一个重要事项是会议。将整个团队带到团队需要与业务人员，其他技术团队等进行互动的每次会议上都是不切实际的。作为团队的领导，您是团队的代表。您去参加会议，以便他们可以留在办公桌前做事。您是联络点，这样他们就不会被直接路过的人打断。然后，您将努力从外部世界获取信息（其他团队正在做什么，敏捷团队的下一个冲刺是什么样子，该公开请求的状态如何等），为他们精简下来并进行交流。
简而言之，您就是润滑剂，以确保它们可以平稳运行。
您的非敏捷描述不会使您的敏捷描述无效。
敏捷团队将依靠紧急设计，而不是预先设计。
关于首席开发人员的定义，没有任何内容表明设计必须预先进行。他可以设定方向，但仍可以进行初步设计。这种设计肯定是新兴的。
敏捷团队一起设计，而不是由一个人决定设计
您对首席开发人员的定义并没有说他决定设计。尽管他可能拥有最终决定权，但只有糟糕的领先优势才能完全无视大多数队友的想法。另一方面，只有一个贫穷的团队会完全忽略首席开发人员的想法。
敏捷团队决定自己的技术方向，这是交付项目的最佳选择
同样，这并不意味着领导者最初不会设定此方向。领导是这个敏捷团队的一部分。即使在不敏捷的环境中，当已知的可行性变得不可行或提供新的信息使该方向无效时，只有不好的领导才能继续向该方向前进。
这个问题还有其他几个问题。您认为有什么资格告诉其他软件工程师团队做什么？是你的经验吗？是老板给你的有趣的小标题吗？是你的自我吗？您在公司任职？是您的“煎饼”吗？你的风格？” 您的“领导能力”？
敏捷团队不会向彼此分发徽章或帽子，说：“恭喜，您是我们的超级天才-您是唯一允许进行超级秘密的双重天才工作的人。” 相反，重点是手头的工作。如果您确实更有经验，那么这种经验应该显示出您的设计将工作推进到完成的程度。您的自选任务（卡片）应反映您最擅长的领域。另一方面，如果某个刚从大学毕业的孩子有更好的主意，并且比大约40年的资深人士浮出水面更适合背景为什么我们会选择较差的设计呢？我们的工作场所不是理疗办公室-它们是我们来打造伟大事物的地方。
这就引出了另一个问题：谁来决定“更好”是什么意思？答案：利益相关者团队。这意味着开发人员，需求人员，测试人员，业务人员等都是相关事物的构建者和用户。如果您有一个好主意，则最好能够证明它为什么更好。如果您不能做到这一点，那么团队就没有理由相信您的想法更好。敏捷鼓励精英。
那么，“开发团队负责人”怎么办？敏捷？没有什么比他们更能兑现这个名字了，他们实际上能够比团队中的其他人更好地生产更好的软件。否则，没有理由称他们为“领导”-它只是一个小徽章或滑稽的帽子，毫无意义。许多人发现这种威胁。他们觉得自己一直在为徽章或滑稽的帽子“工作”。好的开发人员不会为滑稽的帽子工作。他们致力于开发出色的软件，并且计划一直这样做直到他们崩溃为止-他们的目标是每天变得更好地开发软件。如果不是您，也许您可能想研究项目管理。您可能会更快乐。
根据我在敏捷方面的经验，开发团队作为一个整体所承担的责任比您的示例所暗示的要少，这使首席开发人员和架构师可以协调高层设计的选择，而将较低层次的设计交给整个敏捷团队。
因此，首席开发人员仍然负责系统架构和技术选择。这非常重要：尽管敏捷鼓励涌现的设计和重构，但这应该在代码对象级别进行。该系统作为一个整体需要有前期设计和刚度更高水平的其他项目可能会变成一个不协调的混乱。
在我们的项目中，首席开发人员要求选择技术，并设计系统组件之间的交互方式。敏捷计划会议的重点是如何在他的更高权限范围内设计这些组件。顺便说一句，这可以避免其他麻烦的计划会议的范围。
他还充当了最后手段。当个别程序员遇到无法解决的问题时，他们将发挥领导作用，而将问题修复的最终责任则由他来承担。