Como hacemos Scrum: Requerimientos

Algunos piensan que ser ágil quiere decir que no se tienen requerimientos escritos, que toda la comunicación entre usuarios/clientes y desarrolladores es verbal y que si no están usando User Stories, no se puede hablar de desarrollo ágil. Bueno, tengo que discrepar de estas tres creencias.

Hablaré en el contexto de un proyecto que desarrollamos, el cual consistía en construir una aplicación para una entidad del sector financiero. Esta entidad, como muchas otras similares, tiene procesos un tanto rígidos (por no decir burocráticos ni pesados) que guían sus proyectos de desarrollo.

Cuando iniciamos el proyecto, nos fue entregado un documento de casi 150 páginas en donde se describían en detalle requerimientos, mediante especificaciones de casos de uso y pantallazos de un prototipo previamente construido. ¿Qué hacer en estos casos?

El principio básico en todo esto es algo que les sonará familiar a muchos: LA COMUNICACIÓN. Es decir, debe existir un entendimiento común entre aquéllos que desean resolver un problema (usuarios) y aquellos que pueden resolver el problema (desarrolladores).

Para lograr ese entendimiento debe existir un canal amigable entre ambos frentes. En nuestro caso, lo que hicimos fue acordar reuniones dos veces por semana entre nuestro equipo y los analistas del cliente para conversar acerca del documento de requerimientos. Teníamos como objetivos:

1. Compredener de qué diablos trataba la lógica de negocio a un nivel suficiente para que uno de nosotros actuara como Proxy del Product Owner en nuestras reuniones de planeamiento.
   
2. Poder definir un Product Backlog en base a este documento.
3. Priorizar el Product Backlog con los representantes del cliente.
   

El Analista Funcional del cliente se convirtió, casi sin darse en cuenta, en nuestro Product Owner y acompañó a nuestro equipo a lo largo de todo el proyecto, estando siempre dispuesto a absolver dudas y repriorizar ítems, cuando fuera necesario.

Aquí un punto clave es descomponer los casos de uso para poder llegar a un nivel de granularidad suficiente que permita planificar los ítems del Product Backlog dentro de cada iteración o sprint. La técnica que usamos fue considerar a cada escenario como un requerimiento o ítem distinto. Por ejemplo, si hablamos de un mantenimiento de países, los ítems (o stories) serían:

• Consultar países por nombre
• Consultar países por código internacional
• Crear país
• Modificar país
• Inactivar País
• Reactivar País

Otro punto importante son las demos o reviews del producto que se realizan al finalizar cada iteración. En nuestro caso, además de los analistas del cliente y de nuestro equipo, participaban los usuarios finales de la entidad financiera. Como es normal, al interactuar o apreciar el incremento de funcionalidad que se está presentando, a un usuario se le van a ocurrir muchas ideas de cómo mejorar o cambiar el producto. Es básico el poder manejar su expectativa y guiarlo sobre cuáles se van a poder incorporar y cuáles no (por razones de tiempo, costo y/o complejidad).

Lo que hicimos nosotros fue recoger todas las sugerencias e ideas, para posteriormente (o a veces durante la reunión misma) conversarlas con nuestro Product Owner. Aquellas que el equipo consideraba sencillas las incorporamos sin ningún problema. Pero aquéllas que se estimaba iban a tomar más tiempo, quedaron en el tintero para futuras versiones del producto.

Cómo hacemos Scrum

Cuando la gente comienza a aplicar métodos ágiles en un proyecto u organización, las preguntas más comunes son: ¿por dónde empiezo? y ¿cómo realizo esto o aquello? Entiéndase "esto o aquello" como algo que saben que se tiene que hacer pero no tienen mucha idea de dónde encaja dentro un entorno ágil: documentación, estimación, planificación, etc.

Es por eso que en esta serie de posts voy a contar un poco acerca de cómo usamos Scrum/Agile en los proyectos que desarrollamos en la empresa donde trabajo y de cómo aplicamos principios emparentados con agile o lean en la organización de nuestra área.

Trataré de tocar temas como: planeamiento, estimación, capacitación, gestión del talento, retrospectivas, documentación, requerimientos, testing, espacio de trabajo, etc.

Disclaimer: Las opiniones vertidas en esta serie de posts no representan la posición oficial de la empresa ni de los clientes involucrados (según el caso).

Comunidad Agile Perú

Les comunico esta noticia un poco tarde, pero hace unos días creamos la Comunidad Agile Perú en donde discutimos todo lo relacionado a la difusión y aplicación de métodos ágiles en nuestro país. Pronto tambien inauguraremos un web site con artículos e información al respecto.

Son todos bienvenidos a unirse a este emprendimiento, para compartir experiencias, dudas y conocimiento en general.

Curso Certified ScrumMaster fue todo un éxito

Esta semana se llevó a cabo, por primera vez en Lima, un curso oficial Certified ScrumMaster. El instructor fue Tobias Mayer y realmente fue una experiencia única y bastante enriquecedora. Partiendo de las dinámicas de grupo que aplicó Tobias para que todos experimentáramos los valores y principios de Scrum, pasando por las historias que contó de su trabajo aplicando Scrum en Yahoo! y Business Week, sumado al aporte de cada uno de nosotros y culminando en una suculenta cena en Antica, fueron dos días bastante productivos, en los que compartimos muchas ideas, opiniones e inquiedudes con Tobias y con todos los asistentes.

Gracias a todas la personas que hicieron esto posible: Deusdit Correa y la gente de Voxiva, el Capítulo PMI de Lima, el Colegio de Ingenieros, Tobias y todos los asistentes al curso.

Por lo experimentado en esos dos días, estoy seguro que se vienen muchas cosas interesantes aquí en nuestro medio en lo concerniente a la aplicación de métodos y prácticas ágiles de desarollo. Estén atentos!

El Codigo Florinchi (Parte II)

En nuestro ultimo episodio, nuestros heroes se encontraron ante un misterio aparentemente insodable.

Sigamos ahora con la historia...

Despues de la info proporcionada por los "tios del cliente", decidimos buscar en internet el parche para las clases propietarias de encriptacion. Finalmente lo encontramos en la pagina del proveedor (aunque no estaba muy visible que digamos). Pero, una vez mas, la suerte jugo en contra. Al intentar bajarlo, por algun motivo el browser nos daba time-out. Se habra caido la pagina? -pensamos.

Tras un par de llamadas a la gente indicada nos enteramos que la conexion a internet se habia caido en esa zona de San Isidro! En este punto ya empezamos a conjeturar por que estabamos teniendo tan mala suerte en este fuxxxing pase a produccion!! Y entonces........ sucedio.

Al voltear la mirada vimos la fuente de nuestra desdicha. Teniamos frente a nuestros ojos a Mr. Flores (alias Flowers). Ya empiezan a entender el por que del titulo de la presente saga... Y quien es este personaje? -se preguntara Uds. Pues es nada menos que uno de los "tios del cliente", el cual estaba a cargo del pase. El problema con el susodicho -que por cierto es buena gente y no tengo nada personal contra el- es que tiene una mala suerte con los pases a produccion que ni el personaje de Hanna-Barbera se le compara . Para muestra, baste decir que una vez empezo un pase un viernes por la noche y termino el domingo a las 3pm. Y no es exageracion...

Pero volvamos a la historia... tras intentar una y otra vez bajar el parche, finalmente lo conseguimos y tras unos pequeños tropiezos con la instalacion del mismo -pues no estaba bien documentada- todo salio bien. Al momento de probar el producto, sin embargo, obtuvimos nuevos mensajes de error. El tiempo seguia corriendo y si o si teniamos que dejar todo operativo para la mañana siguiente o eramos historia.

Indagando en los logs del servidor de aplicaciones y del web server, descubrimos que este ultimo estaba teniendo dificultades al intentar comunicarse con el primero mediante SSL. Buscando de nuevo en internet, decidimos bajar el ultimo parche del servidor web. Nos llevamos otra sorpresa cuando vimos que no habian parches sino que habia que reinstalar el servidor web... en fin. A estas alturas ya no podiamos ponernos exigentes.

Hicimos un backup del archivo de configuracion y reinstalamos el servidor. Al probar de nuevo la conexion, encontramos nuevos errores. Despues de un par de maldiciones a la mala suerte de Flowers, decidimos regenerar el certificado digital para reconfigurar la comunicacion SSL entre los servers. Finalmente lo logramos, pero al hacer la prueba obtuvimos nuevos errores. Esta vez, Jadclipse mediante, vimos que el problema era que el producto no podia desencriptar los passwords almacenados en los archivos de configuracion. Casi seguro se debia al upgrade que habiamos hecho de las librerias de seguridad.

Ya eran casi las 2 am y nuestra paciencia, si bien no se agotaba, ya saba señales de cansancio. Afortunadamente, los "tios del cliente" se portaron bien y compraron un pollito a la brasa, el cual fue devorado por los presentes. Armandonos de valor, buscamos el mensaje de error en la documentacion on-line y por suerte encontramos una pista.

Si bien lo que hallamos se referia a otra version del producto, al parecer aplicaba a nuestra situacion. La solucion pasaba por correr unos queries en la BD y regenerar otros archivos mediante comandos. Al realizar esto y probar otra vez... finalmente funciono! Pudimos extraer los documentos del servidor de contenido y todo se veia bien.

Sin embargo, la mala suerte de Flowers paracia no descansar. Esto lo descubrimos al salir del edificio y dirigirnos al estacionamiento donde el Agente X habia dejado su auto. Era tan tarde que estaba cerrado y no habia nadie que nos abriera las rejas.... chess!!! Despues de un par de gritos y forcejeos decidimos zafar a nuestros hogares... en el fondo satisfechos de haber cumplido la tarea.

Pero aun hay mas!! ....Cuando todo parecia bien... al dia siguiente tuvimos una desagradable sorpresa. Como nos habiamos amanecido en el bendito pase, nos correspondia llegar tarde a la chamba. Pero a eso de las 10 u 11 recibi varias llamadas de gente del cliente y de mi empresa diciendo que los usuarios no podian conectarse a "El Content" y subir sus documentos escaneados. Diablos!! Si ayer todo funcionaba....

Tuve que dejar mi merecido descanso y volar al lugar del desastre para encontrar que simplemente se trataba de un error de conexion. Como la prueba que habiamos hecho la noche anterior fue en el mismo server todo habia salido OK. El tema era que al regenerar el certificado digital habiamos cambiado el hostname por el nombre calificado de la maquina (hostname + dominio) y las maquinas de los usuarios estaban apuntando al nombre anterior.

Para colmo, el servidor de contenido no estaba inscrito en el servidor DNS -por extrañas razones que no comprendo-, sino que estaba en cada archivo hosts de los usuarios. Y, obviamente, solo estaba el nombre corto. Corregido este impase todo fluyo a la perfeccion y pudimos respirar tranquilos.... no sin antes decir una vez mas... Flowers salado!!

El Codigo Florinchi (Parte I)

Lo que supuestamente iba a ser un relativamente normal pase a produccion de fixes en los servidores del ambiente de produccion del cliente XYZ SAC -normal segun los estandares del cliente en cuestion (o sea, de dos a 3 horas extras de trabajo nocturno) -terminó conviertiendose en una busqueda casi interminable de errores plagada de pistas e indagaciones digna de la proxima novela de Dan Brown. Claro, si Brown esuviera interesado en retratar el devenir de un grupo de arquitectos de SW, gente de infraestructura y programadores.

Pero vamos por partes. Nuestra mision imposible, que decimos aceptar pues nadie nos pregunto si queriamos o no, era parchar un producto que llamaremos "El Content" que sirve para la administracion y manejo de contenido de todo tipo, el cual es vendido por una conocida empresa transnacional de IT y que actualmente utiliza extensivamente el cliente XYZ SAC.

Por motivos de falta de coordinacion y prevencion se decidio cancelar el pase a eso de las 9 pm. Sin embargo ya habiamos realizado el primer paso que consistia en backapear la BD que usa "El Content". Antes de irnos reiniciamos el server y procedimos a probar que todo funcionaba OK.

Grande fue nuestra sorpresa cuanto intentamos acceder a los documentos almacenados y obtuvimos errores innesperados. Sospechando que este percance nos iba a tomar mas tiempo de lo calculado, decidimos convocar refuerzos, o mas bien un refuerzo, alguien quien tiene amplia experiencia con el producto y que estaba planeado que viniera de todas maneras, pero que aun no llegaba pues tenia un compromiso previo ese dia. Llamemoslo Agente X.

Al llegar el susodicho se puso a revisar el estado del backup, el cual se habia realizado con exito. Porsiaca corrio uno mas y tambien termino OK. La BD estaba consistente y podiamos loguearnos sin problemas. El error ocurria cuando accediamos al contenido propiamente, el cual es provisto por un servidor de aplicaciones J2EE de una version un tanto antigua (digamos que era V2 y la actual es V4). Lo extraño es que ni siquiera habiamos tocado el dichoso servidor por lo que nuestra perplejidad se duplico. Y esta se triplico al ver en el log un mensaje de NoClassDefFoundError.

Varias preguntas rondaron mi cabeza: ¿Como era posible que faltara una clase en una aplicacion que viene con un producto como este? ¿Como podia pasar asi de pronto? Tenia que haber una explicacion logica y como tanto el Agente X y yo somos tercos y nos gusta resolver problemas (ademas que teniamos a los tios responsables del pase por parte del cliente "watching our backs") teniamos que encontrar la causa y resolver el impase.

Nos decimos a sacar el kit de rastreo de huellas digitales, o sea el poderoso JadClipse para descompilar las clases Java del producto que estaban lanzanado el NoClassDefFoundError. Fue asi que llegue a la madre del cordero. Al parecer el error se lanzaba al momento de instanciar mediante reflection una clase propietaria para encriptacion/desencriptacion. Pero, ¿como era posible que una clase que estaba funcionando bien se no se pueda instanciar de repente? ¿Era acaso que las clases tiene fecha de caducidad o algo asi? jeje.... nica.....

Pues......sica! Haciendo memoria por parte de los tios del cliente, resulto que habian recibido un mail de parte de la empresa que fabrica el producto hacia un par de dias atras que decia que el 18 de mayo del 2006 vencian las clases de encriptacion usadas en la version de App Server que estabamos usando!!

To be continued...