Наиболее частые ошибки планирования¶
Автор раздела: Ivan Zakrevsky
Список ошибок¶
Четыре наиболее частые ошибки планирования, которые мне приходилось наблюдать на практике.
Ложная коммутативность¶
Представители бизнеса зачастую склонны думать, что если выполнить задачи в последовательности "b", "c", "a", то стоимость их реализации будет такой же, как если бы они были выполнены в последовательности "a", "b", "c". На самом деле, стоимость может отличаться кратно, если даже не на порядок, потому что задача "a" может удешевить стоимость реализации последующих задач. Эта ошибка особенно удивительна на фоне того, как много управленческой литературы освещает этот вопрос. Некоторые книги даже включают в себя даже целый раздел управленческой математики, как, например, "Менеджмент: Учебник для вузов." 3-е изд., Глухов В.В.
Особенно хорошо эта проблема освещена в статье "Systems Thinking" by Craig Larman (на русском).
Шахматы - лучшая метафора для опровержения этой иллюзии. В начале игры оба игрока имеют равное количество фигур, но выигрывает только один. Все дело в том, в какой последовательности они двигают эти фигуры.
Вера в то, что техдолг является константной величиной по отношению ко времени¶
Представители бизнеса зачастую склонны полагать, что стоимость исправления техдолга является константной величиной по отношению ко времени, а поэтому, его можно безболезненно отложить. Такие виды техдолга действительно могут иметь место, но это не исключает существования других видов техдолга, где стоимость исправления через пару месяцев может вырасти кратно, если даже не на порядки. Именно этот критерий является ключевым при применении принципа YAGNI.
Вера в то, что накопление техдолга увеличивает стоимость разработки линейно¶
Исходя из предыдущего пункта, у представителей бизнеса нередко формируется иллюзия, что накопление техдолга увеличивает стоимость разработки линейно. Как показывает практика, и как демонстрируют исследования авторитетных авторов в области архитектуры, характер роста стоимости разработки имеет тенденцию приближаться к экспоненциальной зависимости. Статистику конкретного проекта смотрите в "Clean Architecture: A Craftsman's Guide to Software Structure and Design" by Robert C. Martin. В таком случае итеративная (Agile) модель разработки может вообще утратить свою экономическую целесообразность перед спиральными моделями, или даже BDUF. Как уже говорилось, Agile имеет экономическую целесообразность только при пологом характере роста изменения кода.
Зачастую, эта иллюзия подкрепляется отсутствием мониторинга объективных индикативных показателей здоровья проекта, что не позволяет зафиксировать падение экономики разработки на ранних стадиях, в силу особенностей работы человеческого мозга (когнитивных искажений).
Поскольку представители бизнеса склонны руководствоваться краткосрочными бизнес-интересами в ущерб долгосрочным техническим интересам, сбалансированность решений должна гарантироваться процессами, о чем частично упоминалось здесь.
Современные Agile методики имеют тенденцию перестраховки, которая выражена в том, что внутреннее качество программы является вообще константной величиной, а не переменной управления разработкой.
Я согласен с этим лишь отчасти, и только потому, что технические специалисты лучше разбираются в экономических основах разработки, чем представители бизнеса. И тем не менее, есть риск скатиться к "Эффекту второй системы", т.е. к неоправданному оверинжинирингу.
Я все-таки склоняюсь к тому, что сбалансированность решений должна гарантироваться орг.процессами, а решения должны приниматься в сбалансированном кругу стейкхолдеров.
Вера в то, что разработчикам безразлично качество кода¶
На самом деле, никто не хочет работать в "мусорнике", которому иногда может уподобляться код. Код - это рабочее место программиста. И ничто не деморализует разработчиков так сильно, как запрет на собственную компетентность. Об этом говорят многие известные авторы.
Как взять в релиз техническую задачу¶
Один из частых аргументов представителей бизнеса в оправдание дисбаланса решений в пользу краткосрочных бизнес-интересов и в ущерб долгосрочным техническим интересам, звучит примерно так: "покажите, какую бизнес-сторю мы можем выбросить из плана релиза, чтобы вместо неё взять техническую задачу".
Эта ментальная ловушка основана на предположении о постоянстве скорости разработки и коммутативности (переместительности) задач в последовательности их выполнения.
На самом деле, скорость разработки вариативна, и сильно зависит от последовательности выполнения задач.
Технические задачи можно условно разделить на две категории:
Направленные на достижение Modifiability.
Направленные на достижение всех остальных Quality Attributes.
Почему так? Потому что все остальные Quality Attributes достигаются, как правило, путем изменения кода, а значит, находятся в зависимости от Modifiability (я, конечно, немного обобщаю, поскольку есть еще Evolvability, Flexibility, Modularity, Testabilty, Deployability etc.). Кроме того, все остальные Quality Attributes требуют, как правило, каких-то однократных или линейных затрат, в то время как Modifiability имеет тенденцию влиять на стоимость разработки экспоненциально. Утрата Modifiability означает утрату всего.
Итак, перефразируем вопрос. Теперь вопрос не в том, чтобы выкинуть что-то из плана релиза, а в том, "как взять в релиз техническую задачу". Чувствуете разницу? А это зависит от скорости разработки, на которую можно влиять техническими задачами (зачастую - кратно). Как говорится, долго запрягать, но быстро ехать.
Вообще говоря, в хорошо отлаженных процессах технические задачи возникают редко.
Задачи на Modifiability возникают редко, потому что существуют методики, такие как YAGNI, позволяющие сгладить по времени "Design Payoff Line" и минимизировать в краткосрочной перспективе стоимость решения. См. также "Краткий курс по экономике разработки программного обеспечения".
При использовании этих методик, редко возникают технические задачи на Modifiability, которые не окупятся в пределах релиза. Martin Fowler даже советует не говорить менеджерам о таких технических задачах, так как они все равно не затягивают выполнение графика работ.
А задачи на другие нефункциональные требования возникают редко, так как функциональные и нефункциональные требования нужно, по мере возможности, достигать одновременно.
Проблемным в этом вопросе оказывается обычно Scrum, так как он, с одной стороны, имеет тенденцию сосредоточить все полномочия в руках Product Owner (хотя в "The 2020 Scrum Guide™" появилась такая фраза "Adaptation becomes more difficult when the people involved are not empowered or self-managing."), который часто выполняет роль стейкхолдера категории Business, что лишает его нейтральной позиции в пользу краткосрочных бизнес-интересов. А с другой стороны, "The 2020 Scrum Guide™" не допускает техдолга вообще, чем встает на защиту долгосрочных технических интересов.
Иными словами, Scrum, скорее, разогревает противоречия требований различных групп стейкхолдеров, нежели разрешает их. Начинается перетягивание одеяла. Кто кого.
Но вернемся к нашему главному вопросу. Преследование краткосрочных бизнес-интересов в ущерб долгосрочным техническим интересам приводит к положительной обратной связи, т.е. приводит систему в разнос. Об этом хорошо пишется в статье "Systems Thinking" by Craig Larman (на русском).
В таком случае, чем дольше откладывается выполнение технических задач, тем больше падает скорость разработки, и тем меньше остается ресурсов на технические задачи. А в таком случае, если у компании нет ресурсов решить задачу правильно, то решать ее дважды - и подавно не будет.
