Experiencia en Curso de Certified Scrum Developer (CSD)
Antecedentes
Anteriormente había tomado el curso de Certified Scrum Master (CSM) de la Scrum Alliance con la finalidad de ampliar mis horizontes hacia esta nueva tendencia cada vez más creciente del desarrollo ágil. Lo que obtuve (además de la certificación) fue una respuesta convincente hacia muchos de los problemas actuales en los proyectos de software, que tradicionalmente buscan construir productos de software en entornos altamente cambiantes con metodogías muy rígidas, que se traducen en retrasos, costos añadidos y en el peor de los casos en la cancelación del proyecto.
Si bien obtuve una visión general de la metodología Scrum, fue desde el punto de vista de uno de los roles de esta (Scrum Master), quien básicamente es un facilitador y coach del equipo por así decirlo, fue entonces que tuve curiosidad acerca del rol de un desarrollador ágil dentro del marco de trabajo Scrum, razón por la cuál decidí tomar el curso de Certified Scrum Developer celebrado en la Ciudad de México los días 16 al 20 de Febrero 2015 (Cabe señalar que como ya contaba con certificación de Scrum Master, tuve la opción de sólo tomar el módulo 3 del curso que consistio en 3 días del 18 al 20). El curso fue impartido por Luis Mulato de Kleer y traido hasta nuestro país gracias los esfuerzos de Scrum México.
La experiencia de trabajo durante el curso
Sinceramente fue el curso más interactivo y dinámico al que he asistido (hasta la fecha), básicamente no habia tiempo para “aburrirse” o “distraerse” ya que siempre nos encontrabamos realizando algo en un marco de tiempo definido (Time boxes), y eventualmente los mismos participantes realizabamos ciertas rutinas de manera automática sin que se nos indicara verbalmente realizar la acción, fue muy interesante apreciar este comportamiento de personas con las que realmente jamás habia visto y trabajado antes, por lo que la integración con las mismas en el curso fue dandose de manera natural y gradualmente nos convertimos en un equipo Scrum.
Lo que aprendí durante el curso CSD
En resumen:
Para poder llevar a cabo de manera efectiva un proyecto ágil básado en Scrum, no sólo es necesario conocer Scrum y realizar las ceremonias de la misma, también implica cambiar la forma en que desarrollamos el producto, con prácticas y herramientas que nos permitan entregar valor mediante productos potencialmente entregables y debidamente probados; para lograrlo es recomendable emplear nuevos paradigmas/prácticas de desarrollo como Test Driven Development (TDD), Acceptance Test-Driven Development (ATDD) e Integración continua, que es parte medular del curso de CSD.
En Detalle:
El curso estuvo enfocado fuertemente en las pruebas y su automatización, por lo que antes de entrar en detalle considero pertinente mencionarlas:
Pruebas de Sistema: Suelen ser a nivel sistema y lo recorren parcialmente o en su totalidad, con la intención de validar un flujo de trabajo o proceso dentro de la aplicación.
Pruebas de Integración: Como su nombre lo indica, son las encargadas de verificar la integración de diferentes componentes de la aplicación. Deben poder ser repetibles (poderse ejecutar multiples veces sin cambiar el comportamiento de la aplicación) y rápidas.
Pruebas Unitarias: Suelen probar porciones de código (por ejemplo el Modelo) de una funcionalidad en especifico y deben cumplir el principio FIRST:
- Fast (Rápida): Pues deben ejecutarse en fracciones de segundo.
- Independent (Independiente): Ya que una prueba no depende de otra.
- Repeteable (Repetible): El estado del sistema no debe ser alterado en cada prueba, por lo tanto debe poderse repetir de manera consistente.
- Self-contained / Simple / Small (Autocontenida, Simple, Pequeña): Prueban la minima cantidad de funcionalidad posible que conduce al resultado; no debe de verificar varias cosas a la vez.
- Timely: Deben ser escritas en el momento justo, y este es antes de escribir el código.
Pruebas Funcionales: Sirven para comprobar cierta funcionalidad del sistema en particular. Tradicionalmente este tipo de pruebas las hacemos de manera artesanal (cuando ejecutamos y probamos nuestra aplicación), sin embargo no es muy recomendable abusar de ello, ya que consumen tiempo considerable.
Pruebas de Aceptación: Describen la funcionalidad esperada de la aplicación, suele estar escrito en lenguaje común y mediante el uso de herramientas automatizadas es posible interpretarlo y ejecutarlo, en Scrum normalmente estas son proporcionadas por el Product Owner (aunque bien puede ser asistido por algún miembro del equipo para esta labor). Para el presente curso se utilizo la herramienta Cucumber.
TDD (Test Driven Development)
Como su nombre lo indica, es una metodología de desarrollo basada en pruebas, en primera instancia puede sonar curioso decir que primero se prueba y luego se programa, sin embargo conforme vas entendiendo esta metodología logras comprender que de esta forma logras controlar los errores introducidos en la aplicación, es decir, sabes que fallará y por qué fallará, y procederás a arreglarlo para que funcione, para posteriormente realizar una refactorización del código, y el ciclo se repite continuamente (este ciclo se conoce como RGR: Red-Green-Refactor). Durante la sesión de CSD prácticamos con esta metodología realizando pruebas unitarias sobre el modelo gracias a la herramienta rspec.
Una forma de estructurar las pruebas es mediante AAA:
- Arrange: Definimos todos los prerequisitos de la prueba (llamar a una clase, inicializar alguna variable).
- Act: Ejecutamos la prueba.
- Assert: Verificar que el resultado sea el esperado.
ATDD (Acceptance Test Driven Development) / BDD (Behavior Driven Development)
En todo desarrollo, un punto muy critico es que debemos construir lo que el usuario espera, parece lógico, pero en ocasiones puede darse el caso de que al no estar validado por el usuario, entendamos las cosas desde otro punto de vista y por lo tanto la aplicación a desarrollarse no cumplira con la funcionalidad requerida por el usuario, representando gastos de tiempo y recursos adicionales que pueden haberse prevenido. Es aquí donde realizar ATDD tiene sentido, ya que tiene la finalidad de comprobar que estamos construyendo la funcionalidad esperada y lo interesante de estas es que pueden construirse fácilmente a partir del lenguaje común a través de historias de usuario.
Durante el curso fue utilizada la herramienta cucumber con la finalidad de realizar pruebas de aceptación automatizadas.
Integración Continua
La integración continua no es una herramienta, sino más bien una forma de trabajo (que hace uso de herramientas), donde a través de repositorios centrales el código es continuamente actualizado por todos los miembros del equipo (al menos 1 commit al día). Es importante destacar que para mejores resultados, cada vez que se envie información al repositorio, este debe estar debidamente probado (funcionando) por TDD y ATDD; también, de manera rutinaria antes de comenzar a trabajar cada día, se recomienda sincronizar la copia local del código con la del repositorio.
Xtreme Programming (XP)
El curso incorporo varias dinámicas siguiendo los principios de la programación extrema, por ejemplo trabajamos en pares sobre el código, con una dinámica de piloto-copiloto, con cambios continuos entre la persona que tenía el teclado en ese momento (piloto) y la que apoyaba (copiloto); incluso hasta simulamos cuando una persona se iba del equipo (un integrante de otra pareja venia a sustituir a nuestro compañero), con la finalidad de representar cuando una persona abandona el proyecto y es contratado nuevo personal que necesita integrarse al proyecto.
Menciono algunas prácticas de interes de XP:
Entregas Pequeñas: Donde el equipo busca entregar la minima funcionalidad requerida que aporta valor de negocio, con fines de evalución con miras a producción.
Pruebas del cliente: Cada funcionalidad a desarrollar es realizada en conjunto con el cliente, donde se comprueba que esta funcione de manera correcta y este completa.
Diseño simple: La funcionalidad es realizada de manera simple con el objetivo primordial de proporcionar valor de negocio al cliente. Funcionalidades extras pueden ser agregadas posteriormente durante el ciclo de vida iterativo de desarrollo. Esto es importante, ya que no debemos desarrollar por nuestra cuenta funcionalidad no solicitada por el cliente.
Equipo completo: El cliente se integra con un equipo de desarrollo con personas de diferentes habilidades, en equipos sin experiencia es altamente recomendable incluir un rol de coach.
Juego de la planificación: Existe un plan de entregas aproximado, pero al ser un desarrollo incremental donde el cambio es bienvenido, en cada iteración se comenta con el cliente la funcionalidad a incluir durante la siguiente iteración. De esta manera aunque tengamos un plan inicial, el desarrollo es flexible y siempre se guía de acuerdo a lo que aporte más valor al cliente en ese momento.
Programación de a pares: 2 mentes piensan mejor que una, esto aplicado a la programación tiene ventajas interesantes: Por un lado mientras una persona escribe el código la otra va visualmente validandolo, si existe alguna duda se puede consultar en el momento y en conjunto se busca la solución, además si estas personas tuvieran diferente nivel técnico, es también una forma de ir nivelando la habilidad del equipo (cabe señalar que las parejas no son fijas y van rotando), y finalmente proporciona un mayor entendimiento del código, por lo que cualquiera puede realizar posteriormente una modificación (en caso de ausencia de algún desarrollador).
TDD: No se escribe el código primero, sino una prueba que verifique su objetivo. Primero pruebo, luego existo.
Mejora del diseño: El diseño del código es refactorizado de manera constante, por lo que resultara más fácil mantenerlo e integrar funcionalidad adicional al mismo.
Integración continua: Cada vez que el equipo envie un cambio al repositorio, este cambio pasa por revisión de pruebas de aceptación y unitarias (o las que el equipo decida) de manera automática y es posible detectar defectos.
Propiedad colectiva: Ningún miembro del equipo es dueño absoluto de un modulo, componente o linea de código, por lo que todo el equipo puede trabajar sobre cualquier parte de la aplicación. Este punto en particular lo considero algo muy positivo, ya que todo el equipo de trabajo puede tener conocimiento del código y no depender de una persona que pueda no estar disponible en cierto momento y que se traduzca en retrasos en el proyecto. Además de que se va mejorando el código ya que más ojos observan el código y participan en todas las partes para su mejora (me imagino algo así como el principio de la Wikipedia).
Estándares de codificación: El equipo de trabajo gradualmente debe codificar de manera similar, tan es así que puede parecer trabajo de una persona. Representa una enorme ventaja puesto que el código es fácilmente entendido y mantenido por el equipo de trabajo, ya que se tiene una forma de códificar que actua como común denominador.
Metáfora: El equipo comparte una visión del proyecto, que les permite trascender y lograr un lenguaje común más alla del propio proyecto.
Ritmo sostenible: El equipo de trabajo debe trabajar dentro del horario establecido y debe evitar trabajar horas extras o fines de semanas. Esto es muy importante, primero por que las personas cansadas son menos productivas, y esto es especialmente cierto en el ambiente de desarrollo donde nos puede llevar a retrasos o errores en el código. También por que al ser Scrum una metodología empirica (donde vamos aprendiendo a partir del conocimiento adquirido), es posible medir el ritmo de cada equipo de Scrum durante cada Sprint, si alteramos este ritmo con horas extras o fines de semanas, las mediciones tenderan a ser menos realistas. Finalmente el consejo es no alargar las jornadas de trabajo, en su lugar mejor buscar alternativas para optimizar mejor el tiempo laboral, esta puede ser una manera de que busquemos mejorar continuamente.
Otros conceptos aprendidos
Algunos conceptos usados durante el entrenamiento que llamaron mi atención y los cuales no habia oido durante el curso de Certified Scrum Master son:
Scrum Weather:
Es una forma visual de saber en cada Sprint, lo que sucedio durante cada ceremonia de Scrum, donde se ilustra cada una de ellas como si del clima se tratase (nubes, tormentas, sol). De tal manera que podamos saber como fue cada una de ellas y lo que se tiene que mejorar.
Walking Skeleton: Aunque las metodologías ágiles suelen centrarse en construir la funcionalidad de manera incremental, esto no suele ser suficiente y es necesario definir los elementos mínimos con que debe contar de entrada la solución o producto para que esta pueda realmente aportar valor al cliente. Podría definirse como el mínimo producto viable.
Elevator Pitch:
Consiste en poder presentar una idea o producto en un espacio muy breve de tiempo (como si fueramos platicando la idea a alguien en el tiempo que estamos en un ascensor, de ahí el nombre). Por lo que tiene que tener una estructura muy concreta que permita conocer lo que se ofrece, satisface, la razón de ser, sus ventajas competitivas, entre otras cuestiones; suele usarse la estructura:
Para cliente/publico
Que tiene necesidad/oportunidad
Nuestro producto nombre del producto
es un tipo de producto
que beneficio o razón de compra
a diferencia de principal competidor o alternativa
nuestro producto diferencial competitivo
Agradecimientos
Primero que nada al excelente instructor Luis Mulato y a las personas con quién tuve la oportunidad de compartir esta experiencia, así como a Kleer por brindarnos estos cursos de calidad, y por supuesto a Scrum México que hace los esfuerzos para traer estas certificaciones a nuestro país.
Conclusiones
Es complicado poner en unas cuantas palabras todo lo aprendido durante el curso de Certified Scrum Developer, sin embargo toque los puntos claves del entrenamiento a mi consideración y les pueden servir como punto de partida para documentarse más al respecto, o bien tener idea de que es lo que verán en el curso si es que estan considerando tomarlo.
Es interesante conocer que no basta sólo con saber la metodología Scrum para poder llevar a cabo un desarrollo ágil, también es necesario apoyarse en otras tendencias que facilitan enormemente el desarrollo del producto (ATDD, BDD, XP, etc.), para poder realmente entregar valor al cliente en los cortos tiempos de un sprint, con un producto probado y de calidad.
Finalmente, recomiendo ampliamente a todo desarrollador que tenga oportunidad a tomar este excelente curso, sin duda ampliara su perspectiva y les ayudará a entender mejor el proceso de desarrollo ágil con Scrum.
Fanático de la Tecnología y de los nuevos retos. Agente del Cambio Ágil. Desarrollador de personas, negocios, aplicaciones web y de soluciones gráficas.
