Especificaciones ejecutables, acercando negocio y desarrollo

Notas do Editor

1. Hola, gracias por venir. Estáis cansados, largos viajes, es la última sesión del día, os falta azúcar, así que vamos a empezar con un poco de música y unas chuches.Suplanté.Selva de Vietnam.
2. Imaginaos que estáis en un proyecto de mejora del ser humano. Por ejemplo el cliente podría ser el monstruo del espaghetti volador. Hacéis con él una inception.
3. Hacéis un impactmapping.
4. Haceis un userstorymapping. Y todos los mappings que queráis.
5. Y decidís que lo más prioriatario ahora mismo es lavarse los dientes.
6. Esta es la história. La primera C del Card – Conversation – Confirmation. Habláis con el cliente, le preguntáis como quiere que se lave los dientes. Pues mira, se coge un cepillo de dientes, se pone pasta en el extremo, se moja un poco con agua y se frotan los dientes con él. No está mal, he visto historias de usuario mucho menos trabajadas. Ejemplo de indra.
7. Y le hacemos esto. Tu me has dicho que se ponía en un extremo, en el de los pelillos. Pero encima de los pelillos!Esobvio! Es obvio para ti, pero no para mí, no conozco tanto tu dominio.O resulta que quiere que se utilice un oral-b, que es el único cepillo que conoce.Ejemplo de la máquina de coser??
8. Hay un agujero de comunicaciónquepuedehacerque la gente se focalice en cosaspocoimportantes. Trabajar con especificaciones, con historias de usuario no garantizaque el proyecto se entregue con el valor deseado. Tenemosquepreguntar el porqué de lashistórias e involucrar a desarrolladores y testers desde un principio, comunicando los objetivos de negocio a todo el mundo y quitandoobstáculoscomunicativos.
9. Pq los malentendidos cuestan dinero. No hace falta que sean grandes malentendidos, solo detalles. Tenemos que repetir trabajo, el cliente pierde confianza, puede perder una oportunidad competitiva.
10. Pongamos otro ejemplo: el fuera de juego. Una de las más importantes causas de divorcio en España. Estamos viendo un partido de octavos de la champions. Nuestro equipo se enfrenta a uno teóricamente inferior pero el resultado de la ida no nos favorece. A los del Madrid os sonará esto de hace unos años.Estamos nerviosos y en la primera jugada que el árbitro pita fuera de juego nuestra pareja nos pregunta: porqué ha pitado fuera de juego? Hay dos cosas que nos pone muy nerviosos, que nos pregunten por el fuera de juego y que nos vayan preguntando: y este quien es? Así que vamos a la habitación, cogemos el manual del árbitro de la UEFA y se lo pasamos para que lo lea:
11. Me aburro, me duermo, no entiendo nada y te lo sigo preguntando.Llega el descanso, vamos a la cocina.
12. Nos servimos una cerveza y cogemos papel y boli y le vamos explicando.
13. Aquí está la defensa y el delantero está más retrasado: no hay fuera de juego.
14. Aquí está más adelantado: si hay fuera de juego.
15. Aquí está más adelantado pero no interviene en la jugada: no hay fuera de juego.Y así hasta que lo entiende perfectamente. Si en la vida real lo podemos hacer, pq no lo hacemos cuando desarrollamos software?Ahora mismo, los stakeholders, Pos, Bas, cogen ejemplos reales de lo que quieren, y lo transforman en un tocho de documentación que nadie entiende, o que es malentendible. Y después los testers se inventan otra serie de ejemplos para comprobar que eso funciona bien. Y si trabajaramos todos con los mismos ejemplos? No nos iría mejor?
16. Perfecto, pues entonces nuestros Bas, que se junten y que saquen unos ejemplos. ERROR.Gente en un grupohomogéneotiende a tomardecisiones para minimizarconflictos y alcanzar un consenso sin realmentedesafiar o analizarlas ideas puestas a discusión. Si a parte es un grupopequeño, tambiénhabrá los efectos de la presión del compañero y del conformismo.A parte, solo tienen en cuenta su punto de vista.
17. Un grupopequeño y no homogéneo de 5 a 10 personas funcionabien, alcanzando un estadodonde el grupojuntoesmásinteligentequecualquierindividuo del grupo. Son factores clave para alcanzaresto la diversidadcognitiva y la independencia de opiniones.
18. Portanto, losejemplos, tets y requisites son cosasmuyrelacionadasquehablansobre lo mismo. Tenemosqueencontrarunamaneraque los ejemplosaparezcan lo más pronto possible.
19. Más allá del testing, todo esto habla de comunicación, de comunicarnos mejor. Si os fijáis, muchas de las técnicas que existen son técnicas para mantener conversaciones estructuradas, conversaciones que llevan a algún lugar.
20. Otra ventaja que tenemos, muy importante, es que tenemos una documentación viva. No es un papel que nadie cambia. No es una tarjeta que nadie guarda. Es un documento que está íntimamente ligado al código.
21. No son cosas inmutablesNo son material de traspaso entre business análisis y desarrolladoresNo son scripts mecánicos de testsNo son una verificación completa del sistema
22. Release (N-1) -> si se tercia, hacemos reléase de la iteración anteriorAcceptance test clean-up and review (N) -> cerrarpreguntasabiertas.Implementation (N) -> programar los testsPreparing examples (N+1) -> los business analyst puedenempezaratrabajar con los clients y con QA los ejemplos de la siguienteiteración.Retrospectiva (N)Planning (N+1) -> la planning de toda la vidaSpecification workshop -> a partir de los ejemplosescritos en la fase de preparing examples, refinarlos con el equipo de desarrollo.
23. No hagáis cargo cult.
24. Ventajas para la gente de negocio:Los desarrolladores se van a leer las especificacionesLos desarrolladores entenderán las especificaciones correctamentePodemos trackear el progreso fácilmentePodemos identificar fácilmente conflictos en las reglas de negocio
25. Ventajas para los desarrolladores:Los huecos funcionales serán vistos antes del desarrolloLos analistas de negocio realmente entenderán los casos especialesLos tests automatizados serán tus objetivos para el desarrolloEl código será más fácil de compartir
26. Ventajas para los testers:Tendremos un mejor entendimiento del dominioDelegaremos mucho trabajo en los desarrolladoresPodemos construir en calidad desde el principioSeremos capaces de verificar las reglas de negocio “apretando un botón”  Michael Bolton: no acceptance test pero si rejection test.Tendremos mucho más tiempo para experimentarMejoraremos las relaciones en el equipo