时间管理观念 迟到_错误的时间观念

时间管理观念 迟到

没有人早上醒来时说：“今天我要搞砸了。 今天，我要生气我的老板和我所有的团队伙伴，一起写我可能会写的最糟糕的代码。”

好吧，总是有例外，但通常没有人例外。 如果真是这样，那么敏捷项目现在怎么会失败？ 我们怎么还会遇到同样的老问题？

技术债务故事

前一段时间我在这个项目中，一位开发人员选择开发一种全新功能。 对于此新功能的实现，除了将新功能连接到应用程序的几件事之外，我们不需要触摸任何现有代码。 大约一天后，我提出要与他配对。 自然，因为我刚刚加入他，所以我要求他概述一下该功能的含义。 他Swift向我解释了这一点，我请他告诉我他在哪里，以便我们继续。 在他完成向我展示代码之后，我做了一些观察，因为根据我之前的解释，我不清楚他的代码是否反映了需要完成的工作。 基本上，他用来向我解释业务功能的语言与他在代码中使用的语言并不同步，我还可以看到一些对于实现该功能并不是真正必要的代码。 我还注意到没有测试。 当我问他有关他的信息时，他说_它正在运行，将来我可能需要这些额外的代码。 让我们将您提议的重构和单元测试添加到技术债务积压中。 我需要完成此功能。 那有多疯狂？ 那是一个全新的功能。 我们应该在进行过程中减少技术债务，而不是增加更多。 但是，该开发人员以某种方式认为可以这样做。 一天结束时，我们有大量的技术债务储备，不是吗？ 据说这是一个由经验丰富的开发人员组成的敏捷团队，但是在他们看来，具有这种行为是可以的。 也许有一天，有人会研究技术债务并采取一些措施。 可能吧 也许。 不太可能。 不，永远不会发生。

但是我们想做正确的事

但是我们都想做正确的事。 我们不是故意这样做的。 但是，随着时间的流逝，我意识到我们开发人员对时间的理解是错误的。 我们认为，我们需要时刻抓紧时间来完成我们承诺的任务。 压力将永远是软件开发人员生活的一部分，当存在压力时，我们最终会偷工减料。 我们不这样做是因为我们草率。 我们之所以这样做，是因为我们认为我们需要走得更快。 我们认为我们做得很好，并尽可能快地向企业证明了他们想要的功能。 问题在于，我们并非总是了解自己的决定的含义。

忙碌的团队，没有空闲时间

我在一个非常大的组织中加入了这个团队。 压力很大，开发人员非常努力。 首先，我花了几天的时间来设置机器。 该项目是在我们的IDE中进行配置的噩梦。 我们正在使用Java，并且试图将Eclipse导入项目。 该项目有70多个Maven项目和模块，带有大量循环依赖项。 几天后，我设置了本地环境。 该项目使用了重量级的JEE容器，大量的队列，并且不得不与许多其他内部系统集成。 与其中一个配对时（在那里配对并不常见，但我问他们是否可以配对），我注意到他正在队列中播放消息并查看日志。 我问他在做什么，他说不可能在本地运行系统，所以他不得不向代码中添加日志负载，打包，在UAT环境中部署应用程序，将XML消息播放到一个入站中队列中，查看控制台中的日志，然后尝试找出应用程序在做什么。 显然他已经进行了更改，并且预期的消息没有到达预期的出站队列中。 因此，在更改XML消息并将其重播到入站队列近二十分钟之后，他对可能出现的问题有所了解。 因此，他返回本地计算机，更改了几行代码，添加了更多日志，更改了一些现有日志以打印出更多信息，然后再次开始构建应用程序。 在这一点上，我问他是否将不为更改编写测试，以及他是否对该应用程序的其余部分进行测试。 然后他告诉我，他正在从事的任务很重要，因此他必须快速完成任务，而没有时间编写测试。 然后，他再次在UAT中部署了该应用程序的新版本（请注意，在进行测试时，没有其他人可以使用UAT环境），在入站队列中播放XML消息，然后再次开始查看日志。 持续了两天，直到问题解决。 事实证明，代码中存在一些较小的逻辑错误，单元测试会立即发现这些错误。

我们没有时间，但显然有人

想象上面的情况。 想象一个有几十万行的应用程序。 现在想象一个由七个开发人员组成的团队。 现在想象一下，来自五个不同国家/地区的十个团队从事同一应用程序。 是的，就是这种情况。 有一些系统测试（黑匣子测试），但是它们过去通常要花四个小时才能运行，而且经常会损坏，因此没有人真正关注它们。 您能想象每个开发人员每个任务或每个故事浪费的时间吗？ 让我们不要忘记质量检查小组，因为测试人员显然是世界上所有的人。 他们必须手动测试整个系统中系统中的每个更改。 当然，添加到系统的每个新功能都会使系统变大，从而导致系统测试更加缓慢，并且质量检查周期甚至更长。 调试时间也越来越长，因为每个开发人员都添加了更多代码，所有其他开发人员都需要对其进行调试以了解其工作方式。 现在，每天，每周，每个月都在这里浪费时间。 这是因为我们开发人员没有时间。

专门的质量保证团队是一种反模式。 测试人员什么也找不到，零。 每次测试人员发现错误时，我们开发人员都应该对此感到难过。 生产中发现的每个错误都表明我们尚未完成某些工作。 一些错误与不良要求有关，但是即使那样，我们也应该对此做一些事情。 也许我们应该已经帮助我们的BA或产品所有者澄清了它们。 我绝不是说我们不应该有测试人员。 对于以人类无法企及的方式探索我们的应用程序，它们可能非常有价值。 他们不应浪费时间执行开发团队可以自动化的测试计划。

业务部门希望尽快获得这些功能，而我们认为，满足这些功能是我们的义务，而且确实如此。 但是，商务人士从整体上看待系统，我们也应该如此。 他们着眼于一切，而不仅仅是我们正在研究的故事。 删除（自动化）所有重复工作是我们的工作。 我仍然记得，在90年代，调试技能是技术面试中的重要标准。 那些日子已经一去不复返了。 尽管具有调试技能很重要，但是每当我们需要诉诸调试时以及在调试发生时，我们都应该对此感到不愉快，我们需要立即解决该问题，编写测试并重构我们的代码，这样我们就不再需要这样做。

明智地利用时间

我们的客户和/或雇主对满足他们需求的软件感兴趣，这些软件可以按规定运行，并且只要他们改变主意就可以轻松更改。 向他们提供这些是我们的工作。 通常，我们满足他们期望的方式取决于我们。 尽管他们可能会提到诸如自动化测试和敏捷方法之类的东西，但他们真正想要的是物有所值的投资，这笔钱涉及他们在软件项目中进行的投资。 我们需要明智地利用（时间）时间，使我们可以做的一切自动化（测试或部署过程），而不是认为我们可能没有时间这样做。 我们总是可以量化我们在重复性任务上花费了多少时间，甚至可以进一步展示它们在一段时间内在这些活动中花费了多少时间。 在实施任何新功能或任务之前，我们应该花一些时间准备系统以一种不错的方式接受更改，因此我们可以顺畅地滑动该in_，并确保可以轻松测试和部署我们编写的任何内容。 在估算我们的工作时，我们应该始终将其作为“一部分时间”考虑在内，这将使我们能够做到这一点，而不会有错误的印象，即如果将它们视为单独的任务，我们会走得更快，因为，机会是，他们可能永远也做不完，因此，整个过程将会变慢。 我们浪费的时间更少了，我们浪费了手动测试（或等待一个长时间的自动化测试套件运行），调试，处理大量技术债务，试图使您的IDE与您搞砸的项目结构良好地工作或为部署而战的时间在应用程序中，我们不得不花更多的时间来维护应用程序的质量并使客户满意。

注意：我在上面提到的团队经过大量的努力，投入，管理层的支持以及大量的投资（时间和金钱）设法扭转了局面，现在已经成为组织中最好的团队。 一些团队设法替换（重写）了一个不可靠的内部测试套件，该套件过去要花费三个多小时才能运行，而可靠性更高的套件要花费大约20分钟。 其中一个团队非常接近实现“一键式”部署，并拥有广泛的测试套件，其测试范围从单元到系统（黑盒），可在几分钟内运行，代码覆盖率接近100％。

参考：来自Crafts Software博客的JCG合作伙伴 Sandro Mancuso 的错误时间观念 。

翻译自: https://www.javacodegeeks.com/2012/12/the-wrong-notion-of-time.html

时间管理观念 迟到