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 (lamentablemente el link no funciona mas)
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.
En 1994 se celebro una competición de remo entre dos equipos:
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.
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
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.
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.
Vivo en Capital Federal, Argentina, en el famoso barrio de Caballito; cerca del Parque Centenario (para los que conozcan).
Los invito a participar de este espacio que, como dice por ahi, intenta ir entendiendo mejores formas de construir software (desde ya iterativamente)
