El concepto de terminado en el mundo del desarrollo de software

La semana pasada, en medio de la vorágine que esta suponiendo este mes de Agosto, escribí un post en el blog de Kabel Sistemas de Información donde hablaba sobre el concepto del trabajo terminado.

En el ámbito del desarrollo del software, vamos a encontrar que en función del rol que interectue con una tarea, normalmente el significado de terminado es diferente. Es muy importante, definir que se espera de una tarea y cual es el camino para conseguirlo. A continuación podéis leer el post, o podeís acceder al post que escribir originalmente en el blog de Kabel.

Acabado, cerrado o terminado, son palabras usadas comúnmente para referirnos a lo mismo: el momento en el que a una tarea no es necesario dedicarle más tiempo.

Probablemente el concepto de terminado, sea uno de los conceptos que más controversia levanta en el mundo del desarrollo de software, ya que es algo muy habitual que el concepto de terminado sea diferente para los diferentes roles que intervienen el ciclo de desarrollo y por lo tanto, cuando una persona del equipo de desarrollo dice esto esta terminado o cerrado, el jefe de proyecto, el arquitecto o el product owner esperan una resultado concreto que casi seguro es diferente al que espera alcanzar el desarrollador.

¿Que supone esto? tareas que se reabren / tareas que no se cierran, fricciones y en algunos casos frustración.

Evitar los problemas que surgen en relación al trabajo terminado es un propósito que tiene que perseguir la persona que esta liderando el desarrollo del proyecto y además, tenemos que entender la importancia que tiene ya este concepto esta directamente relacionado con otros de gran importancia, como la evolución del proyecto o el trabajo ideal.

Evitar los problemas que surgen en torno al trabajo terminado es algo asumible, simplemente, prueba lo siguiente:

Define cuando se encuentran las tareas terminadas.

Las tareas se encuentran terminadas cuando el responsable de hacer las pruebas dice que esta terminada.

Sencillo, contundente y sin dejar lugar a ningún tipo de duda. Una tarea estara acabada cuando la persona que prueba dice que esta acaba y que no es necesario dedicarle más tiempo.

Los hay que también defienden que una tarea esta acabada cuando una vez se ha desplegado la solución funciona en un entorno idéntico al que será el entorno de producción. Más o menos es lo mismo, ya que cuando decimos que el responsable de pruebas dice que esta acabada, esto implica que la solución ha tenido que desplegarse, que la solución ha de ser estable etc.

Una tarea estará terminada cuando el responsable de hacer las pruebas dice que esta terminada. En esta afirmación hay una parte muy importante que es “el responsable de hacer las pruebas”, es decir, damos por hecho que tendremos una persona implicada en el proyecto cuya labor sera probar y decir que es lo que esta y que no esta cerrado. Una persona que en definitiva se responsabiliza de lo que se va desarrollando y de que los  acabados y niveles de calidad del producto son suficientes.

Define que significa terminado y que niveles de calidad esperas cuando algo esta terminado.

Comparte con el equipo de desarrollo que esperamos cuando algo esta terminado. La comunicación dentro del equipo es directamente proporcional al resultado del ciclo de desarrollo. En relación a las tareas que se encuentran hechas y las que no lo están, también. Como hemos dicho en la introducción normalmente nos encontramos que el concepto de terminado es diferente en base al role que desempeña cada uno de los miembros del equipos, así pues, unifica el concepto de terminado, deja claro cuando esta terminada una tarea y que es lo que implica.

Un buen ejercicio, es describir que es lo que se espera de cada una de las tareas y dejarlo escrito. Evidentemente esto tiene un coste en la gestión / creación de tareas, pero este sobre coste sera siempre inferior al coste que tiene sentarse con cada miembro del equipo que participa en el desarrollo de una tarea y contarle que esperas de ella o por supuesto, del coste que tiene esperar un resultado sin especificar cual es el resultado.

En un proyecto en el que participé, nos encontramos que el día que nos hicieron una demo del proyecto con las tareas terminadas, no se había realizado ningún trabajo en relación a la interfaz de usuario. Cuando nos hicieron la demo del supuesto trabajo terminado y preguntamos que pasaba con la solución ya que no tenía una hoja de estilos que plasmara la imagen corporativa del cliente ni ayudara a comprender lo que se le estaba exponiendo al usuario final, la respuesta fue:

El trabajo esta hecho, los estilos son interfaz.

Poco que decir al respecto la verdad. No obstante, ¿Que es lo que ha pasado para que un proyecto se considere terminado cuando falta por desarrollar una de las piezas más importantes del mismo?

No utilices el termino terminado.

Terminado es un concepto demasiado absoluto, muchas veces lo utilizamos pero no siempre es el mejor. Es decir, dado que vamos a tener en el equipo una persona que va a ser el responsable de definir que esta terminado, trata de que el termino terminado solo lo utilice él.

Desde el punto de vista del desarrollador, puedes utilizar otros términos, términos no tan absolutos que te dan margen para interactuar con las tareas, por ejemplo, en scrum, es un formalismo comúnmente aceptado utilizar los términos rojo y verde.

  • Rojo cuando la tarea se encuentra en progreso.
  • Verde cuando ya se ha realizado el trabajo y podemos considerarlo hecho.

Como conclusión, evitar los problemas que surgen en relación al trabajo terminado, es tan sencillo como hacerle ver al equipo cuando se puede dar una tarea por cerrada, quien dice que esta abierto y qué está cerrado y sobre todo que todas las personas que intervienen en el ciclo de desarrollo, tengan el mismo concepto de lo que supone que algo este terminado.

Y a tí, ¿que te parece? Espero comentarios.

Anuncios

Equipos de desarrollo, productividad y software o como mejorar la productividad del equipo de forma sencilla

Anoche, escribi un post muy chulo sobre como mejorar la productividad de los equipos de software en el blog de Kabel, compañia para la que trabajo.

En este post, cuento experiencias propias que pongo en práctica en los proyectos que ejecuto con Kabel. En el hablaba de una serie de prácticas que van a promover que el equipo de desarrollo se encuentre coexionado y alineado con una forma de trabajar y los objetivos que hay que cumplir.

Si quieres leerlo, puedes hacerlo mediante el post escrito en el blog de Kabel, o a continuación:

Uno de los aspectos recurrentes al que nos enfrentamos cuando nos encontramos inmersos en el desarrollo de proyectos de software es la gestión del retraso en la ejecución de tareas planificadas por parte del equipo de desarrollo.

Normalmente, antes de iniciar cualquier proyecto, incluso antes de de haber ganado un proyecto, se realiza un ejercicio de definición de alcance del proyecto y estimación. Estimar es un proceso (normalmente) empírico por medio del cual tratamos de definir el coste en tiempo(por lo tanto también en dinero) del trabajo que vamos a realizar. ¿Qué sucede en la vida real? que en algunas ocasiones, nos encontramos con que el tiempo dedicado a la ejecución de las tareas es más alto del que hemos estimado / planificado.

Cuando estoy liderando un equipo que crea software y detecto que esto sucede, la primera aproximación que realizo es tratar de analizar como esta trabajando el equipo y ver si hay un estado mental de equipo y proyecto. Que quiero decir con esto, pues simplemente que el equipo tiene que avanzar en un dirección y todos los miembros del equipo tienen que tener en la cabeza cual es el próximo objetivo a alcanzar, cuando lo vamos a alcanzar y la calidad que tenemos que alcanzar para poder calificarlo de éxito.

Es muy importante que lleguemos a este estado mental de proyecto ya que esto nos va a permitir ser mucho más productivos y aumentar el velocity de forma significativa.

Como lo conseguimos:

El equipo ha de estar junto.

Que el equipo de desarrollo ha de estar junto parece evidente, pero es sorprendente ver como algo que debería ser habitual no siempre sucede y encuentras que en una misma sala, hay varios equipos de desarrollo y cada miembro de los equipos, en una punta de la misma.

Esta situación genera interrupciones (por ejemplo, cuando tenemos que preguntar algo y nos levantamos y te cruzas con otro de tus compañeros y se mantiene una charla), genera ruido(cuando dos personas hablan desde sus sitios en voz alta), genera problemas de comunicación (ya que es muy dificil realizarla de forma eficiente), no permite que se comparta el conocimiento correctamente (la distancia física fomenta que no todas las personas puedan acceder al mismo) etc.

Reduce el espacio físico y pon a todos los miembros del equipo juntos y si puedes separados / aislados del resto. Verás como de repente, el equipo estará más centrado, verás como hay menos interferencias en la realización de tareas, verás como la comunicación es más eficiente y fluida y verás como poco a poco se crea ese ambiente de proyecto, es decir de tensión debido precisamente a que evitamos todo lo anterior.

Reduce las interferencias al equipo.

Muy importante. Reduce interferencias. Si ves que alguno de los miembros del equipo constantemete es interrumpido, trata por todos los medios que esto no suceda.

Cual es la mejor forma, nombra a un miembro del equipo como el portavoz (o como lo quieras llamar) del mismo, canaliza todas estas interrupciones a través de el y que sea esa persona el que se encargue de gestionarlas. Si alguno de los miembros del equipo, se encuentra desarrollando a tiempo parcial, trata de cerrar ese tiempo en base a jornadas, es decir, es mejor que este de lunes a jueves al 100% y el viernes se dedique a otro proyecto a que cada día de la semana le dedique una horita a ese proyecto.

La concentración del equipo en las tareas que esta realizando es directamente proporcional a la calidad, velocidad y resultado de la ejecución de tareas, por lo tanto del proyecto.

Crea hábitos.

Crea habitos, trata de realizar la reunión de scrum SIEMPRE a la misma hora, trata de ir a comer a la misma hora, trata de tomar el cafe a la misma hora y además, trata de hacer todo esto con todo el equipo. Nos reunimos todos, tomamos el cafe todos y comemos todos juntos. Estas acciones simples, permiten crear esa conexión de la que hablaba anteriormente, permite crear ese estado mental y en la práctica, implica que cuando tomamos cafe, tratamos de resolver dudas respecto a tareas, comentamos problemas que hemos encontrado, le ayudamos a un compañero, así que, cuando  estamos en la reunión de scrum, hablamos del proyecto, cuando tomamos cafe, hablamos del proyecto, cuando comemos, hablamos del proyecto, cuando… hablamos del proyecto. PROYECTO, PROYECTO, PROYECTO.

El proyecto siempre ha de estar presente y todo el mundo tiene que estar a mil con el mismo. Desde luego para asuntos personales / sociales etc. también hay tiempo, pero trata de que sea menor que todo lo relativo al proyecto.

Comparte objetivos, fechas y plazos.

Comparte los objetivos, fechas y plazos, es más, haz participe al equipo en la planificación de estos objetivos, de las fechas y los plazos y trata de que todo mundo este involucrado y de acuerdo con estos aspectos.

Que los compromisos salgan del equipo, siempre te va a ayudar a compartir la responsabilidad y que cada uno de los miembros del equipo trate de conseguir este objetivo ya que son responsabilidad suya directamente.

Que todo el mundo tenga presente que hay que entregarle al cliente y cuando hay que entregárselo.

Fomenta las buenas relaciones del equipo.

Todos los miembros  del equipo han de tener con sus compañeros una relación de confianza basada en el respeto. Es muy importante que el equipo este a gusto con sus compañeros, que disfrute trabajando con ellos y que los conozca bien.

Como fomentar estas buenas relaciones, pues simplemente al crear hábitos ya estas haciendo algo importante, además también puedes tratar de realizar alguna actividad que vaya en esta linea.

Lo que esta claro es que el equipo tiene trabajar bien junto y las relaciones tienen que basarse en el respeto. Si alguien no cumple con esto, tendrá que salir del equipo.

Aquí acaba el post, y a tí ¿que te parece?

El diagrama de burndown en la práctica: El burndown del proyecto NBICI

El viernes de la semana pasa, publique una entrada en el blog de NBICI en la que hablaba del diagrama de burndown. El proyecto NBICI, se esta desarrollando de forma ágil y podría casi casi decir que en modo garage. Muchas veces los profesionales del sector ajenos al agile, tienen la opinión que desarrollar en modo ágil por medio de scrum (o lean o kanban), implica no gestionar lo cual está totalmente alejado de la realidad.

El diagrama de burndown tiene como cometido representar de forma gráfica la evolución del desempeño del equipo en un proyecto concreto y compara este desempeño con el trabajo ideal a realizar.

A continuación podeís leer la entrada y ver el diagrama de la primera semana del sprint:

El diagrama de burndown, es una representación gráfica del trabajo por hacer (y por supuesto también del trabajo hecho) en el tiempo. Este diagrama normalmente se utiliza para predecir cúando se completara un trabajo concreto en base a una temporalidad concreta.

Por medio de este diagrama, representamos el trabajo actual en comparación con el trabajo ideal, y nos permite de un solo vistazo, detectar si vamos adelantados o retrasados respecto al trabajo planificado a realizar durante el Sprint. El diagrama de burndown, es muy utilizado en las metodologías de desarrollo ágil de software (agile), y sobre todo en Scrum.

El burndown, de esta semana, podéis verlo a continuación:

2012 - 08 - 03 - Diagrama de burndown

Como se puede observar, en esta primera semana, hemos acumulado un retraso importante aunque seguro que podemos subsanarlo