¿Todos los miembros de un equipo ágil deben ser desarrolladores de software?

Recientemente comenzamos a utilizar metodologías ágiles en mi empresa. Como soy bastante nuevo en ágil, me pregunto si nuestra forma de implementarlo es correcta de acuerdo con los principios básicos de ágil.

Anteriormente, teníamos roles como analista de negocios, probador de control de calidad y desarrollador de software. Pero ahora la gerencia ha decidido que estos roles deberían eliminarse y todos trabajarán como desarrolladores de software.

En la práctica, esto significa que un desarrollador de software tendrá las mismas responsabilidades que tres roles separados anteriormente (es decir, un analista de negocios, un probador de control de calidad y un desarrollador de software).

Justifican el cambio con el hecho de que esto es ágil. ¿Es esta la forma en que otras compañías también implementan ágil?

No. Esto definitivamente no es ágil. Tampoco es una buena idea.

Los equipos interfuncionales, es decir, los equipos que incluyen todas las funciones (analista, administrador del servidor, administrador de la base de datos, diseñador de experiencia de usuario, comprobador de control de calidad, escritor técnico, diseñador gráfico) que se necesitan para entregar con éxito el software de trabajo, son un elemento básico de muchas metodologías ágiles. De hecho, en muchas metodologías, el cliente mismo también se considera parte del equipo.

En realidad, esto es ortogonal a ágil, sin embargo. Los equipos multifuncionales son simplemente una buena idea, independientemente de si lo estás haciendo ágilmente o no.

Lo que es cierto, sin embargo, es que con el aumento constante de las pruebas automatizadas, pruebas de desarrollador, basado en pruebas y desarrollo de la conducta impulsada por una parte, y la infraestructura definida por software, altamente automatizado puesta en marcha, configuración y despliegue, DevOps, y alojamiento en la nube, algunas de las cargas de trabajo pueden haber pasado de administradores a ingenieros de DevOps, y de control de calidad al desarrollo. Eso no , sin embargo, que esas funciones se han extinguido. Simplemente significa que el control de calidad tiene errores más interesantes que perseguir porque las pruebas de desarrollador han encontrado todos los triviales, y los administradores se centran más en permitir que DevOps administre la infraestructura con herramientas automatizadas que en administrarla ellos mismos.

Hay una prueba fácil para verificar si algo es ágil: cuando alguien dice "haces esto porque es ágil", entonces no es ágil. Agile se trata de equipos autogestionados que constantemente reflexionan sobre sus procesos y los adaptan. Cada vez que alguien dice "haces esto", entonces no es ágil. Sólo es ágil cuando el equipo dice " nosotros hacemos esto, porque después de reflexionar sobre nuestras experiencias pasadas, hemos determinado que funciona, y vamos a seguir reflejando en ella y dejar de hacerlo tan pronto como se determina que no lo hace."

¿Es así como otras compañías también implementan ágil?

Por desgracia sí. Hay muchas compañías donde Agile es impuesto por la gerencia, o al menos lo que piensan que es Agile (que por supuesto no lo es).

Si mira en la guía Scrum , que probablemente es de donde su gerencia tomó la idea, encontrará esto:

Scrum no reconoce títulos para los miembros del Equipo de Desarrollo que no sean Desarrollador, independientemente del trabajo que realice la persona

Pero la idea de que todos en el equipo sean "desarrolladores" es que sin importar su rol (control de calidad, programador, diseñador, etc.), todos contribuyen al desarrollo de la aplicación, juntos, con igual esfuerzo e igual responsabilidad y responsabilidad. . El programador no es más importante que el probador solo porque escribe el código y el probador solo lo prueba, el diseñador no crea los wireframes y luego desaparece mientras los desarrolladores front-end los implementan. Todos son importantes. Todos contribuyen. Entonces, todos son iguales desde este punto de vista. Los títulos de trabajo no importan. Es por eso que todos son "desarrolladores".

Pero no significa que, de repente, el diseñador comience a hacer la arquitectura de la aplicación o a escribir el código. Y en la misma línea de pensamiento, solo porque ahora son todos "desarrolladores" porque la gerencia lo dijo, no significa que estén haciendo Agile.

Lo que están haciendo es una tontería. Por ejemplo, si hace que un desarrollador de software asuma un rol de control de calidad:

Uno, el desarrollador de software no tiene la experiencia requerida. Es todo lo que se puede aprender, pero yo personalmente comenzaría como ingeniero de control de calidad junior, siendo mucho menos efectivo que hacer un trabajo de desarrollo de software.

Dos, las personas tienen talentos diferentes y toman posiciones donde sus talentos cuentan. Las personas se convierten en desarrolladores de software porque tienen un talento para ello, y otros se convierten en ingenieros de control de calidad porque tienen un talento para eso. Y ambos habrían sido menos buenos en el otro trabajo.

Tercero, si la misma persona realiza tanto el desarrollo de software como el control de calidad, están en conflicto. El control de calidad encuentra problemas que hacen que los desarrolladores de software trabajen más. Los desarrolladores de software, como todos, no les gusta más trabajo. Entonces, ¿qué espera que haga un desarrollador de software que trabaja como QA?

Aunque los orígenes de Agile están en el ámbito del desarrollo de software, los enfoques iterativos del desarrollo han existido desde finales de los años 50 y se utilizaron en los primeros días de la NASA (ver https://en.wikipedia.org/wiki/Iterative_and_incremental_development ). Estos equipos obviamente solo eran ingenieros de software.

Hemos utilizado con éxito varios enfoques ágiles en mis empresas y para el equipo de robótica que mentores. El concepto de sprints, picos y diseño iterativo con épicas generales ha demostrado ser muy exitoso en todo el equipo: software, hardware, CAD, marketing, etc. Para esto no tenemos nada de la infraestructura "DevOps", los niños están haciendo prototipos sencillos y demostraciones de sus aprendizajes en sprints de dos semanas. A partir de ahí, se toman decisiones sobre cómo proceder, pero en el núcleo hay un robot que gradualmente mejora cada sprint. En cuanto al rol, se trata de "desarrolladores de software", "tipo CAD", "constructores" y "divulgación". La mayoría de este equipo NO está involucrado directamente en el software de codificación.

Para mis compañías de software, el equipo generalmente consiste en desarrolladores, probadores, desarrolladores, diseñadores y soporte.

En general, Agile no es una cosa y hay muchos enfoques para implementar la filosofía. Pero en esencia es la idea del desarrollo iterativo, dividir el trabajo en tareas cortas y reevaluación continua. A menudo se usan cosas como reuniones de scrum diarias, trabajos atrasados, historias de usuarios, etc., pero de ninguna manera se requiere que sean "ágiles". Agile se trata de adaptarse constantemente, y eso incluye la forma en que un equipo en particular implementa Agile.

Entonces, respuesta corta: su equipo de administración no entiende que Agile es o está usando esto como algún tipo de justificación para eliminar las cosas que consideran una pérdida de dinero. Puede estar justificado hacer cambios, pero no es porque Agile es solo para programadores.