我太生气了，所以我自己做了一个

AWS 安全上线！

挫折往往孕育创新。多年来，我一直在与各种项目管理工具较劲，但这些工具却始终无法满足我的需求，我终于到了崩溃的边缘。这些工具要么太复杂，要么太死板，要么缺少团队所需的关键功能。所以我做了任何沮丧的开发人员都会做的事情——自己开发一个。

所见即所得的 Markdown 简洁性

大多数项目管理工具都会强迫你使用其专有的编辑器，这些编辑器拥有花哨的格式选项，最终带来的问题比解决的问题还多。我只想编辑 Markdown 文件——简单、可移植、版本控制友好、人人都懂的文本。为什么记录故事要比编写代码更复杂呢？

我的解决方案：一个以 Markdown 为核心的项目管理系统。故事、文档、评论——全部都是 Markdown 文件，可以用任何文本编辑器编辑，也可以通过简洁流畅的界面进行编辑。

超越故事点的暴政

业界一直执着于将故事点作为唯一正确的估算指标，但这种想法总是显得局限。开发工作是多维度的，那么我们的估算为什么不能反映这一点呢？

我实施了一个包含四个关键指标的相对权重系统：

• 价值：这给用户/企业带来什么好处？
• 惩罚：不做这项工作的代价是什么？
• 努力：需要做多少工作？
• 风险：实施的不确定性或复杂程度如何？

这种方法为团队提供了一种更细致的方式来确定工作优先级，并使权衡变得明确而不是隐藏。

文档是头等公民

在大多数工具中，架构决策记录 (ADR) 和事后分析（如果它们真的存在的话）都是事后才想到的。它们通常被埋藏在 wiki 或共享驱动器中，与它们相关的工作脱节。

我构建了一个系统，其中 ADR 和事后分析与故事同等重要。它们有版本控制，链接到相关的工作项，并遵循相同的工作流程。这创建了一个互联的知识库，它会随着项目的发展而发展，而不是脱离项目本身。

关闭反馈回路

我最大的挫败感之一就是缺乏来自生产系统的反馈。我们部署了功能，然后……一片寂静。项目管理工具根本不知道接下来会发生什么。

我的解决方案旨在将部署数据和生产指标直接集成到工作流程中。部署故事时，我们会自动跟踪：

• 部署频率
• 变更的准备时间
• 平均恢复服务时间
• 变更失败率

这些 DORA 指标可立即反馈我们的开发实践进展情况，从而形成反馈循环。

真正测量的看板

大多数看板实现只是一些漂亮的带有列的面板。它们缺乏让看板变得强大的指标：周期时间、吞吐量和在制品限制。

我将看板指标构建到系统核心，自动追踪工作流程，并突出显示瓶颈。看板不仅仅是一个可视化工具，更是一个数据收集工具，帮助团队持续改进。

大型上下文窗口的威力

随着大型上下文窗口 AI 模型的出现，构建这个系统变得更加可行。我可以输入 CSV 文件、Excel 电子表格和整个代码库，从而生成全面的文档、用户故事，甚至实施计划。

这极大地加快了开发速度，并确保了整个系统的一致性。人工智能可以理解不同组件之间的关系，并帮助生成反映这些联系的连贯文档。

一切都已架构好，并且应用程序本身非常适合“工具使用”，这或许能带来很多帮助。然而，我不想为了省钱而先解决一堆问题，然后再集成第三方代理 API。

个人工作流程的个人工具

这个项目的特别之处在于，我主要是为了自己而构建的。我并不想取悦所有用户，也不想迎合企业的需求——我只想用自己想要的方式解决自己的问题。这种自由让我能够尝试一些商业工具永远无法想到的方法。

这个最初只是个充满挫败感的业余项目，却有潜力成为我的个人竞争优势。我可以更快地行动，做出更明智的决策，并且对自己构建这一切的初衷有着完整的理解——与此同时，我还创造了一个环境，让人工智能代理能够提供越来越有价值的帮助。

有时候，最好的解决方案并非找到完美的工具，而是打造你真正需要的东西。有时候，一点愤怒就足以成为动力。