vlambda博客
学习文章列表

我想说，敏捷就像是青少年的性行为，他们口口声声说做过，但却没人真正知道它到底是什么。

不过，更严重的是，我们的行业（即软件开发行业）通常都会走敏捷的路线，这意味着开发团队通常采用诸如 SCRUM 之类的方法，在此过程中，他们会花费很少的时间来尝试交付微小但又很简洁的代码，简化对特定项目的改进。

一些团队通过遵循认证人员的建议来实现这一点，而另一些团队则只是从书中获取他们认为有用的内容，并希望这能有所帮助。在我看来，无论哪种方式，都是好的，只要你不是盲目地遵循一套规则而没有真正理解它们的目的，它仍然比瀑布（顺便说一句，它在某些行业仍有一席之地）之类的其他替代方案要好得多。

作为这种方法论的一部分，需要遵循一些仪式（即会议，尤其是现在的会议，通常是虚拟会议），需要使用工具，一般来说，你并不是一个人在工作，这意味着还需要遵循一些团队合作的礼节，这一点并不是每个人都能真正意识到的。

因此，为了给你（敏捷开发人员）一个在敏捷丛林中健康生存的机会，如果你愿意接受的话，特别是现在 COVID-19 肆虐，虚拟网络正在兴起，我将向你展示我的建议清单（绝对不是由于多年来与不遵循这些原则的人打交道而产生的挫折！），作为敏捷开发团队的一员，这些建议可以指导你如何进行敏捷开发。

团队站立通话（stand-up calls）通常持续不了 15 分钟，具体取决于团队的情况，这个数字可能会有所不同，但是请考虑一下：通话被称为“站立”通话是有原因的，开发人员应该在站着的时候完成通话，这样每个人都会抓紧时间尽快完成他们的部分。

这些会议常用的脚本流程是依次发言（是的，团队中的每个人都应该发言），说出你前一天做了什么，今天打算做什么，如果有的话，提出你遇到的任何阻碍因素。在这里，你影响了同事们的生活。这不是在讲笑话，而且最重要的是，即使在你项目的范围内，也不能离题地谈论你所遇到的特定问题。

Sprint 是团队集中精力去达成某个（通常）小目标的一小段时间。因此，当你在为这段时间以及你和你的团队将要做的工作类型做计划时，确保整个团队都致力于实现这一目标是很重要的。

这就是为什么通常鼓励整个团队都参加这些会议的原因。通过让每个人都审查要完成的工作，可能会出现一些有趣的问题，而这些问题反过来可能会彻底改变正在审查的工作。但是，这只有在相关人员都关注这一点的情况下才能实现，即使你不是将要实施该工作的人，甚至你的角色不适合来处理该工作，也可能会从不同的角度提出问题，从而解开障碍，因为这些障碍并不是每个人都能看到的，有些人可能对这项任务已经存在偏见了。

这与争论开发人员是否应该负责测试他们自己的工作（请注意，他们不应该这样做）一样。拥有局外人的视角是审查和测试某个特性的关键，这同样也适用于规划未来的工作。

因此，当你和你的团队正在审查未来的工作时，在没有提到你时，请不要关闭你的大脑。当别人正在说时，请不要在另一个标签上开始浏览互联网。在场、到场并努力去理解正在审查的任务，可能十次中有九次，你不会提出任何相关的问题，但有一次，你提出的问题可能会改变用户故事的一切。

通常， Sprint 的时长是 2 周，尽管有些团队可能会稍微调整这个数字。这里的重点是，你应该始终确切地知道你还剩多少天可以交付你在计划会议上承诺的工作。

反过来说，你不能在 Sprint 的最后一天完成任务，这是不理想的。你说这不是你的责任，甚至说你的经理应该能预见到这一点，而且他应该采取一些措施来缓解这个问题。

作为一个管理者，让我来告诉你，这并不完全正确。是的，在某些情况下，需要对团队进行微观管理，即使在某些情况下，仅与几个团队成员一起进行管理可能会对所有人和整个团队都是有益的。但是，有足够经验的团队应该能在没有任何人执行微观管理的情况下进行工作（这需要双方花费大量时间和精力），并且能够按时交付承诺的工作。

而且，如果遇到困难或挫折（当然，在现实世界的项目中总会遇到这种情况），你应该了解得更多，并在出现问题时举手（也就是说点什么）。不要等到 Sprint 结束时才把这些问题提出来，然后为自己辩解说你认为自己可以解决这些问题。把这些问题提出来，让你的经理知道，然后一起决定如何最好地进行下去。

这不是一个与敏捷相关的问题，更像是一个软件开发的问题，但是考虑到 Sprint 所涉及的时间窗口很小，因此在这种情况下这样做会产生更大的影响，因为这样犯错的余地很小。

考虑如下情形：

在单个 Sprint 中，你通常需要完成其他人需要的工作，无论是前端开发人员需要与之交互的后端代码，还是 QA 团队成员需要验证的 UI，你需要把你的工作看作是更大背景的一部分。

换句话说，在 Sprint 的最后一天交付你的工作已经太迟了，因为有可能，你已经完成了任务，但是你正在处理的整个用户故事（即你尝试添加的功能）需要其他人与你的代码进行交互，现在就没有时间了。

因此，下次你在做某件事情的时候，想想还有谁需要它：是否需要进行 QA 流程？需要多长时间？我的代码是否阻碍了其他任务的开发？其他任务需要多长时间才能完成？

你并不是一个人在工作，你当然也不是在一个真空环境中工作，在这个环境中你可能遇到的任何延迟或问题都不会影响到其他人。实际上，任何你可能造成的延迟，都会耽误你团队中的其他人。因此，当你提前计划工作或问题开始堆积的时候，一定要把这两个因素都考虑进去。

不要再仅仅考虑你自己的工作，而要考虑你团队的目标，这应该可以帮助你牢记团队的其他成员。

无论你使用的是 JIRA、Trello，还是市场上的其他任何任务跟踪工具，你都会讨厌它。仅仅是因为开发人员在编写代码，所以几乎没有时间登录那些（通常）) 繁琐的工具并更新状态来作为日常会议的一部分。

所以，为什么要找麻烦呢？对吧? !

错了，事实上，这就是原因。

除了让你的生活变得痛苦之外，任务跟踪工具还可以让你一目了然地了解一个项目的当前状态，以及对团队能否按计划交付他们承诺的里程碑进行合理的猜测。

站在经理的角度考虑一下，考虑他们的职责，以及利益相关方每天是如何询问他们项目能否按计划进行的。你是否愿意他们依次询问开发人员、设计人员、QA 和其他团队成员，他们的生活会怎样？还是你认为鸟瞰项目可能会有帮助？

我认为没有人会真正选择第一项，所以如果要选择第二项，就需要有人更新每个任务的进展情况。这就是你要做的，只需每天简单地更新下你任务的状态，就能为你的经理提供很多价值。请注意，我并不是要你记录每个任务的工作时间，我只是说，将任务标记为“待处理”、“进行中”、“已阻塞”或“已完成”就能提供很大的价值了。如果你想多做一点，比如留下评论解释为什么它被阻塞了，那么你可能就很了不起了，值得奖励一块饼干，所以继续，拿着它，一边享受一边继续阅读。

我知道，对于用户故事来说，给出没有任何实际意义的随机数是没有意义的。但是相信我，这只是在开始的时候，一旦你看到了它们的意义（顺便说一句双关语），它们就变成了必备品。

让我问你一个问题：如果你要领导当前的项目，那么在计划未来的工作时，你如何决定在一个 Sprint 中要投入的工作量呢？我知道，作为一名开发人员，在很长的一段时间里，我从来都没有真正考虑过这个问题。我必须完成的任务被分配给了我，我要在两周内完成。就是这样。

这就是我当上经理之前的情况。我怎么知道我团队的魔力数字是多少呢？有多少用户故事就足够了呢？多少又太多了呢？这只是一个反复试验的问题吗？我能用这些故事点做些有用的事吗？

但是考虑一下更大的计划，如果我不能可靠地知道我的团队在短短的两周内可以完成多少工作，我又怎么知道我是否能够按时完成项目呢？

这就是故事点发挥作用的地方。如果你始终根据同一比例来挑选故事（哦，是的，你需要设置一个比例，以便每个人都能以 1 或 8 来理解同一件事），那么经过几次 Sprint 之后，你便开始了解多少个故事点你可以在 Sprint 期间完成。这就是所谓的“速度”（Velocity），这就是你计划未来 Sprint 时要使用的。

所以，请记住，下次当你必须挑选故事时，有一个非常好的理由！

作为一名优秀的敏捷开发人员，并不是要快速地编写代码，而是要采用所选的方法，考虑项目和团队，而不仅仅是任务和自己。并记住：

• 把你每天的更新保持在最低限度，把其他的事情都放在一个更集中的会议上。

• 计划会议是非常重要的，出席并为会议作出贡献。

• Sprint 是一个非常明确的时间窗口，请记住这一点，并考虑其他人可能正在等待你的工作。

• 任务跟踪很重要，它可以帮助其他人了解整个团队的工作方式，因此这样做吧。

• 故事点很重要，不要忽略它们，也不要在用户故事上随机抛数字。

从本质上说，和你的团队好好相处，你就会享受这个过程，只考虑自己，敏捷方法论就会把项目变成一场噩梦。

你在过去的项目中见过类似的行为吗？我有没有漏掉你认为很重要的建议？请在下方留言，让大家知道你的经历！