Resumen: El desarrollo de software es una disciplina en la cual la motivación de las personas que lo crean es directamente proporcional al resultado de la creación del mismo, por lo tanto mantener motivado al equipo es una de las tareas más importantes que has de realizar. Sigue leyendo
Archivo de la etiqueta: liderazgo
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.
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?
6 consejos a tener en cuanta cuando lideramos equipos que crean software.
A continuación os dejo con un post que escribí en su momento en el blog de Kabel Sistemas de Información compañía en la que trabajo y desempeño mi carrera profesional.
Siguiendo la estela del post 6 consejos a tener en cuenta cuando escribimos software, hoy vamos a ver algunos aspectos que se dan en los equipos encargados de generar software que tenemos que tratar de evitar.
El código no es ni tuyo ni mío, es nuestro.
Una frase típica en los equipos de software es “mi código funciona”. El código no es tuyo, es del equipo, es nuestro. Siente el código que ha desarrollado otra persona del equipo como tuyo, esto, te va a obligar a involucrarte más en el desarrollo y ser más crítico con nuestro trabajo.
En mi equipo funciona.
El software que desarrollamos no funciona hasta que está desplegado en los entornos de producción y vemos que funciona. Eso de “en mi equipo funciona” es un error. Tenemos que asumir que nuestro código falla, y una vez refactorizado y muy probado, podemos tener la seguridad de que funcionara ok, pero no te lo creas hasta que no lo veas.
Cuantas veces te has encontrado con este caso. Muchas. Aprende de los errores y asume que el entorno de desarrollo no es el mismo que el de producción, que los servidores no van a estar siempre configurados de la misma forma y que aunque no lo queramos, pueden aparecen sorpresas a última hora.
Despliega el software que estas creando de forma asidua en un entorno exactamente igual que el de producción y no te encontraras con estas sorpresas de última hora, que implica cambios a fuego en ficheros de configuración o trabajos a deshoras de la noche.
Los equipos grandes son inversamente proporcionales a la productividad.
Cuanto más grande es un equipo menos productividad tiene el mismo.
Cuanto más grande es un equipo más obligado te vas a ver a realizar tareas de documentación, revisión de código, gestión de tareas, gestión del equipo, etc.
Evítalo.
Si el proyecto es muy grande, crea equipos más pequeños con tareas concretas. Delega funciones. Verás cómo la gente está deseando involucrarse en tareas que de otra forma tendría que realizar el jefe de proyecto / arquitecto y cuanta más gente, más trabajo y sobrecarga para esta persona.
5 equipos de 4 – 5 personas y un jefe de equipo van a ser mucho más productivos y eficientes que 1 equipo de 30 personas.
Interfaces de usuario y perfiles muy “juniors”.
Es un clásico, a menudo se desprecian las interfaces de usuario y se ponen a las personas con menos experiencia a implementarlas.
ERROR GRAVÍSIMO.
La pieza más compleja de toda aplicación, es la que le permite la comunicación hombre-máquina.
Pon ahí a gente con experiencia, profesionales que entiendan que están haciendo, que tengan gusto por el detalle y las cosas bien hechas y sobre todo que le den la importancia que tiene.
La tecnología es un medio no un fin.
La tecnología es el medio que nos va a permitir desarrollar ideas o resolver problemas y tenemos que usarla para eso.
En muchas ocasiones, cuando estas desarrollando software nos olvidamos de esto perdiendo el foco de las tareas que tenemos que realizar, para crear plataformas tecnológicas que se apartan la “idea” inicial que pretenden resolver.
Los mejores han de estar en tu equipo.
Rodéate de los mejores. Busca buenos profesionales. Gente que haya puesto aplicaciones en producción. Es complicado, pero existen muy buenos profesionales con gusto por lo que hacen, búscalos e incorpóralos al equipo de desarrollo.
Como aumentar la productividad.
Hace algún tiempo, estaba muy interesado en todo lo relacionado con la productividad, y la verdad es que debería estar presente en cualquier tarea de cualquier profesional, independientemente del sector, ya que es algo totalmente positivo y necesario.
Si estás gestionando equipos, léelo, ya que es totalmente necesario.
Mientras leía esta mañana mis RSS, estaba escuchando a Portishead. Los más grandes del Trip Hop, que son capaces de crear canciones tan Joy Division como esta.
A deshoras 