软件开发人员应该提供少量的功能
软件开发人员应该提供少量的功能
想象一下，您在一个为传统零售商开发电子商务网站的团队中。产品所有者对商店定位器功能有一个很好的想法。然而，当你开始讨论这个故事时，你开始想知道有多少 迭代 您将开发功能。
Photo by 苏西黑兹尔伍德
让我们考虑一下此功能的要求：
- 用户可以通过邮政编码或城市和州搜索商店：
- 该应用程序将显示最近的五家商店及其地址、电话号码和营业时间。
- 该页面将显示一张地图，其中包含五个最近的商店，并且可以放大和缩小。
- 搜索结果还将显示区域经理的姓名、电话号码、电子邮件和图片。
- 如果用户已登录，让我们预先填写他们的地址以进行搜索。
一次太多
想了想之后 故事 或者 特征 ，您认为一对在一周内完成的工作量太大，甚至可能在两周内完成太多。
你能做什么？
您考虑将其分解，因此您在第一周完成域模型和服务，然后在第二周完成用户界面。这种方法可行，但存在一些问题。
首先，您在第一周开发的模型是否足以完整地完成用户界面而无需更改？他们是否有足够的功能，功能是否正确？
其次，当你的产品负责人询问故事的进展情况时，你会告诉他什么？你会说你完成了 40% 吗？如果你完成了 40%，你什么时候才能完成？更重要的是，您能否在此过程中展示任何功能？
最后，如果有人愿意帮助这个故事，你能交出任何任务吗？可以并行完成任何工作吗？
以这种方式分解您的故事，首先关注模型和服务，然后关注用户界面，会导致许多难题。不幸的是，答案要么是“不”，要么是“我不知道”。
那么你能做些什么来改善这种情况呢？
功能链
如果你拿这个怎么办 故事 而是将其重新表述为几个端到端的功能？每个功能都小得多。完成后，您可以向产品所有者演示每个部分。一旦完成了一些关键元素，您就可以并行开发其他功能。最后，一旦产品负责人开始看到这个故事被构建出来，他们可能会有不同的想法或想要完全改变方向。
那么我们需要做些什么来为我们的团队提供所有这些选择呢？
首先，让我们把这个故事分解成特征。区别是微妙的，开发团队可以互换使用这些词。
我喜欢将功能视为为用户增加价值的单个端到端功能。
那么，我们如何将 Store Locator 故事分解为一些组成功能呢？这是一种方法：
- 用户通过邮政编码搜索并查看包含地址和营业时间的商店列表。
- 用户按地址搜索。
- 结果以静态地图显示。
- 地图可以放大、缩小和平移。
- 显示区域经理的姓名、电话和电子邮件。
- 展示区域经理的照片。
- 用户登录时预填充搜索。
对每个人都有好处
当我们以这种方式通过特征来思考这个故事时，就会出现很多机会。每个部分都很小，集中，因此更容易开发。在开发了带有结果的初始搜索之后，您可以并行创建特征。产品经理将能够更直接地看到实际进展。
各个功能可以在彼此之间和其他故事之间进行优先级排序，以便仅开发最有价值的功能。
虽然我最初是从产品所有者的角度来分解故事，但对开发人员也有好处。最显着的优势是开发人员一次可以只专注于一个功能。专注于一个部分比原始的完整故事更容易思考。例如，您可以专注于搜索，而不必担心地图或区域经理。此外，在处理一个重要的故事时，很难知道从哪里开始。将其分解为细小的特征可以更容易集中注意力。
在薄片上工作也很有趣。快速获胜和快速反馈的结合使开发人员充满活力。此外，特征的激光焦点使它们的心理堆栈保持光亮。
细微差别
将重要的故事分成小而薄的片段并不总是直截了当的。
关键是要考虑什么能给用户带来价值，你可以向用户展示什么。你不希望你的故事太薄，所以没有什么可展示的。相反，您希望它们端到端地通过您的系统，从用户界面到您的域逻辑、持久性甚至协作系统。
这个例子不是虚构的，也不是理论上的。它来自我从事的一个实际项目。我们经常将其称为向我们的系统添加功能的绝佳方式。
带走
一旦你展示了工作功能，你就可以得到反馈来制作一个壮观的系统。这为受控创新和增长提供了肥沃的土壤，因为这一切都始于展示价值。
专注于细微的功能，并不断地停留在这个价值和创新的最佳位置。
_ 给我一个掌声和“_ ** 跟随** ” 如果你喜欢这篇文章。
关于美禄
_我是一名技术主管、作家、演讲者、企业家、开发人员和发明家。自 1995 年以来，我一直在开发软件，并在过去十年中开发团队。 _
我撰写有关软件、工程、管理和领导力的文章。
你也可以 在推特上关注我 _. _
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
