在敏捷环境下工作时，我的工作习惯应该如何改变？

Question

我在一个开发团队工作，在那里我们严格遵循敏捷。

然而，我并不需要改变我的工作方式(单元测试等并不算数，因为我已经这样做了)。我的意思是，我需要改变我沟通的方式或频率吗？我对敏捷的这种软技能方面很感兴趣。

谢谢

Answer 1

如果您的团队很好地利用了敏捷，那么您可能会看到工作方式发生了一些变化。你有可能已经以相当“敏捷兼容”的心态进行开发，即使你之前的工作经验是在一种更具瀑布式的方法中。

我认为敏捷开发人员应该做的一些具体事情(在一个运行良好的敏捷团队中，自然会发现他们需要来做)

-从宏观规划的角度来说，这是敏捷的核心租户，但即使对于单个开发人员来说，实践也是很重要的。对于2到3周的迭代，你会发现你根本没有时间花11周半的时间来开发一些东西，而半周的时间把所有的together.

• Check集成在一起，经常签入，并签入工作代码--不要这样做，你很快就会发现你就是那个在迭代之前一天就破坏构建的家伙，而在接下来的一两周里，什么可能会阻止你。告诉人们这件事--敏捷团队中没有人喜欢在最后一秒听到从事关键工作的开发人员在整个迭代过程中等待完成关于迭代结束的work.

• Think的事情--你写的每一行代码都应该考虑到在迭代之前完成这是否现实。(嘿，如果没有一个可爱的，Glengarry Glen Ross抄袭的缩写，我不可能有一个简洁的建议列表！)你会在第二或第三次迭代中学到，偷懒一周，然后通宵工作，会咬你的屁股。--

如果你已经关注了所有这些--太棒了！它们当然是通用的最佳实践，而不是特定于敏捷的。不过，我认为大多数开发人员都有一两个坏习惯(我知道我偶尔也会这样)。

Answer 2

除了Ryan的伟大观点之外，这里还有其他几点。

• Discuss你的想法与你的团队的其他成员。你的开发伙伴将很快指出你的想法中的潜在缺陷，并提出替代方案(准备倾听，不要被冒犯)。我发现这在计划/故事任务期间效果最好。在2-3周的冲刺中，当你走上错误的道路时，这是非常明显的。它甚至可能会阻止你成功地完成所有的任务/故事。如果其他人预先知道你的攻击计划，这会让他们更容易介入并帮助你完成工作，如果你需要it.
• Do毫不犹豫地建议新的做事方式。敏捷的伟大之处之一是团队过程不是一成不变的，而是从一系列回顾中演变而来的。如果你的开发人员从来不发声，那么这个过程永远不会改变，事情也不会变得更好。
• Put你的用户的帽子上。每个应用程序有一个最终用户。有时(特别是当您与用户没有密切联系时)，您必须后退一步并质疑决策(即使是由产品所有者做出的)。如果你能做一个很好的案例，不仅你的用户，而且整个团队都会从中受益，因为产品会得到更好的接受。开发人员并不经常这样做。我们想让事情变得更好、更快、更精简，而牺牲了其他有时更重要的事情，比如按时交付或添加更多功能。

我希望这能帮到你。

Answer 3

敏捷的细节对于你所问的每个人来说都是不同的。是的，你可能想要定期交流，但你不想走到极端，让你(或你的同事)无法提高工作效率。

但就像我说的，对每个人来说都是不同的。唯一知道如何最好地匹配你的团队的人是你团队中的人。只要告诉他们你不习惯敏捷，你想知道你是如何处理它的。他们真的是唯一能确定答案的人。