Una técnica de estimación de proyectos basada en Casos de Uso

Si bien el movimiento ágil (tan de moda últimamente) dice claramente que no se debe ni puede estimar un proyecto completo al momento de iniciarlo y que cualquier técnica que intente hacerlo va a terminar mal; no son pocas las veces que se necesita conocer de ante mano la duración estimada del mismo. Hay que tener muy en claro que esta estimación suele ser de mínima (el proyecto no va a tardar nunca menos de esto) pero la duración real puede incrementarse mucho; a menos que sean sumamente estrictos y acotarse a hacer únicamente lo que se escribió dentro de los casos de uso utilizados en la estimación.

A partir de un mail, donde alguien preguntaba como estimar un proyecto; se me ocurrió postear una forma a mi me da resultados aceptables. No tiene conceptos teóricos, es una solución netamente empírica que a mí me funciona (si utiliza algunos conceptos teóricos “blandos”, pero nada más). Algunas ideas están tomadas prestadas del libro “Software Estimation” de Steve McConnell (muy recomendado).

Disclaimer: Desde ya que la estimación y planificación de proyectos es una tarea muy compleja y única. Cada proyecto tiene sus detalles, sus compromisos, sus equipos, tiempos, costos, etc. Cada proyecto es un mundo y como tal, esta técnica que yo utilizo debe ajustarse y modificarse con criterio (y hasta puede no servir). Sea cual sea la técnica final a utilizar, siempre tener cuenta de no cometer errores conocidos.

Terminada ya la introducción pertinente al tema, les comento la técnica:

Notificar cambios de forma sistematica

En los últimos días me surgió la necesidad de notificar a la vista cada vez que ocurrian cambios en el modelo. La solución rápida, aburrida y repetitiva es la de ir a la clase base del modelo y publicar los eventos. Luego ir a cada clase del modelo y en todos los setters agregar el codigo para notificar el cambio.

Haciendo uso de Reflection, delegates anonimos y generics; implementé otra solución que si bien no es super novedosa, me pareció que vale la pena compartir con ustedes.

Jornadas Agiles 2008

Ya se vienen las “Primeras jornadas latinoamericanas sobre metodologías ágiles” en el hotel Bauen. Entre otras cosas, durante las jornadas se dictaran cursos para certificarse como scrum master (al cual estoy inscripto hace rato).

A pesar de no haber participado en la organización, se que se hizo bastante a pulmón y ad-honorem asi que esta bueno ver que no se necesita ser una gran empresa para organizar este tipo de eventos.

Les dejo el link en caso que quieran ver el programa de charlas y anotarse en alguna:Jornadas Agiles 2008

Drop Box – Almacenamiento Remoto

Gracias a la invitacion de un amigo mio, estuve probando DropBox.

DropBox se instala como una carpeta virtual dentro de windows o mac y uno puede copiar archivos como si estuviese trabajando local, pero esto se transmite a un almacenamiento remoto; permitiendo compartir informacion entre distintas ubicaciones de una manera muy facil. La sincronizacion es excelente, no interfiere para nada. Entre otras cosas tambien tiene versionado de documentos y la posibilidad de compartir carpetas.

Les recomiendo que lo miren, funciona muy bien. En la pagina hay videos de demostracion de su uso. La pagina es: http://www.getdropbox.com

Si les interesa me pueden dejar un comentario, con algun email y les envio una invitacion. Por el momento me quedan 5.

RAF 08

Enviada a la lista de arquitectura del MUG, les dejo el link a los videos de la RAF (Regional Architect Forum) 2008.

http://www.arquitectum.org/portal/Publicaciones/Videos/RAF08/tabid/81/Default.aspx

Estimando con Planning Poker

Planning Poker

Estimar es la tarea más difícil del proceso de desarrollo. Nunca se tiene menos información que al momento de estimar y por otro lado, las decisiones tomadas marcan el futuro del proyecto. Si bien todos sabemos que son estimaciones, usualmente estos números (generados a partir de no conocer el problema) llegan al cliente y vuelven al equipo de desarrollo en forma de deadlines estrictos e inquebrantables. Hace poco, leyendo más que nada sobre la metodología SCRUM, me encontré con un método de estimación llamado “Planning Poker” que parece muy prometedor.

El Remero que podria ser programador

En 1994 se celebro una competición de remo entre dos equipos:

• Uno compuesto por trabajadores de una reconocida empresa argentina
• El otro por sus colegas de una similar japonesa.

Apenas fue dada la orden de partida, los remeros japoneses comenzaron a destacarse. Llegaron a la meta prontamente. El equipo argentino lo hizo una hora después. De regreso a nuestro país, la Dirección se reunió para analizar las causas del desconcertante e imprevisto resultado. Se llego a esta conclusión: En el equipo japonés había un jefe de equipo y diez remeros, mientras que en el argentino había un remero y diez jefes de equipo.

Etapas de un proyecto

1. Optimismo inicial
2. Fase de desorientación
3. Desconcierto generalizado
4. Período de desorden incontrolable
5. Búsqueda implacable de culpables
6. Sálvese el que pueda
7. Castigo ejemplar a los inocentes
8. Recuperación del optimismo perdido
9. Finalización inexplicable del proyecto
10. Condecoraciones y premios a los no participantes

La soja del software en la Argentina

Hace rato que le vengo dando vueltas al tema, pensando y pensando sobre la situación actual y perspectivas del mercado laboral. Han pasado varias etapas (al menos yo he pasado), momentos de poco trabajo, no existían las “punto com” e internet era algo impensado. Luego, de a poco el sector fue creciendo, se fue ubicando, fue ganando su lugar hasta llegar hasta lo que es hoy; un mercado muy dinámico, de alta rotación, buenos sueldos (en general) y baja calidad profesional (también en general). De a poco nos estamos convirtiendo en un mercado orientado a testers y no a ingenieros.

Generando CIL con CECIL

Este fin de semana me puse a investigar como inyectar código .Net con la librería Cecil. El uso más común para este tipo de práctica es el la programación orientada a aspectos. La idea es compilar un assembly .net y como proceso post-compilación modificar dicho assembly para agregarle funcionalidad. El ejemplo puntual es muy simple y no pretende ser un framework para programación de aspectos (al menos por ahora), pero si es útil para ver cuán poderoso son los mecanismos de reflection que brinda .net y abre la puerta para un montón de aplicaciones o bibliotecas de generación o modificación de código.