Написан пост, в котором вы даёте оценку процессу инженерии в вашей организации: насколько он далеко от «водопада».
Ситуация с водопадом и гибкими методами разработки зеркалит техническую ситуацию с монолитами и микросервисами. С одной стороны, номинально все слышали, что монолиты/водопады это плохо, немодно и надо срочно от этого избавляться. И как всегда шкалу не видно, видно только два крайних значения. И делается попытка прыжка между краями обрыва, вместо того, чтобы построить мост. Монолиты распиливаются абы как, водопад объявляется забытым. А фактическое состояние это сумрачная зона между мирами. Потому что микросервисы не микросервисы, а распределённый монолит. А гибкие технология, не то, чтобы гибкие.
Любопытства ради зашла в айтишный чатик, когда там обсуждали DDD. И парень пишет “другими словами, совмещение модели требований с моделью решения, откуда ныряем в классический Object Oriented Analysis and Design и прочие Гради Буч, Якобсон и прочее
тогда можно предположить, что DDD есть набор паттернов для применения OOAD”. На что я ему отвечаю “Если что требования умерли вместе с водопадной разработкой.” И дальше происходит ожидаемый водоворот, на тему “требования - это документация, вы что не пишите документацию?!”, “требования это потребности заказчики, я - а они гвоздями прибиты? нет, мы их переписываем конечно по несколько раз”.
Такое ещё
по идее требования не связаны с процессом разработки
и они присутствуют на разных уровнях причем в разной степени формальности - от рыхлых хотелок “заказчика”, более менее формализованных на уровне бизнес-аналитика (уже можно наивно руками выполнять проверки на полноту, непротиворечивость) и уже “формальных” в коде
И у нас всё примерно так же. Выпускаются версии продукта (релизы), набитые фичами. Очередная фича может полностью переписывать предыдущую. Причем это не гипотеза провалилась, давайте новую затестим. А то, как вы сделали, работает неправильно, надо переделать. А как это мы сделали неправильно? А никто не знает, как правильно.
Продолжаю из-за шторки слушать, как мои ребята пытаются делать “большую сложную фичу”. Проектирование (верхнеуровневое) сделано бизнес-архитектором. Там что-то вида “примерно такие алгоритмы и примерно такие наборы данных”. Одно в другое переходит, добавлены связи, которые хотели заказчики, по-другому собираются суммы. Но это эпик. Т.е. это всё надо будет уточнять. Дальше этот эпик на стори разбивает бизнес-анализ. Разбивает на глаз. Внутри стори должен системный анализ “выписать” задачу на разработчика. Т.е. функциональная декомпозиция осталась в эпике. СА уже пишет сделай мне конструктив для такого куска. Как это всё вместе будет собираться, никто не думает. Точнее разработчик, когда глазами смотрит на то, что “описал” СА начинает задавать уточняющие вопросы вида “кажется вот тут не будет работать, давайте ещё подумаем”. Собираются втроём разработчик, СА, БА и думают. Описание задачи переписывается. Работы в этот момент уже начались фактические? По-разному. Сильно зависит от разработчика и от человека-с-палкой. Человеком-с-палкой подрабатывает БА, когда сроки поджимают. Как раз начинается “содержание работ меня не волнует, давайте начинайте”, содержание скидывается на СА. Как бы он для этого и нужен вроде. А по факту, разработчик доделывает/заставляет СА делать работу о том, как деталь должна выглядеть, каких там винтиков не хватает. Т.е. непосредственное написание кода может идти параллельно с уточнениями описания задачи. Переписали описание, переписываешь код. Бывает так, чтобы “постановка задачи” изменилась после этапа тестирования? Бывает и так.
Меня, как разработчика, одно время это очень сильно раздражало. Определитесь, что мы делаем и мы сделаем нормально. Потом я себя успокоила мыслью про инкременты. Как различать инкременты и брак вопрос остался. На одной из работ у нас пытались считать соотношение новых фичей (развитие) и переделок(ремонт). Но там просто баги считали переделками. Но в более-менее сложных доменах это не работает. Я периодически шучу “заводите баг на аналитика”. Бывают ещё смешные баги “мы ожидали, что оно будет вот так работать, а оно не работает”. А задачи на разработку, чтобы оно “так работало” не было. Магически должно было само заработать? Теперь понятно, что концепции использования нет.
Во всё большем и большем числе проектов (начиная с айтишных проектов) признавали, что нельзя сделать никакого предварительного (up-front) планирования отдельных работ.
Менеджерское представление о сроках осталось “водопадное”, никаких вам знаниевых проектов. Кто-то пообещал, что к такой дате будет готов такой функционал. Делайте. Будет оно работать, не будет, менеджер не думает. Ещё есть в айти присказка “задача не должна занимать больше трёх дней, если у вас занимает больше, значит плохо разбили на задачи”. Вот оно так и делается. Вот берём какой-то кусок, разработчик ставит на него три дня, потому что не ставить срок нельзя. А дальше как пойдёт. Повезло, успел. Не повезло, будет “перенос с объяснениями”. Третий вариант, задача застряла из-за связей. Наша задача застопорилась работами соседа по команде, или соседней команды. Бывает связи внезапно выясняются.
Написан пост с оценкой того, как часто приходится выполнять работы в методологическом времени (обсуждать методы работы в инженерном процессе) и сколько процентов вашего рабочего времени занимает работа в методологическом времени.
Здесь надо понимать, что методологическая работа должна бы выполняться на каждом уровне: на уровне сотрудника, на уровне команды, на уровне взаимодействия двух соседних команд, на уровне команд блока, на уровне всех блоков продукта и выше. О наличие или отсутствии методологической работы на уровнях блока и выше я могу только прикидывать/фантазировать. На уровне сотрудника (себя) я начала задумывать о методе работе. Начала задумываться о методе работы на уровне постановки стори/эпика, которая в итоге потом ко мне придёт задачами. На уровне сторей это чаще всего сейчас делается постфактум. Пытаюсь что-то думать и делать на уровне взаимодействия с соседней командой. На уровне команды (продуктовой) стоило бы подумать, там куча проблем. Думает кто-то о методах работы команды? Маловероятно. А главный вопрос, а кто? Внутри команды команда себя не видит. Кто-то совсем с далекого верхнего уровня, проблемы конкретной команды тоже не видит скорее всего.
Итого, как часто? Часто для себя. Сколько времени? Процентов 20-30.