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

В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП. В своё время они обе были прорывными и эффективными, но превратились в cargo-культ с десятками интерпретаций. Я же хочу рассказать вам об исходных предположениях, на которых они основаны, и контексте их появления, чтобы вы смогли использовать эти отличные идеи для своей выгоды.

Scrum

Изначальная идея

Возьмём книгу Джеффа Сазерленда "Scrum: искусство выполнять вдвое больше работы за вдвое меньшее время". Сазерленд - это один из создателей Scrum, а эта книга рассказывает историю возникновения методологии и её основные принципы. Это как раз то, что нам нужно. Будем опираться на неё.

Жизненный опыт Джеффа привёл его к следующим мыслям:

• Адаптация - Эффективно выживают только те, кто умеет адаптироваться к изменениям

• Ценность - Производство продукта, не имеющего подлинной ценности - это безумие

• Команда - Небольшие (7±2 человека) сплочённые команды достигают результата быстрее, чем набор разрозненных специалистов

Опираясь на эти предположения мы можем сформулировать стратегию:

Проект выполняется небольшой сплочённой командой в несколько подходов. В конце каждого подхода команда поставляет клиенту готовую и ценную часть продукта. На основе результатов подхода план проекта адаптируется

Фактически - мы получили Agile

Реализовать эту стратегию можно разными способами, которые приведут нас к разным методологиям. Мы рассмотрим способ, который приведёт нас к Scrum.

"Подход" мы будем называть "спринтом". Каждый спринт выполняется по циклу Деминга-Шухарта. Почему именно по нему? Потому что создатели Scrum посчитали его подходящей адаптационной моделью. Можно было бы взять и другую модель, и тогда мы бы получили другую методологию.

Как работает цикл Деминга-Шухарта:

1. Сначала мы выдвигаем гипотезу: план. Мы предполагаем, что если мы будем делать что-то ка��-то, то достигнем цели (Plan)

2. Потом мы следуем этому плану (Do)

3. Когда план выполнен, тогда мы проверяем, как хорошо мы достигли поставленной цели. А если не достигли, то почему (Check)

4. На основании этих данных (полученных экспериментальным путём!) мы изменяем свой рабочий процесс (Act) и идём проверять его эффективность на следующем цикле

А теперь соотнесём эти 4 этапа с "ритуалами" Scrum:

• "Планирование спринта" - это "Plan"

• "Обзор с клиентом" - это "Check"

• "Ретроспектива" - это "Act"

• "Ежедневный Scrum" - это "Do". Этот этап превратили в самостоятельный маленький цикл Деминга-Шухарта, где Check/Act/Plan выполняются ежедневно в начале рабочего дня

Основа готова. Собираем команду и идём работать. Роли, backlog, user stories и т.д. - это дополнения, необходимые для плавной работы.

Что пошло не так

В изначальном варианте Scrum спринт длился 1 месяц. Ни 2 недели! Ни, тем более, 1 неделю! Месяц! Одна из целей спринта - это поставить клиенту законченную и полезную версию продукта. Если раньше, в проекте на 6 месяцев, мы занимались сначала только сбором требований (1 месяц), потом только анализом (ещё 1 месяц), и только потом реализацией (4 месяца), то по Scrum проект разбивается на 6 спринтов-месяцев, где эти 3 фазы повторяются в каждом спринте.

Подумайте, к чему приводят недельные спринты:

• У вас нет времени на сбор требований и анализ. При спринте в 1 месяц вы можете заниматься подготовкой ~ 1 неделю. Вы продумываете план, критерии завершённости, архитектуру, распределяете задачи. При спринте в 1 неделю на это всё у вас есть максимум 1 день. О какой архитектуре или стратегическом планировании тут можно говорить? У вас даже нет времени пообщаться с клиентом, чтобы обновить модель предметной области

• У вас нет времени на реализацию. У вас осталось 4 дня, за которые нужно успеть реализовать полноценный Epic. Вы не справляетесь, и вынуждены делить 1 Epic на несколько спринтов. Но пока весь Epic не готов - вы не можете заливать его на PROD. И тогда мы выбираем из 2 зол: либо мы делим Epic на отдельные истории, получая не консистентный UI и кашу в коде; либо релизимся раз в несколько спринтов, что противоречит заявленной стратегии (1 подход = 1 релиз). И тогда зачем вообще сокращать спринт до 1 недели?

• Этап планирования становится бессмысленным. Зачем что-либо планировать, если можно сделать "как поняли", показать клиенту, а потом исправлять с его слов? Но во время планирования мы определяем критерии завершённости, которые позже используем на этапах Check и Act. Нет планирования = нет критериев завершённости = нет данных для улучшения процесса

• Невозможно распараллелить работу. При планировании на 1 месяц можно создать диаграмму PERT, перетасовать её, чтобы получились несколько параллельных веток, и отдать эти ветки разработчикам. При планировании на 1 неделю это не эффективно. Как следствие на проекте уже не могут работать 7 человек. Команду сокращают до 2-3 человек, что удлиняет время работы над проектом, и не позволяет компании получить на рынке конкурентное преимущество за счёт быстрой сдачи проектов

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

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

Напомню наши ценности из начала статьи: Адаптация, Ценность, Команда. Если вы выкидываете хотя бы один из ритуалов, то забудьте об Адаптации. Никаких улучшений со временем не будет.

Можно ещё много чего сказать о том, что пошло не так со Scrum. Agile методологии сложны. Это набор принципов и ценностей, которые не связанны между собой логически. А значит всегда есть соблазн что-то выкинуть или изменить, ведь трудно понять, на что это повлияет. Когда-нибудь мы, как сообщество, решим эту проблему. Но не сегодня.

А теперь, давайте окунёмся в мир инженеров.

Объектно-ориентированная парадигма

Изначальная идея

Эта история началась в Xerox PARC. Инженеры этого исследовательского центра работали над революционной идеей: оконным графическим интерфейсом.

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

И вот компьютерная мышь придумана и собрана, концепция интерфейса с окнами, менюшками и кнопками разработана. Есть даже идея для WYSIWYG текстового редактора. Но для программирования этого "добра" существовавшие тогда языки и методологии не подходили, потому что были заточены под один ввод-вывод. Инженерам PARC нужен был способ запрограммировать элементы интерфейса так, чтобы они могли быть независимыми (как например "окна"), но при этом могли взаимодействовать между собой (кнопка внутри одного окна открывает другое и т.п.). И вот что они придумали.

Они дали каждому элементу интерфейса "почтовый ящик". Теперь каждый элемент мог отправлять другим элементам "письма", а получатель "письма" мог на них как-то отреагировать (или не отреагировать, всё зависит от получателя). Давайте называть тех, кто может получать и отправлять письма "объектами", а сами письма будем называть "сообщениями".

Пример. Вы нажимаете на "крестик", чтобы закрыть окно с приложением. Объект кнопки посылает объекту операционной системы сообщение "я кнопка закрытия приложения (id) и на меня нажали". Операционная система отправляет сообщение объекту приложения "тебя хотят закрыть". Приложение подготавливает себя к закрытию и отправляет сообщение операционной системе "я приложение (id) готово к закрытию". После чего операционная система завершает процесс. А что случится, если приложению отправили сообщение о закрытии, но от него долго не поступает ответ? Вы видите на экране сообщение "Приложение не отвечает".

Так и появилась ООП, которое мы сейчас знаем. Системы в них - это набор объектов, которые могут посылать друг другу сообщения и реагировать на эти сообщения. По своему устройству это асинхронная система, потому что ответы на сообщения не предполагались. На основе этой парадигмы реализовали язык Smalltalk, на котором и запрограммировали первый в мире компьютер с графическим интерфейсом Xerox Alto.

Давайте введём определение:

Объектно-ориентированная парадигма описывает систему как набор объектов, обменивающихся друг с другом сообщениями

Вот некоторые выводы, которые можно из этого сделать:

• ООП видит систему как "подсеть". Можете сравнить это с несколькими телефонами и ноутбуками в квартире, связанными через Bluetooth (или через wi-fi, но тогда у них есть маршрутизатор. Кстати, вы только что открыли паттерн "Mediator"). Каждый такой телефон или ноутбук - это объект. Запросы по сети между ними - это сообщения

• ООП отлично справляется с моделированием передачи данных, и никак не помогает в их трансформации. Если вам нужно превратить один тип данных в другой по каким то правилам - воспользуйтесь ФП или СП. А вот если нужно смоделировать общение между узлами сети, да ещё и асинхронное, то ООП в этом пока нет равных

• Лучшее применение ООП находит в программировании UI, сетевом взаимодействии и программировании конечных автоматов

Что пошло не так

Всю проблему с ООП можно описать одним предложением: "Её используют там, где не нужно, и не используют там, где нужно".

Нет смысла моделировать всю систему через объекты. Если предположить, что "Программная система - это набор UseCase'ов по передаче, трансформации и хранению данных", то ООП хорошо справляется только с "передачей". Для трансформации лучше всего подходит функциональная парадигма. Для хранения (чтение и запись) - реляционная.

Вот хороший и лёгкий пример применения ООП. Вы пишете небольшую программную систему, и она может связываться с другими программными системами (через сеть или процессы). Представьте каждую внешнюю систему как объект. Предположим, что ваше приложение взаимодействует с базой данных, сервисом для отправки SMS и облачным хранилищем файлов. Создайте для каждого из них интерфейс (абстракция):

interface Database
{
    public function saveUser(User $user): void;
    public function getUser(UserId $id): ?User;
}

interface SmsService
{
    public function send(Phone $number, string $text): void;
}

interface AmazonStorage
{
    public function put(File $file): void;
    public function get(FileId $id): ?File;
}

Потом создайте 2 реализации: одну для тестов, а другую для PROD (полиморфизм). Внутри реализации для PROD объект будет хранить адрес сервиса и credentials, самостоятельно настраивая и отправляя запросы по сети (инкапсуляция).

Пример с UI (крестик для закрытия окна) вы уже видели выше. Если вы пишете интерфейсы на JS, то там посылки сообщений используются почти для всего. Чаще они делаются через замыкание, но их можно превратить в объекты:

// Посылка сообщения `open` объекту `modal` при клике на кнопку
button.addEventListener('click', modal.open);

"Когда у вас в руках молоток - все вокруг становится похоже на гвоздь". Помните, что ООП - это про посылку сообщений. Используйте его для настраивания взаимодействия между изолированными программными модулями. А трансформацию данных оставьте ФП. Связка из этих двух парадигм - лучшее решение при создании приложений.

P.S. И прошу, не надо больше кошек, собак и машин. Вам нужны все данные из этих объектов, и по итогу вы просто делаете getters и setters для каждого поля. Для моделирования предметных областей лучше всего подойдёт ФП. Методологию можете прочитать в книге "Domain Modelling Made Functional" (Scott Wlaschin).

Итог

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

В этой статье мы рассмотрели 2 такие идеи:

• Scrum - это Agile методология (Адаптивность, Ценность, Команда), которая реализована через цикл Деминга-Шухарта

• ООП - это парадигма, которая рассматривает систему как набор объектов, обменивающихся сообщениями