Las ideas clave:
- Todos los grupos creen que la interrupción / falta de atención es un problema, y supera a la mayoría de los problemas (Entonces, ¿por qué son tan populares las oficinas abiertas?).
- Los equipos que realizan envíos cada mes o más allá (incluidos los de 3 meses y anuales) ven que los requisitos del producto cambian mientras se trabaja como un enorme desafío, y tienen menos problemas de deuda técnica o subestimaciones que sus pares.
- Los equipos que se embarcan cada día tienen muy pocos problemas con el trabajo de cambio del equipo de diseño, pero con frecuencia tienen problemas con la tecnología (más sobre esto más adelante).
- Los equipos que se embarcan cada semana no reciben amor en ninguna categoría
Fuerzas motrices
Según los gerentes y desarrolladores, Agile fue una gran fuerza motriz para ayudar a los equipos a embarcarse más rápido. Aunque algunos sugirieron que ralentizaba a sus equipos, recibió un apoyo abrumador. Los cierres específicos fueron para Kanban.
Tanto los desarrolladores como los gerentes de desarrollo sugirieron que el uso de nuevos marcos mejoraría su productividad.
Unos pocos desarrolladores se entusiasmaron con los nuevos patrones de diseño que podían usar para construir código, y esta es una postura muy saludable.
Algunos gerentes de desarrollo estaban entusiasmados con la posibilidad de automatizar más trabajo (especialmente en lo que respecta a las pruebas de IU), y con las mejoras de rendimiento en las velocidades de construcción, prueba y despliegue.
Fuerzas de contención
Algunos directivos compartían que el cambio constante de prioridades, la falta de comunicación, las reuniones constantes y la ayuda a los demás eran los mayores obstáculos para su progreso. Los desarrolladores-gerentes atribuyeron a los lentos procesos automatizados, a una mala cultura de desarrollo, a la lucha contra el fuego y a la ayuda a los demás como sus mayores restricciones.
Los desarrolladores fueron los más vocales. El lento proceso automatizado, el cambio de contexto (enfoque), el cambio de prioridades, el exceso de reuniones, la deuda de alta tecnología, los sprints sobrecargados, la adición de requisitos a los sprints existentes, la falta de motivación y el proceso poco claro estaban en su lista de restricciones.
¿Qué significa esto?
El mayor obstáculo parece ser la desconexión entre las percepciones de los gerentes y los desarrolladores.
A medida que el software se mueve a través de su ciclo de vida, comienza con una necesidad, se evalúa en relación con otras prioridades, se explora y se diseña, se desarrolla, se lanza y la gente experimenta su uso. Su proceso probablemente se ve lo suficientemente cerca de esto como para estar de acuerdo en que esto es lo que generalmente sucede, pero obviamente esto no es perfecto y universal.
Existe una teoría (llamada «La Teoría de las Restricciones») que en realidad describe dos escuelas de pensamiento que se utilizan cuando se intenta mejorar la velocidad y la cantidad de trabajo embarcado («throughput»).
- Contabilidad de costos: Centrarse en los pasos individuales de un proceso estando a plena capacidad en todo momento.
- Contabilidad de rendimiento: Concéntrese en el rendimiento total, los pasos individuales no necesitan estar a plena capacidad.
Son radicalmente diferentes, y la contabilidad de costos se siente tan obvia e intuitiva que puede ser una enorme lucha para lograr que su organización la abandone. Es probable que los gerentes individuales reciban incentivos basados en el desempeño de su grupo específico.
Esto puede funcionar en los campos de batalla, pero tal vez no en el desarrollo de software, y sabemos con certeza que esta mentalidad causó el cierre de muchas plantas de fabricación para siempre. El defecto es que los pasos individuales se vuelven competitivos en lugar de colaborativos.
Cuando se consideran los prejuicios humanos, es claramente más que pura coincidencia que los gerentes piensen que los cuellos de botella son más severos en el lado de los negocios, y los desarrolladores piensen que es más severo en el lado de la tecnología. Ambos observadores atribuyen el problema a lo que están más expuestos. El software no es el único lugar en el que esto ocurre: es un defecto humano.
En pocas palabras: no podemos confiar en nosotros mismos, a escala.
Sin datos, alguien que pueda identificar correctamente un problema debe ser capaz de: a) identificar correctamente los artefactos, b) recordar correctamente los hechos pertinentes, c) recordar perfectamente los hechos, d) tener un razonamiento y una interpretación correctos, e) no estar influenciado por la sugerencia de sus pares, f) no estar influenciado por las tendencias sociales, y g) la autoimagen/confianza no es un factor.
Una de las mayores fallas humanas en el proceso de planificación se llama «Aversión a las pérdidas». Puesto en términos simples, todos sabemos que el conductor promedio de un auto siente un fuerte dolor emocional cuando el precio de la gasolina sube un 5%, pero una sonrisa más mundana cuando baja un 5%.
Puesto en términos de desarrollo de software, puede parecer que estamos ganando algo cuando no tenemos en cuenta el control de calidad porque podemos enviar más rápido. O tal vez no nos ponemos a trabajar en el diseño y el alcance del proyecto porque le quitaría mucho tiempo a los desarrolladores para escribir el código. La NASA publicó un informe que describe cómo este tipo de proceso aumenta el precio pagado para resolver un defecto.
En pocas palabras: no podemos confiar en nosotros mismos, a escala.
Avanzando
A medida que avanzamos es importante darse cuenta de que nuestras perspectivas individuales son demasiado estrechas para identificar correctamente el problema. Con una perspectiva más amplia podemos identificar los verdaderos cuellos de botella y procesos defectuosos. Si no sabes qué está mal, no sabes qué cambiar. Y si no puedes cuantificar dónde estás, ¿cómo sabrás que has mejorado?
Estamos inmediatamente predispuestos. Por ejemplo, muchos desarrolladores que se embarcan diariamente indicaron que su proceso de construcción se interpuso en su camino. ¿Es probable que estas salvaguardias y procesos retrasen el rendimiento total de la empresa, o es probable que estos procesos eviten los fallos en la producción (que se sabe que son órdenes de magnitud más caros y retrasan el rendimiento total).
Bueno, sin datos reales, nunca lo sabrás.
Los datos significativos atraviesan la política de la oficina y la subjetividad, y eliminan las conjeturas del éxito.
La ingeniería de software es difícil de medir, y las métricas fáciles de comprender son injustas o sólo métricas de vanidad. Pero eso no significa que debamos levantar las manos y rendirnos.
Como Peter Drucker observó famosamente, «Si no puedes medirlo, no puedes mejorarlo». Sin datos estamos atascados en la oscuridad con suposiciones y opiniones.
Los datos significativos pueden y deben ser utilizados para responder a preguntas como:
- ¿Los cambios en nuestro proceso mejoraron las cosas?
- ¿Estamos puliendo un rasgo hasta la muerte a costa del envío?
- ¿Cómo afectan a la productividad las reuniones de todos los miércoles?
- ¿Qué ingenieros causaron el mayor impacto el mes pasado?
- ¿Cuánto se quemó para pagar la deuda técnica?
Los datos significativos atraviesan la política de la oficina y la subjetividad, y eliminan las conjeturas del éxito.
Brian Graham es el fundador del Grupo Stata, que ayuda a los equipos de ingeniería a enviar más software, más rápido. Sus experiencias cubren años de desarrollo de pila completa, participación en código abierto y construcción de comunidades. Siga a @BrianGrahamDev en Twitter.