Scrum团队不遵循YAGNI原则

13

在SCRUM会议上，产品团队讨论了移动应用程序将使用的API功能。我们进行了一次模拟，显示了屏幕的外观以及屏幕应包含的关键元素（“布局”）。

基于此以及与产品所有者的讨论，我创建了API响应（HAL + JSON）的原型。这是非常简单的，符合HAL规范的JSON，仅能代表模型中的内容而已。我没有受到商人所预见的未来想法的影响，因为他们倾向于经常改变他们的想法，因此我决定采用简约的方法。我的提议被团队拒绝，而我的提议以7比1胜负。

团队决定使用更复杂的，非语义的抽象json结构，该结构允许在布局布局中提供更大的灵活性。这种方法的缺点是我们最终得到了一组统一的对象，这些对象在设计上可能具有null和empty属性。他们还认为最好进行A / B测试，但这只是基于他们的预测，因为我们没有这样的要求。

大多数时候，我们都在争论那些不是冲刺的一部分，也不是在样机上提到的东西。所描述的问题是“未来的市场营销将如何……”，“企业可能希望我们...如何”。

我和产品负责人都是经验丰富的程序员，我们过去已经看到过这类问题。我们尝试遵循YAGNI和KISS原则。团队的其他成员经验不足，尽管他们了解这些原则，但似乎并不了解它们。

我们同意他们的解决方案，因为整个团队对我们来说更重要，我们不想为那些不那么重要的事情而战。但是我担心这样的事情是否会成为即将来临的，更复杂的辩论的先例？如何应对这种行为？作为团队负责人，我有什么可以做得更好的？

值得一提的是，该产品是早期MVP。

— 杰西克·科布斯（Jacek Kobus）
source

11

I'm afraid if such thing can become a precedence for upcoming, more complicated debates?-这也违反了YAGNI：担心未来可能不会发生。如果您要坚持自己的立场，那么您应该已经这样做了。

— 罗伯特·哈维

@gnat：这似乎与时间限制无关。

— 罗伯特·哈维

是否符合HAL要求不受YAGNI的约束？

— 马修（马修）

@Matthew整个过程花了一个星期，我还使用纯JSON准备了另一个原型来摆脱HAL，但由于“不够灵活”而被拒绝。团队对其进行了修改，最终使用了修改后的版本。HAL对我们来说是一个标准和一套准则，对我而言，在所有端点上强制采用统一的结构比较容易。以前的API没有使用任何标准，并且效果不佳。

— Jacek Kobus

5

灵活性增加了复杂性。只要团队了解，就可以向前迈进。

— 乔恩·雷诺

10

我感到你很痛苦，去过那里。恕我直言，这类问题是由您拥有8个人组成的团队造成的，这个团队已经太大了，无法让您始终做出最佳战略决策。

在8人或以上的团队中，平庸的程序员的数量比经验丰富的程序员的数量高。这通常会导致情况平庸的决定胜过更好的决定。这听起来并不令人满意，尤其是当您（或认为自己）是较有经验的人之一时，但对于真正的错误决策，至少通常也是如此。

事实是，只要团队不改变，就无能为力了，至少如果事情保持民主，那么

学会生活
与团队合作一两年，分享您自己的专业知识，并希望他们随着时间的推移了解YAGNI和KISS的价值
用自己的技能向团队“销售”设计或战略决策
尝试切换到另一个（可能较小）的团队，使您自己的专业水平接近整个团队的平均水平

我认为学习和理解简约方法和YAGNI真正价值的唯一方法是亲身体验。例如，通过以许多错误的“假设情况”预测参与到遗留系统的维护中，以“以防万一”的论点为动机，或者包含许多实际上不需要的过度概括的框架代码，从而导致错误的设计决策。但这无济于事，您可以在两天内教团队成员，而人们必须自己做一些经验。

— 布朗博士
source

5

大多数人必须触摸火炉才能知道它是热的，而不是去触摸它。软件基本相同。++

— RubberDuck

2

保持项目日志/日记是此类事情的关键。一旦您记录了已经进行的各种讨论，它们就比人们几个月或几年后对对话的回忆更为具体。有在练习一个很好的问题在这里。

— 罗比·迪

@RobbieDee：当然，这是否有助于团队了解YAGNI和KISS。

— 布朗

3

第三个项目符号（利用您自己的“销售”设计技能）没有引起足够的重视。这就是为什么开发人员仍然需要具备（或从事）良好的沟通技巧的原因。

— 兰德尔·斯图尔特

@RandallStewart：绝对。但是，即使具有最好的沟通技巧，也很难将YAGNI卖给自己没有经验的人，或者将其与“快速而肮脏的”混淆，或者被教育“抽象是（总是）好的”，所以尝试为了抽象而不是为了简化而对事物进行抽象。交流需要两个方面-一方面可以很好地解释事情，另一方面则愿意倾听和理解。

— 布朗

8

正向兼容性是一个合理的考虑

如果胜过您的七名开发人员之一是架构师，则他有权利根据需要引入NFR，而其中的NFR之一可能是“前向兼容性”，尤其是当您支持的远程系统组件可能稀疏时。发布时间表。您不希望用户不必安装新版本的应用程序，因为您没有事先考虑。

像其他要求一样，您需要接受条件

话虽如此，任何NFR必须作为要求记录在案，并且必须具有明确的验收标准。另外，您必须想出一种测试它们的方法。这就是为什么YAGNI如此重要的原因-您不想编写无法测试的代码，并且如果代码的唯一目的是支持没人使用的功能，则很难进行测试。

这不应该是一个判断电话

我建议您让团队同意您显然遗漏的隐性要求，并将其记录下来。定义了一种测试方法后，您的实现应至少通过一项测试失败，因此，这不必投票。

— 吴
source

1

您在问题中哪读到，由于向前兼容性要求，OP的团队离开了YAGNI？

— 布朗

向前兼容性是什么Content-Type标题是

— 杰克

2

如果您愿意，我愿意称之为其他名称，也许是可扩展性。重点是一样的。它仍然是NFR。

— 约翰·吴

1

有两种方法可以使系统可扩展。一种方法是尝试预见许多潜在的需求更改，并在“以防万一”的情况下对它们进行大量配置。我相信人们可以为这种可扩展性发明许多验收测试。或者，使事情尽可能简单，以使代码库保持较小，易于掌握，并且在以后确实需要扩展点或抽象时可以添加它们。后者是您无法（或不需要）为其编写测试的任何内容。因此，我认为不能通过“写下无声的NFR来轻松解决” ...

— Doc Brown

...所以这更多地是关于如何阻止一群可能具有创造力的开发人员对NFR进行假设并进行发明。

— 布朗

3

听起来您的开发团队正在尝试通过创建允许他们进行快速试用的框架来帮助产品团队，这显然是产品团队真正希望拥有的。您的方法更像是“从字面上给他们他们所要的，而不为他们考虑”。

我敢打赌，如果我是产品负责人，那么与采用第一种方法的开发团队相比，我会更高兴。

— 马丁·马特
source

3

+1预测和计划变革与全面架构宇航员和创建内部平台并非一回事。现在的一些基础工作可能会阻止将来的大量工作。尽管OP的团队可能偏向于假设的方向，但原教旨主义的YAGNI方法肯定不是最佳选择。

— 阿蒙

4

听起来您比团队的其他成员更乐于胜过OP，并为“将来的市场营销会怎样..”进行计划时犯同样的错误。当人们开始构建框架而不是构建应用程序软件时，他们的任务就是构建应用程序软件，他们几乎总是在做错事情。

— 布朗

@DocBrown从技术上我同意。然而，这种情况似乎与愿意促进和要求个人尊重有关。一方面是“正确的”，另一方面是有用的或有帮助的。我在这句话中读到的是，OP正在失去自己的位置，并选择通过向在线观众强调他的经验来提升自己的自我，而不是在他不再感到舒服的环境中做出贡献。这种动态是引入Scrum所特有的。

— 马丁·马特

@MartinMaat我对他们不同意我的事实感到失望。我不明白为什么会这样。在日常工作中，我帮助他们进行代码审查等。我们经常争论但我喜欢，因为最终结果会更好。我知道他们尊重我的意见；我总是尝试使用支持我的理论的有效论点。最后，他们选择最佳方案并对此承担责任。团队做了应该做的事情-他们解决了问题。这是我和产品所有者的错误，因为问题太广泛了，一开始就描述得不好。

— Jacek Kobus

2

好吧，我的观点是民主制度无法正常运作-无论是在政治体系中，还是在大多数程序员都是初级或中级的团队中，民主都无法正常运作。

作为团队领导者和团队中最有经验的人之一，您的话语应该比团队其他成员具有更高的影响力。如果YAGNI对您来说很重要，那么您应该对此进行介绍。讨论一下，并向他们展示为什么很好。

毕竟，您对他人的责任要更高。它不仅是编写代码，而且还可以指导人们。

— BЈовић
source

3

民主可能是造成问题的原因，但恕我直言，没有民主不是解决之道，因为它很容易引入比问题中所描述的更大的问题-实际上，这可能会破坏团队。

— 布朗

@DocBrown您只是在同一句话中矛盾自己。IMO的某些决定不是由人们决定的。OP解释的就是其中之一。引用阿姆斯特朗的人不使用YAGNI：你想要一个香蕉，但你得到的是拿着香蕉和整个丛林大猩猩

— BЈовић

2

不，这不是矛盾（也许我没有很好地表达我的观点）。事情并不总是“黑白”。仅仅因为民主在某些情况下不能很好地运作，不民主就不能保证改善局势和改善局势。通常不是那么简单。

— 布朗

1

有了民主，您就不必获得大多数人都同意的“正确”的东西。这可能是有缺陷的。通常，“正确”的事情在社会接受度方面存在问题。YAGNI不应被铐住，以免妨碍您引入适当的抽象，从而使您可以根据需要轻松添加“大猩猩”或“整个丛林”。

— oopexpert

@oopexpert问题是：您可能需要它们。YAGNI反对工程过度。适当的抽象是一回事，添加您可能不需要的东西是不同的事情。

— BЈовић

2

它认为YAGNI有点混乱。

开发人员经常认为，当他们省略抽象时，他们会遵循YAGNI，这会使系统“为修改而关闭，为扩展而开放”。

除非您不使用“明显”不要求的功能来“扩展”系统，否则您将不会处理YAGNI。在可能发生扩展的地方引入抽象是已经提到的“前向兼容性”。

我个人的观点是，只有对领域有深刻的了解才能帮助做出抽象决策以及在何处定位抽象。

— oopexpert
source

2

YAGNI AND KISS的麻烦在于它们完全主观且含糊。

json ?? 亚尼！只需发送一个csv字符串！

对象？接吻!!! 只是使用gotos！

“团队负责人”的角色定义不明确，但我建议您不要对团队的技术选择发表主观意见。即使您觉得他们是错的。遵守明确定义的需求清单。

代码的单元测试
api集成测试
最终产品的自动化UI测试
性能和扩展要求

如果团队可以通过对所有业务需求和规模技术需求的基本性能的通过测试，则您拥有一个有效的产品。

在那之后，它只是想做同样的事情但是更快

— 伊万
source

1

团队中的每个人都必须就完成的定义达成共识。否则，您将容易发生大量的范围变化，观点和核心要求的混混。

超出此范围交付的任何内容都必须保留在积压中，积压本身也具有完成的定义。

至于优先事项，MoSCoW方法始终为我们服务-YMMV。

— 罗比迪
source

1

我对此的第一个想法是...团队为什么要关注变化？他们是否对产品负责人有一定的历史了解，从而使他们感到需要构建第一个解决方案以使其更具可配置性，以使将来的增强变得更容易？如果您的解决方案需要2天，而他们需要5天，是的，则需要花费两倍以上的时间。但是，如果每次更改计划都需要2天，而对他们的计划进行改进则需要1天，那么从长远来看，他们的计划似乎确实更有效率。我认为在这个问题上没有正确或错误的决定。这取决于其他因素，恕我直言。但是，如果您在其他解决方案上将LOE加倍，而没有任何直接指导来做到这一点，则您对此想法是正确的（一些证据表明，可伸缩性，鲁棒性等需要额外的复杂性）。我的建议是让产品负责人参与这些对话，因为他们需要帮助确定优先级。如果您的解决方案是5分，并且现在可以满足需要，但是他们想要做的将需要50分且需要两个冲刺或更多，那么PO可能会说：“等等，我们计划并已优先发布此MVP，不能花2周的时间来开发路线图上没有的功能！”

— 柯蒂斯·里德
source