小任务，小信任

信任是动机的最高形式。它带给人以最好的感觉。

现在，这基本上是一项神圣的项目管理原则：将您的工作分解成尽可能小的任务。与您的团队一起估算。然后将它们放入全知产品积压清单中。但是似乎没有人在批判性地研究这种做法如何影响软件工程专业。上世纪90年代，当我开始编程时，这并不是怎么回事。我敢说，这有点专业。

那时，您的老板要负责一打或更多的事情，而当您被录用时，他们深感欣慰。

“最后，既然文森特在这里，我就可以让他做A和B；而Ted负责C，D和E，Jan负责F，G和H，我终于可以到达I，J，K，L和M。”

最重要的是，Aand B是大物件，例如整个产品或大型系统库。建立和维护它们会占用您的所有时间。它们是您委派的责任，而不仅仅是任务。以这种方式管理人员也不难。如果您做得不好，老板会告诉您。

“嘿，文森特，艾斯没有像我想象的那样出现。您能再做一点吗？当然可以增加更多的牛铃。”

然后，您回到了您的私人办公室（我肯定想念私人办公室，但这是另一天的话题），并修复了一些问题。稍后，在每周一次的状态会议上，您将告诉人们情况如何……是的，是的，每天站起来，您会悲痛地看着自己的鞋子，并承认您尚未取得任何显着进步。

也没有积压的梳理会议或燃尽图。您的经理只是看着您的产品如何发展。一点信任，一定的责任心和健康的部分“给我一些工作空间”。

我们现在的工作方式有所不同。可悲的是，它缺乏动力，效率低下，并且对个人能力的尊重程度大大降低。

正如我所看到的，小任务源于根本不同的管理态度。小任务不是所有产品愿景都取决于管理的一种不太巧妙的说法。远离。别碰

而较大的任务会发送完全不同的消息。在这里，管理为您提供了更大的机会，邀请您将自己的创造力与最终产品融合在一起。您可以进行一些设计工作，考虑客户的需求，并对另一端的需求感到自豪。当然，组织有一个总体战略，但他们仍然希望人们承担责任，而不仅仅是差事。他们相信您会与整体愿景保持一致，并且因为您感觉自己确实是“俱乐部”的一部分，所以您确实希望这样做。

小任务也很流行，因为它们与古老的流水线思维相吻合。可悲的是，仍然有一些管理人员依旧信奉这一教条。对于他们来说，关键在于选择指标并对其进行优化-管理图表和图形。

不幸的是，Jira中的小任务（或那里的数十个其他问题跟踪系统中的任何一个）带来了许多美味的新图表的承诺：燃尽，燃尽，速度，提前期，周期时间，任务年龄，吞吐量，失败的部署，流程和控制。就像糖果一样令人无法抗拒。

但是，分配职责而不是任务会占用流水线经理最喜欢的工具。由于职责更大，因此无法轻松地衡量和跟踪职责。 Sometrics经理将竭尽全力，使您的工作保持分裂，并按可追溯的微小说明进行分类。

可悲的是，作为开发人员，我们也要自己做。一旦有人给我们一个更好的头衔，我们就可以参与该计划。当普通开发人员可能有机会进行一些研究或设计时，我们会立即将其抢走。

作为技术管理，我们标准化了框架，语言，部署操作系统和云服务提供者。我们围绕网络，日志记录和监视库编写包装器，并要求始终使用它们。然后，在完成设计和研究CI / CD工具和管道的任务后，我们为我们的编码标准编写了编码标准。

更糟糕的是，我们设计了每种产品的体系结构，并期望任何偏差都将首先得到我们的批准。剩下的只是细小的杂物。一旦乐趣消失了，步兵们的辛苦工作就结束了。

可怜的前线程序员左眼睁睁地看着空碗，问道：“先生，请问我能再给我一些吗？我只想设计一个小服务。我知道我不值得，但是我可以不使用thatawful ORM来编写自己的sql查询吗？请？”

可悲的是，当那些可怜的程序员最终寻求晋升，希望他们的第一枪真正实现更高层次的参与时，他们被拒绝了：“恐怕您真的没有任何设计经验。我们正在寻找设计大型系统的人。”

他们可以正确地对他们的经理说：“那是你的事，不是我的！”

有一个严重的误解，就是如果您只是坐在舒适的会议室椅子上坐下来，将项目分解为细小的任务，这些任务要小到可以单独估计，那么当您将它们加起来时，Viola！您将对整个项目有一个准确的估计！十分简单。

这个错觉有两个问题。首先，没有任务，即使是很小的任务，也很容易估计。我已经看到许多“微小的”，为期一天的任务在长达一周的竞选活动中破裂。所有这些都是由于隐藏的复杂性，一旦您开始对它进行编码，就会像Pandora的盒子一样弹出。

其次，当您将工作划分为小任务，而实际上没有执行任何任务时，您所做的假设未经检验。许多人。您定义的任务越多，您必须承担的假设设计的方面就越多（当然，这是隐含的，因为没有人在任务描述中编写过设计假设）。很快，您就坐在墙壁上的便签纸上，创建了很长的设计选择链，这些选择都取决于先前的选择。

问题是，一旦您开始研究其中之一，就会意识到隐式设计决策是错误的。现在，您将花费比以前估计更多的时间来完成此任务，并且所有其他依赖其错误设计的任务均将无效。整个纸牌屋倒塌了。有时间再进行一整天的积压培训会议吗？真浪费！

过去，在每个人都意识到软件公司可以赚很多钱的定位之前，我们有了一些弯腰的空间。我们有很多责任，也有能力做出很多决定。但是现在，有更多的人聚集在该岛上。不幸的是，其中一些已经在软件工程师的领域慢慢消失了。他们从船上下来，一一插上了国旗：

“我是Amerigo，产品负责人。迄今为止，还没有开发人员可以做出产品决定，而杂牌店是我的。”

“而我是费迪南德，流程专家。迄今为止，没有开发人员会做出流程决定，因为它们是我的。”

“我非常擅长于Microsoft Access，我想我会成为数据库专家。”

一步一步地，直到所有不是真正的开放式营销和开始打字的东西编程的责任都被取消，甚至被禁止。 然后，剩下的纯技术任务由建筑/标准standard积工程师负责，他们渴望获得实质性的东西。 只剩下干燥，破碎的broken体散落在地上。 当然，有一个解决此困境的方法-将责任委托给每个人，一直到最底层。 或更好的是，将层次结构一起放平或废除。 但是，在这种情况发生之前，您只需要满足于适度的for循环和if语句即可，遵循课程的编码标准。