Creo que casi todos hemos escuchado alguna vez que la profesión de informático es la que mejor futuro tiene. No parece nada extraño si pensamos en este mundo hiperconectado de internet, apps móviles y todo tipo de tecnologías que surgen tan rápidamente. ¿Pero a qué precio muchos profesionales de la informática que trabajan en el sector lo están pagando malgastando sus carreras profesionales?

Si queremos defender la profesión de informático y mantenerla como la profesión de futuro que siempre ha sido, debemos revisar qué nos mueve y cómo debemos adaptarla. Con esta motivación surge el evento SaveInformaticOs que reunirá a profesionales, empresas, clientes, estudiantes y docentes entorno a este Open Space el día 27 de Abril en la Universidad Politécnica de Madrid.

El formato Open Space es una modalidad dinámica sin agenda previa en la que se propone de forma conjunta los temas a tratar en los diferentes tracks al comienzo del evento. Cualquiera que tenga una propuesta la puede exponer y “venderse” al resto de asistentes para que asistan a su charla o corrillo de ideas. Se votan las mejores propuestas y se participa libremente en la que más nos apetezca, siempre con la posibilidad de ir de charla en charla (la famosa regla de los 2 pies). Podéis conocer más sobre el formato Open Space en el blog de reelab que explica a la perfección sus reglas.

Durante estos días, seguro que habréis escuchado debates interesantes sobre la profesión de informático. Muchos de ellos iniciados entorno a la perspectiva de este evento. Entre ellos, el tremendo cáncer de nuestra profesión como son las “cárnicas” que trafican con horas/hombres ¿Cuantos buenos programadores se han perdido por la desmotivación de ese tipo de trabajos? La desmotivación estacan nuestra carrera de técnicos, quedando con el tiempo obsoletos. Cada vez más los jóvenes tendrán la habilidad innata de programar y crear su propio hardware o software, pero en las universidades no sabrán aprovechar esos talentos con clases alejadas de la realidad. La sociedad evoluciona y nosotros, los informáticos, quedamos anclados.

Por todos estos motivos, creemos que un Open Space que libere las mentes y fomente que todos los implicados dialoguen sobre el futuro de la profesión es importante. Pasando por temas como el trabajo, el cambio hacia un nuevo paradigma en que la metodologías ágiles se adopten de pleno y, sobre todo, que seamos consciente cómo se hacen bien las cosas y olvidar las prisas/ñapas.

Es necesario el esfuerzo de los profesionales y las empresas. Seguro que muchos profesionales que están motivados con su profesión y tiene la intención de hacer bien las cosas se animarán a contar en las distintas charlas cómo trabajan y dar ideas para mejorar la profesión de informático.

Podéis encontrar más información en el sitio web de SaveInformáticos, así como leer la opinión de buenos profesionales que participan activamente en el evento.

Más información | SaveInformáticOS

La Pila de Producto, o Product Backlog, es un artefacto del marco de trabajo para la gestión agile de proyectos de desarrollo de software, SCRUM. Y que es, en líneas generales, una lista ordenada u priorizada de las tareas que componen un proyecto de aplicación.

Aunque SCRUM no lo define, el formato que más se utiliza para la tarjeta de trabajo que compone una Pila de Producto es la Historia de Usuario. Sin que haya mayores problemas en utilizar Casos de Uso, o una lista de tareas.

Lo importante es que el propio esfuerzo de realizar la división en tareas implica una organización del trabajo y una primera visión del alcance del proyecto. Es decir, qué es lo que se quiere obtener después de semanas o meses de trabajo.

Construcción

Persona que se empapa del dominio y de lo que quiere el cliente final, para ejercer las labores de Dueño del Producto, y por ello quien, asesorado por el Scrum Master, define las historias de usuario que componen el Product Backlog.

Teniendo en cuenta que es un artefacto vivo y que va a sufrir modificaciones tanto de prioridad como de alcance durante todo el proyecto, se construye una primera Pila de Producto que comprenda la descripción de las funcionalidades esperadas a alto nivel.

En este momento el Product Backlog empieza a mostrar sus ventajas. Es un punto inicial para gerencia, si hubiese que presentar una oferta al cliente, en la estimación en tiempo y dinero del coste del proyecto. Ya que la definición del alcance la genera el propio cliente, o las personas que más saben sobre lo que quieren que realice la futura aplicación.

Por otra parte, el equipo adquiere la primera visión del proyecto. Cual es el objetivo y la motivación que ha llevado al cliente a pensar en que un desarrollo de software puede ser una ventaja o una solución a sus necesidades. En definitiva, porque es una mejora.

Y el cliente puede observar de forma visual y cómoda todo el trabajo que representa el construir su proyecto, decidir las funciones que más valor le aportan y detectar que cosas puede dejar en duda, por si no fuera necesario o interesante de construir.

Otra gran ventaja de utilizar Pilas de Producto es que permite encapsular una metodología Agile, como Scrum, dentro de un proceso formal de gestión de proyectos. Es decir, puedo cumplir con los artefactos clásicos de Toma de requisitos, Análisis funcional, Análisis Técnico, etc. Y, simultáneamente construir el Product Backlog (aunque con más esfuerzo) para empezar a desarrollar y ha obtener software que funcione de forma iterativa.

Hasta que dirección se dé cuenta que el esfuerzo dedicado a la documentación exhaustiva es dinero tirado a la basura en la mayoría de los casos.

Gestión y mantenimiento

El seguimiento de la Pila de Producto es una gestión relativamente sencilla pero que genera decisiones importantes y fundamentales en el proyecto.

En cada iteración, se realiza una revisión de las tareas del Product Backlog que han sido completadas y el Dueño del Producto tiene la potestad de repriorizar las tareas que quedan por realizar. O, como casi en todos los casos, hay que añadir nuevas tareas que no fueron detectadas en la construcción inicial de la Pila de Producto o que han surgido durante el proyecto.

Y aquí emerge otra ventaja de este artefacto. Ya que tenemos las historias de usuario estimadas y, como veremos más adelante, una media de velocidad del equipo, podemos darnos cuenta de forma temprana que el alcance no se va a poder completar en los plazos iniciales, por lo cual el cliente debe decidir qué cosas no se realizaran para poder añadir las tareas nuevas.

En una alegoría, un desarrollo Agile es como un cántaro. Lo puedes llenar de agua hasta el borde. Pero por cada gota que añadas de más, debes ser consciente que saldrá otra del recipiente. Ya que este no se puede estirar, al igual que pasa con el tiempo. Aún no se han inventado los días de 25 horas.

BurnDown y velocidad

Es un eje de ordenadas simple en donde en la horizontal tenemos una medida temporal. Ya sean fechas, o iteraciones. Mientras en el vertical tenemos una medida de cantidad de trabajo ha realizar. Ya sea por estimaciones en trabajo (horas o puntos de esfuerzo), número de tareas, etc.

Con ello, según va pasando el tiempo, obtenemos una línea descendente (o ascendente, según la orientación de la gráfica) en donde se visualiza de forma sencilla el estado del proyecto. Que cosas se han realizado, cuanto queda por realizar, si se ha variado el número de tareas o si se está dentro del alcance del proyecto.

Otra métrica que se puede obtener a partir del BurnDown es la velocidad del equipo. Por ejemplo, si veo en la gráfica que cada sprint de dos semanas el equipo, de media, es capaz de completar 230 puntos de esfuerzo, puedo afinar la estimación del número de tareas que me entran dentro del alcance del proyecto y tomar decisiones correctivas lo antes posible.

Y si en un sprint se han completado 150 puntos de esfuerzo, está claro que tengo un impedimento que ha llevado al equipo a trabajar por debajo de su ritmo habitual y que debe ser localizado, señalado y corregido.

Conclusión

El Product Backlog, o Pila de Producto, es un “must have“. Es decir, algo que todo equipo que considere la implantación de la filosofía Agile y sus metodologías asociadas, debe estar dispuesto a construir, mantener y utilizar.

Es importante comprender que el objetivo no es reportar a dirección o al cliente del trabajo realizado, aunque se pueda utilizar de esa forma. Si no que el equipo y el cliente sean conscientes del estado actual del proyecto y poder mantener una previsión del alcance de los desarrollos a futuros.

Es un mecanismo que provee de la visión del proyecto, que ayuda a que los errores salgan pronto y de forma llamativa para corregirlos lo antes posible; que permite ajustar el alcance de acuerdo a las necesidades reales y cambiantes de los clientes; y todo esto de una forma poco costosa para el proyecto y, a diferencia que en metodologías clásicas, no bloqueante. Es decir, mientras lo construyo o lo modifico el equipo no para de construir ni se queda detenido a la espera del documento funcional de turno.

En GenbetaDev | Historias de usuario, una forma natural de análisis funcional

El teletrabajo, deseado por unos, necesario para otros y del que huyen los que dicen que se aburrirían si trabajasen en casa. Pero, ¿Se puede trabajar en equipo desde casa? ¿Se puede utilizar metodologías ágiles desde casa? ¿Puedes trabajar en casa y sentirte arropado por tu equipo? ¿Puedes ser igual o más productivo desde casa? Pues bien, sí, sí, sí y sí.

Quiero empezar explicando, para evitar confusiones, la diferencia entre equipos dispersos y equipos distribuidos. La diferencia es simple, los equipos distribuidos son distintos equipos que tienen que colaborar juntos y que están en ubicaciones distintas. Por su parte los equipos dispersos son integrantes de un mismo equipo que están separados geográficamente.

Difícil elección

Quien diga que es fácil trabajar desde casa, miente vilmente, sobre todo si es en equipo. Necesitas un “entrenamiento” previo, disciplina y un compromiso por encima del resto del equipo para que vaya todo rodado. Te vas a enfrentar a innumerables peligros: soledad, escasez de comunicación, incomprensión…

Partimos de que idealmente no debería haber más de siete integrantes por equipo y de que sería una locura pensar que podría funcionar un equipo si todos sus miembros trabajasen separados. Si es sólo una persona la que trabaja desde casa, se puede conseguir que el equipo funcione casi como si estuvieran juntos. Con dos personas, la cosa se complica, pero con un poco de esfuerzo se puede conseguir. A partir de dos personas la situación se vuelve inmanejable, coordinarse con más de tres personas en remoto puede ser tan complejo que puede minar la moral del equipo.

Si no confías en nadie, nadie va a confiar en ti

La premisa más importante para que un equipo disperso sea un equipo competitivo, en el que todos reman al unísono para conseguir los objetivos, es la confianza. En un equipo convencional, en el que todos trabajan juntos, la confianza entre unos y otros debería ser palpable.

Sin embargo, alguien que entra nuevo a un equipo no debería irse a trabajar a casa desde el minuto 1, el equipo no confiaría en él, tendrían dudas de su forma de trabajar, de si realmente hace todo lo que dice o de si se moja igual que el resto. Por su parte, la persona desde casa pensaría parecido del resto, se sentiría incomprendido y aislado.

Por eso es necesario que, antes de dar el paso, trabaje un tiempo codo con codo con sus compañeros, hacer piña, para que no sólo haya confianza, si no también compañerismo. La persona desde casa tiene que conocer al dedillo la forma de trabajar de cada uno de sus compañeros y viceversa. Y no sólo eso, también tiene que conocer la dinámica del equipo, como es el daily scrum, las retrospectivas, las planificaciones, las demos…

Una vez que está en casa es importante que vuelva cada X tiempo a trabajar unos días a la oficina para darle continuidad a esa confianza, aprender como usar las nuevas herramientas que se hayan podido empezar a utilizar, trabajar junto a nuevos compañeros que se hayan incorporado y, como no, para tomar unas cervezas y hacer un poco de team building. Cuanto más lejos están, las visitas a la oficina suelen ser menos frecuentes y es precisamente por eso por lo que deben prolongarse durante más días.

be agile my friend

Si has llegado hasta aquí, seguro que te habrás hecho muchas preguntas: ¿Y qué hay del daily scrum? ¿Y de las retros? ¿La planificación? ¿Quién tuvo la brillante idea de cambiar el nombre a los petit suisse por Danonino? En cuanto a las 3 primeras, tu aliado principal va a ser Skype, Gtalk o algún programa similar que te permita hacer videoconferencia. En cuanto a la cuarta, tu aliado principal va a ser un psicólogo.

Daily scrum

La recomendación que se suele dar para el daily scrum en remoto es que no hagas videoconferencia, son 15 minutos y con problemas técnicos puede retrasar más que agilizar la reunión diaria, puede valer una simple llamada por teléfono con manos libres.

Mi recomendación es justo la contraria, que utilices videoconferencia, siempre que dispongas de buena conexión, ya que ayuda a mantener el foco de la conversación (al equipo en general) y a que la persona en casa vea algún signo de vida humana

Consejos:

• Hay que ser puntuales, no vale un llámame cuando puedas
• Si es posible, que la persona que habla en cada momento vaya girando el monitor para que la persona de casa le pueda ver
• Ponte en la piel del que está en casa y no cruces conversaciones. Prueba de empatía: La próxima vez que haga una visita a la oficina que otro integrante del equipo coja un portátil y se vaya a una sala emulando al de casa.
• Tarjeta roja: hay veces que la cosa se va de madre, ayuda que el que está en casa, ya que no puede dar una colleja, saque una tarjeta roja cuando empieza a perder el hilo

Retros y planificación

Si la visita a la oficina no se va a prolongar varios días es mejor evitar que coincida con la retro o la planificación, una videoconferencia con Skype debería ser suficiente. Seguro que es mucho más provechoso para todo el equipo que esa visita la dedique a trabajar con los compañeros, a poner puntos en común o a hacer tareas de análisis.

Consejos:

• Si la planificación la haces con planning poker cada uno debe tener su juego de cartas o puedes utilizar una herramienta online si así lo prefieres.
• Hay que hacer un esfuerzo por explicar bien las cosas, hay que evitar expresiones como “esto de aquí” ya que no todos están viendo lo que es eso de ahí.
• Si hay que mostrar detalles sobre algo prueba la videoconferencia desde el móvil y acerca a la persona de casa a esos detalles.
• Si crees que es imprescindible que todos estén en estas reuniones, la solución es simple, que estén :)

Pair programming

Es mucho más sencillo de lo que a priori parece, para que sea algo natural, habitual y rápido simplemente hay que saber elegir las herramientas adecuadas. Herramientas que permitan la comunicación entre ambos y que den la posibilidad de compartir el escritorio y de que pueda ser controlado en cualquier momento por las dos partes.

Consejos:

• No lo dudes, hazlo. El pair programming ayuda muchísimo al equipo y no tienes excusa para no hacerlo.
• Skype para compartir escritorio se queda bastante cortito, sin embargo Teamviewer va de lujo en este sentido.
• Para que os deis cuenta de hasta que punto funciona el pair programming en remoto, recomiendo que lo hagáis incluso entre los miembros del equipo que estén en la misma oficina: no se tiene que mover nadie de su sitio y si en un momento dado uno tiene que mirar documentación mientras el otro pica código puede hacerlo.

Disclaimer

Evidentemente no quiero sentar cátedra con todo esto, simplemente compartir experiencias personales y “trucos” que han surgido como ideas en las retrospectivas. Y, claro está, lo que en unos equipos funciona en otros puede convertirse en un impedimento. Espero por lo menos que ayude a aquellos que quieran dar el paso a trabajar en casa y a aquellos jefes que son reacios a “soltar la correa” a sus empleados.

En Genbeta Dev | Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

Uno de los mayores males que azota la productividad de las empresas de desarrollo de software es la metodología de desarrollo ASM: A Salto de Mata. Es decir “Aquí lo pillo y aquí lo mato“ o dicho de otra forma, la inexistencia de un método de producción ordenado.

Además, la nula visibilidad del flujo de trabajo produce efectos muy perniciosos como son la simultaneidad de los proyectos por encima de la capacidad de los desarrolladores o la existencia de la figura del “Hero” en contrapunto al equipo y el conocimiento compartido.

El Kanban (del japonés: kanban, donde kan significa “visual,” y ban significa “tarjeta“ o “tablero“) es, en la versión nacida y evolucionada en Toyota, una completa y compleja metodología de señalización. Pero en este artículo me refiero a la simple herramienta visual compuesta por el tablero y las tarjetas que soporta.

Es el primer paso que deben completar los desarrolladores para iniciar el camino de convertirse en un equipo Agile de desarrollo.

Descripción general del tablero

Las tareas, plasmadas en postit, se van moviendo de derecha a izquierda completando cada una de las etapas. Se pasan hacia adelante o hacia atrás, aunque esto último siempre ha de ser considerado como un fallo. Pero esto no sería realmente de gran utilidad si no fuera por el concepto de WIP (Work In Progress). Este número que se coloca en el encabezado de la columna es el que indica cuantas tareas máximas (o mínimas) puede haber de forma simultanea en una etapa.

Flujo de trabajo

También puede ocurrir al contrario, que una columna esté continuadamente vacia o con muy pocas tareas en relación a su WIP máximo. Lo cual puede indicar que hay un cuello de botella en alguna etapa anterior o que la carga de trabajo es muy baja.

Sea cual sea la incidencia en el flujo de trabajo, con un tablero Kanban obtenemos de un vistazo el estado del trabajo en todo momento y, en mucho casos, algo más importante como es que las personas que deciden sean consciente de una forma muy sencilla de la realidad de los proyectos.

Además cumplimos dos conceptos Agiles: los errores y los impedimentos son muy visibles y se ven muy pronto, y la comunicación que produce es la de cara a cara, que es la preferente a cualquier otra.

Prioridades y Filas

Así que en un Kanban las tareas han de ser priorizadas para evitar este tipo de confusión que tantas horas extras y frustración produce. Las tareas técnicas obviamente las prioriza el equipo, que es el que sabe desarrollar; y yo prefiero empezar por las más difíciles y dejar las más sencillas para el final.

Otra práctica que nos permite el tablero es el pintar filas o carriles. Es una forma de dividir un tablero en diferentes proyectos que comparten las mismas etapas. O se pueden dividir en tres filas que implican la criticidad de las tareas:

• ASAP. Aquí se sitúan las tareas que algún día se harán. No están priorizadas ni se sabe cuando van a realizarse. Está pensado para aquellas que se dejan para los tiempos muertos y que, al no tener prioridad, cualquier tarea es más prioritaria que ella.
• Priority. Tareas que han sido priorizadas y que están en el flujo de trabajo normal.

• Fire. Tarea que provoca que todo el equipo, a veces toda la empresa, deje lo que esté haciendo y se centre al completo a resolver esta tarea hasta que llegue a Done. Se puede reforzar señalando de forma inequívoca que personas están involucradas en la tarea y que no deben ser interrumpidas en ningún caso. Por ejemplo con chalecos reflectantes.

Más información | Kanban vs Scrum en Presión Blogosférica, Scrummanager, LeanKitKanban
En GenbetaDev | Test de metodologías ágiles, ¿Qué metodología es mejor: Scrum, Kanban o Scrumban?

Hay quien se empeña en crear una guerra de metodologías ágiles, que si mejor Scrum, que no que mejor Kanban… Mi opinión es que hay que saber elegir la metodología adecuada según tu modelo de desarrollo y las necesidades que este tenga, no hay una mejor que otra, simplemente hay una más apropiada que otra.

Como ayuda a la hora de tomar esta decisión, propongo un pequeño test para poder escoger la metodología ágil más adecuada (10 sencillas preguntas al más puro estilo revista adolescente), ya sea porque tienes la intención de “volverte ágil” o bien porque ya estás utilizando alguna pero hay algo que chirría:

1. ¿Te enfrentas únicamente a proyectos grandes?

Ten en cuenta que si te decantas por Scrum, lo normal es que hagas sprints de entre dos y cuatro semanas (puedes hacerlo de más o de menos, aunque no es recomendable) por lo que si los proyectos son grandes cobra mucho sentido que vayas haciendo entregas graduales al cliente. Si por el contrario son proyectos muy pequeños, o algunos de ellos lo son, conviene que te plantees la siguiente pregunta.

2. ¿Tiene sentido que todas o casi todas las funcionalidades que desarrollas esperen un mínimo de 2 semanas para estar en producción?

En Kanban cuando finalizas un work item este acaba en producción. En equipos acostumbrados a resolver incidencias o en equipos de investigación parece difícil justificar ante el cliente que lo que ya tienes solucionado o desarrollado tiene que esperar 2 semanas para tenerlo disponible.

3. ¿En tu empresa hay Legacy Code y requiere bastante mantenimiento?

En el mundo ideal de muchos agilistas tenemos una cobertura del 100% , un código limpio, claro y libre de bugs. En el mundo real de la mayoría de los mortales, cada vez lo hacemos mejor, vamos mejorando nuestra cobertura y cada vez nos salen menos bugs, pero “haberlos haylos”. Además, no siempre hemos sido “tan buenos” y siempre hay legacy code que hace aguas por algún sitio.

4. ¿Tienes que entregar un release plan?

Esto sucede en la mayoría de los equipos de desarrollo, no obstante la respuesta afirmativa a esta respuesta está altamente ligada a la primera pregunta que planteo, cuando el proyecto es grande hay que proporcionar al cliente un calendario de entregas de funcionalidades de su producto. Cuándo previenes que a lo largo de tu proyecto van a surgir numerosas tareas inesperadas es complicado proporcionar un release plan.

5. ¿A menudo te encuentras con numerosas tareas “no esperadas” con prioridad alta?

Las dichosas tareas no esperadas son unas rompe-sprints, son al tablón lo que Belén Esteban a Tele5, sea el momento que sea siempre aparecen por algún lado. ¿De verdad quieres que sigan apareciendo? ¿No es mejor tenerlas controladas? Si tienes sprints y siempre te acaban colando este tipo de tareas, quizá Kanban o Scrumban se adapten mejor a tu equipo.

6. ¿En tu equipo hay gente especializada en, por ejemplo, QA o despliegue en producción?

Esta pregunta es muy importante, los equipos que siguen Scrum por definición han de ser multidisciplinares, si tenemos alguién especializado en algo, ¿No nos sirve? ¿Ponemos a alguien con años de experiencia a dedicarse a otras áreas de trabajo?

7. Ante varios productos, ¿puedes alternar la prioridad de un producto sobre otro?

Si tienes dos productos de una dimensión importante tienes que ir dando más prioridad a uno frente al otro en cada sprint, para que al menos un cliente encuentre jugoso el fín del sprint, a no ser que a ambos clientes les puedas ofrecer un flujo constante y regular de entregas.

8. ¿Pueden añadirte tareas más prioritarias sin previo aviso?

Tienes que pensar muy detenidamente cómo vas a poder afrontar o reaccionar ante una tarea que de repente cobra una prioridad máxima, ya sea una que ya estaba en el backlog y que ha cambiado su prioridad, como una no esperada.

9. ¿Toda tu pila de producto está priorizada?

Idealmente tu backlog está perfectamente priorizado, pero a menudo nos encontramos con backlogs parcialmente priorizados o de user stories idempotentes, en este caso si tienes limitado el WIP (work in progress) tu capacidad de reacción ante nuevas tareas o tareas más prioritarias es mucho mayor que si te mueves entre sprints

10. ¿Tienes que proporcionar soporte a tus clientes?

Obviamente, si tienes que proporcionar soporte a tus clientes, nunca sabes cuándo te van a llamar y por tanto vas a tener, sí o sí, tareas inesperadas. Como he mencionado anteriormente, haz que esas tareas estén perfectamente definidas y controladas, tienen que tener hueco en tu tablón.

Conclusiones

Si hay mayoría de respuestas afirmativas en 1, 2, 4, 7 y 9, entonces la balanza se inclina hacia SCRUM. Todo tiene sentido: pila de producto priorizada, sprints, proyectos grandes con entregas incrementales, equipo multidisciplinar…

Si has contestado afirmativamente en la mayoría de estas: 3, 5, 6, 8 y 10, estás muy cerquita de KANBAN con tareas no esperadas, flujo constante de trabajo, bien con equipos especializados o multidisciplinares…

Un momento, ¿Y si hay un empate técnico o no está muy decidido el resultado? Ok, ¿entonces por qué no consideras SCRUMBAN? Tienes toda la potencia de ambas metodologías: iteraciones bien definidas para tus productos y capacidad de reacción para aquellas tareas que “surgen de la nada”, siempre controlando las velocidades por sprint y las velocidades positivas y negativas de Kanban.

Más información | Scrumban
En Genbeta Dev | Ser ágil es algo más que iterar

En el anterior artículo hablábamos del sentido de las iteraciones/sprints en las metodologías ágiles, y una de las cosas que resaltaba era la necesidad de la entrega de valor continúa.

Para esto hay una cosa fundamental que no debemos olvidar: que la calidad, en el sentido más amplio de la palabra, no es opcional. No me refiero sólo al típico “que no falle”, sino a ¿entrega el valor esperado? ¿Resuelve los problemas que debería? ¿Cómo se comporta esto ante condiciones anormales de negocio (p.ej.: 1000 usuarios)?

Ante esto, cuando estamos trabajando con esta mentalidad, debemos de poner la calidad como foco desde el principio. Se acabó esa forma de pensar en la que los testers son un equipo, normalmente el enemigo, de los desarrolladores. Ese típico ir y venir de descripciones de fallos (seguro que todos recordáis el mítico Pong).

Recordemos, en las metodologías ágiles siempre hablamos de equipo. Esto no quiere decir que dentro del mismo no haya gente que sepa más acerca de un tema que de otro, eso es lógico, pero todos forman parte del mismo barco. Si este se hunde, todos al agua. Y en este caso es lo mismo, la gente que define y ejecuta las pruebas de la aplicación son parte del equipo, y por tanto debemos incluirlas y colaborar con ellas. No son un equipo a parte que vive de la sangre de los desarrolladores … bueno vale aquí me he pasado …

Y como parte del equipo, ¿cuándo intervienen?. Tradicionalmente la ejecución (y a veces hasta la definición) de las pruebas se ha dejado para el final, esto siempre me ha recordado mi época de estudiante, ese dejar el estudiar para el día antes del examen. Y, como ya sabréis muchos, ese momento suele ser demasiado tarde.

Con las pruebas es igual, si las dejamos para el final, para esa famosa fase de corrección de errores o estabilización, lo que suele ocurrir es que el tiempo se acaba o que finalmente no disponemos del tiempo suficiente para probar las cosas.

La definición, preparación y hasta ejecución de pruebas tiene que ser algo que venga desde el principio, más allá de prácticas recomendables (o necesarias) como pruebas unitarias o de integración durante el desarrollo. Estoy hablando de incorporar a la gente que va a definir las pruebas también en reuniones como el sprint planning.

En estas reuniones iniciales, al igual que obtenemos todos los detalles de lo que necesitamos construir y hacer durante la iteración, también necesitamos saber bajo qué condiciones lo que vamos a crear va a ser aceptado. Esto, por supuesto, debería pertenecer a nuestra Definition of Done, de modo que cualquier historia de usuario o requerimiento, que no pase sus pruebas de aceptación no debería de ser dado por válido.

Ahora bien, ¿qué podemos hacer para asegurar el valor en cada sprint?. Lo más claro es, probar, probar y volver a probar.

Empezaremos con nuestros requerimientos. Todo requerimiento debe de llevar, al menos, un conjunto de pruebas de aceptación definidas al principio. Esto, por supuesto, será algo vivo. A medida que avancemos las completaremos, mejoraremos, crearemos nuevas, al igual que se hace en Scrum con el Sprint Backlog a nivel de desarrollo.

También, desde el inicio podemos empezar con pruebas de exploración, ya sea con las primeras funcionalidades que se vayan completando a nivel de desarrollo, como sobre prototipos, que son una herramienta muy útil para asegurar el feedback temprano del cliente o los usuarios.

Otro método aprendido en el libro Agile Testing de Lisa Crispin, es el uso de ejemplos. Esto consiste en, para cada funcionalidad, describir un ejemplo de uso al menos. De modo que sepamos cual es el procedimiento que realizarán los usuarios. Estos pueden ser ejemplos básicos, o ejemplos más completos estilo end to end.

En definitiva y como conclusión, si queremos entregar valor sprint a sprint, debemos:

• Incorporar la calidad desde el principio, no esperando al final.
• Incluir el equipo de pruebas como parte integral del equipo. No es un grupo de personas que viene a posteriori a validar lo que hemos hecho, pertenecen integralmente al equipo que va a construir el producto y desde el principio.
  

Por supuesto, y como en todas las metodologías, cada situación es potencialmente distinta y siempre nos podemos encontrar con entornos en los que tengamos que hacer, por ejemplo, iteraciones de estabilización o iteraciones en paralelo para pruebas.
Incluso en ocasiones, podemos llegar a realizar iteraciones de release previas al despliegue.

Pero ojo, esto no es una iteración en la que hemos dejado para luego la calidad. Todo resultado
de iteración, aunque no despleguemos, debe ser potencialmente entregable. En estas iteraciones nos concentraremos en convertirlo en entregable. De todos modos este tipo de iteración, suele darse en proyectos muy grandes.

Más información:
Agile Testing quadrants por Brian Marick
Agile Testing de Lisa Crispin y Janet Gregory

En Genbeta Dev | Ser ágil es algo más que iterar

Hemos hablado ya en varias ocasiones de Scrum como una excelente metodología para el desarrollo ágil. Aunque para aplicarlo no sea necesario disponer de ninguna herramienta software, en ocasiones cuando se trabaja con equipos dispersos o incluso si lo aplicamos nosotros mismos está bien tener una herramienta online que nos ayude a llevar un control global del proyecto. Scrumrf cumple precisamente esa función, ya que nos permite gestionar proyectos de manera ágil con todas las funcionalidades esperadas como poder gestionar el backlog, crear proyectos, manejar sprint con sus tareas y estimaciones, ver una visión global en un calendario, además de las gráficas de burndown o burnup.

Con Scrumrf podemos manejar toda la información relacionada al desarrollo de nuestra empresa. Disponemos de un panel de control para verificar las tareas que está llevando el equipo, las últimas tareas asignadas. Toda nuestra pila de sprint está contemplada dentro de la aplicación, así podemos decidir las historias de usuario que se quieren entregar controlando la velocidad del equipo. Podemos gestionar ese tipo de tareas desde una lista tradicional o con un muro de sprint, una forma gráfica de ver el seguimiento del sprint, como ya comentamos con Scrumblr.

Para comenzar basta con crearse una cuenta (de momento gratuita) y empezar a crear nuestros proyectos asignado nuestros participantes al equipo, tanto el Scrum Master como el resto de miembros. Se encuentra limitada a dos proyectos por cuenta y cinco personas en el equipo. Todavía no hay planes de precio para una posible versión premium.

Scrumrf ha sido desarrollado por Tonkalabs, formado por dos programadores españoles que han decidido crear un producto en internet, relacionado con la programación y, además de momento de forma gratuita. Aun quedan cosas por pulir, pero esperan feedback de todo el que quiera participar sugiriendo propuestas de nuevas funcionalidades. Si os interesa, está desarrollo de la aplicación se ha hecho usando PHP con el framework Yii.

Vía | Pensamientos Ágiles
Sitio web | Scrumrf
Más información | TonkaLabs

En un principio se crearon los programadores y los proyectos, pero no había nada más que tinieblas y el espíritu del cliente cabreado planeaba por los departamentos.
Así que un buen día, dos tipos llamados Takeuchi y Nonaka dijeron: ¡Hágase el Scrum!
Y vieron los jefes de proyecto que era bueno, y volaron sombreros en algarabía.
Casi sin saberlo, se había inventado lo que iba a ser una de las implementaciones Agile más populares del planeta.

¿Qué aportó Scrum que lo diferenció del resto de formas de gestionar proyectos? En mi opinión dos aspectos básicos: transparencia con los clientes y ciclos de release periódicos y definidos.
En los otros sistemas de gestión que usé anteriormente (if any!) los proyectos se cargaban de una pesada losa de documentación que se llevaba casi la mitad de los costes disponibles y que el cliente debía firmar entre un mar inmenso de dudas (y de papeles).
Esta es la semilla de las frustraciones y lo que ha marginado a los proyectos de software hacia una de las experiencias más insatisfactorias que pueda sufrir el ser humano, junto a la de participar en juegos de azar y ponerse a dieta.

Tocar el producto desde el principio

Ver el producto mientras crece
(Foto: http://thegardenpalette.wordpress.com)

Este aspecto es el más valorado por el cliente, quien es ni más ni menos que el que nos paga.
La sensación de estar metido desde la “mórula”, la génesis de su proyecto, les hace ser más comprensivos con los posibles imprevistos que puedan ir surgiendo, amén de proporcionarles una infinita tranquilidad sobre su inversión.
Yo lo comparo con comprar por internet: pagas por algo que no has tocado, ni olido ni visto. ¿Quién no mira el tracking code para ver dónde está el paquete? Puede que esté parado en Berlín y lleve tres días, pero sabes que está ahí.

Con Scrum el futuro propietario del producto, el padre adoptivo, también sabe dónde está, y además también sabe cómo se va construyendo. Esto que parece nimio es nuestra revolución. ¡Estamos iniciando a un muggle a los rudimentos de la magia! Esta persona aprenderá que los programas no son “dar un botón y listo”, que tienen tanto de artesano como ese Murillo que tanto admira y que sabe que es único.
Será comprensivo (salvo Saurons) cuando le digamos que ese BotónVerdeQueSaltaYVuela que le prometimos es totalmente imposible, pero que intentaremos hacerlo de una manera parecida.

Lo que hay que hacer bien clarito

La gran herramienta de Scrum es el Product Backlog, que no es ni más ni menos que la lista de funcionalidades que debe realizar el software que vamos a empezar a hacer, perfectamente ordenada y documentada incluso a nivel de procesos.
Es la Herramienta, así con mayúsculas, y todo el mundo podrá verla y tocarla desde el principio.
Lo ideal es montarla como una Wiki, y que vaya evolucionando como el germen de la documentación del proyecto, ayudándolos de los resultados de los sprints y las actas de reunión.

Mantener al equipo centrado

Es común que haya interferencias externas (teléfono, propuestas de cambio, etc) que desconecten a los programadores de su tarea. Tarea dicho sea de paso que está mal reconocida y valorada. Programar es algo muy complejo y necesita una altísima carga de concentración y de eficiencia mental. Cualquier distracción hará que el desarrollador tenga que perder dicho estado de foco en la tarea y, después de 10 minutos al teléfono, tenga dificultades para saber qué estaba haciendo justo antes.

Concentrarse en las tareas evita errores
y facilita los objetivos (Foto: http://www.pce.uw.edu)

El Scrum Master es nuestro “papi”, que lo arregla todo todo, y que evita que tengamos que sufrir dichas distracciones y cuyo trabajo nunca es fácil, teniendo que manejar las situaciones con la maestría que les caracteriza.
Este rol es fundamental y, bajo mi punto de vista, es el más importante de todos. Era un rol que hacíamos los programadores habitualmente cuando llamaba el cliente para quejarse por algo o para preguntar qué tal iba el módulo ChachiOptimizador que le estábamos haciendo.

Objetivos cercanos y factibles

Los Sprints son eso: objetivos a realizar en un corto periodo de tiempo que incrementarán la funcionalidad del software.
Para los programadores este aspecto es magnífico porque nos permite saber qué tenemos que hacer (ojo a ese plural) para cumplir la planificación prevista.
Las tareas son concretas, divisibles por módulos y asignables libremente (en principio), y usando un Pomodoro todo parece más fácil, y lo mejor de todo es que ¡es trabajo en equipo!

Scrum Board de tareas domésticas (Foto:http://scrum4kids.blogspot.com)

Cualquier cambio o nueva característica habrá de respetar el Sprint. Nada de imprevistos durante ese tiempo cerrado e intocable, ya se planificará en la siguiente iteración.
Ah, y ojo con valorar dichas novedades en tiempo y dificultad sin contar con los que las tienen que hacer: en Scrum eso es ilegal.
Y nada de sofisticados sistemas: una pizarra, papeles y un reloj de cocina es lo único que vamos a necesitar. Con esto no habrá proyecto que se nos resista.
Esta es la revolución Scrum, y ha venido para quedarse, al menos en mi equipo.
Ha llegado la cordura a la gestión de proyectos.

Foto portada | www.martinalaimo.com

Craig Larman, especialista en procesos de desarrollo, autor de siete libros técnicos y con una larga experiencia de más de 30 años en el desarrollo de software, habla acerca del desarrollo incremental del software. El desarrollo incremental consiste en simplemente hacer crecer un software, no construirlo como se haría un edificio. Hoy en día los conceptos o entidades tratados en el software son complejos de especificarlos de antemano. Por ello, se debe enfocar el desarrollo de un modo diferente.

Actualmente, el hombre vive inmerso en una naturaleza compleja, llena de técnicas y ciencias complejas y diversas. Todo ello se ha conseguido realizando pequeñas mejoras sobre el estado anterior sin haber planificado de antemano donde vamos a llegar.

Del mismo modo, nuestros sistemas de software deben desarrollarse de manera creciente basado en un desarrollo incremental que haga mejoras según nuestras prioridades o necesidades. Craig comenta que siempre ha trabajado con esa mentalidad y cuando a mediados de los 80 escuchó por primera vez la palabra “arquitecto del software”, le pareció disonante con su perspectiva.

Andrew Hunt y David Thomas, en su libro “The Pragmatic Programmer: From Journeyman to Master“, comentan que la ciencia del desarrollo de software “se parece más a la jardinería que a la arquitectura”. La palabra arquitectura no es solo una metáfora, es la influencia sobre la política y la gente. Cuando una tarea la asemejamos a la arquitectura, se da a entender que hay una “fase de arquitectura” donde trabajan los arquitectos calculando todo y una “fase de desarrollo” donde los obreros ejecutan la obra.

Por lo general, en el desarrollo del software esto nunca ocurre así y cualquiera con experiencia en ese mundo lo conoce. Sin embargo, existe una influencia importante de las políticas y comportamientos en la formación. En ocasiones personas no expertas técnicamente pero con poder político escuchan la palabra arquitectura y en seguida sugieren políticas de impacto, procesos, planes, etc, semejante a la arquitectura del sector de la construcción.

Por todo ello, lo más interesante es pensar en “jardinería” más que en arquitectura, en una cultura de diseño creciente para evitar tal asemejanza con la construcción de edificios. Se suele creer que una arquitectura ágil proviene de un comportamiento ágil. No es el uso de un patrón de diseño particular, si no por las acciones y la mentalidad.

Fuente original | InfoQ

Uno de los puntos claves de Scrum es que el equipo se reúna alrededor de un tablón en la reunión diaria para comentar que se ha hecho, lo que se va a hacer y los impedimentos que se tienen. Cuando los desarrolladores trabajan en un mismo proyecto a distancia es necesario manejar una serie de herramientas para mantenerse ágiles. Ya sea Dropbox, Skype, Evernote, wikis o cualquier aplicación colaborativa que ayude al equipo a organizarse , pero sigue faltando un elemento fundamental en el que todo el mundo pueda interactuar: el tablón físico con las historias y tareas propias del Scrum.

Para solventar la carencia de un tablón en el que todos los desarrolladores puedan interactuar en tiempo real, sin importar la distancia, surge Scrumblr. Una herramienta muy simple, realizada por Ali Asaria que nos permite compartir la evolución de nuestro trabajo entre equipos distantes.

Para probarlas podemos ir al sitio web de scrumblr.ca, hacernos una cuenta donde tendremos un tablón scrum con url propia y ahí el equipo podrá interactuar a distancia colocando sus propios post-it sobre el tablón moviéndolos sin problema. También se puede montar en un servidor propio, ya que el código ha sido liberado y disponible en GitHub. Scrumblr está desarrollado con Node.js, socket.io, Jquery que aportan un fludez impresionante en tiempo real.

En definitiva, una herramienta esencial para la gestión ágil de proyectos que facilitará la vida a los equipos que trabajen a distancia y quieran mantener una filosofía ágil con un tablón Scrum lo más parecido al real.

Vía | Navegapolis
Sitio web | Scrumblr.ca
Más información | repositorio del código de Scrumblr (github), blog Ali Asaria
En Genbeta Dev | Mike Cohn, reflexiona sobre 10 años del manifiesto ágil utilizando Scrum