Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Eliminando la brecha entre clientes y desarrolladores mediante BDD

3,001 views

Published on

Muchos, si no la mayoría, de los problemas o fracasos en proyectos de desarrollo de software se debe a que clientes y equipos de implementación de aplicaciones sencillamente no se entienden porque ven el mundo de manera muy distinta, hay una brecha entre ambas partes, dificultando materializar los requerimientos en software que realmente aporta valor para el negocio.

La metodología ágil BDD (Behavior-Driven Development) tiene precisamente el objetivo de lograr que ambas partes, cliente y equipo de desarrollo, en un proyecto se comuniquen de manera efectiva, ayudando a los primeros a especificar de manera sencilla y clara sus requerimientos, y a los segundos a entregar software que realmente cumple esas expectativas.

Tomando muchas de las buenas prácticas de desarrollo ágil de software y Lean, BDD fomenta y facilita la colaboración entre los miembros de diferentes roles, así como la integración de todas las etapas del proceso de desarrollo de software de tal manera que, aun escribiendo código fuente, nunca se pierda la referencia y conexión con las especificaciones del cliente, asegurando que el producto que se entrega coincide con ellas, es de calidad y, como un beneficio adicional, queda soportado por pruebas automatizadas.

Esta sesión mostrará, tanto a gente de negocios (gerentes de proyectos y analistas de negocios), como a gente técnica (especialistas en QA, arquitectos y desarrolladores de software), como aplicar BDD para obtener todos sus beneficios a la vez que hacen más felices a sus clientes con un proceso más eficiente y mejor producto.

Published in: Technology
  • Be the first to comment

Eliminando la brecha entre clientes y desarrolladores mediante BDD

  1. 1. Eliminando la brecha entre clientes y desarrolladores … mediante BDD (Behavior-Driven Development) para especificar e implementar mejor softwareJorge GambaConsultor en Arquitectura y Desarrollo de SoftwareWeb: http://jorgegamba.comTwitter: @jorgegambaCorreo: contacto@jorgegamba.com
  2. 2. Eliminando la brecha entre clientes y desarrolladores … mediante BDD (Behavior-Driven Development) para especificar e implementar mejor softwarehttp://altnethispano.org/ http://agilescolombia.org/ http://mcscolombia.org/
  3. 3. Eliminando la brecha entre clientes y desarrolladores … mediante BDD (Behavior-Driven Development) para especificar e implementar mejor softwareAgenda : Por qué Qué Cómo
  4. 4. Por qué (BDD)
  5. 5. Las mujeres son de Venus Los hombres son de Marte
  6. 6. Los clientes son de Venus Los desarrolladores son de Marte
  7. 7. ¿ Y cuál es el problema ?
  8. 8. No me cumplistecomo yo quería ¿ Y cuál es el problema ?
  9. 9. No me Pero ¿quién cumpliste te entiende?como yo quería ¿ Y cuál es el problema ?
  10. 10. No me Pero ¿quién cumpliste te entiende?como yo queríaNunca cumplescon los tiempos esperados ¿ Y cuál es el problema ?
  11. 11. No me Pero ¿quién cumpliste te entiende?como yo queríaNunca cumplescon los tiempos Ayer lo querías esperados de una manera y hoy de otra ¿ Y cuál es el problema ?
  12. 12. El problema es: Comunicación …Nodjfhdjhfjdhfdhfjdhjfd se están entendiendo [los requerimientos]
  13. 13. El teléfono roto Core / Business Incidental Stakeholders Stakeholders (ejecutivos) (usuarios)ClienteEquipo de Desarrollo Business Analysts Desarrolladores (BAs) (Devs) QAs (Testers)
  14. 14. Qué (BDD)
  15. 15. Desarrollo Ágil de Software
  16. 16. Agile es acerca de … minimizar el tiempo para obtener feedback
  17. 17. http://agilemanifesto.org/iso/es/
  18. 18. “Behaviour-driven developmentis about implementing an applicationby describing its behaviourfrom the perspective of itsstakeholders” http://dannorth.net/
  19. 19. “BDD is a second-generation, outside-in, pullbased, multiple-stakeholder, multiple-scale, high-automation, agile methodology.“It describes a cycle ofinteractions with welldefinedoutputs, resulting in the deliveryof working, tested softwarethat matters.” http://dannorth.net/
  20. 20. ATDDTDD BDD DDD
  21. 21. Cómo (BDD)
  22. 22. El ciclo• Outside-In• Pull-based• Fractal• Decomposition• Deriving scope from goals http://www.infoq.com/articles/pulling-power
  23. 23. Divide yvencerás http://www.infoq.com/articles/pulling-power
  24. 24. • Factor diferenciador • Se hace software por – Hacer dineroBusiness Value – Ahorrar dinero – Proteger dinero • Core Stakeholders
  25. 25. “Aumentar las ventas y controlar la cartera enun estado saludable”
  26. 26. • Todo proyecto necesita una única visión, de un mejor futuro – Por qué es importante – Qué esperamos lograrBusiness Value – Cómo se reconocerá el logro Vision • Debe ser transmitida al equipo • Es la definición general de “Done” • Es el mayor punto de referencia • Core Stakeholders
  27. 27. MyCRM dará a la organización un control que no se tieneactualmente, al proporcionar información valiosa que serviráde soporte para la toma de decisiones y definición deestrategias para proteger nuestro patrimonio.Esto mediante proporcionar herramientas de capturaefectiva de información útil, analizándola y reportandoindicadores que permitan evaluar el estado del negocio.
  28. 28. • Lo que necesitamos para implementar la visión • Son Stories muy grandes para manejar y estimar, deben ser divididas Feature SetsVisión • Pueden corresponder con los (Epics) subsistemas de la aplicación • Se deben mantener en un alto nivel de abstracción • Incidental Stakeholders
  29. 29. Para contar con información Para tomar mejores Para diseñar mejoresque podamos evaluar decisiones en el tratamiento estrategias de cobroComo un gerente de de clientes Como un gerente dedepartamento comercial Como un asesor comercial departamento de carteraYo quiero capturar Yo quiero que el sistema me Yo quiero disponer deinformación comercial de los proporcione información reportes que me detallen elclientes sobre cada cliente estado actual de la cartera
  30. 30. • Es una manera de capturar y describir una feature del sistema, algo que el usuario quiere • Constituye una unidad deFeature Sets entrega, algo que habrá que Stories implementar • Debe ser tan pequeña como sea posible sin perder significado para el negocio • Business Analysts (BAs)
  31. 31. Para realizar una venta ágil y Para no poner en riesgo la Para concretarsin demoras cartera de la empresa oportunamente una ventaComo un asesor comercial Como un asesor comercial Como un asesor comercialYo quiero disponer Yo quiero saber si le puede Yo quiero registrar los datosinformación detallada sobre vender a crédito a un cliente de una venta potencial olos artículos en venta según su endeudamiento efectiva
  32. 32. • Constituyen o detallan los criterios de aceptación • Son ejemplos, así de sencillo • Deben incluir contexto, acciónStories Scenarios y verficación • Given / When / Then • Se pueden automatizar • Qas / Testers [ + Bas + devs]
  33. 33. Dado que el cliente no es Dado que el cliente es moroso Dado que el cliente es morosomoroso Y no excede su límite de Y excede su límite de créditoCuando solicite comprar a crédito Cuando solicite comprar acrédito Cuando solicite comprar a créditoEntonces debería aprobarse crédito Entonces debería negarse Entonces debería aprobarseY mostrarle el nuevo cupo Y debería informarse la causa Y mostrarle el nuevo cupo
  34. 34. • No son scripts, son especificaciones • Son mejores que la documentación tradicional – Especifican qué hay que hacer – Pruebas de aceptación y regresiónScenarios Executable – Documentación dinámica Specifications • Son el artefacto más durable en el proyecto • Son tan confiables como el código pero más legibles • Devs (desarrolladores)
  35. 35. Beneficios• Win-Win• Clientes felices• Equipo feliz• Calidad• Menos bugs• Documentación• Pruebas• Etc. http://www.infoq.com/articles/pulling-power
  36. 36. Referencias• Dan North - http://dannorth.net/• Liz Keogh - http://lizkeogh.com/• Jorge Gamba  - http://jorgegamba.com/• Skills Matter - http://skillsmatter.com/• InfoQ - http://www.infoq.com/
  37. 37. ¿ Preguntas ?
  38. 38. Jorge GambaConsultor en Arquitectura y Desarrollo de SoftwareWeb: http://jorgegamba.comTwitter: @jorgegambaCorreo: contacto@jorgegamba.comhttp://altnethispano.org/ http://agilescolombia.org/ http://mcscolombia.org/

×