Mostrando las entradas con la etiqueta atdd. Mostrar todas las entradas
Mostrando las entradas con la etiqueta atdd. Mostrar todas las entradas

domingo, febrero 21, 2016

Equipos Scrum: El equipo es multifuncional, no los team members polivalentes



Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:
  • a verificar el producto,
  • a aprender de estrategia de pruebas
  • a buscar lo que no se ha perdido, 
    • es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
    • adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
    • Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
  • a pensar como usuario
  • entre otras fortalezas de un buen tester
Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:
  • el equipo: pues le reclamarán tempranamente por habilidades que no tiene
  • el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
  • el scrum master: le dirán que por que no removió este impedimento oportunamente
  • el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
  • la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.


Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:
  • Desarrolladores de software
  • Tester
  • Tester automatizador (depende del proyecto y producto)
  • Base de datos (depende del proyecto y producto)
  • Diseñador gráfico  (depende del proyecto y producto)
Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

  •  los testers se apoyan en sus compañeros de desarrollo para probar, 
  • o que desarrolladores enseñan a testers a programar,
  • expertos de bases de datos y desarrolladores
  • etc
 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.



Saludos ágiles
Jorge Abad.



Notas y Aclaraciones:

  • (1) Guía oficial de Scrum (clic aquí)
  • (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores

domingo, agosto 31, 2014

Software funcionando sobre....¿pruebas exhaustivas e intensivas?

Siempre me he mantenido en algo que aprendí de tantas conversaciones con mis amigos y compañeros haciendo software, y de la experiencia:

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y NO AL CONTRARIO

igual se podría leer en el contexto organizacional

LA CALIDAD 
Y/O PROCESOS DEBEN TRABAJAR PARA LA ORGANIZACIÓN Y NO AL CONTRARIO 


En Agile damos prioridad a software funcionando, pero es necesario hacer pruebas, ¿cuántas?¿cuáles?, la repuesta es: todas y cada una que le permitan entregar un software funcional y de valor, de modo que usted no pierda la tranquilidad y el sueño luego de terminar su jornada laboral, léase entonces:

  • pruebas par
  • pruebas unitarias
  • pruebas funcionales
  • pruebas de integración
  • pruebas de seguridad
  • pruebas de compatibilidad
  • pruebas de adaptabilidad 
  • pruebas de instalabilidad..
  • pruebas de stress
  • etc
  • etc
  • etc
Pero cuantas y cuales..vuelvo y lo repito  LAS NECESARIAS ni una más, ni una menos.

A que se refiere esto, por ejemplo dentro de las prácticas ágiles se encuentran:
  •  TDD : Test driven development - desarrollo dirigido por las pruebas
  • ATDD: Aceptance test driven development - desarrollo dirigido por las pruebas de aceptación
Y hablamos de cobertura (cuantas pruebas aseguran nuestro código).

Sobre lo que quiero llamar la atención es:
  • NO ES NECESARIO cubrir todo el código con pruebas unitarias (ejemplos los POJO, DTO, o VO no lo requieren), solo objetos que tengan lógica de negocio (es mi humilde recomendación, ahora si a tu equipo esto le agrega valor, lo acepto y difiero respetuosamente).
  • Ni es estratégico  volcarse a una cobertura de 100% de pruebas sobre el código.

Nuestro objetivo es proveer software funcional, las pruebas nos ayudan a hacer software funcional pero como tal:
  • Las pruebas no son un entregable que agregue valor al cliente, me explico, si hacemos pruebas o no al cliente no le interesa, a el solo le interesa que funcione y no falle..
  • Las pruebas codificadas se convierten en una pieza de código más para mantener
    • incluir en el servidor de integración continua
    • hacerle refactor
    • corregir,
    • adaptar,
    • etc
Por lo tanto,  hagamos las pruebas suficientes para estar tranquilos y que nos aseguren ENTREGAR SOFTWARE DE CALIDAD.


LA CALIDAD NO ES NEGOCIABLE...

Pero 

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y el no software para cumplir con tdd del 100%, atdd del 100%, etc, etc.



Saludos ágiles
Jorge Abad

miércoles, febrero 20, 2013

Conferencia: La complejidad de lo simple - Jorge Valderrama - Universidad Eafit

Una excelente conferencia donde se evidencia el resultado de trabajar metodologías ágiles



El listado de las herramientas mencionadas es el siguiente:


  • git repositorio
  • jenkins servidor de integracion continua
  • maven/gradle herramientas de build
  • spock/cucumber bdd
  • geb pruebas funcionales
  • grails es el framework
  • confluence
  • jira tracking actividades
  • servidor web apache
  • web container jboss
  • tenemos un servidor cache varnish
    fit para atdd