软件开发跟踪是如何被打破的

原文：https://medium.com/hackernoon/how-software-development-tracking-is-broken-and-how-it-can-be-fixed-ec7db2578d81

"人们在 90 秒内做出大多数决定，然后花几个小时证明自己是对的."

当我给 Waydev 发布电子邮件添加最后的润色时，我想起了这句话。这实际上是我在过去十年中一直记得的一句话，通常是在试图从各种图表和电子表格中找出一些意义时，据称这些图表和电子表格向我展示了我的项目进展情况。我还记得告诉自己:

“必须有更好的方法来了解发展是否步入正轨”

我创建了 Waydev，因为我相信保持开发在正轨上不需要涉及对图表和电子表格的仔细研究。在过去的 15 年里，作为一个试图领导开发项目的非技术人员，我对作为一个企业主所能提供的选择深感不满，所以我最终决定开发一个我真正喜欢使用的工具。

我不是微观管理的粉丝；实际上，我发现监视开发人员或不断询问状态更新的整个过程是自相矛盾的。每当对项目的状态有一些抽象的不确定性时，反射就是开始调查，从而给开发团队带来额外的压力，除了他们已经很繁重的推动产品增量的任务之外，他们现在还必须制作每周或每天的报告。

难怪管理和发展之间会有沟通障碍。当然，这不是任何人的错。利益相关者、客户或竞争对手总会给我们压力，要求我们走在游戏的前面，因此经理需要不断地问这样一个问题:

“发展是否步入正轨？”

当然有监控开发的方法，但是它们远非理想，通常是因为它们涉及开发人员中断他们的工作来更新一些问题状态，在清单上标记一个项目，或者将一些便利贴移动到不同的列。这种方法有几个问题:

这是一个需要不断维护的系统——通常必须有人来做坏人，提醒每个人移动便利贴，否则进展就不会明朗
它将焦点从编码上移开——无论说了什么，感觉都是团队的成功是根据完成的任务数量来衡量的；这本身会产生各种各样的反模式，从任务膨胀到利用系统挤出+5%的任务来满足任意配额
为了提供明确的状态更新，大多数仪表板都试图在屏幕上显示尽可能多的信息，以至于细节变得令人不知所措

相比之下，Waydev 试图做的是提供所需的最少量的信息，以便了解开发是否在正轨上。为此，它从源代码控制中获取一些高级指标(当然不是实际的源代码)，并将它们编译成一个易读的数字，我们称之为 Wayrank。这个简单的数字一眼就能告诉你，你的项目是否已经步入正轨，或者是时候开始提问了。

我们相信更少的报告有助于创建更好的代码

此外，还有上下文的问题，这是很多时候因为更多的细节而被忽略的。例如，查看提交的代码行数很难判断进度。另一方面，在上下文中，它可以揭示很多东西:

人们可以通过查看存储库中有多少实际代码以及编写代码花了多长时间来了解两个不同项目的相对规模和复杂性。
如果提交的代码行数急剧增加或减少，这通常是可能存在问题的迹象——要么是存在一些障碍，需要比编码更多的思考(或者比平常更多),要么是存在一些只有通过反复试验才能发现的模糊问题。
提交或版本更新的规模和频率可以显示团队的节奏，以及良好的实践是否被遵守。
最后，上述因素的结合有助于对产品可靠性变化的速度产生现实的预期。

当前的跟踪解决方案忽略了这些方面，进一步扩大了期望和交付之间的差距，使开发人员和管理人员都感到沮丧。通过只提供高层次的信息，我们希望鼓励项目领导多关注上下文，少关注武断的 KPI。

我们也相信软件开发管理应该是可访问的，不管一个人多么精通技术

我们希望 Waydev 将改善各地的开发过程，我们当然相信它有潜力做到这一点。我们还希望它能消除一个阻碍非技术人员将他们的想法推向现实世界的障碍。我觉得，通过为各种技术水平的人提供一种开发软件产品的方法，我们正在为这个行业开辟新的前景。

我们很想知道你的想法！试试 Waydev，告诉我们你的想法。