本质复杂性 偶然复杂性
当我与人们谈论如何在几乎零问题的情况下持续交付客户价值时,我通常会被嘲笑。
在我告诉他们没有什么可笑的之后,人们开始挑战我如何与其他系统集成,如何管理缺陷,如何处理不断变化的需求,如何管理回归问题以及如何应对上下文切换和挑战。其他类似问题。
幸运的是,我有经验数据,我的答案是基于经验的,而不是我在某个地方读过的书或模型,所以一段时间后,我设法使人们从嘲笑我变成至少开始好奇。
必须说,人们变得好奇,但内心深处他们仍然不相信我,仍然认为我是个大傻瓜。
我怎么能责怪他们? 几年前我也会做同样的事情。 我知道人们需要证明自己才能相信它,我对此没有问题。
尽管我设法解释了处理缺陷,更改需求,回归和上下文切换的方式,但直到现在我仍无法回答所有这些最大的问题,但每次对话最终都会解决这个问题:如何做您处理需要扩展的极其复杂的系统?
我已经考虑了好一阵子了,我考虑得越多,我就越确信复杂性是借口 。
当我们无法确定交付价值的优先次序时,就存在复杂性(我们不知道自己真正想要的是什么)。
当我们无法理解和描述我们正在构建的系统时,就会存在复杂性。
最后,复杂性是一个很好的借口,因为它不能适当地完成我们作为软件工程师的工作并应承担责任。
降低复杂性并停止借口:
- 您想交付客户价值,好的。 您无需在第一天就交付所有内容。与您的业务合作伙伴坐下来,确定增值最高的功能,然后专注于该功能。 如果问到风吹草动,说:“我们稍后再做,只有在我们真正需要的时候才做。”当您完成第一个功能时,很有可能会知道您仍然需要一些其他的东西。
- 在决定如何实现这种功能时,请寻找最简单,最便宜的解决方案,不要过时。 通过将来的证明,您将增加复杂性并猜测什么? 亚尼 衡量您的功能是否成功,并随时改变方向,失败就是学习。
- 确定要交付的价值后,请确保分解其自身的复杂性。 如果用户故事或工作单元或您所说的任何东西具有不止一条快乐的道路,那么它太复杂了,请将其分解为2个或多个工作单元。
- 如果您开始做某事,发现它比您想象的要复杂,那么请停止并将其分解为不那么复杂的单元,如果您继续不说话,您将隐藏复杂性,迟早会陷入混乱起来。
扩大规模是对错误复杂性问题的错误答案。
您根本不需要扩大规模:一次又一次地阅读1和2,您会发现您不需要的资源不如您所想。 在大多数情况下,扩大规模是抵抗复杂性的最简单,最昂贵和最懒惰的方法。
为了以结构化的方式进行1.和2.,我强烈推荐Gojko Adzic设计的一种名为Impact Mapping的方法。
进行操作3.单击此处
做这个时4.用头。TL; DR:当您不了解所构建的内容时,不要再指责复杂性。
翻译自: https://www.javacodegeeks.com/2014/07/complexity-is-the-excuse.html
本质复杂性 偶然复杂性