Últimamente he estado pensando mucho sobre cómo construir un equipo de desarrollo eficiente. En última instancia, me gustaría abrir mi propia pequeña casa de software con un pequeño número de personas de ideas afines. El objetivo no será hacerse rico, sino tener un ambiente de trabajo saludable.
Hasta ahora, estoy definiendo un equipo esbelto de la siguiente manera:
- Pequeña;
- Autoorganizado;
- Todos los miembros deben tener QA en mente;
- Los miembros deben ser capaces de realizar múltiples roles.
El último punto es donde estoy un poco preocupado porque, como dice el mantra ...
Los desarrolladores hacen malos probadores.
Si bien entiendo que, a menudo, los desarrolladores están "demasiado cerca" de su código o del código de su colega para hacer evaluaciones de calidad de nivel superior, no estoy convencido de que sean de hecho probadores malos. Por el contrario, soy de la opinión de que las cualidades de un buen desarrollador se superponen en gran medida con las cualidades de un buen probador.
Asumiendo que esto es correcto, he estado pensando en diferentes formas de solucionar el problema del desarrollador / evaluador y creo que he encontrado un modelo viable.
Mi modelo requiere:
- Una pequeña casa de software con más de 2 proyectos.
- Un enfoque ágil (iterativo) para el desarrollo y la entrega
- 1 equipo por proyecto
- Todos los miembros del equipo serán desarrolladores de software
- La descripción de su trabajo indicará claramente el desarrollo , el aseguramiento de la calidad , las pruebas y la entrega como responsabilidades.
Si se han cumplido todas estas condiciones previas, los proyectos se pueden organizar de la siguiente manera (este ejemplo se referirá a dos proyectos, A y B ):
- Cada miembro del equipo alternará entre el rol de desarrollador y el rol de probador
- Si un miembro del equipo es un Desarrollador en el proyecto A , será un Probador en el proyecto B
- Los miembros trabajarán en sólo el 1 proyecto a la vez, y por lo tanto se espera que esté actuando como tampoco una Dev o un probador.
- Un ciclo de roles consiste en 3 iteraciones como Dev y 2 iteraciones como Tester (nuevamente, en dos proyectos diferentes)
- Los equipos del proyecto tendrían 3 desarrolladores y 2 evaluadores en todo momento.
- Los ciclos de roles de los miembros deben estar desfasados por 1 iteración.
- Esto minimiza la brusquedad de los cambios del equipo. Para cada iteración, 2 Devs y 1 Tester permanecerán igual que la iteración anterior.
Dado lo anterior, veo los siguientes Pros y Contras:
Pros
- Distribuye conocimiento del proyecto en toda la empresa.
- Asegura que los miembros del equipo no estén probando el código que ayudaron a escribir.
- Los ciclos de roles fuera de fase significan que ningún proyecto tiene un cambio de 100% de miembros.
- Alternar roles rompe la monotonía de los proyectos aburridos.
Contras
- Las iteraciones de ambos proyectos están estrechamente relacionadas. Si un proyecto cancelara una iteración a mitad de camino y comenzara de nuevo, entonces los dos proyectos no estarían sincronizados. Esto dificultaría la gestión del ciclo de roles.
- Las bisagras en la contratación de desarrolladores también trabajan como probadores.
Recibí críticas mixtas cuando discutí este enfoque con amigos y colegas. Algunos creen que pocos desarrolladores querrían alternar roles como este, mientras que otros me dicen que personalmente les encantaría probarlo.
Entonces mi pregunta es: ¿podría un modelo así funcionar en la práctica? Si no es así, ¿podría modificarse en un modelo de trabajo?
Nota: En aras de la brevedad, solo me he centrado en los roles de Dev y Tester. Expandiré otros roles si es necesario.
fuente
Respuestas:
No estoy de acuerdo con
La mayoría de los equipos en los que he trabajado en mi carrera no han tenido ningún soporte de control de calidad. Esto incluye un par de grandes corporaciones globales que involucran productos como su sistema global de inicio de sesión y registro. En otro caso, tenía el 30% de los ingresos de la compañía a través de una caja en mi escritorio. (Estas prácticas no se recomiendan BTW;)) Estas empresas dependían de los ingenieros para asegurarse de que su código funcionaba correctamente. Y nosotros, orientados a los detalles, un poco compulsivos y orgullosos de nuestro trabajo, haríamos todo lo posible para asegurarnos de que nuestro software funcionara correctamente.
Además, como desarrollador, realizo muchas más pruebas que los Testers. De forma rutinaria, pruebo mi código al 90% o al 100% si no estoy trabajando con Java.
Me gusta trabajar con probadores porque lo hacen desde una perspectiva diferente y captan cosas en las que no pensé. Pero realmente no cuento con ellos para proporcionar más de aproximadamente el 30-50% de cobertura de prueba, mientras me considero responsable del 100%. (Por cierto, eso no es un golpe para ellos, generalmente se extienden por todos los proyectos).
En lugar de preguntar a los ingenieros en las entrevistas si quieren hacer un control de calidad, pregunte: si aparece un error en la producción, ¿quién es el responsable? Si presento un error y un cliente lo experimenta, me siento mal y asumo la responsabilidad. No culpo a los chicos de QA. En mi humilde opinión, ese es el tipo de ingeniero que desea contratar (y trabajar)
Mi método para garantizar la calidad es a) pruebas de unidad súper agresivas (aunque no puedo hacer un desarrollo completo basado en pruebas), b) un proceso de revisión de código sólido realmente ayuda, yc) integrar una intolerancia e impaciencia con defectos en la cultura del equipo.
Siempre me llamó la atención que los tipos más veteranos eran los más diligentes y atentos incluso a problemas menores, porque podían señalar un problema mayor. Pero principalmente fueron los más dispuestos a pasar el tiempo para hacerlo bien.
Pero la mayoría de los equipos en los que he trabajado, especialmente para pequeñas empresas, no han tenido un componente formal de control de calidad.
fuente
Estoy de acuerdo con la respuesta de @Rob Y, y me gustaría agregar algunos puntos:
En los probadores ágiles y dedicados dentro de un equipo son un antipatrón, porque obligan a los equipos a canalizar el trabajo y son inherentemente ineficientes. Constantemente terminas con historias que están "desarrolladas" pero no probadas. Los evaluadores dedicados están bien si trabajan fuera del equipo (o un equipo separado).
Dev hace malos probadores ... y los probadores hacen malos probadores. El control de calidad es difícil. De hecho, es muy difícil. Su problema podría no ser personas y roles. Su problema puede ser que su software se apresure. Nuevamente, en ágil, es responsabilidad de su equipo probar antes de la producción (si tienen un control de calidad dedicado o no).
El control de calidad forma parte del desarrollo, como la refactorización, la arquitectura, etc. Es responsabilidad de un equipo de desarrollo producir software con un estándar determinado, realista y acordado. Los QA no mejorarán ese estándar. Los mejores desarrolladores probablemente lo harán.
Provocación: ¿Quién dice que los QA son mejores que los desarrolladores en QA-ing? Es algo que la gente dice pero ... [cita requerida]. La mentalidad de "hacker" necesaria de QA es una mentalidad de desarrollador. De hecho, básicamente todos los hackers son o fueron desarrolladores, no QA ...
Provocación 2: el 99% del trabajo de control de calidad puede ser (y, me atrevería a decir, debería ser ) automatizado mediante scripts. Un buen equipo hará esto, y para hacerlo correctamente necesita ... desarrolladores.
fuente
En un trabajo anterior, solo teníamos desarrolladores y no personal de control de calidad. Como resultado, no había nadie más a quien culpar si un problema llegaba a la producción. Nos tomamos muy en serio nuestras responsabilidades de control de calidad y confiamos en gran medida en los conjuntos de pruebas automatizadas. Dado que escribir pruebas automatizadas sigue siendo codificación, no fue un gran problema lograr que los desarrolladores lo hicieran.
La clave es hacer que sea parte de la cultura del equipo y parte de cada proyecto. Escribimos planes de prueba (solo breves listas de pruebas que teníamos la intención de escribir para un proyecto), y otros desarrolladores revisarían y sugerirían casos y escenarios que nos habíamos perdido.
Si eres riguroso al respecto, puede funcionar muy bien. Lo hizo para nosotros: tuvimos un excelente tiempo de actividad y pocos defectos en un servicio web de comercio electrónico siempre activo.
fuente
Primero una advertencia: he trabajado profesionalmente como ingeniero de control de calidad e ingeniero de software.
Todo es posible.
Depende de qué tipo de prueba necesite. Si necesita pruebas manuales repetitivas, monótonas y adormecedoras para asegurarse de que cada pantalla o elemento se haya traducido realmente a Elbonian ... tendrá problemas.
Y en mi experiencia, cada proyecto requiere al menos un poco de este tipo de pruebas (incluso si no todos los proyectos hicieron ese tipo de pruebas). El problema es que no recibe este tipo de pruebas de personas que no están familiarizadas con las mejores prácticas de control de calidad. Demonios, ni siquiera lo obtienes de personas que conocen las mejores prácticas, sino que "confías" en los desarrolladores.
Como probador, no puedes confiar en los desarrolladores. Perdí la cuenta de los errores y descubrí que "no podría haber sido causado por ese cambio" o "funciona perfectamente bien en mi caja de desarrollo".
Incluso si puede encontrar desarrolladores que toleren no hacer lo que les gusta hacer 2 de cada 5 semanas, también se encontrará con esta contradicción central. Peor aún, está gastando tiempo y energía para capacitar a las personas para que sean buenos en dos trabajos en lugar de uno. A las empresas les resulta bastante difícil encontrar y capacitar a personas buenas en un solo trabajo, y mucho menos en dos.
Tal vez eres increíble de alguna manera que aún no he encontrado, pero lo dudo.
fuente
Creo que podría funcionar, pero hay un par de cosas que me aseguraría de que hagas.
Sincronizar proyectos no parece una solución práctica. Si alguien es un probador en un proyecto, puede ser el mejor candidato para reemplazar a un programador y viceversa.
Este plan no permite que los equipos se autoorganicen lo suficiente. Una estrategia probablemente no se ajuste a todos los equipos y todos los proyectos.
fuente