Жёсткие рамки или при чём тут бесконечный скролл

При работе над разными проектами, чаще всего можно встретить два варианта построения процессов: долгие эпики на несколько кварталов (и даже лет) и значительно менее продолжительные спринты с фиксированными фичами.

При таком формате важно избегать состояния scope creep (или же неконтролируемое увеличение масштаба проекта, что особенно часто встречается в начале разработки, бывалые менеджеры проектов поймут о чём речь).

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

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

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

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

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

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

Его имя — Аза Раскин. И именно ему мы должны сказать спасибо (или выразить негодование) за появление бесконечного скролла. Ведь в далеком 2006 году кроме пагинации не существовало альтернативы, и именно благодаря ему пользователи теперь значительно реже ощущают ход времени в ряде запрещённых соцсетей.

Хотелось бы, чтобы разработка все-таки не превращалась в бесконечный скролл, а мы с вами понимали, в какой момент должна быть перевёрнута нужная страница.

😃 iOS Dev