La mayoría de las empresas siguen algún tipo de proceso Scrum. Típicamente esto implica sprints de 2 o 3 semanas. Al final de cada sprint se demuestran los cambios, se realizan retrospectivas y se prepara el backlog. Durante cada sprint se captura el tiempo de finalización de tareas, lo que permite a la gerencia proyectar hacia el futuro cuándo se completarán los proyectos.
Muchos de los proyectos Scrum en los que he participado enfatizan “comprometerse” con tareas o “asumir la responsabilidad”. Al final del sprint muchos ingenieros son responsabilizados por tareas incompletas. La velocidad del sprint es otra idea que se martillea constantemente. ¡Tenemos que mantener nuestra velocidad! Es como si crear software fuera una carrera, y no lo es. Si los ingenieros son responsabilizados por una métrica, optimizarán para esa métrica, y eso no es lo que quieres.
Scrum crea un marco fácil de entender para que los equipos sigan y proporciona a la gerencia las herramientas para predecir el futuro. Los equipos que han practicado waterfall encuentran que Scrum es fácil de comprender.
Muchas de las prácticas de Scrum no son necesarias. Por ejemplo, la mayoría del software de seguimiento de problemas permite a los gerentes ejecutar informes sobre la frecuencia de finalización de tickets. Con esta información, los gerentes pueden inferir la velocidad, en lugar de incorporar la velocidad en el proceso y convertirla en un gran problema. Asumir la responsabilidad es una farsa, lo hacemos naturalmente, hacerlo explícito es insultante. En todos los proyectos en los que he participado, cada ingeniero tiene un rincón de la aplicación que es su espacio.
Otras formas de mejorar la entrega de software:
- Si necesitas despliegues semanales, programalos. Despliega lo que esté listo.
- Mantén el backlog preparado; así los ingenieros nunca se quedarán sin trabajo.
- En mi opinión, las retrospectivas son la actividad no relacionada con el desarrollo más esencial. Sin ella, no tienes oportunidad de convertirte en una organización mejor y más eficiente.
- Automatiza, automatiza, automatiza
- Comprometerse con una lista de características es ridículo. Clasifica las tareas y completa lo que puedas. Preocuparse por qué la “tarea A” no se completó es una pérdida de tiempo. Es claro que la tarea era demasiado grande, o se asumió trabajo de mayor prioridad.
- Las demostraciones son una pérdida de tiempo a menos que al cliente le importe y proporcione retroalimentación.
- Las reuniones diarias pueden ser necesarias o no. Prefiero reunirme cada par de días.
Al final del día se trata de proporcionar valor al cliente de la manera más eficiente.
Autor: Chuck Conway es un Ingeniero de IA con casi 30 años de experiencia en ingeniería de software. Construye sistemas de IA prácticos—canalizaciones de contenido, agentes de infraestructura y herramientas que resuelven problemas reales—y comparte lo que está aprendiendo en el camino. Conéctate con él en redes sociales: X (@chuckconway) o visítalo en YouTube y en SubStack.