Seguimiento Marzo
Objetivos cumplidos
Beta funcional del programa

Consideramos que la primera entrega fue un fracaso previsto y avisado, ya que el tiempo era poco, y si bien se realizaron avances extraordinarios en dos semanas de intenso trabajo, la presión por la inmediatez de la entrega redujo notablemente la calidad del desarrollo, lo que condicionó notablemente nuestro fallo. Por parte del equipo consideramos que no es razonable volver a pedirle al personal semejante esfuerzo de desarrollo, que va contra la buena gestión del tiempo y contra una planificación realista y efectiva de los recursos humanos, y de cara a no gastar en exceso a la gente pretendemos que no se vuelva a repetir bajo ningún criterio. Esto, aunque implique tener que incumplir requisitos externos, siempre que por mayoría simple los juzguemos irrazonables, y con consciencia de las consecuencias.

No obstante, una vez liberados de ese problema inmediato hemos podido dedicarnos a la mejora del código solventando todos los problemas que habíamos ido localizando y posponiendo durante el apresurado desarrollo. Ejemplo sean los problemas detectados de codificación en el código con acentos, que se debían principalmente a faltas de consistencias entre los módulos.

Todo ello nos ha permitido una entrega a final del mes en gran parte ya funcional: al margen de hacer y recuperar versiones de archivos, también creamos un snapshot inicial del sistema al arrancar la aplicación (para protegernos de periodos durante los que esté cerrada), y están resueltas las planificaciones periódicas e instantáneas con cron (entre las que la inicial se puede considerar un caso particular) y los pequeños problemas que tenía el mecanismo de notificaciones de cambios en archivos. Además de esto, tenemos previstas y desarrolladas parcialmente (incluso sólo por probar exhaustivamente) bastantes de la funcionalidades que aún nos faltan para aproximarnos a los objetivos iniciales de proyecto y a los casos de uso planteados entonces, como por ejemplo borrar snapshots, caducarlos para poder borrarlos, obtener una eficiencia de uso de los recursos que permitan no notar la aplicación, feedback de las operaciones en curso hacia el usuario, o una versión en consola de la aplicación.

Queda pendiente una refactorización de partes del código que no están a la altura de la calidad requerida y que supondrá restar un tiempo extra al ya ajustado del que disponemos, en buena parte motivada por ese apresurado y algo caótico desarrollo inicial.

Contratación de personal

La reciente incorporación de un miembro extra a nuestro proyecto nos enorgullece y da perspectiva sobre cómo se percibe a nuestro grupo de proyectos externamente. Nos permitirá repartir mejor la carga de trabajo y reforzar áreas donde andamos escasos de personal y que podrán hacer buen uso de su talento, si bien nos supone nuevos riesgos y dedicarle a su vez a personal para introducirla a todo el material (documentación, procedimientos y código) que tenemos hasta ahora y que el resto conocemos. Nos supondrá, en resumen, un esfuerzo extra en formación que esperamos rentabilizar cuanto antes.

Puesta a prueba de la arquitectura

A raíz de tener la primera versión funcional del programa hemos empezado a explorar lo que haría falta para ampliarlo, de cuyo análisis inicial concluimos que buena parte de las horas invertidas en pensar la aplicación inicialmente ahora dan su fruto, y la mayoría de las extensiones para completar funcionalidad parecen "factibles" y hasta "fáciles", solo limitadas por el tiempo del que disponemos. La falta de cambios notables a la arquitectura para conseguir esto nos habla de la calidad de la misma y nos permite a partir de ahora un desarrollo mucho más rápido que en el caso contrario.

Puesta a prueba del despliegue

Dos entregas sucesivas en unos 10 puestos simultáneos han probado la arquitectura provisional de despliegue con éxito, no notándose ralentización alguna durante el uso pese a su perfil relativamente intensivo de uso de disco. Ello se ha debido en parte al equipo donde se ha desplegado, lo bastante potente y con un subsistema de disco solvente (dos discos en RAID0), y en parte a la relativa complejidad en probar una aplicación de este perfil en condiciones más reales (con un volumen más grande de documentos y archivos del usuario). Tener dos miembros del equipo trabajando de administradores de sistemas también ha sido determinante, con acceso a recursos de red que nos hubiera sido complicado obtener de otro modo.

Si bien esta arquitectura es provisional y solo motivada por las limitaciones que nos imponen los técnicos de laboratorio, nos servirá para generar el UML de despliegue y seguimos explorando y proponiendo a los técnicos otros medios de despliegue, como máquinas virtuales que, sin suponer un riesgo de seguridad, son un entorno más real sobre el que probar.

Quedan pendientes aún temas de empaquetado del software que se resolverán en breve.

Revisión de las pruebas

Durante las pruebas con usuarios reales, sobre todo la segunda, hemos obtenido bastante feedback sobre las mismas. Parte del mismo nos será de gran ayuda para mejorar usabilidad de la aplicación, habiéndose detectado problemas nuevos que por la falta de revisión formal se habían pasado por alto hasta ahora. Se dará buena cuenta de las sugerencias recibidas mientras seguimos explorando por nuestras cuenta otras mejoras adicionales.

Nuevo GUI

El uso de herramientas de prototipado rápido, como Python y sobre todo la herramienta Glade de desarrollo visual de interfaces en XML, nos han permitido cambiar el interfaz que teníamos inicialmente reutilizando casi todo el código preexistente, así como desarrollar nuevas interfaces como la vista en dos paneles, en muy corto espacio de tiempo. Ello ha mejorado mucho la calidad de la aplicación y nos demuestra lo acertado del enfoque de utilizar herramientas que desacoplen el diseño de interfaces del de código. Si bien hay multitud de aspectos a mejorar detectados, ahora el GUI es mucho más ordenado y visualmente atractivo. Además se han añadido elementos como una barra de botones que hacen accesibles las funciones más comunes y se han solventado fallos elementales como el no poder diferenciar entre una carpeta y un elemento, aunque esta mejora no llegó a la entrega.

Ruta de comunicación inversa

Un miembro del equipo ha desarrollado la funcionalidad de comunicación inversa usando el mismo canal D-Bus existente, esto es: de backend a frontend. Ello nos resuelve finalmente el riesgo del sistema de comunicación interproceso que utilizamos (D-Bus) y nos permite proporcionar feedback al usuario de modo eficiente (sin usar polling). Gracias a esto podremos desarrollar varias mejoras, como un refresco de la ventana principal para responder a cambios en el backend y exploraremos la posibilidad de incluir barras de progreso o popups de notificación.

Fechas de reunión

Ante la dificultad de encontrar horarios comunes por tener a 4 miembros del proyecto trabajando (un 30%, cifra muy elevada) hemos establecido para ello las horas de laboratorio de Jueves y Viernes, normalmente improductivas en lo que a desarrollo se refiere y en las que normalmente estamos todos presentes. En cualquier caso, el estado del desarrollo actual nos permite reunirnos menos que en la fase previa de definición del proyecto.

Licencias en el código

Hemos añadido la licencia GPLv2 al código y los copyright pertinentes para cumplir con la legalidad, al haber reutilizado pequeños fragmentos de otras aplicaciones que nos obligaban a ello. Con este cambio nos integramos plenamente en el floreciente mundo del desarrollo de software libre y mejoramos las posibilidades de su mantenimiento una vez acabado el desarrollo del proyecto, sea por nosotros o por terceros.

Hdlogger y tratamiento de fallos

El módulo desarrollado de logging nos ha permitido centralizar toda la información de depuración útil para diagnosticar fallos, e incluso desarrollar. Sobre el mismo hemos construido un módulo de informe de excepciones inesperadas y cuelgues, que nos enviará los archivos que Hdlogger genera, para poder analizar en profundidad los fallos que se produzcan en la aplicación.

Queda pendiente que sea exhaustivo y más útil aún y que se aproveche desde el GUI, lo que requiere moverlo ligeramente de donde está en la arquitectura para sacarlo del backend, y de un esfuerzo por parte de todos los desarrolladores para utilizarlo adecuadamente.

Bugtracker, listas de correo y traducciones

La aplicación web que utilizamos para la gestión de configuración, http://launchpad.net , además de centralizar el control de versiones que hemos estado usando hasta ahora, nos integra funcionalidad extra de seguimiento de bugs detectados, así como gestión de traducciones online (un aspecto sobre el que investigaremos, pues fue mencionado en las revisiones de las entregas), y recientemente listas de correo (archivadas e indexadas para su búsqueda). Exploraremos también la posibilidad de integrar la gestión de fallos mencionada anteriormente con launchpad, ya que recientemente hemos descubierto módulos Python que sirven para ello.

Retoques al modelo de desarrollo

Pendientes de ser documentados en inmediatas actualizaciones de la documentación, hemos realizado retoques al modelo de desarrollo para facilitar las integraciones de código y reducir riesgos. En adelante tendremos múltiples niveles de repositorios. Los que ya teníamos (los privados de cada usuario), se integrarán en los de cada grupo de desarrollo (como gui, db para bases de datos, console o snapshot-manager), donde se desarrollarán las features nuevas en progreso. La integración entre estos nuevos repositorios se hará a través de un repositorio común llamado unstable, que probablemente tenga problemas producto de esta integración. Tras estabilizarlo se migrará el código a un nuevo repositorio de testing, que debe ser estable y probado, y sobre el cual solo aplicaremos correcciones de errores (que, gracias al control de versiones que usamos, podrán ser portadas con algo de cuidado bidireccionalmente entre testing y unstable sin afectar a las divergencias que hayan surgido entre ambos). Finalmente, las versiones que hagamos se etiquetarán en testing y se dejarán en trunk, de donde obtendremos el resumen de todas las entregas al final del curso, y que estará establecido como repositorio principal.

Con esto solucionaremos todos los problemas de integración a la vez que podremos mantener baselines estables independientes del desarrollo y portar parches entre repositorios.

Objetivos no alcanzados
Documentación

La documentación ha sufrido un descenso de la calidad motivada por el exceso de trabajo. Al margen de la revisión y actualización de la documentación existente, no se han cumplido en absoluto las planificaciones acerca del desarrollo de UML por parte de los respectivos grupos de trabajo. Ello se debe sobre todo a la sobrecarga de trabajo de todo el mundo. Para solventar este problema hemos reasignado a tiempo completo a un miembro del equipo que ha trabajado en prácticamente todas las partes de la aplicación. Su trabajo, consistente en consultar a todos los equipos sobre la aplicación, desarrollar los pertinentes diagramas, detectar patrones de diseño aplicables que no hayamos usado y documentar los que sí, aún está por completar pero esperamos tenerlo listo para la siguiente iteración.

En cuanto a la revisión de la documentación existente, supone un riesgo cada vez mayor sobre el que exploraremos soluciones.

Por último, mencionar el retraso en las fechas de entrega de la documentación, motivado por el exceso de trabajo del mantenedor de la misma, así como por haber esperado a la segunda entrega de código y a evaluar sus resultados, la cual a su vez se retrasó hasta la primera semana de Abril por la Semana Santa.

Eficiencia aplicación

Al conseguir poner a funcionar la aplicación hemos detectado algunos problemas de esperas excesivas de cara al usuario sin feedback alguno. Como nos supone un riesgo muy importante (ya que si la aplicación es demasiado lenta será el primer impedimento para su usabilidad), según se detectó el problema se reasignó a personal para su evaluación y solución. El problema está en buena parte generado por el uso de llamadas síncronas -las más sencillas y habituales para el equipo de desarrollo- que dejan a la aplicación "esperando" operaciones grandes de disco, así como otros problemas relativos a la gestión de patrones para expresiones regulares. Confiamos en que la arquitectura, mediante el scheduler que tenemos incorporado, y un uso juicioso y sencillo (para evitar inestabilidad) de threads, nos permita al menos no perder la responsividad frente al usuario.

Consola

La consola, desarrollada hacia la mitad de la iteración, no ha sobrevivido a los numerosos cambios de la aplicación por no haber sido adecuadamente mantenida y probada. Su uso nos sería muy útil para automatizar el testeo de la aplicación completa muy fácilmente, con meros scripts (que pueden ir incluso al margen de las unidades de prueba), y cubre casos de uso con relativa sencillez.

Se resolverá cuanto antes y además se solventarán riesgos relativos a la misma, como medios alternativos de conectarla con el backend que no dependan de D-Bus (por ejemplo señales convencionales) y un nuevo proxy para las mismas (ya que es un servicio del sistema que no suele estar presente en un entorno sin gráficos, precisamente donde sería más útil en recuperación del sistema).

Calidad

Carecer de un plan de calidad más allá de las directrices establecidas nos empieza a pasar factura. El seguimiento de la calidad del código es irregular y no existen procesos para rechazar código, ni revisiones formales y exhaustivas sobre el mismo. Estas deficiencias, aparte de reducir nuestra puntuación para la evaluación de Software Capability Model, nos generan problemas al desarrollar y nos suponen un riesgo a la hora de mantener la aplicación que deberemos valorar y solucionar cuanto antes, mejorando nuestro proceso existente. Sin embargo, carecer de personal suficiente nos lo pone muy complicado.

Formación del nuevo personal

El nuevo miembro de personal incorporado aún no ha concluido su formación y por tanto aún nos supone un balance neto negativo de productividad; la información nueva es mucha, y además hay algunos fallos de actualización de la misma cuando está explicitada en el wiki. Ello deberá solventarse a la mayor prontitud posible.

Riesgos reducidos
  • Aplicación: ya tenemos una versión de la misma funcionando. Aunque le falten características, ha tranquilizado a todo el equipo, ya que desde aquí el proceso es mucho más incremental.
  • Despliegue: dos entregas sin percances nos quitan el problema de cómo presentar y probar la aplicación, uno de los más importantes y olvidados de cara a una entrega con éxito.
  • Personal: la reciente incorporación de un miembro más al equipo nos puede reducir la carga de trabajo en áreas importantes y descuidadas.
  • Personal: puesta a prueba durante un fin de semana de programación extrema, la dinámica del grupo funciona perfectamente y hemos resuelto todos los problemas entre nosotros sin percance alguno. El grupo funciona muy bien para trabajar, la relativa falta de jerarquías contribuye a la confianza entre miembros, lo que mejora el flujo de información y el control de los distintos grupos. Basar las decisiones delicadas y discutidas en revisiones del grupo permite reaccionar con cierta rapidez a cambios polémicos y subsanarlos de modo eficaz mediante consensos. A pesar de dicha falta de jerarquías formales, la confianza en las relativas capacidades de los miembros del equipo nos permite mejorar la rapidez en solucionar esas discusiones y agilizar la toma de decisiones.
Nuevos riesgos
  • Personal: Contratar a un nuevo miembro siempre supone un riesgo de personal: integrarse en un equipo y proceso de trabajo preestablecido, posibles roces con la gente, formación intensiva a esa persona, etc., no sin descuidar en entornos más formales que este los posibles problemas que surgieran de adquirir credenciales de seguridad, boicoteos internos, etc. Para mitigar este riesgo confiamos sobre todo en la buena dinámica de personal antes mencionada, pero además hemos comprobado que los procesos establecidos de gestión de código, ya basados en niveles de acceso a distintos repositorios de código, nos permiten dar permisos lo bastante atómicos para trabajar, así como determinar la autoría de los cambios en caso de posibles problemas. Por ello creemos mínimas las consecuencias de ese hipotético problema (principalmente en tiempo), y comprobamos la validez del proceso.
  • Personal: conforme avanza el desarrollo y se reduce el tiempo restante, el riesgo de "quemar" al personal crece por exceso de trabajo, y una planificación cuidadosa de procesos y asignación de responsabilidades es la única forma de minimizarlo hasta que sea irrelevante por haber acabado la asignatura. Es importante intentar extraer el máximo rendimiento posible del equipo, pero no debemos intentar extraer más que lo razonable y necesario por querer avanzar más de lo realista.
  • Tiempo: reducido por la formación del personal nuevo.
  • Tiempo: reducido del lead developer por otras asignaturas y cansancio del desarrollo seguido.
  • Tiempo: muy escaso para concluir la aplicación (solo dos iteraciones más).
  • Problemas de rendimiento de la aplicación que la hagan poco usable aumentan su posibilidad de aparición, pues ya han sido detectados, y se están evaluando y subsanando.
  • Tecnología de base de datos: demasiado lenta (bloquea entera la base de datos en escrituras); un cambio fue planificado y por tanto la arquitectura del código minimizaría el impacto, pero aún así sería un problema añadido que reduciría aún más el tiempo del que disponemos.
  • El uso de threads puede hacerse necesario para solucionar esos problemas de rendimiento, con el consiguiente riesgo de desarrollo por ser una tecnología relativamente complicada de aplicar bien y de depurar.
  • Carencias en la documentación: podrían no llegar a ser subsanadas a tiempo, y cuanto más tardan mayor es su impacto. Por ejemplo, por no haber examinado y completado el documento de la evaluación de Software Capability Model, no llegamos actualmente a nivel 2 (y no por no ser capaces de ello).
  • Futuras entregas "sorpresa" como la primera nos exponen al riesgo que conllevan: si no las entregamos, de cara a la asignatura, y si apresuramos el desarrollo y nos saltamos los controles que ralentizan el desarrollo, de cara a la calidad de la aplicación. Sin embargo consideramos este un riesgo no planificable en absoluto.
Tiempo real empleado

El tiempo empleado ha sido excesivo, incluso superior a lo planificado que ya contaba con los problemas para llegar a la primera entrega. Incluso hemos llegado a dedicar un fin de semana completo para desarrollar, aparte de ausencias en asignaturas por parte de buena parte del personal. Replanteados objetivos y medios, la segunda mitad del mes ha sido algo más relajada y a su vez mucho más productiva, necesario para no desgastar en exceso al personal. En general, debemos tratar de reducir nuestro alcance para no repetir esta situación, por complicado que resulte.

Conclusiones

Con cierta sorpresa para todos y también bastante ilusión, tenemos la aplicación al fin funcionando, al menos mínimamente, con lo que apenas hemos modificado el plan de fase existente y, aunque hay sensación de agobio, seguimos manteniendo vigente la última planificación de fase. Queda muy poco tiempo ya de desarrollo, así que habrá que aplicarse en estabilizar (crítico para el éxito hipotético de nuestra aplicación), a la vez que intentamos cubrir funcionalidades adicionales, lo que supone todo un conflicto de intereses a resolver con políticas adecuadas de release. Por lo demás, la iteración ha sido todo un éxito en la medida que hemos podido estrechar bastante los lazos entre el personal, en particular durante el apresurado y algo caótico desarrollo de la primera entrega. Nos quedamos por tanto con eso de toda la iteración: todo el equipo nos respetamos mucho más, al habernos visto trabajando -y rindiendo- bajo presión.

Como punto amargo, no haber conseguido hacer funcionar la entrega 1 por detalles de última hora nos lleva a tomar la decisión de no volver a realizar "maratones" de ese estilo para futuras entregas no planificadas -ni planificables-, conocedores del riesgo relativo en que incurrimos con ello.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License