Pruebas unitarias, bugs, features y bolas de nieve
Empiezo con una frase que me gustaría que recordárais mientras leeis esta entrada: «A mí eso no me va a pasar«. Continuo…
Me encuentro delante de mi proyecto recién acabado y con satisfacción me digo… «tanto tiempo desarrollando un proyecto de más de un año, cuantas líneas de código escritas, eliminadas y modificadas, cuantas pruebas unitarias pasadas una y otra vez, cuantos documentos escritos sobre el proyecto, cuantos dibujos en pizarras explicando aspectos del desarrollo, cuantas reuniones de seguimiento, cuantas discusiones de qué funcionalidades deberíamos introducir en la primera versión y cuales dejar para otra versión futura, cuantas horas y momentos compartidos,… y ya por fin hemos engendrado a nuestro pequeñín 1.0».
La satisfacción que da terminar un proyecto (incluso cuando es una versión alpha) y verlo corriendo en un sistema no se puede describir, cada proyecto es diferente y la sensación al terminar un proyecto es similar pero distinta (los problemas, los momentos, las alegrías, las discusiones, las tomas de decisión, etc).
Sin embargo, una vez que implantamos nuestro proyecto en diferentes clientes, rápidamente pensamos en esas características que no pudimos abordar y que dejamos para una versión 2.0, aquellas otras cosas que los clientes nos comentaron en alguna ocasión que estarían bien que las tuviéramos en cuenta para futuras versiones de nuestro producto, e incluso esas formas de hacer las cosas que aunque estén bien, nos damos cuenta que estarían mejor si las rehiciéramos de otra manera, o a lo mejor esa nueva tecnología que ha aparecido mientras llevábamos a cabo el desarrollo de nuestra versión 1.0 y que daría un valor añadido a una determinada funcionalidad que en su día hicimos como está ahora porque no teníamos la posibilidad de hacerlo de otra manera.
De nuevo comienzan las discusiones, la toma de decisiones y rápidamente sin casi pausa alguna, iniciamos con mucha ilusión un nuevo proyecto, la versión 2.0 de nuestra aplicación.
Mientras tanto, nuestra primera versión sigue vendiéndose como churros y se instala por doquier. El éxito está asegurado y nos acordamos de aquellos tebeos de Disney dónde aparecía el Tío Gilito bañándose en su gran caja fuerte repleta de monedas de oro. ¡Que bien nos va todo!, ¡me como el mundo!.
Como Murphy existe y siempre aparece cuando las cosas van mejor, en un momento dado, la aplicación que tenemos implantada en numerosos clientes empieza a dar problemas. Quizás las pruebas unitarias que hicimos no fueron completas, también quizás no hicimos todas las pruebas que deberíamos haber hecho, o simplemente, pensamos de forma cafre en que no era necesario hacer pruebas de las funcionalidades más básicas (ERROR, hay que hacer pruebas unitarias DE TODO, esto lo sabemos ¿verdad?).
El caso es que se han detectado demasiadas quejas y demasiados errores por no haber planificado bien las pruebas, y lo que es peor, metimos la pata en algunas funcionalidades que inicialmente parecían estar bien implementadas. Todo eso nos está creando un grave problema, ya que el equipo de desarrollo no es tan numeroso como para hacer dos grupos de trabajo, uno que siga desarrollando la nueva versión y otro que resuelva los problemas detectados en la versión anterior. Además, los errores de la versión 1.0 deberían estar resueltos en la versión 2.0 también, por lo que el proyecto de la versión 2.0 se ve alterado de forma directa.
En realidad, tenemos varias alternativas, arreglar los bugs indicados como graves y seguir adelante con la planificación de la versión 2.0 y a medida que avancemos resolver los errores leves y medios, o dedicar los esfuerzos a arreglar todos los errores (graves, medios y leves), aplicarlos a la versión 2.0 y o continuar el desarrollo de la versión 2.0 o paralizar ese desarrollo y focalizar los esfuerzos en la resolución de problemas de la versión 1.0. ¿Continuar?, ¿parar?, ¿hacer una mezcla entre continuar y parar?…
Ante esta tesitura y mientras sigamos discutiendo qué demonios hacer, lo que sí tenemos claro es que la pelota efecto de nieve ha comenzado a bajar la ladera de forma vertiginosa, y cada vez la pelota es más grande. Estamos perdiendo un tiempo precioso y la gente se está empezando a poner nerviosa. La toma de decisiones debe ser ágil, rápida y efectiva, pero tenemos delante de nosotros una situación para la que no estábamos preparados y para la que nadie había propuesto nada, y tenemos que tomar la decisión acertada o errónea sobre la marcha.
Así que las nuevas características de la versión 2.0 podrían ser paradas, pero hay muchas características que dejamos sin poner a la versión 1.0 por tiempos y costes y decidimos consensuadamente aplicarlas en una versión 2.0 que realmente saciaría la inmensa cantidad de necesidades de nuestros clientes, porque para que vamos a engañarnos, la versión 1.0 tiene funcionalidades muy interesantes, pero en realidad la versión 2.0 tiene una serie de características que harán mucho mejor y más potente a nuestro producto, la competencia se ha dado cuenta y está mejorando sus productos, y los clientes están esperándo esas funcionalidades ya. Así que se junta la insatisfacción del cliente por que la versión 1.0 no tiene muchas de esas funcionalidades, y el cabreo inmediato por los fallos detectados en esa versión 1.0. Pero claro, han aparecido tantos errores por no haber hecho bien el trabajo inicial (pruebas unitarias, repaso de funcionalidades, etc) que nos encontramos con que la piscina del Tío Gilito está empezando a hacer aguas.
Hay muchas formas de resolver esta problemática, se me ocurren varias y muy diferentes todas ellas, pero yo quiero preguntar ante este caso teórico-práctico, inventado eso sí, pero que podría darse en nuestras vidas, ¿que haríais vosotros?.
En realidad esta entrada es quizás muy distinta a las que he puesto normalmente, pero me gustaría saber que opinais vosotros desde el punto de vista de cada uno.
¿Cerrais la empresa y mandais todo a paseo?. ¿Contratais más personas para llevar a cabo los dos procesos de resolución de problemas de la 1.0 y la nueva 2.0?. En este último caso, ¿dónde ponéis a las personas nuevas, a hacer la versión 2.0 o a arreglar la versión 1.0 o dónde?. ¿Parais el desarrollo de la 2.0 y focalizais los esfuerzos en arreglar y cerrar los errores de la 1.0?. En este caso, ¿aplicais la resolución de problemas de la 1.0 a la 2.0 en paralelo?.
Vamos, quiero saber que opinais e incluso si os atreveis, que sería lo ideal, porqué.
Y ya finalmente… si os atreveis también… ¿como pensais que una herramienta como Visual Studio Team System podría ayudaros para resolver estos problemas?. Si alguien se atreve a argumentar sus comentarios en una entrada en su blog genial, porque os aseguro que este ejemplo, da para mucho juego y muchas entradas. 😉
7 Responsesso far
Creo que lo mas eficiente en cuanto al desarrollo, quizas ya no tanto en cuanto a lo comercial, seria:
No tocar la version 1.0,
Se terminan las funcionalidades nuevas empezadas para la version 2.0, se arreglan los errores sobre esta version y se saca una version 1.1
Esta respuesta dependería de ambas partes, por un lado el jefe de proyecto – desde mi punto de vista – debería decidir por medir los tiempos necesarios para poder primero resolver los errores críticos que pueden surgir en la primera versión, estos errores no necesariamente debe ser los q ya aparecieron, sino más bien detectar las funcionalidades que bajo ninguna premisa y/o concepto deberían fallar.
En esta primera fase q se aboque todo el equipo, dependiendo de la complejidad de los errores a tratar y mientras esta complejidad va disminuyendo, ir pasando poco a poco a las personas a q se aboquen a la versión 2.0
Pero tb esta decisión no solo la debe tomar el jefe del proyecto, sino tb debe consultarla con el equipo de desarrollo y tomar una decisión juntos – puede ser adecuado aplicar una tormenta de ideas – pq supongamos que del 100% solo el 20% está de acuerdo con esta decisión; entonces el fastidio con el que trabajaría el restante 80% dilataría más aúin el tiempo para poder resolver los errores críticos de la versión 1.0; y en este caso la solución es peor que el problema.
Es lo q haría, considerando tb q la empresa está de acuerdo y nos da carta libre para trabajar como mejor nos parezca.
Gracias.
PD: Saludos Jorge.
Para mi es de cajón: Hay que arreglar los errores, por dos motivos.
1) Lo clientes no va a comprar la versión 2 si recuerdan la versión 1 como una aplicación plagada de errores.
2) No hay nada menos eficiente que tratar de construir nuevas funcionalidades sobre una base de código llena de fallos.
No queda otra, a corregir los bugs, la calidad en el software no es opcional (http://geeks.ms/blogs/rcorral/archive/2006/09/02/En-el-software_2C00_-la-calidad_2C00_-no-es-opcional.aspx).
¡Un saludo titán!
Concuerdo con Alfredo en los aspectos básicos.
Hay que reparar y hay que avanzar, sinó el producto se congela junto con las ventas y el equipo se frustra y baja la productividad y hay un círculo vicioso.
Pero el equipo no es suficientemente grande así que hay que hacerlo crecer.
Los equipos debieran quedar mezclados entre los nuevos, para que la sangre nueva se empape del sistema de trabajo y rinda de mejor manera.
La idea en general, es hacer el típico forge-merge.
Separas una rama y la llamas 2.0, mientras trabaja un equipo en las nuevas características en esa rama, el otro equipo repara los problemas en la rama 1.0 y obtiene parches 1.x que son entregados al cliente como respuesta rápida y a la vez contribuye al desarrollo de la rama 2.0.
Mi opinión es:
Después de valorar los tiempos en corregir la versión 1 y finalizar la versión 2 (incluyendo las mejoras detectadas) procedería a:
Realizo los cambios en la versión 1 siempre y cuando representen hasta un 30 % del tiempo estimado en realizar la versión 2.
En caso contrario, que esperen un poco los clientes (actualización sin coste) y terminamos la versión 2.
Saludos,,,
A ver si comenta cosas técnicas no confidenciales de la aplicación, seguro que aprenderíamos mucho de un crack como J.S 🙂
Si la versión 2.0 parte del código heredado (v.1.0) lo cual es lo usual, definitivamente coincido con Rodrigo Corral. No se puede avanzar sin corregir los errores, al menos los ya reportados y aquellos que surjan de su resolución. Pero si se puede garantizar un alto margen de calidad mucho mejor, ya que a fin de cuentas repercutirá en la v.2.0.
Sólo en caso que la versión sea una re-escritura (no necesariamente desde 0, pero si a partir de una buena re-ingeniería / re-estructuración) pues se podría optar por hacerlas a la par si es que los recursos humanos y financieros lo permiten. Pero si no, bien se podría postergar la v.1.1 e incluso ya no corregir la 1.0, acordando de antemano con los actuales clientes la actualización a un bajo precio, o incluso nulo si colaboran como socios (Beta Testers y promotores) de la 2.0. Obviamente tienen que analizarse bien las opciones para determinar el camino menos costoso a seguir, sin olvidar el costo de tener clientes insatisfechos…
En caso de llevar a cabo un desarrollo en paralelo, parte del personal actual es quien debe corregir la 1.0, mientras que el resto aventurarse, junto con nuevo personal, a realizar la 2.0.
Pero insisto en que si se piensa crear la 2.0 a partir de la 1.0, no puedes (o al menos no deberías) hacerlo sin corregir la primera.
Saludos,
Willy Mejía.