Archivo de la etiqueta: Management

SCRUM de dos equipos en distintas ciudades

Management, Programación, Proyectos, Técnico,

El pasado mes de mayo comenzamos el desarrollo de un nuevo proyecto que ha terminado recientemente, al menos la primera fase del mismo. Partimos casi de cero, los requerimientos eran muy básicos y poco documentados, pero parte del equipo teníamos en la cabeza exactamente lo que teníamos que hacer, de hecho era plasmar en una única aplicación todo nuestro trabajo de los últimos cuatro años.

Desde el principio nadie tuvo dudas, SCRUM era la mejor metodología posible para cumplir los plazos que nos habían impuesto. Planteamos sprints de dos semanas y dailys diarios (obviamente) a las 10 de la mañana de alrededor de 10 minutos. Como scrum master se quedó uno de nuestros project managers y como product owner otro del departamento de operaciones. La mayoría nos habíamos leído ya el Scrum desde las trincheras, pero una cosa es la teoría y otra muy diferente la práctica, y ahí casi nadie teníamos experiencia.

No trataré en este artículo de enseñaros SCRUM, no soy un experto, como mucho un poco “evangelizador” :P, simplemente trataré de explicar mis sensaciones tras cinco meses de SCRUM intensivo.

El Equipo

En el proyecto participaron dos equipos de desarrollo, uno en Valencia de 6 personas y otro en Madrid en el que llegaron a trabajar más de 30. Ninguna de estas casi 40 personas tenía disponibilidad completa para este proyecto sino que hubo que redistribuir toda la carga de trabajo para, con el mismo equipo, asumir un nuevo proyecto de cinco meses de duración. Salió bastante bien. Los dailys se hacían vía conferencia entre una sala de reuniones en Madrid y otra en Valencia. Se hicieron, además, infinidad de reuniones a dos bandas entre los dos equipos para decidir funcionalidades, discutir los puntos donde no había acuerdo y resolver dudas.  No sólo participaban desarrolladores sino también jefes de equipo, project managers, diseñadores, “expertos” en usabilidad, gente de testing y calidad, documentalistas, gente de sistemas, de datawarehouse…

En la parte tecnológica tuvimos otro grave problema. Desde Madrid desarrollaban en .NET y desde Valencia en PHP. ¿Cual es el problema? :P. Se diseñó la arquitectura de manera que la aplicación trabajase indistintamente en uno u otro lenguaje. Dentro de un mismo entorno web, unos módulos se cargan de un lado y los otros del otro de forma completamente transparente al usuario. Se diseñó un sistema de single sign on que pudiesen compartir y consultar ambas tecnologías y, asociado a éste, todo un mecanismo de seguridad de acceso a distintos menús y opciones de la aplicación. El resultado fue formidable, todo funciona perfectamente de una manera integrada, robusta, eficiente y segura.

La Pila de Producto (product backlog)

Con la poca documentación que se tenía al principio se elaboró una pequeña pila de producto que fue creciendo a medida que las tareas de análisis evolucionaban. A esto debemos sumar requerimientos que iban llegando por parte de los departamentos comerciales y de operaciones. Al final el backlog era considerable. En agosto hubo que decidir quitar algunas historias de usuario ya que era imposible acometer todo lo que se quería, de hecho los requerimientos a estas alturas eran infinitamente superiores a los que se habían supuesto en mayo. Aún así, eliminando cosas, se hizo un producto mucho más ambicioso de lo esperado. Las historias de usuario eliminadas no se olvidaron, simplemente se trasladaron a una segunda versión.

Para el seguimiento del SCRUM, en vez de la clásica pizarra y dada la dispersión de los equipos, decidimos utilizar una herramienta de software. Comenzamos con un sencillo Excel y a mitad del proyecto incorporamos ScrumWorks, no creo que sea el programa ideal pero cumple su función.

Los Sprints

Los tres primeros sprints fueron prácticamente de análisis. Se hicieron documentos funcionales y orgánicos de todos los módulos requeridos y se perdió bastante tiempo definiendo la arquitectura de la aplicación, en realidad de las dos aplicaciones (.NET y PHP). Todo esto nos llevó a plantarnos a mediados de junio, tras 3 sprints, con muy poco que mostrar en la demo, y nos condujo a la consabida reprimenda de los que mandan, nos estábamos desviando (teóricamente) de la planificación estipulada. Sin embargo el tiempo nos daría la razón, el tiempo perdido en el diseño de la arquitectura se recuperó con creces en sprints siguientes y llegamos a la fecha con el proyecto terminado. Bueno, en realidad dejamos para el final un pequeño detalle, el rendimiento, que se solucionó en un sprint adicional.

A todo esto hemos de añadir, como ya he dicho, que el equipo no estaba dedicado al proyecto, cada día variaba la gente que entraba al daily ya que no todos estaban trabajando en el proyecto en ese momento. A eso hay que sumarle lo que llamo “contingencias del trabajo diario“, es decir, nuevos proyectos que van surgiendo durante todo ese tiempo y que implican dedicarle tiempo que tienes que quitarle a lo verdaderamente importante. Por si eso no fuera poco, a finales de junio se nos informa que una parte de la aplicación, un módulo de reporting, tiene que estar operativa a finales de julio puesto que se necesita para dar servicio en otros proyectos. Esto, que de palabra suena sencillo, nos obligó a modificar la planificación, el product backlog y la pila de sprint ya que el funcionamiento de este módulo implicaba a otros (login, seguridad, diseño…). Y aún así cumplimos todos los plazos, increíble. Eso sí, otros proyectos tuvo que decidirse entre descartarlos o aprobar una desviación de una o dos semanas en el proyecto del que hablamos, con lo que de igual manera fueron descartados :P.

Las Estimaciones

Uno de los mayores problemas es, sin duda, estimar las horas de las tareas. Comenzamos quedándonos cortísimos y terminamos quedándonos cortos también, creo que rara vez se hizo una estimación cercana a la realidad. Es muy complicado, sin duda. Las tareas de análisis se sobrestimaron en su mayoría y las de desarrollo (la mayoría) se quedaron cortas. Para planificar los primeros sprints utilizamos Poker-Scrum, pero acabamos haciéndolo directamente de viva voz ya que decidimos que no aportaba nada. En los primeros sprints hubo que arrastrar bastantes tareas de uno a otro porque se habían estimado muy a la baja, sin embargo hacia el final se recuperó el tiempo perdido y las estimaciones no eran tan malas.

Las Demos

Las demos al cliente (interno en nuestro caso) son el peor momento del sprint, no pocos días nos tocó quedarnos hasta altas horas de la noche para llegar a la demo del día siguiente con el trabajo terminado o, al menos, visible. Si esto lo hacíamos cada dos semanas, imaginaos que hubiese pasado si utilizásemos metodologías tradicionales, hubiésemos llegado al final del tiempo de desarrollo sin hacer ninguna demo, sin haber probado las cosas de una manera real. Habría sido imposible, de hecho es lo que ocurre habitualmente :P.

En nuestro caso nos sirvió no sólo para ver la reacción del cliente ante el avance del producto sino también para ver las fortalezas y debilidades del trabajo que estábamos desarrollando y reorientar los siguientes sprints.

Las demos están para que el cliente vea el avance del producto que se le está desarrollando. El cliente en nuestro caso era una persona en representación de uno o varios departamentos internos de la organización. ¿Qué utilidad tienen las demos si sólo asiste el product owner? Digo esto porque de vez en cuando aparecía por allí algún despistado que se dedicaba a criticar el producto, en concreto partes del mismo que llevaban dos o tres meses terminadas y validadas por el product owner. ¿Por qué esa actitud revienta-demos? O mejor aún, ¿por qué no le prestas el debido interés a un producto en el que se basará todo tu trabajo los próximos años? Ah, ya, es más fácil dejar la responsabilidad al product owner y después quejarse. Sin la implicación de toda la organización da igual qué metodología se utilice, ninguna conseguirá triunfar. Estamos hablando de media hora cada quince días, sólo eso.  Otro punto importante a tener en cuenta es la opinión. La gente que asiste a la demo debería estar obligada a decir algo y no quedarse callados como si no fuera con ellos porque al final ocurre lo mismo, cuando tienen que opinar no opinan y después, cuando ya no se puede hacer nada, es cuando hablan.

Retrospectiva y planificación

Las reuniones de retrospectiva fueron bastante interesantes. Por un lado comentábamos la indiferencia de los asistentes a las demos y por otro discutíamos sobre los problemas que se habían presentado durante el sprint, unas veces con más energía y otras con menos. En realidad casi podríamos decir que servían como válvula de escape al pasotismo de los asistentes a la demo.  Son necesarias las retrospectivas, sirven precisamente para evaluar no sólo lo que ha ocurrido sino también los ánimos del equipo.

Tras la retrospectiva llega la reunión de planificación de sprint. Tal como indicaba más arriba, las estimaciones se hicieron muy complicadas, muchísimas tareas por historia de usuario, muchísimas dependencias entre ellas y no siempre tenemos todos en la cabeza las implicaciones que pueden tener unas con otras, lo que termina en estimaciones muy poco aproximadas por no decir aleatorias. Aún así poco a poco se fueron afinando bastante. En las reuniones de planificación se ponían sobre la mesa también nuevos requerimientos que habían ido surgiendo y modificaciones sobre los ya terminados que obligaban a modificar las prioridades de la pila de producto ajustando el calendario a las nuevas necesidades y objetivos hasta llegar a la pila del sprint siguiente.

Conclusiones

Sin duda la experiencia ha sido muy positiva. En otras ocasiones habíamos hecho intentos de aplicar SCRUM a determinados proyectos  que resultaron en utilizar solamente algunos conceptos de SCRUM, pero la falta de implicación del cliente (casi siempre interno) restaba utilidad a la metodología. En esta ocasión se hizo una aplicación completa, real y efectiva, implicando a todos los elementos de la organización que tuviesen algo que decir dentro del proyecto y, aunque siempre se pueden hacer críticas a la implicación de algunos, podemos afirmar que, en general, todos cumplieron con su parte.

Una de las cosas de SCRUM que todos alabamos cinco meses después son, sin duda, los dailys. Nos sirvieron a todos los partícipes del proyecto para conocer de buena mano qué estaban haciendo los demás, qué problemas había,  cuándo se iban a resolver, etc. Creo que cualquier equipo de desarrollo, independientemente de la metodología que utilice, debería realizar reuniones diarias para compartir ideas y problemas.

La idea de tener demos del producto cada dos semanas obliga a todo el equipo a pensar más en hacer cosas que funcionen que en ir avanzando en tareas, es más importante terminar dos historias de usuario para presentar al final del sprint que comenzar 20 tareas que no se terminen.

Uno de los puntos que nos desviaron del objetivo en cada sprint fue el proceso de integración y preparación para la demo. Nunca tuvimos en cuenta estas horas que al final implicaban bastante tiempo de todo el equipo ya que al realizar la integración siempre había cosas que no funcionaban bien. El último día estaba dedicado casi íntegramente a estas labores que nunca estaban planificadas en la pila del sprint.

Los que me conocen saben que llevo ya unos años defendiendo SCRUM como metodología adecuada para el desarrollo de software. Esta experiencia no ha hecho más que confirmar esta opinión, la adaptación del producto al cliente que se consigue no se podría lograr con metodologías clásicas en las que la más mínima modificación de las tareas a realizar puede provocar una desviación enorme.

Supongo que pagamos algo cara la falta de experiencia, sobre todo al principio, pero aún así logramos el objetivo, seguramente con un poco más de experiencia el resultado habría sido aún mejor.

Por cierto, no hemos dejado SCRUM, el proyecto sigue y ya trabajamos en la siguiente release, así que seguimos liados con dailys, sprints, estimaciones…

Motivar y desmotivar en la gestión de personal

Libros, Management, Técnico, , ,

Estas vacaciones de Semana Santa que he pasado en Túnez (pronto contaré la experiencia como siempre 😛 ) me han servido para terminar de leer un libro (en realidad dos) que se me había atragantado un poco, El mito de la motivación, como escapar de un callejón sin salida, de Reinhard K. Sprenge. Lo empecé en diciembre pero hacia la mitad se me hizo un poco pesado, algo que después cambia y se hace mucho más llevadero pues el libro es realmente  interesante y de recomendable lectura a cualquiera que tenga gente a su cargo.

Reinhard, a partir de su experiencia en multitud de empresas, diferencia claramente entre motivación y manipulación,  desmitificando cualquier tipo de sistema de incentivos, léase por objetivos, pagas de beneficios, comisiones… Para él cualquiera de estos sistemas son la respuesta a la acción desmotivadora de algún directivo que no sabe cómo reconducir a su gente después de haber provocado, sin saberlo, la situación que viven.

En un momento del libro, Reinhard dice algo así,

Si nuestros colaboradores son gente adulta, con hipotecas, niños a los que criar y educar, parejas por las que luchar… ¿Por qué hemos de pensar  que en su vida  profesional alguien tiene que tratarlos como críos diciéndoles en cada momento lo que deben hacer y cortando su iniciativa?

Nuestros colaboradores son gente con conociemientos, preparación y experiencia y no quieren un trabajo de marionetas, quieren retos, afrontar problemas y tomar decisiones, pero si alguien se hace responsable permanentemente de las decisiones sin permitir que los demás tomen la inciativa y demuestren su valía nos plantamos en eso que se conoce como “desmotivación”. ¿Quién es el culpable entonces?

Intentar motivar es absurdo e imposible una vez se ha caído en la desmotivación. Por muchos intentos que se hagan por conseguirlo, normalmente a base de incentivos económicos, su éxito será sólamente efímero puesto que el dinero se valora y disfruta en un primer momento, cayendo en el olvido o en la costumbre en los siguientes.

La verdad es que en el libro no se cuenta nada que, desde la perspectiva de los que estamos por debajo, no hayamos visto siempre como “de cajón“, pero parece que hay mucha gente que nunca ha tenido este punto de vista y hay que mostrárselo.

Un libro que todos los directivos y managers deberían leer para entender muchas de las cosas que ocurren a su alrededor.

Y seguimos con la falta de personal técnico cualificado

Personal, Programación, Proyectos, Técnico, , , , ,

Tenía pendiente hacer un comentario desde la semana pasada.

¿Por qué se empeña Enrique Dans en contradecir a cientos de programadores? ¿En serio es creíble el argumento de que no hay personal adecuadamente cualificado en España? Suelo leer a Enrique y creo que es un tío normalmente serio y coherente en sus argumentaciones (estés o no de acuerdo con ellas), pero es que con ésta no puedo, no la veo reflejada por ningún lado en el mundo real.

Mi experiencia me dice lo contrario. Claro que ya no se reciben cientos de curriculums para una oferta de trabajo, pero es que aquello era lo anormal. ¿Acaso recibes docenas y docenas de currilums para un puesto importante de departamentos tradicionales (comercial, marketing, rrhh…)? ¿Por qué esperas entonces recibirlos para un puesto de programador? Un programador es, desde la base de su formación, personal altamente cualificado y han estado puteados durante muchos años. Resulta que ahora cuando comienza a verse un poco de dignidad en el sector, no hay gente, curioso ¿no?, es decir, ahora que queremos jornadas normales y salarios decentes, faltan programadores. Recuerda que, ante todo, buscas a la/s persona/s que diseñarán y construirán tu producto…

Lo he comentado ya en otras ocasiones pero creo que mis razones siguen siendo completamente válidas:

Sobran más palabras ¿no?.

¿Programando a los 50? No, por favor

General, Programación, Proyectos, Técnico, , , , , ,

Los que me conocen saben que uno de mis blogs habituales es Navegapolis, de Juan Palacio. Es un tío muy coherente y con mucha experiencia en el ámbito de la gestión de proyectos de software, pero lo mejor de todo es que habla desde el punto de vista de un técnico, no de un “director de”, y de los problemas que se encuentran los desarrolladores por culpa de la mala gestión de los equipos. Este artículo hace referencias a algunos de sus posts de los últimos meses:

Como referencia a uno de ellos, muy interesante también Circuitos de pérdida de talento, por José Medina.

El viernes pasado, cenando con un alto cargo de RRHH de una multinacional, surgió el tema de los equipos y las selecciones de personal en IT.  Esta persona, antes de su actual puesto, desempeñó puestos similares en consultoras y telecos, con lo que algo sabe del tema. Me sorprendieron, sin embargo, algunas de sus opiniones. Este artículo es la mía.

Desde mi punto de vista y basándome en mi experiencia, un equipo de desarrollo es más que un grupo de gente. Salvo excepciones, son personas con una elevada formación y muy especializada, acostumbradas a pensar, a crear, a diseñar, a las que les apasiona su trabajo, construir, hacer cosas que otros van a utilizar. Esto no se puede entender de otro modo, nadie en su sano juicio se metería en este sector si no le gustase, los salarios son ridículos y el trabajo estresante.

Para entender la mentalidad de un desarrollador debemos comenzar por entender la estructura de un equipo de desarrollo.

Los últimos de la cadena son ellos, los programadores, los que construyen el trabajo, los que afrontan los problemas, los buscan, los solucionan, los preveen, cumplen los plazos… y sólo son los últimos eslabones de la cadena. A continuación tendríamos al responsable del equipo, la pieza clave, el encargado de motivarlos, de valorarlos, de mimarlos. Es el Luis Aragonés de un equipo de desarrollo. Un buen responsable debería preocuparse por la situación personal de su gente,  si tienen problemas (hipotecas, parejas, divorcios, niños…) no rendirán como se espera de ellos. La solución no es pegarles el puro y que se espabilen, es la solución fácil pero la menos buena. Si una persona tiene problemas no necesita que tu le crees más. Es una persona, no un recurso, cuanto antes lo entiendas antes conseguirás formar un equipo.

Encima del equipo y su responsable están toda una maraña de jefecillos y directores de, en general preocupados exclusivamente por su culo y su nómina a final de mes. Gente que hace años pudo ser programador pero se dió cuenta que no tenian un buen futuro y ahora son jefes. Gente para la que su trabajo es cumplir ocho horas e irse a sus casas. No les gusta especialmente su trabajo ni sienten pasión por él, es necesario para llegar a final de mes y punto.

Finalmente están los departamentos comerciales, los encargados de preguntarte plazos y recortarlos a su antojo. Los encargados de decir que sí a todo lo que los clientes solicitan, independientemente de que sea o no viable, ya habrá algún programador que lo solucione, y si no, a trabajar 12 horas diarias y fines de semana para cumplir los plazos.

Bajo esta estructura es fácil adivinar que muy pocos programadores (o ninguno) sienten, con 30 años, que quieren seguir siendo programadores a los 50, picacódigos que decimos. Todos aspiramos a ser responsables o, a poder ser, directores de algo y que otros hagan el trabajo. Triste pero cierto. Hay comerciales, gente de marketing, rrhh… con salarios de 50 a 70.000 euros al año pero nunca habrá un programador, ni siquiera un analista, que llegue a esas cifras. ¿Por qué?. Ellos hacen un trabajo imprescindible, fabrican, piensan, se echan a la espalda un duro trabajo. Un trabajo para el que, en muchos casos, se han pasado años y años en la facultad estudiando, soportando asignaturas y profesores duros (¿ingenierías vs. ADE, derecho, psicología…?). ¿Todo para qué? ¿Para empezar con 800 euros al mes y con suerte, en un par de años, llegar a los 1.000?

Esta persona con la que hablaba me comentaba que, para ella, un equipo eran un par de buenos programadores y el resto picacódigos. Imagino que la estructura que pasaba por su cabeza hablaba más de analistas que de programadores. Aún así es un grave error pensar así. Es como pensar que un equipo de fútbol son dos galácticos y 9 jugadores de relleno que se encargan de dar balones a las estrellas. Qué queréis que os diga, yo prefiero un equipo bien formado de 11 jugadores donde la integración del conjunto cree una estructura sólida y eficaz, un equipo del que ninguno de sus componenes quiere salir pero tampoco necesite destacar, que se sientan valorados y que sientan que participan en algo importante. Alguien diría, claro, ese es el trabajo del responsable del equipo, motivarlo. Y yo le contestaría, entre basura no se puede motivar a nadie. No le puedes hablar de motivación a alguien que cobra 15.000 euros anuales. Su motivación es buscar quien le de 16.500 y cambiar de trabajo. La motivación comienza por el salario y las políticas de mejoras. Si un empleado no puede pagarse un piso, irse de vacaciones unos días o salir a tomar unas copas… ¿cómo vas a motivarle? ¿le vas a contar milongas de que lo que hace es importantísimo? ¿que aquí va a aprender mucho? Yo, sinceramente, me reiría de ti en tu cara.

No vas a ganar la Eurocopa si no tienes equipo. No necesitas a los mejores, pero sí a unos cuantos válidos, compenetrados y motivados. Empieza por un sueldo decente. Trátalos como si fuesen personas, no como animales (de hecho a los animales se les trata muchas veces mejor que a los empleados). Preocúpate por sus vidas y que se sientan valorados. Esa es la motivación que te toca, que sientan que hacen algo útil y que su opinión cuenta, no son simples machacas, es gente que piensa y le gusta encontrar mejores soluciones. Si consigues una maquinaria bien engrasada y trabajando en equipo, sin competencias internas, sin que nadie busque medallitas, con lealtad, con capacidad para reconocer el error de uno y solucionarlo entre todos, amigo, tu trabajo así será mucho más sencillo y productivo.

Cuando un responsable de equipo consigue formar un buen grupo de gente intentará por todos los medios llevárselo con él allá donde vaya, es su garantía de trabajo y confía plenamente en ese equipo, los valora por encima de todo, sabe que su trabajo, si no tiene debajo un buen equipo, será casi imposible.

Siempre se dice que nadie es indispensable, y es cierto, nadie lo es, pero el hecho de que una persona abandone el equipo y entre una nueva puede llevar a tu equipo al fracaso. Puede desestabilizarlo, crear competencias que no existían por el simple hecho de buscar las conocidas medallitas… ¿En serio vale la pena dejar marchar a un buen trabajador sólo por no negociar con él? ¡Qué fácil es pensar que dónde había ese hay más! De un modo o de otro, tu equipo se resentirá y tu serás el primero en sufrir las consecuencias, tu planificación se irá por la borda y los plazos comenzarán a agobiarte.

Hablemos también de los de más arriba, de los directores de. Sí, esos con tan poca autoestima que en cuanto aparece alguien que intenta hacer bien las cosas hacen todo lo posible para cargárselos creyendo que así salvan su puesto de trabajo cuando en realidad están destruyéndolo lentamente. Como argumenta José Medina:

los números uno se rodean de números uno, y los doses, de treses y cuatros

Sobran más comentarios. Más aún en esta conocida cultura que hace jefes a los que ayer eran machacas, la cultura del peloteo, sí. El machaca convertido en jefe será siempre un número tres o cuatro que intentará que un número uno no se le suba a las barbas.

Un programador es una persona que se tiene que reciclar contínuamente, cada año su trabajo cambia, cambian las tecnologías, los lenguajes, las máquinas… y él está ahí al pié del cañón. ¿Os imagináis la experiencia que debe tener un tío de 50 años que lleve 25 programando? Impresionante. Pero nadie lo va a valorar. No. Más bien al contrario. Pensarán, vaya, menudo paquete tiene que ser este para ser un simple programador a su edad… En efecto, esta es la realidad.

Que nadie olvide que, por mucho director de que haya, no estarías ahora utilizando un ordenador si no existiesen los programadores. Es un trabajo donde te acuestas pensando y te levantas buscando soluciones. Piénsalo la próxima vez que arranques tu ordenador.

Por todo esto, no, a los 50 prefiero ser el responsable de un buen equipo e intentar hacer lo que hoy no nos dejan y que los que vengan detrás crean que ser programador es un buen trabajo, digno, gratificante y que te permitirá jubilarte.

Alguien que conozco me llamará ahora idealista 😉 , que todo esto está muy bien pero la realidad es bien distinta. En efecto, así es, pero a mi también me queda algo de idealismo aún. Esperemos que dure.

Sé que se me han quedado algunas cosas que quería decir en el tintero, pero ya está bien de aburriros, me ha quedado más largo de lo que esperaba. Hasta la próxima 🙂 .

¿Por qué nos siguen enseñando gestión de proyectos en cascada?

Programación, Proyectos, Técnico, , , , , ,

Cada día que pasa lo entiendo menos. Cualquiera que haya participado en algún proyecto de software, da igual el tamaño del mismo, se habrá dado cuenta que los patrones a seguir que nos enseñan a todos en las asignaturas de ingeniería del software y gestión de proyectos ya no tienen sentido. De hecho hace mucho tiempo que dejaron de tenerlo. Toma de requisitos, análisis, desarrollo, pruebas, implantación… Y cuando los usuarios finales comienzan a utilizarlo te das cuenta de que la usabilidad es nula (no es lo mismo como piensan los técnicos que los usuarios finales), faltan funcionalidades básicas, determinados procedimientos cotidianos se han complicado tanto que el trabajo diario se alarga… ¿Solución? O bien se aumenta el presupuesto para contemplar las modificaciones (suele ocurrir con las administraciones públicas) o bien el cliente no te paga hasta que el software funcione como él y sus empleados necesitan, con lo cual tu estimación de tiempo/recursos se ha quedado corta y empiezas a perder dinero sobre el plan inicial.

¿Por qué ocurre esto? Sencillo, por que es muy difícil contemplar todas las necesidades del cliente en la fase inicial del proyecto. Pensar que con las notas que se toman durante esas semanas va a ser suficiente lleva a ocultar las potenciales carencias. Sí, hablas con el personal de tu cliente, ves como trabajan, te lo apuntas todo. Pero tú no eres el que trabajará con la aplicación, son ellos, pero vas a plantear el proyecto desde tu punto de vista, no desde el del cliente. Cuando les enseñas el producto aparecen los problemas.

¿Y si, en vez de eso, implantas en tu equipo de desarrollo técnicas de desarrollo ágil? Podríamos decir que sería un método de desarrollo orientado a producto, periódicamente se liberan versiones funcionales del software, con más o menos funcionalidades, pero que funcionan y permiten al cliente toquetear y jugar con su compra.

El ejemplo más evidente lo tenemos en el desarrollo de webs. Cualquiera que haya trabajado en ese campo se habrá topado con el momento en que el cliente empieza a ver lo que hay hecho (es una web, puede verla en cualquier momento ¿no?) y comienza a pedir cambios y a decir cosas que no le gustan. Para nosotros, que tenemos nuestra idea clara del desarrollo lineal, que sabemos que teníamos tres meses para hacer el desarrollo y vamos a cumplir ese plazo, comienzan los problemas. Pierdes la línea de tus planes y comienzas a centrarte en lo que el cliente ha dicho al ver cosas, en cambios, en errores, olvidándote de todo lo planificado que te queda por hacer porque mañana volverá a ver la web y querrá ver los cambios solicitados, tu mente en cascada no es capaz de verlo de otro modo.

En vez de eso vamos planteando pequeños desarrollos cada tres o cuatro semanas. Cada periodo se presenta algo nuevo que funciona, es decir, comenzamos por una pequeña porción del sistema, siempre funcional, y la vamos aumentando poco a poco en periodos posteriores teniendo siempre en cuenta los errores detectados y las impresiones del cliente, sin olvidarse de las funcionalidades pendientes. Estaríamos, por tanto, ante un desarrollo adaptativo en función de las necesidades que se van viendo sobre la marcha. Por esta misma razón comenzamos a tirar líneas de código mucho antes que en los procesos tradicionales ya que apenas nos preocupamos por concretar todos los detalles al inicio, lo vamos haciendo sobre la marcha y con una idea inicial bastante general es suficiente. El objetivo es algo siempre complicado, que el cliente se implique en el proyecto y aporte continuamente su feedback.

Puedes comenzar con el Manifiesto ágil y buscar documentación y bibliografía sobre desarrollo ágil y SCRUM (una de las técnicas más utilizadas). Ya de paso no estaría de más echar un vistazo a Xtreme Programing (no, no es trabajar 15 horas diarias).

A los desarrolladores, en general, nos cuesta mucho asimilar los conceptos ágiles. Nos enseñaron a ser mecánicos en los procedimientos de desarrollo de software y este tipo de técnicas se basan más en ir sobre la marcha, y cuidado, esto no significa ni mucho menos que sin planificación, al contrario. La primera pregunta del director de proyectos la primera vez que oye hablar de desarrollo ágil será: bueno, pero así ¿cómo hago las estimación del tiempo necesario? Pues igual que lo hacías hasta ahora, estamos proponiendo nuevas técnicas de desarrollo, pero la estimación tienes que seguir haciéndola igual: piensa en las tareas que hay que hacer y estima el tiempo necesario para realizarlas, compáralo con la cantidad de recursos (personas) de tu equipo y obtén las estimación, o mejor aún, ya que hablamos de técnicas ágiles, deja que sea el propio equipo el que estime la duración de las tareas, a fin de cuentas son los que las van a hacer.

Subversion, ese gran desconocido

Programación, Proyectos, Técnico, , , , , , ,

Equipos de varias personas, proyectos sin fecha de finalización, corrección de bugs, nuevas funcionalidades… ¿cómo gestionáis todos esos cambios?

Me resulta difícil de creer, por no decir incomprensible, que, en la época en que vivimos, la inmensa mayoría de empresas de desarrollo de software no utilicen un mínimo sistema de control de versiones (CVS, Subversion, Sourcesafe…). Y no hablamos sólo de pymes, hablamos también de grandes consultoras con grandes proyectos de las administraciones públicas. Y es que no hay mejor cara que aquella que se te queda cuando haces update y te contesta file merged. O mejor aún, cuando has metido la pata hasta el fondo y recurres al superhéroe de la película, a revert.

Algunos pensarán, cuando hablamos de desarrollo de software, que hablamos de grandes aplicaciones o proyectos, pero están equivocados, hablamos de cualquier cosa que se programe, incluida una web.

Subversion es lo que se conoce como un sistema de control de versiones (del inglés Control Version System). Control de versiones es la gestión de los cambios y modificaciones en el código fuente de un proyecto, es decir, cada cambio que se hace en el código queda registrado de manera que en cualquier momento se puede saber quién hizo qué. Pero eso no es todo. ¿Qué ocurre cuando dos o más programadores trabajan sobre la misma aplicación y sobre los mismos ficheros de código? En un escenario normal no podrían. Uno tendría que esperar a que terminase otro para obtener la última versión, hacer sus modificaciones y pasárselo al siguiente. Obviamente eso no es ni óptimo ni deseable, tendríamos programadores esperando para poder trabajar. Subversion soluciona esto permitiendo que varios programadores trabajen sobre el mismo proyecto simultáneamente. Llegado el momento de unir todas las piezas, él lo hace por ti, es lo que se conoce como merge.

¿Qué ocurre cuando el cliente solicita cambios en tu proyecto y, cuando lo tienes terminado, da marcha atrás y prefiere que todo vuelva a estar como antes? Como no has hecho copia de seguridad del código en el estado anterior tendrías que volver a rehacer tu código para quitar lo nuevo y ajustar lo anterior. Con Subversion es tan sencillo como recuperar la versión anterior.

Lo más sorprendente es buscar gente para tu equipo de desarrollo y encontrarte con que a ninguno les suena ni CVS, ni Subversion ni nada similar. ¿Tan poco profesionalizado está el sector? Dá igual los estudios, nadie sabe lo que es y siempre les cuesta adoptar el cambio de filosofía ftp/Subversion.

Lo mejor de todo es que hoy en día no tienes que saber ningún comando manual, está todo automatizado. Eclipse tiene integración plena con Subversion, de manera que hacer commit, update o cualquier otra cosa son unos simples clicks de ratón. Pero eso no es todo, con TortoiseSVN tendremos integración plena con el explorador de archivos de Windows. De un vistazo podrás ver qué archivos has modificado, cuales están sincronizados, etc…

¿Aún no ves las ventajas?