A pesar de haber leído mucho sobre el tema e intentar hacerlo lo mejor posible, invariablemente los proyectos requieren muchos más recursos que los que valoro inicialmente.
También invariablemente, estas son las causas que he detectado:
Poca profundidad y claridad de los requerimientos iniciales. Los clientes envían un pliego técnico en el que expresan a muy grandes rasgos lo que desean. Basándose en ese documento es que se debe hacer la oferta.
La solución ideal sería "obligar" al cliente a que el documento que aporte sea más completo.
Esta solución no siempre se puede aplicar, que para eso el cliente es el cliente, y estoy seguro de que a mi empresa no le interesa perder de esos sólo porque el arquitecto se niega a hacer una valoración sin un documento de requerimientos más completo.
Por eso, una alternativa más viable sería separar mucho más tiempo, al menos 4 veces el tiempo que se reserva actualmente, para la discusión con el cliente. La mayor parte de este tiempo debería utilizarse antes de que haya más de una o dos personas en el equipo que puedan ir generando contenido inicial e ir haciendo pruebas para determinar la arquitectura final de la aplicación.
Otro aspecto importante es que la valoración debe hacerse en módulos que el cliente pueda entender. Por ejemplo, no se puede poner:
Acceso a base de datos -> 40 horas
sino que hay que adaptarse a la terminología del cliente, y poner
Módulo funcional 1 según documento -> 32 horas
aunque a la hora de implementar se genere primero la interacción con la base de datos de todos los "módulos" del cliente.
La solución obvia sería hacer una valoración interna utilizando las categorías y tareas que mejor reflejen el desarrollo real y después distribuyendo las horas entre los "módulos" del cliente. Pero, por algún motivo, este paso actúa como una lupa de gran aumento, y a todo el mundo le parece demasiado tiempo, incluso a mí mismo, y se comienzan los recortes. ERROR!! La valoración inicial es la correcta.
Debe existir una valoración interna utilizando las categorías y tareas que mejor representen el proceso real de desarrollo, y toda discusión, observación, reducción, etc, que afecte a la cantidad de horas debe hacerse sobre esta valoración. Para entregar al cliente se debe preparar un modelo más comprensible que requiera la misma cantidad de horas.
Por último, se debe reservar tiempo en la valoración para las pruebas de desarrollo que seguramente se harán, y para el "maquillaje" final de la aplicación, algo que el cliente ve como "sencillo" pero que siempre requiere un tiempo extra considerable.
Thursday, October 30, 2008
Análisis de mi desempeño actual en la ejecución de proyectos
¿Qué NO hago suficientemente bien? (según mi propio criterio)
1. Valoraciones.
2. Control de las tareas asignadas a los subordinados.
3. Orientación al resto de miembros del equipo de trabajo sobre las tareas a realizar.
4. Selección de las tecnologías, frameworks, metodologías, etc, a utilizar durante el proyecto.
5. Mantener visión global del proyecto.
1. Valoraciones.
2. Control de las tareas asignadas a los subordinados.
3. Orientación al resto de miembros del equipo de trabajo sobre las tareas a realizar.
4. Selección de las tecnologías, frameworks, metodologías, etc, a utilizar durante el proyecto.
5. Mantener visión global del proyecto.
Mi gestión de proyectos informáticos
Estoy muy inconforme con la manera en que se van desarrollando las cosas en lo referente a los proyectos de desarrollo de aplicaciones informáticas en los que he participado y participo. Es una actividad que me gusta, y además, es mi trabajo, así que este es el primer aspecto en el que intentaré mejorar.
Nota: Hay más cosas que quisiera mejorar, pero no están relacionadas con la informática ni mi con vida profesional, así que no aparecerán en este blog :-)
La ejecución de un proyecto es algo que no depende solamente de mí, pero creo que hay muchas cosas en las que debo mejorar. Publicaré una entrada para el análisis de cada uno de los aspectos.
Nota: Hay más cosas que quisiera mejorar, pero no están relacionadas con la informática ni mi con vida profesional, así que no aparecerán en este blog :-)
La ejecución de un proyecto es algo que no depende solamente de mí, pero creo que hay muchas cosas en las que debo mejorar. Publicaré una entrada para el análisis de cada uno de los aspectos.
¿Cómo mejorar?
Para mejorar es necesario determinar:
1. Lo que ya haces suficientemente bien.
2. Lo que NO haces suficientemente bien.
3. En cual de las cosas que NO haces suficientemente bien deseas mejorar.
Se puede hacer un autoanálisis o se puede pedir ayuda a una o varias personas. Casi siempre es una buena idea pedir el criterio de los demás e incluirlo en el autoanálisis, siempre que "los demás" sea gente cuyo criterio valores.
También es una buena idea no perder el tiempo explicando a "los demás" lo que pretendes hacer sino extraer sutilmente la información que deseas.
1. Lo que ya haces suficientemente bien.
2. Lo que NO haces suficientemente bien.
3. En cual de las cosas que NO haces suficientemente bien deseas mejorar.
Se puede hacer un autoanálisis o se puede pedir ayuda a una o varias personas. Casi siempre es una buena idea pedir el criterio de los demás e incluirlo en el autoanálisis, siempre que "los demás" sea gente cuyo criterio valores.
También es una buena idea no perder el tiempo explicando a "los demás" lo que pretendes hacer sino extraer sutilmente la información que deseas.
Monday, May 19, 2008
Por qué no es lo mismo una aplicación "de escuela" que una aplicación "del mundo real" - II
Además de lo ya comentado en la primera parte de este post, hay otro problema que afecta gravemente a la utilidad de lo que aprendemos en la escuela en el momento de incorporarnos al "mundo real" de la programación: las herramientas.
Utilizar solamente un compilador y un IDE para desarrollar una aplicación actualmente es como utilizar pico y pala para excavar los cimientos de un edificio, ignorando que existen máquinas escavadoras que facilitan el trabajo de los obreros y garantizan un mejor resultado en menos tiempo.
Control de versiones (CVS), gestión de tareas (Issue tracking, bug tracking, etc), pruebas unitarias, generación automática de los productos finales, integración continua, generación de documentación mediante wiki, son todas herramientas imprescindibles para un desarrollador profesional de las cuales nunca oí hablar.
Esta falta de preparación a nivel escolar trae como consecuencia que en muchos lugares estas herramientas sean consideradas innecesarias, o que mucho programadores no se sientan cómodos con ellas y por lo tanto no sean productivos.
A todos esos que como yo no recibieron una formación adecuada los invito a que sufran el proceso de aprendizaje. Cuesta acostumbrarse a utilizar todas estas herramientas que al principio parece que aumentan la carga de trabajo, pero créanme, cuando el proyecto entra en fases más avanzadas se aprecian las ventajas de haber hecho el esfuerzo.
Cuando aparece un bug "misterioso", ya no es tan misterioso cuando se puede comparar la versión que introdujo el bug con la versión anterior, sobre todo si cada revisión del código incluye sólo unos pocos cambios relacionados con una única tarea del sistema de administración de tareas.
Cuando se entrega más de una versión del mismo producto y aparece un bug en una de las versiones, ya no hay que decirle al cliente: "tienes que actualizar a la última versión porque no tenemos el código de la versión que tienes".
Cuando al iniciar el desarrollo de una aplicación se valoraron varias alternativas y se discutió muchísimo y al final se tomaron decisiones, no se pasará nuevamente por todas esas discusiones porque cuando alguien pregunte "por qué no se hizo así..." le podemos decir: mira ESTA página de la Wiki.
Cuando se han ocurrido buenas ideas que ha sido necesario posponer, no quedarán en el olvido, sino que sólo tendrás que ir al Issue Manager y ver las tareas pendientes con baja prioridad.
Y cuando alguien pregunta: ¿cuánto falta para terminar esto? no hay que mentirle ni inventar nada, sólo vas al Issue Manager y miras cuantas tareas faltan por completar, e incluso podrías discutir qué características dejar fuera para terminar antes sobre una base concreta, y no en el pasillo.
Utilizar solamente un compilador y un IDE para desarrollar una aplicación actualmente es como utilizar pico y pala para excavar los cimientos de un edificio, ignorando que existen máquinas escavadoras que facilitan el trabajo de los obreros y garantizan un mejor resultado en menos tiempo.
Control de versiones (CVS), gestión de tareas (Issue tracking, bug tracking, etc), pruebas unitarias, generación automática de los productos finales, integración continua, generación de documentación mediante wiki, son todas herramientas imprescindibles para un desarrollador profesional de las cuales nunca oí hablar.
Esta falta de preparación a nivel escolar trae como consecuencia que en muchos lugares estas herramientas sean consideradas innecesarias, o que mucho programadores no se sientan cómodos con ellas y por lo tanto no sean productivos.
A todos esos que como yo no recibieron una formación adecuada los invito a que sufran el proceso de aprendizaje. Cuesta acostumbrarse a utilizar todas estas herramientas que al principio parece que aumentan la carga de trabajo, pero créanme, cuando el proyecto entra en fases más avanzadas se aprecian las ventajas de haber hecho el esfuerzo.
Cuando aparece un bug "misterioso", ya no es tan misterioso cuando se puede comparar la versión que introdujo el bug con la versión anterior, sobre todo si cada revisión del código incluye sólo unos pocos cambios relacionados con una única tarea del sistema de administración de tareas.
Cuando se entrega más de una versión del mismo producto y aparece un bug en una de las versiones, ya no hay que decirle al cliente: "tienes que actualizar a la última versión porque no tenemos el código de la versión que tienes".
Cuando al iniciar el desarrollo de una aplicación se valoraron varias alternativas y se discutió muchísimo y al final se tomaron decisiones, no se pasará nuevamente por todas esas discusiones porque cuando alguien pregunte "por qué no se hizo así..." le podemos decir: mira ESTA página de la Wiki.
Cuando se han ocurrido buenas ideas que ha sido necesario posponer, no quedarán en el olvido, sino que sólo tendrás que ir al Issue Manager y ver las tareas pendientes con baja prioridad.
Y cuando alguien pregunta: ¿cuánto falta para terminar esto? no hay que mentirle ni inventar nada, sólo vas al Issue Manager y miras cuantas tareas faltan por completar, e incluso podrías discutir qué características dejar fuera para terminar antes sobre una base concreta, y no en el pasillo.
Por qué no es lo mismo una aplicación "de escuela" que una aplicación "del mundo real"
Mientras más aplicaciones pasan por mis manos, más lamento la mala preparación que recibí en la escuela con respecto al diseño de una aplicación. La separación del mundo académico y el mundo real en la carrera de "Ciencias de la computación" de La Habana es tan grande que en el transcurso de la carrera no se mencionan cosas como "Arquitectura de 3 capas", "Capa de acceso a datos", "Capa de de negocio", ni mucho menos me enseñaron cómo se diseña un modelo de negocios en una aplicación del mundo real.
En la escuela (al menos en la UH), increíblemente, la mayoría de las aplicaciones que se deben entregar como tarea son aplicaciones sin persistencia, con lo cual nuestros super galardonados y reconocidos profesores nos privaron de la desagradable (pero tan necesaria) experiencia de enfrentarnos a los problemas de OR-Mapping, ni a decisiones sobre si utilizar una base de datos orientada a objetos o una relacional.
Uno de los principales problemas con el que me encuentro al iniciar cada aplicación (y ya van siendo muchas), es el de diseñar un modelo del negocio que no me complique demasiado la vida cuando haya que añadir la persistencia, y que a su vez, me permita la gran flexibilidad de la orientación a objetos, y que no me haga obtener de la base de datos un objeto completo para actualizar una relación del mismo. Me explico mejor:
Supongamos que tengo una clase "Autor" y una clase "Libro", y que en este modelo de negocios que invento yo, un Libro sólo puede tener un Autor mientras que un Autor puede escribir muchos Libros, es decir, que existe la relación 1-n entre Autor y Libros.
Si ésta fuera una aplicación para la escuela, en la cual habrá 10 autores y 50 libros, el "juego de programar" consistiría en crear una clase "Autor" con una lista de "Libros"... ahh, pero que distinto sería todo si pensáramos que nadie invierte dinero en una aplicación que gestion 10 autores y 50 libros, y que en el mundo real esta aplicación debería ser capaz de gestionar miles de autores y cientos de miles de libros y brindando al usuario una velocidad de interacción "aceptable".
Si pensáramos en esto veríamos que con el modelo propuesto parece imprescindible obtener de la base de datos (o servicio de persistencia, en general) una instancia completa de un Autor, ¡incluyendo la lista de todos sus libros!, sólo para añadir un nuevo libro, una operación que, aunque en ciertas aplicaciones podría ser aceptable, es indudablemente ineficiente.
Ahora imagínense hacer este tipo de análisis y tomar una decisión para cada clase en un dominio complejo, sin tener ninguna guía ni ningún patrón al respecto. Imaginen a todos los programadores, al menos los que hacen el curso de "Ciencias de la computación" en la Universidad de La Habana y los que hacen el curso de "Ingeniería Técnica en Informática" en la Universidad Rovira i Virgili de Tarragona. Sólo la Universidad Oberta de Catalunya (UOC) ofrece cierto entrenamiento de este tipo.
No divago más, que el tema es complicado de explicar y la idea central ya está dicha:
No es lo mismo "jugar a programar" que hacerlo de verdad, y en la escuela nos enseñan el juego.
En la escuela (al menos en la UH), increíblemente, la mayoría de las aplicaciones que se deben entregar como tarea son aplicaciones sin persistencia, con lo cual nuestros super galardonados y reconocidos profesores nos privaron de la desagradable (pero tan necesaria) experiencia de enfrentarnos a los problemas de OR-Mapping, ni a decisiones sobre si utilizar una base de datos orientada a objetos o una relacional.
Uno de los principales problemas con el que me encuentro al iniciar cada aplicación (y ya van siendo muchas), es el de diseñar un modelo del negocio que no me complique demasiado la vida cuando haya que añadir la persistencia, y que a su vez, me permita la gran flexibilidad de la orientación a objetos, y que no me haga obtener de la base de datos un objeto completo para actualizar una relación del mismo. Me explico mejor:
Supongamos que tengo una clase "Autor" y una clase "Libro", y que en este modelo de negocios que invento yo, un Libro sólo puede tener un Autor mientras que un Autor puede escribir muchos Libros, es decir, que existe la relación 1-n entre Autor y Libros.
Si ésta fuera una aplicación para la escuela, en la cual habrá 10 autores y 50 libros, el "juego de programar" consistiría en crear una clase "Autor" con una lista de "Libros"... ahh, pero que distinto sería todo si pensáramos que nadie invierte dinero en una aplicación que gestion 10 autores y 50 libros, y que en el mundo real esta aplicación debería ser capaz de gestionar miles de autores y cientos de miles de libros y brindando al usuario una velocidad de interacción "aceptable".
Si pensáramos en esto veríamos que con el modelo propuesto parece imprescindible obtener de la base de datos (o servicio de persistencia, en general) una instancia completa de un Autor, ¡incluyendo la lista de todos sus libros!, sólo para añadir un nuevo libro, una operación que, aunque en ciertas aplicaciones podría ser aceptable, es indudablemente ineficiente.
Ahora imagínense hacer este tipo de análisis y tomar una decisión para cada clase en un dominio complejo, sin tener ninguna guía ni ningún patrón al respecto. Imaginen a todos los programadores, al menos los que hacen el curso de "Ciencias de la computación" en la Universidad de La Habana y los que hacen el curso de "Ingeniería Técnica en Informática" en la Universidad Rovira i Virgili de Tarragona. Sólo la Universidad Oberta de Catalunya (UOC) ofrece cierto entrenamiento de este tipo.
No divago más, que el tema es complicado de explicar y la idea central ya está dicha:
No es lo mismo "jugar a programar" que hacerlo de verdad, y en la escuela nos enseñan el juego.
Thursday, February 21, 2008
Microsoft Application Blocks y familia
Los Applications Blocks, Software Factories y Guidance Packages de Microsoft han mejorado muchísimo desde la última vez que los vi. Con motivo de la definición de la arquitectura de una aplicación los he redescubierto, y ahora aparecen como productos mucho mejor pensados y acabados.
Recordatorio personal: hacer una lista con los mejores recursos sobre el tema, en especial, sobre los Software Factories disponibles en estos momentos.
Sería genial si hicieran el release del Web Client Software Factory 2.0 con soporte para VsNet 2008 en febrero como tienen prometido, para así poder utilizarlo en mi próximo proyecto.
Actualización: WCSF fue liberado con retraso, pero aún a tiempo para utilizarlo en la aplicación. Estamos en ello.
Recordatorio personal: hacer una lista con los mejores recursos sobre el tema, en especial, sobre los Software Factories disponibles en estos momentos.
Sería genial si hicieran el release del Web Client Software Factory 2.0 con soporte para VsNet 2008 en febrero como tienen prometido, para así poder utilizarlo en mi próximo proyecto.
Actualización: WCSF fue liberado con retraso, pero aún a tiempo para utilizarlo en la aplicación. Estamos en ello.
Resultado de la cruzada (después de mucho tiempo)
He dejado abandonadas estas notas personales por el mismo motivo de siempre: otras cosas más "importantes" que hacer. En este caso, sí que eran cosas mucho más importantes, las cosas más importantes de mi vida.
En fin, que después de haber hecho la reunión "de la semana que viene" como comenté en el blog anterior, encontré muchísima menos resistencia de la que esperaba y a pesar de que se cayó en algunas discusiones tontas, finalmente llegamos al acuerdo de que cada uno explicaría su aplicación y metodología favoritas para la gestión de incidencias y de código fuente.
La únicas condiciones impuestas eran que las aplicaciones fueran gratuitas y que se pudieran utilizar en desarrollos Java y .NET.
Yo propuse Trac + Subversion. El resto fueron más tradicionales: BugZilla. Trac ganó con gran ventaja por su integración con Subversion y por ser más flexible.
En fin, que desde hace 6 meses en todos los proyectos utilizamos Trac + Subversion, y aunque nada es perfecto, estamos mucho mejor que antes, tanto que ya le gente no recuerda cómo se trabajaba sin estas herramientas.
Me felicito! :-)
En fin, que después de haber hecho la reunión "de la semana que viene" como comenté en el blog anterior, encontré muchísima menos resistencia de la que esperaba y a pesar de que se cayó en algunas discusiones tontas, finalmente llegamos al acuerdo de que cada uno explicaría su aplicación y metodología favoritas para la gestión de incidencias y de código fuente.
La únicas condiciones impuestas eran que las aplicaciones fueran gratuitas y que se pudieran utilizar en desarrollos Java y .NET.
Yo propuse Trac + Subversion. El resto fueron más tradicionales: BugZilla. Trac ganó con gran ventaja por su integración con Subversion y por ser más flexible.
En fin, que desde hace 6 meses en todos los proyectos utilizamos Trac + Subversion, y aunque nada es perfecto, estamos mucho mejor que antes, tanto que ya le gente no recuerda cómo se trabajaba sin estas herramientas.
Me felicito! :-)
Subscribe to:
Posts (Atom)