Общался на днях со своим коллегой - невероятно грамотным человеком. И он помог мне сделать для себя открытие.

В пабликах часто обсуждается проблема о том, что "рефакторить некогда, нужно сделать всё на вчера", и команда безуспешно пытается найти хоть какое-то понимание со стороны бизнеса в упорядочивании стремительно разбегающейся по коду лапши, в которой она уже успела несколько раз запутаться.

Пропущу длинную цепочку умозаключений, скажу только вывод. Пытаться "продать" решение в таком случае, действительно, может оказаться бесполезно. Вместо этого нужно наладить планирование разработки. Да, пусть план будет долгим, корявым и неточным, но он должен быть, т.к. именно он может снять те самые когнитивные искажения, на основе которых формируются иррациональные решения ЛПР.

Животворящая книга в этом вопросе - это "Planning Extreme Programming" by Kent Beck, Martin Fowler, которая хорошо раскрывает тему о том, почему бесполезно убеждать ЛПР в условиях отсутствия планирования.

[UPDATE]: об инструментах планирования:
- https://www.tgoop.com/emacsway_log/1079
- https://www.tgoop.com/emacsway_log/1081
- https://www.tgoop.com/emacsway_log/1098

О методах планирования и оценивания:
- https://www.tgoop.com/emacsway_log/916

В продолжение темы планирования.

Вот что пишет Дейл Карнеги в своей книге "Как перестать беспокоиться":

💬 Сорок два года спустя, в тихий весенний вечер, когда в университетском парке цвели тюльпаны, сэр Уильям Ослер обратился к студентам Йельского университета. Считается, сказал он, что такой человек, как он,- профессор четырех университетов и автор популярной книги, должен обладать «мозгом особого качества». Это неверно, заявил он. Оказывается, и его близкие друзья знали, что он обладал «самыми посредственными способностями». В чем же секрет его успеха? Он сказал, что достиг успеха потому, что стремился жить в отсеке сегодняшнего дня, непроницаемо отгороженном от остальных дней. Что он имел в виду? За несколько месяцев до своего выступления в Йельском университете сэр Уильям Ослер пересек Атлантический океан на большом океанском лайнере, на котором капитан, стоявший на мостике, мог нажать на кнопку, и сразу же слышался шум механизмов, и отдельные отсеки корабля начинали герметически закрываться, чтобы в них не попала вода. «Каждый из вас,- сказал доктор Ослер этим студентам,- является гораздо более замечательным механизмом, чем гигантский лайнер, и, вступив в жизнь, вы отправляетесь в более длительное плавание. Я настаиваю на том, что вы должны научиться контролировать данный вам механизм и защищать его от штормов, то есть вовремя изолировать его отдельные отсеки. Только тогда вы обеспечите безопасность своего путешествия. Стойте на мостике и обеспечьте, чтобы хотя бы главные переборки корабля находились в рабочем состоянии. Нажмите на кнопку, и вы услышите, как на каждом этапе вашей жизни железные двери изолируют от вас прошлое - мертвые вчерашние дни. Нажмите на другую кнопку, и металлический занавес изолирует будущее - не родившиеся завтрашние дни. Тогда вы в полной безопасности - на сегодняшний день!.. Изолируйте прошлое! Пусть мертвое прошлое хоронит своих мертвецов... Изолируйте вчерашние дни, которые освещали глупцам путь к могиле. Груз будущего, прибавленный к грузу прошлого, который вы взваливаете на себя в настоящем, заставляет спотыкаться на пути даже самых сильных. Изолируйте будущее так же герметически, как прошлое... Будущее в настоящем... Нет завтра. День спасения человека - сегодня. Бессмысленная трата энергии, душевные страдания, нервное беспокойство неотступно следуют по пятам человека, который беспокоится о будущем... Итак, закройте наглухо все отсеки корабля, отделите носовую и кормовую части лайнера железными переборками. Воспитывайте у себя привычку жить в отрезке времени, отделенном от прошлого и будущего „герметическими переборками".

Разве доктор Ослер хотел сказать, что мы не должны прилагать никаких усилий для подготовки к завтрашнему дню? Нет. Отнюдь нет. Он лишь неустанно утверждал в этом выступлении, что лучший способ подготовиться к завтрашнему дню - сконцентрировать свои силы и способности на наилучшем выполнении сегодняшних дел."

-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.

И еще одна выдержка из той же книги:

💬 Один военный врач дал мне совет, который полностью преобразил мою жизнь. После тщательного осмотра он пришел к выводу, что в основе моих заболеваний было расстройство психики. «Тед, - сказал он, - я хочу, чтобы ты смотрел на свою жизнь, как на песочные часы. Ты знаешь, что тысячи песчинок находятся в верхней части песочных часов; и все они медленно и регулярно проходят через узкую перемычку посередине. Если ты или я сделаем так, чтобы через это отверстие в определенное время проходило больше, чем одна песчинка, часы испортятся. Ты, я и все остальные люди похожи на эти песочные часы. Когда мы утром встаем, возникают сотни дел, которые мы должны выполнить в этот день. И если мы не будем выполнять эти дела по одному в определенный промежуток времени (как одна песчинка проходит через узкое отверстие), а будем стремиться сделать все сразу, мы подорвем свои физические или психические силы».

Я применял эту философию на практике с того незабываемого дня, когда военный врач дал мне совет: «Одна песчинка - в единицу времени... Одно дело- в определенный промежуток времени». Этот совет спас меня физически и психически во время войны; он также помог мне теперь в мирное время. Я работаю клерком Коммерческой кредитной компании в Балтиморе.
В своей деятельности я столкнулся с теми же проблемами, которые возникали передо мной во время войны, - мне надо было выполнить очень много дел сразу, но в моем распоряжении было слишком мало времени, чтобы с ними справиться. Наши акции упали в цене. Нам надо было вводить в свою деятельность новые формы. В то время организовывались новые акционерные общества, которые открывались и закрывались, меняли адреса и т. п. Вместо того, чтобы раздражаться и нервничать, я вспомнил то, что мне говорил врач: «Одна песчинка - в единицу времени, одно дело - в определенный промежуток времени». Повторяя себе эти слова снова и снова, я выполнял свои обязанности наиболее рациональным образом. Делая свою работу, я больше не испытывал растерянности и замешательства, которые чуть не искалечили меня в боевых условиях».

Одним из самых ужасающих комментариев к нашему образу жизни является то, что почти половина коек в наших больницах занята пациентами, страдающими нервными и психическими расстройствами, пациентами, которых сломил непомерный груз накопившихся вчерашних дней и устрашающих завтрашних дней. Ведь значительное большинство этих людей могло бы спокойно наслаждаться жизнью и быть счастливыми и приносить пользу окружающим, если бы они следовали совету Иисуса Христа: «Не тревожьтесь о завтрашнем дне», или совету Уильяма Ослера: «Живите в „отсеке" сегодняшнего дня».

Вы и я в настоящую секунду стоим на пересечении двух вечностей: безбрежного прошлого, которое длилось вечно, и будущего, которое устремлено вперед до последнего момента летосчисления. По всей вероятности, мы не можем одновременно жить и в одной и в другой вечности - нет, даже ни одну долю секунды. Пытаясь этого добиться, мы можем подорвать свое физическое здоровье и умственные силы. Поэтому давайте довольствоваться тем, чтобы жить в единственном отрезке времени, в котором мы, вероятно, можем жить,- от настоящего момента до отхода ко сну.

-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.

А вот что говорит по этому поводу Kent Beck:

💬 When Kent was about ten, he went fly-fishing for the first time in the Idaho panhandle. After a fruitless, sweaty day in pursuit of brook trout, he and his friends headed for home. After half an hour of stumbling through dense trees, they realized they were lost. Kent started to panic — fast breathing, tunnel vision, chills. Then someone suggested a plan — they would walk uphill until they hit a logging road they knew was up there. Instantly, the panic disappeared.

Kent was struck at the time by the importance of having a plan. Without the plan, he was going to do something stupid, or just go catatonic. With the plan he was calm again.

Plans in software development work the same way. If you know you have a tight deadline, but you make a plan and the plan says you can make the deadline, then you'll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.

But we've also seen plans lead to trouble. They can be a huge time sink, dragging days out of people who'd rather be doing something productive. Plans can be used as a stick to beat people with, and worst of all, they can conceal trouble until it's too late to deal with it.

-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

ЛПР, не имеющий уверенности в том, что он имеет достаточно ресурсов для выполнения требуемого объема работ до наступления контрольного срока, имеет склонность действовать эмоционально, а не рационально. Поэтому я и сказал, что любые рациональные доводы в таком состоянии имеют небольшие шансы быть услышанными. Хотите быть услышанным - дайте ЛПР уверенность в том, что его беспокоит, и продемонстрируйте это на примера плана. Ну или на примера плана докажите невозможность осуществления задумки. Если она невозможна, то и беспокоиться о ней тем более глупо. Человека изматывает неопределенность.

См. также https://www.tgoop.com/emacsway_log/771

В той же книге:

💬 Chapter 6. Too Much to Do

When you are overloaded, don't think of it as not having enough time; think of it as having too much to do. You can't give yourself more time, but you can give yourself less to do, at least for the moment.

We were on a project together once that the team had rescued from impending oblivion. Toward the first release there came a time when it was clear to everyone that we weren't going to make the release date. One day we had a stand-up meeting to discuss the problem. We went around the circle answering the question "What is preventing us from going into production?"

"I don't have enough time."

"I don't have enough time."

"I don't have enough time."

Nobody had enough time. But there was no obvious answer. Everybody went home.

Over Korean food that night (we always ate Korean; it seems to be good for the brain), we were talking about the meeting. Suddenly a cosmic ray collided with a piece of kimchee and we saw the real problem.

The next morning we called another stand-up.

"Repeat after me—I have too much to do."

Shrugs all around, but what the heck.

"I have too much to do."

"I have too much to do."

"I have too much to do."

And so on around the circle until we got to Richard.

"I have too much to do. What is your point?"

The point is that when you don't have enough time you are out of luck. You can't make more time. Not having enough time is a position of hopelessness. And hopelessness breeds frustration, mistakes, burnout, and failure.

Having too much to do, however, is a situation we all know. When you have too much to do you can:

- Prioritize and not do some things
- Reduce the size of some of the things you do
- Ask someone else to do some things

Having too much to do breeds hope. We may not like being there, but at least we know
what to do.

-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

Вот зачем нужно планирование.

Тут возникло предположение о том, что Agile и планирование несовместимы.

Я не буду сейчас говорить о том, что сегодня Agile в чистом виде стремительно снижает свою долю на рынке в пользу гибридных моделей разработки. Хотя на этом можно было бы и остановиться, потому что:

💬 An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work. Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.
-- AgileImposition by MartinFowler (один из ключевых соорганизаторов Agile Manifesto)

Раз уж затронули этого фигуранта Agile Manifesto, то давайте выслушаем его полностью:

💬 Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.

Agile plans are a baseline that we use to help us control changes. Agile teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software.

Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.

Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team's effectiveness, but are always second-order influences.
-- Agile Software Guide by Martin Fowler

💬 The problem with predictive processes is that project quality is measured by conformance to plan. This makes it difficult for people to signal when reality and the plan diverge. The common result is a big slip in the schedule late in the project. In an agile project there is a constant reworking of the plan with every iteration.
-- New Methodology by Martin Fowler

💬 A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.
-- New Methodology by Martin Fowler

Из этого видно, что ключевым в Agile является не отсутствие плана, а отсутствие следования плану, точнее, присутствие изменяемости плана с каждым новым инкрементом знаний, возникающим в результате практического исследования каждого нового системного инкремента. Подробнее смотрите в главе "Predictive and Adaptive Planning" его книги "UML Distilled" 3d edition.

Задача Agile заключается не в устранении плана, а в компенсации трудности заблаговременно планирования путем использования эмпирического способа обработки неопределенности (т.е. путем adaptation, responding).

При этом нужно учитывать, что адаптация тоже имеет свою стоимость, и важно находить баланс между экономической целесообразностью Prediction и Adaptation, о чем шла речь здесь:
https://www.tgoop.com/ru_arc/50

Иными словами, адаптации должно быть настолько мало, насколько недорого обходится Prediction. Вот что по этому поводу говорит сам организатор Agile Manifesto:

💬 The cost of improving the estimate, the initial work breakdown estimation, the cost of refining that grows exponentially. With every next layer you want to take it down. And the benefit of doing that does not grow exponentially. It grows logarithmically."
—"YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)" at 33:15

А поскольку тут собрались главным образом архитекторы, то, дабы не впасть в Культ Карго, возникает вопрос, а какую проблему решает Agile? Вот здесь перечислен список решаемых им проблем: https://www.tgoop.com/ru_arc/288

Это список является причиной появления Agile на свет, и если вдруг в какой-то компании список этих проблем не решается, то значит применение Agile в текущем виде лишено своего основного смысла.

Обратите внимание на эти пункты:

Customers are afraid that:
- They won't ever see a meaningful plan.
- The plans they do see will be fairy tales.

Собственно говоря, в основу Agile Manifesto положен документ Bill of Rights:
- https://www.tgoop.com/ru_arc_chat/15572

И ключевую роль в появлении философско-психологической составляющей Agile сыграла эрудированность Kent Beck в вопросах психологи, философии и менеджмента. Кстати, именно от него заразился этими идеями Robert Martin, который и организовал встречу Agile Manifesto. Я уже цитировал позицию Kent Beck по вопросу планирования:
- https://www.tgoop.com/emacsway_log/1221
- https://www.tgoop.com/emacsway_log/1222

Добавлю еще одно его выражение, которое идеально отвечает на вопрос по сути обсуждения:

💬 Like so many, we enjoy Eisenhower's quotation: "In preparing for battle I have always found that plans are useless, but planning is indispensable." [Richard Nixon, Six Crises (New York: Touchstone Press, 1990)] That's why this isn't a book about plans; it's about planning. And planning is so valuable and important, so vital, that it deserves to go on a little every day, as long as development lasts.
-- "Planning Extreme Programming" by Kent Beck, Martin Fowler

Это говорит Kent Beck, основатель XP - одной из первых и наиболее успешных Agile методологий, практики которой использует подавляющее большинство современных методологий.

Но обратимся к основателям Scrum.

💬 One of the purposes of the plan is to convince someone to fund the project. The plan should provide sufficient details to satisfy a source of funding that the project has merit, that it will deliver certain things at certain times, that the benefits outweigh the costs and risks, and that the people who will staff the project are sufficiently compentent to execute the plan.
-- Agile project management with Scrum by Ken Schwaber.

В основу Scrum положен цикл PDCA, первая буква которого расшифровывается как Plan. Об этом пишет другой основатель Scrum - Jeff Sutherland. Кроме этого, он пишет:

💬 Release Planning & Initial Product Backlog Refinement

A question that is sometimes asked is how, in an iterative model, can long-term release planning be done. There are two cases to consider: (1) a new product in its first release, and (2) an existing product in a later release.

In the case of a new product, or an existing product just adopting Scrum, there is the need to do initial Product Backlog refinement before the first Sprint, where the Product Owner and team shape a proper Scrum Product Backlog. This could take a few days or a week, and involves a vision workshop, some detailed requirements analysis, and estimation of all the items identified for the first release.

Surprisingly in Scrum, in the case of an established product with an established Product Backlog, there should not be the need for any special or extensive release planning for the next release. Why?

Because the Product Owner and team should be doing Product Backlog refinement every Sprint (five or ten percent of each Sprint), continuously preparing for the future. This continuous product development mode obviates the need for the dramatic punctuated prepare-execute-conclude stages one sees in traditional sequential life cycle development.

During an initial Product Backlog refinement workshop and during the continuous backlog refinement each Sprint, the Team and Product Owner will do release planning, refining the estimates, priorities, and content as they learn.

Some releases are date-driven; for example: “We will release
version 2.0 of our project at a trade-show on November 10.” In this situation, the team will complete as many Sprints (and build as many features) as is possible in the time available. Other products require certain features to be built before they can be called complete and the product will not launch until these requirements are satisfied, however long that takes. Since Scrum emphasizes producing potentially shippable code each Sprint, the Product Owner may choose to start doing interim releases, to allow the customer to reap the benefits of completed work sooner.

Since they cannot possibly know everything up front, the focus is on creating and refining a plan to give the release broad direction, and clarify how tradeoff decisions will be made (scope versus schedule, for example). Think of this as the roadmap guiding you towards your final destination; which exact roads you take and the decisions you make during the journey may be determined en route.

Most Product Owners choose one release approach. For example, they will decide a release date, and will work with the team to estimate the Release Backlog items that can be completed by that date. In situations where a “fixed price / fixed date / fixed deliverable” commitment is required – for example, contract development – one or more of those parameters must have a built-in buffer to allow for uncertainty and change; in this respect, Scrum is no different from other approaches. The advantage of Scrum is that new requirements can easily be added into the release at sprint boundaries as long as low prority requirements scheduled later can be removed and still keep the project on time and on budget.
-- "Jeff Sutherland's Scrum Handbook" by Jeff Sutherland

Таким образом, Agile не отрицает и не подменяет собою планирование, а позволяет компенсировать сложность заблаговременно планирования путем адаптации плана.

Вот эта картинка из главы "1.4.2.2 Relationship between Requirements Models and Design Models" справочника "Handbook of Requirements Modeling According to the IREB Standard", которая слегка модифицирует оригинальную картинку из известной статьи Twin Peak Model , очень хорошо выражает функцию, возложенную на Ubiquitous Language как средства обобщения (и конвергенции) ментальной модели эксперта предметной области и доменной модели решения.

Кратко о fitness functions. Любое приложение всегда стремится к энтропии. Как говорил известный в ИТ-индустрии Gregor Hohpe:

💬 It’s almost like enterprise IT is subject to the Second Law of Thermodynamics, which concludes that the entropy in an (isolated) system can never decrease - at best it can be constant, but usually it increases.
-- "Here’s why enterprise IT is so complex" by Gregor Hohpe

Технически невозможно контролировать качество работы каждого разработчика. Это побуждает индустрию искать способы поддержания качества архитектуры на принципиальном уровне. Одним из таких способов является Evolutionary Architecture.

Генетический механизм репродукции реализует адаптивный способ разрешения неопределенности.

Причина его существования заключается в том, что никто не знает какие условия обитания будут на планете завтра. Т.е. имеет место неопределенность условий существования. Вдруг завтра прилетит метеорит и изменится состав атмосферы?

В связи с этим, двуполое размножение обеспечивает постоянную генерацию новых генетических комбинаций. Мы просто не знаем какая именно генетическая комбинация окажется наиболее приспособленной к завтрашним условиям окружающей среды.

Те генетические комбинации, которые слабо приспособлены к текущим условиям окружающей среды, не должны препятствовать распространению более приспособленных комбинаций. Иными словами, если существует механизм формирования разнообразия генетических комбинаций, то должен существовать и механизм истребления слабо приспособленных генетических комбинаций. Именно поэтому двуполый механизм репродукции не может выполнять свои функции без хищников, назначение которых сводится к истреблению слабо приспособленных генетических комбинаций. Т.е. к селекции. Это как пропалывание грядки.

Зачастую проблема кодовой базы заключается в том, что никто и ничто не выполняет роль этого самого хищника, истребляющего несоответствующие решения. Поэтому больные решения хорошо размножаются.

Robert Martin говорил, что архитектура - это о том, как не надо делать. Иными словами, архитектурное решение - это сокращение количества возможных вариантов. Т.е. архитектура должна выполнять хищнические функции.

Чем отличаются собаки от волков? Волк имеет естественных врагов-хищников, а собаки - нет.

Вместо хищников, процесс селекции собак выполняют выставки и стандарты пород, которые фиксируют желаемые свойства пород.

Выводок, не соответствующий требованиям стандарта породы и допустимым пределам отклонения, отбраковывается и не получает сертификат соответствия. Его рыночная ценность падает, и он не используется заводчиками для репродукции.

По мере возникновения исторических изменений в породе, в стандарт вносятся изменения, требования ужесточаются, что обеспечивает прогресс породы.

Этот же принцип положен в основу Evolutionary Architecture. Архитектор выступает в роли автора стандарта породы, а разработчик - в роли заводчика, который выбирает (путём сравнения) для репродукции такой экземпляр породы из всех возможных, который наилучшим образом соответствует стандарту.

Роль стандарта породы выполняют fitness functions (функции соответствия, приспособленности). Они позволяют разработчикам измерить степень соответствия старого варианта системы и нового, и выбрать тот, который соответствует требованиям наилучшим образом.

Понимая, что требования fitness functions будут ужесточаться, разработчик всегда стремится увеличивать запас по требованиям , что вынуждает искать его новые решения и постоянно повышать собственный уровень знаний.

Хотя fitness functions выполняют охранные функции, препятствуя деградации свойств системы, главная их ценность заключается не в этом, а в создании благоприятных условий для постоянного развития уровня квалификации специалистов.

Наиболее важными я считаю fitness functions с нагрузочным и объемным тестированием, которые мгновенно выявляют костыльные запросы и побуждают разработчиков изначально закладывать в систему решения с дальним горизонтом развития, например, такие, как CQRS.

Пример реализации fitness functions.

у автора есть и другие интересные статьи по моделированию:
https://habr.com/ru/users/maxstroy/

Очень актуальная статья, разъясняющая суть Bounded Context с еще одного ракурса:
https://habr.com/ru/articles/332064/

Оказывается, у Eric Evans это есть прямым текстом:

💬 MODEL-DRIVEN DESIGN discards the dichotomy of analysis model and design to search out a single model that serves both purposes.
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

Вот что такое DDD одним предложением.

P.S.: Моя благодарность всем участникам дискуссии в @ru_arc_chat