¿Por qué es importante Scrum, Kanban o cualquiera de las variantes de Metodologías Ágiles? ¿Es importante para proyectos de BI?
Depende. Depende de muchos factores: del tamaño tu empresa, la cantidad de desarrolladores, … Hay lobos solitarios que están acostumbrados a trabajar de forma individual y lo hacen bien, incluso genial. Eso puede funcionar en ciertos clientes y hasta cierto punto. Cuando existen muchos lobos solitarios y deben ponerse de acuerdo para trabajar todos en el mismo sentido, la cosa se complica.
Una breve historia sobre las metodologías ágiles que se remontan a precursores como el Lean Manufacturing de Toyota (1940) y el Proceso de Desarrollo de Software Adaptativo (1970). En los 90 surgieron las llamadas “Metodologías de Desarrollo de Software de peso liviano” (Lighweight), como Crystal (1992), Scrum (1995), Feature Driven Development (1997), Desarrollo de Software Adaptativo (1999), Extreme Programming (1999). El Manifiesto Ágil fue promulgado en 2001 y desde entonces el movimiento ágil a continuado evolucionando, el Lean Software Development (2003), con exponentes como el Desarrollo basado en comportamiento (2006) y el Kanban aplicado al desarrollo de Software (2007).
Los que conocen o han trabajado con Metodologías Ágiles se dividen en dos grupos:
- Una mitad piensa que es la octava maravilla del mundo.
- La otra mitad piensa que es un completo desastre.
Lo más importante en las Metodologías Ágiles para el desarrollo de los sistemas de análisis es que no esperamos a tener un sistema completo para ponerlo en marcha. Vamos desplegando funcionalidades desde etapas tempranas. Con eso conseguimos dos puntos importantes:
- Feedback de las áreas funcionales, corrigiendo el rumbo en etapas iniciales –> No hay desviaciones grandes.
- Involucrar a negocio en todo el ciclo de vida del desarrollo.
Para ello necesitaremos de algunas herramientas que nos ayuden a tener el control de qué hemos hecho, qué tareas estamos actualmente desarrollando y qué tenemos por delante en el proyecto. Más adelante describiremos varias herramientas que nos ayudarán a tener el control en la gestión del proyecto.
Una de las buenas cosas de Scrum es que promete fallar muy rápido. ¿Qué fallar es bueno?
¡Claro que sí! Y en BI más que en otros proyectos. En BI las cosas hay que hacerlas muchas veces. No hacerlas bien a la primera es lo normal… porque eso es imposible.
Uno de los retos más complicados es adaptarse a los programadores y otro tema que siempre trae de cabeza a los gestores de proyecto es la trasparencia. Esto se irá consiguiendo a través de los finales de Sprint y los controles que estas metodologías emplean mediante la revisión del Sprint para analizar el producto y mediante retrospectiva para analizar las mejoras para el equipo.
Scrum va a sacar lo peor de los usuarios, pero lo bueno es que eso será al principio. Lo normal es que las primeras sesiones de Scrum sean caóticas, pero eso se va regulando y mejorando cada Sprint (2-3 semanas).
Actividades de cada Sprint:
 |
|
¿Cómo segmentar? A través de las Historias de Usuario que deberán tener un peso, un coste. ¿Cómo se valoran el peso de las historias de usuario?
- Estamos acostumbrados a trabajar en horas…
- Hay un mito que todos los programadores tienen el mismo nivel de productividad/hora, pero a eso te voy a responder en gallego… Depende. Depende mucho de la experiencia del programador, de si se ha enfrentado antes a un problema similar, … O Depende de lo mal que esté diseñado el cubo, el ETL o el producto en cuestión.
- Bromas aparte, ya te adelanto que en los primeros sprint te vas a equivocar, porque al principio se valorará a ojo. Valorando las historias de usuario y eso nos dará un número de historias de usuario que hemos sido capaces de realizar en cada sprint. En pocos Sprints deberíamos saber cuántos puntos de historia podemos asumir en los siguientes Sprints.
Tener las tareas separadas nos ayudará a tener identificadas las métricas más importantes, a segmentar los cubos, a saber cuáles son las dimensiones y los hechos más relevantes en el proyecto.
Bus Dimensional
Una buena práctica para antes de empezar los proyectos es crearse un Bus Dimensional, en el que tendremos los procesos de Negocio y las dimensiones de nuestro proyecto de BI. Nos ayudará a tener una idea del alcance del proyecto y nos ayudará a priorizar. Veamos un ejemplo:
Otra de las cosas buenas que tiene Scrum para los proyectos de BI es que tiene elementos abiertos, porque es un marco de referencia o un modelo. Y en muchos de los proyectos de BI, el usuario no sabe lo que quiere, hasta que se lo muestras. Pero CUIDADO cuando tenemos presupuestos cerrados.
Para utilizar Scrum el equipo debería ser de un equipo de no menos de 3 ni más de 9 personas para que no tengamos problemas. Según nuestra experiencia los proyectos en cascada NO se deben utilizar en los proyectos complejos, como normalmente son los proyectos de BI. Los análisis de 50 páginas de requerimientos son una “rata muerta”. Es decir que cuando los has terminado ya hay cambios y están obsoletos.
Scrum hace que un proyecto sea un desarrollo incrementa a través de iteraciones (Sprints).
Y ¿cómo controlamos esas Historias de Usuario? Existen diferentes softwares que nos ayudarán a gestionar nuestras tareas, sin embargo, cada uno tiene sus propias limitaciones y posibilidades de cada solución. Es importante escoger bien cual se quiere utilizar, dependiendo de nuestras necesidades y posibilidades económicas. Veamos algunos ejemplos de herramientas que nos ayudarán en la gestión de nuestros proyectos mediante Metodologías Ágiles:
Jira, ya sea en su versión completa, como en su versión Agile, es una de las herramientas líderes del mercado que nos puede ayudar a controlar nuestros proyectos, tanto Scrum, como Kanban. Ya que tiene tableros que podemos personalizar, así como definir flujos de trabajo para diferentes tipos de tareas (incidencias, documentación, evolutivos,…). Es una de las herramientas más completas del mercado que nos ayudará a controlar tiempos de nuestro equipo y proyectos.
A parte de poder utilizarlo como pizarra virtual, permite un seguimiento exhaustivo de los Sprints, ver los avances de cada programador, de cada sprint, de cada proyecto, mediante un apartado de informes…
Al principio costará un poco ponerlo en marcha, pero una vez estás en movimiento se le puede sacar mucho partido. Además, dispone de una comunidad bastante grande y de cantidad muy importante de add-ons (algunos gratuitos y otros de pago) que nos ayudarán a sacarle todavía más rendimiento a esta herramienta. Por ejemplo, añadiendo un Time-Tracking, conectando con Github o realizando encuestas de las incidencias resueltas.
Trello, es una herramienta que nos puede venir muy bien si nos preocupa el tema económico, ya que es gratuito. No es tan completo como puedan ser otros productos, pero es muy usable y fácilmente configurable. Nos resultará muy visual e intuitivo y a través de fichas que podremos crear con dos clics nos permitirá gestionar nuestro proyecto.
Además, se pueden personalizar colores y estados por los que pasará una tarjeta mediante drag&drop. Las tarjetas se pueden asignar a personas y tener una fecha de cierre.
Aunque tiene sus limitaciones, como que no podemos llevar el control de horas de cada tarea o en el proyecto, es cómodo de trabajar y fácil de compartir con otras personas. Y sobre todo es una herramienta cómoda y abierta que nos permitirá gestionar nuestros proyectos y nos permitirá por ejemplo sincronizar el calendario de Trello con el de google.
Slack, lanzada en enero de 2013 puede ser el área de comunicación de nuestro equipo de trabajo pudiendo configurar varios canales, el lugar donde se comparten mensajes, herramientas y archivos, ahorrándote tiempo e incentivando la colaboración entre compañeros de trabajo.
Es muy fácil de utilizar y si no dispones de este tipo de herramientas puede ser una opción a tener en cuenta o al menos probarla, ya que es gratis… Y eso siempre ayuda. Aunque hay algunas características que sólo están disponibles en la versión de pago.
Microsoft Teams, puede ser una buena herramienta si estamos metidos en el mundo de Microsoft, ya que se integra perfectamente dentro de las herramientas de Office 365. Fue lanzada en marzo de 2017 y es una herramienta de pago.
Al igual que con Slack tenemos posibilidad de chatear con el equipo, realizar reuniones o compartir archivos. Teams también se puede integrar con Trello, Planner y muchas más herramientas.
TFS – Team Foundation Server, nos ayudará a trabajar colaborativamente entre varias personas en nuestros proyectos, así como a controlar las versiones de nuestros archivos. Incluye seguimiento de tareas y errores y se integra perfectamente con Visual Studio.
Además, es gratis en su versión TFS Express hasta 5 personas. Consulte la página de Microsoft para equipos más grandes.
Para realizar la gestión del control de código se recomienda la utilización de Team Foundation Server (TFS) debido a su integración con Visual Studio, pero podría utilizarse cualquier otra herramienta siempre y cuando seamos capaces de volver a versiones anteriores y poder gestionar los cambios de una manera apropiada. Además, TFS está preparado para integrarse con metodologías ágiles, ya trabajes con Kanban o Scrum, dispone de Dashboards que ayudan a garantizar la transparencia y trazabilidad de los avances. Proporciona un sistema de informes y facilita el seguimiento del progreso de los elementos de trabajo y recursos del equipo. También, dispone de una versión en la nube.
Agile with Visual Studio Team Services
El ciclo de control de código sería el siguiente:
- Crear Elementos en Visual Studio.
- Almacenar los elementos em TFS
- Realizar check-in (protección) del elemento con el que vamos a trabajar
- Realizar el cambio
- Realizar un check-out (desprotección) del elemento, asociándole al elemento de trabajo (bug, user story) relacionado con el cambio, incluyendo un comentario sobre los cambios realizados.
- Etiquetar la solución con un código de versión previa a cada empaquetado y despliegue
- …Y vuelta a empezar
Dentro de TFS llevaremos al menos dos ramas, una rama principal donde están las versiones desplegadas, y una segunda rama donde se realizará el desarrollo. Una vez completado el desarrollo, la rama se etiquetará y se fusionará en la rama de producción.
Para hacer un cambio:
- Se crea un User Story en TFS
- Se genera el cambio y al hacer checkin se asocia a la tarea /user story, se añade comentario, se hace checkin.
- Una vez terminado el cambio, se hace un merge a la rama Release, y allí se vuelve a hacer checkin del mismo modo.
- En Release se pone una etiqueta o Label con la versión.
Es una buena práctica cuando vamos a hacer una entrega, preparar una versión de vuelta atrás:
- De SSIS como mínimo (si se entrega SSIS en el cambio, claro). Para ello, es conveniente hacer una copia de los paquetes a tocar antes de hacerlo. Se puede utilizar el Deployment Wizard.
- De SSAS no es necesaria esa vuelta atrás, porque casi siempre utilizaremos un backup.
- De SQL hay veces que se hace con un backup o hay veces que se entrega una carpeta de scripts de vuelta atrás, según el cambio.
La documentación a entregar en cada Sprint puede variar según las exigencias del cliente, pero se suele entregar un word con la información de despliegue y un zip, conteniendo las carpetas (SQL, SQL_VueltaAtras, SSIS, SSIS_VueltaAtras, SSAS). Los nombres no son convención, es sólo lo que se viene usando).
Github, lanzada en 2008 es una de las herramientas más utilizadas para la gestión y versionado de nuestro código fuente. Está en la nube y facilita el uso compartido de código. Tiene una comunidad muy fuerte y una línea expansiva de colaboradores y desarrolladores. Tiene una integración con Visual Studio y nos ayudará en nuestros proyectos de BI, si no optamos por el TFS.
Al igual que TFS, permite compartir código con otros colaboradores y tener Continuos Delivery / Integration (CD / CI). Tiene una mayor comunidad de usuarios que TFS. El despliegue de las realeases puede que sea un poco más rápido que en TFS y hay una gran cantidad de empresas que usan Github.
Conclusión:
¿Voy a aplicar Scrum a mi proyecto? ¿Y qué herramientas escojo para mi proyecto?
“Esto os lo contesto con gallego nativo: Depende, Depende, Depende…”.
Bueno, ya que habéis llegado hasta aquí y para ayudaros a elegir añadimos unas tablas comparativas que os ayudarán a tener la decisión un poco más clara:
Comparando Herramientas de Gestores de Tareas para nuestro proyecto:
Jira empieza siendo asequible para empresas pequeñas, pero con una cantidad importante de usuarios los precios se disparan. Pero es una plataforma muy probada y con un largo recorrido que ofrece gran cantidad de funcionalidades y mayor robustez que otras herramientas más simples. Trello, por su parte es muy simple de poner en funcionamiento y no necesita de aprendizaje apenas por parte de los usuarios ya que es muy intuitivo y fácil de entender. Eso sí, no puedes hacer todo lo que Jira te ofrece, pero si tus necesidades no son demasiado exigentes es una muy buena alternativa.
Comparando Herramientas de Comunicación en el proyecto:
Microsoft Teams y Slack son muy similares. Mientras Slack es más personalizable y tiene características interesantes como los atajos de teclado, Teams está totalmente integrado con Office 365 y tiene la seguridad que puedas tener en Sharepoint o Exchange.
Comparando Gestores de Código en el proyecto:
Microsoft TFS es muy competente y robusta en la gestión del ciclo de vida de las aplicaciones. Por su parte si vas a desarrollar y colaborar en proyectos open source con una gran comunidad de desarrolladores, Github es una plataforma ideal. Eso sí, en los proyectos privados hay que pasar por caja. Ambas tienen un precio razonable e integración con otras herramientas. Su integración en el equipo de trabajo es necesaria cuando tienes a un equipo de trabajadores para no perder código y tener una trazabilidad de las modificaciones del mismo. La gran diferencia entre ambas es que TFS tiene las versiones centralizadas, mientras que Git distribuidas entre los usuarios.
Lo que es seguro es que vas a necesitar organizar a tu equipo y que esté preparado para afrontar los cambios de forma rápida y segura. Existen multitud de herramientas que te pueden ayudar en las metodologías ágiles. Aquí hemos tocado algunas, pero si tienes dudas, contáctanos y te ayudaremos a tomar una decisión.
Recursos:
