subscripción
Blog de Julio César Pérez Arques
Cierre y resumen del 2009
Diciembre 31st, 2009 - [Enlace local]
Finalmente este año 2009 llega a su fin. Ha sido un año que ha dado mucho de sí. Marcado, profesionalmente hablando, por La Crisis, Oracle compra Sun y el rugir de lo Ágil. Es tiempo de hablar con uno mismo, celebrar los éxitos, reconocer los errores, aprender de las experiencias y plantearse nuevas metas. Descansar el cuerpo y la mente, para volver ya el año que viene con renovadas fuerzas.
En lo relativo a este blog, me quedo con la espinita clavada de no haber superado el número de posts del año pasado. 35 el año pasado, por 34 éste. Por poco. Y eso que iba por muy buen camino, pero en Agosto me mudé y con el ordenador en el suelo, aún a falta de elegir mi despacho, se hace muy duro escribir.
Lo que sí han aumentado considerablemente han sido el número de visitas y el número de suscriptores. El primero se ha doblado (cerca de 35.000), aunque mucha culpa la tienen las visitas desde Google, y el segundo se ha quintuplicado (190). Pero lo que más me ha gustado han sido los debates que se han generado en algunos posts. Muchas gracias a todos.
El top 5 de los posts más visitados de este año ha sido (1) Buenas prácticas para desarrollar Servicios web SOAP, (2) Esquema de un Sistema de Gestión de Desarrollo Software, (3) Chuleta Maven, (4) 10 formas de mejorar tu código y (5) Programación basada en Google.
Una de mis nuevas experiencias de este año ha sido gracias a Jorge Rubira, que me invitó a participar en los podcasts Servicios web y Testing de aplicaciones de javaHispano. Fue un auténtico placer contribuir en ellos junto al susodicho, a Alfredo Casado, Leonardo de Seta y Jorge Luis Bugarín.
También me ha dado tiempo a hacer un experimento con AdSense. No es que quisiera monetizar el blog, simplemente tuve un ataque de emprendedor y quería ver, de primera mano, cómo funcionaba el tema de la publicidad en páginas web. De hecho, no ha llegado a generar ni 5 euros y no se cobra nada hasta que no se ganan al menos 70. En el próximo diseño del blog lo eliminaré.
Otra opción que estoy meditando es si pasarme a contractor o freelance y anunciar mis servicios por el blog. Ya veremos...
Llegados a este punto, sólo me queda desearos un Feliz 2010 y dedicaros un brindis por el talento.
» Leer más, comentarios, etc...
PROGRAMANDO EN .NET
Propósitos para el 2010
Diciembre 30th, 2009 - [Enlace local]
Pues eso, a falta de horas para que acabe el año se me ha dado por hacer una lista de los propósitos para el 2010, a ver si consigo cumplir con alguno :P- Ser bueno ... no, voy a seguir siendo malo que es más divertido :D- Acabar alguno de los 2 libros que tengo sobre Arquitectura de aplicaciones en .NET- Probar la beta 2 del Visual Studio 2010, a ver si este cambio de versión no me pilla el toro
» Leer más, comentarios, etc...
DGG
¿Por qué fracasan los proyectos? Fase I: Captura de requisitos
Diciembre 29th, 2009 - [Enlace local]
En este post quería analizar los principales puntos que a mi entender son claves en el fracaso de un proyecto. En esta primera entrada quería centrarme en los fallos que se cometen en la primera fase del proyecto: La captura de requisitos y el análisis. Los fallos cometidos durante esta fase serán los fallos más graves porque serán arrastrados hasta el último día del proyecto y durante toda la vida útil del software por eso es la fase más importante del proyecto.
Desde mi punto de vista estos son los fallos más comunes:
1.- Análisis de requisitos insuficientes.
Para poder terminar un proyecto es necesario recopilar los requisitos funcionales de éste, si esta captura no se realiza formalmente durante esta primera fase tendrá que hacerse durante la fase de diseño o peor aún durante la fase de desarrollo. Ya hay un término que describe esto: IKIWISI (I’ll know it when i see it). El cliente no sabe lo que quiere o no se le involucró lo suficiente durante la captura de requisitos, y las consecuencias son que el cliente querrá cambiar o añadir nuevos requisitos cuando vea el trabajo ya finalizado, es decir, al final de la fase de desarrollo.
Si la gestión del proyecto se basa en esta anti-metodología IKIWISI del prueba-error será imposible que el proyecto no se retrase y se multipliquen los costes. Si comparamos este proyecto software con un proyecto más simple, por ejemplo, pintar una habitación, en esta anti-metodología el pintor empezaría a pintar la habitación sin que el cliente se involucrase en la decisión de elegir el color. Cuando el pintor haya terminado de pintar 3 paredes en azul se las enseñaría al cliente, y este opinará que el color es muy frío, preferiría uno más cálido, ahora el pintor si quiere contentar al cliente tendrá que lijar las 3 paredes y decide pintarlas de rojo, cuando ya están terminadas se las enseña de nuevo al cliente, pero por desgracia el rojo le parece demasiado cálido. Después de varios días de tensión porque se multiplican los costes y se retrasa el proyecto, acuerdan pintar la habitación en naranja y cerrar el proyecto. Después de una semana de retraso, el pintor termina las cuatro paredes en naranja y el cliente por fin está medio contento. Es lo que al final quería, pero tras un retraso considerable, y unos costes que se multiplicaron por 3. Si se hubiese realizado adecuadamente la captura de requisitos, ambos se hubieran ahorrado los retrasos y los sobrecostes.
2.-Cambios frecuentes en los requisitos.
Al no haber un documento funcional donde se describa lo que se acordó, el cliente tiene total libertad para cambiar los requisitos a su libre albedrío y cuantas veces quiera. Si hubiese un documento formal donde se describan los requisitos sería mucho más fácil para el jefe de proyecto oponerse a estos cambios, si no tiene nada, al final acabará cediendo a todos los cambios y nuevos requisitos porque no tiene a qué agarrarse.
3.-Planificación no realista.
Incluso teniendo en cuenta el mejor de los casos, donde hay un análisis de requisitos bien documentado, no se suelen tener en cuenta muchas series de factores que van a influir seguramente en la planificación. Estos factores pueden ser: vacaciones del personal, fiestas, posibles bajas, posibles inclemencias del tiempo, fallos técnicos, etc…
Para contrarrestar estos imprevistos los jefes de proyecto pueden añadir más presión al equipo de programadores, pero esto será sólo un parche y no conseguirá hacer mejor software mediante esta estrategia, aparte de otros muchos inconvenientes que pueda tener. Los programadores bajo presión trabajan más rápido, pero no trabajan mejor.
“People under time pressure don’t work better; they Just work faster.”
Tom DeMarco & Timothy Lister.
Referencias:
http://www.joelonsoftware.com/articles/fog0000000036.html
http://www.joelonsoftware.com/articles/PickingShipDate.html
http://garciagonzalezdavid.wordpress.com/2008/08/12/the-art-of-project-management/
http://garciagonzalezdavid.wordpress.com/2006/10/31/peopleware-productive-projects-and-teams/
http://es.wikipedia.org/wiki/The_Mythical_Man-Month
Posted in Gestión Tagged: management
» Leer más, comentarios, etc...
Najaraba.com: Software libre, metodologías ágiles y más.
Quinto cumpleaños
Diciembre 29th, 2009 - [Enlace local]
Hoy hace cinco añitos este blog. Casi abandonado y en la pobreza de posts sobrevive a mi poca dedicación al mismo. Pensaba que este año había sido el más triste en el mundo Najaraba, pero ahora he visto que el 2007 fue incluso más parco en la publicación de posts.Así que solo saludo al personal que siga leyendo este blog, y que informo que sigo vivo :)Aunque este año ha ido bastante activo en
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Participación en el podcast Testing de aplicaciones de javaHispano
Diciembre 23rd, 2009 - [Enlace local]
En javaHispano han publicado las dos partes del podcast Testing de aplicaciones en el que tuve el enorme placer de participar durante una noche del ya lejano mes de Noviembre.
El podcast fue en realidad una intensa tertulia, junto a Alfredo Casado, José Luis Bugarín y Jorge Rubira, donde mezclamos la importancia y ventajas del testing automático de aplicaciones con experiencias, buenas prácticas, técnicas, frameworks y herramientas.
La primera parte se centra más en introducir el testing automático, los tipos de tests, buenas prácticas y la metodología TDD.
Mientras que en la segunda parte se tratan herramientas y frameworks concretos, principalmente del mundo Java, para terminar comentando cómo explotar el testing al máximo desde un entorno de integración continua.
Poco más que añadir a lo contado en el podcast y comentado en javaHispano. Sólo volver a animaros a dar el salto a hacer testing a los que aún no lo habéis hecho. Merece la pena.
Espero que os haya gustado.
» Leer más, comentarios, etc...
PROGRAMANDO EN .NET
Establecer propiedades del IDE de Visual Studio dependiendo del proyecto que se abre
Diciembre 18th, 2009 - [Enlace local]
En el proyecto en el que estoy trabajando tenemos en el Team Foundation un branch con la solución de desarrollo y otro con la misma solución de producción. Considero que es una buena práctica que evita subir código no probado a producción y por ahora nos está llendo bastante bien.El "problema" es que a veces tenemos que tener ambas soluciones abiertas a la vez, y como los cambios que tienen
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Un test para todos tus mapeos Hibernate v2.0
Diciembre 10th, 2009 - [Enlace local]
El otro día uno de mis chicos me dió un tirón de orejas. Resulta que el test para probar todos los mapeos de las entidades Hibernate de un proyecto que publiqué en el pasado, no es correcto para la versión 3 de Hibernate. La culpa es del método iterate de Query, que si bien en la versión 2 de Hibernate hacía un select de todas las columnas, en la versión 3 sólo lo hace de aquellas que forman el identificador de la entidad.
Así que nueva versión del test, compatible con Hibernate 3 y un poco más sofisticada. Allá va.
public void testHibernateMappingsOk() {
boolean allOk = true;
Map metadata = sessionFactory.getAllClassMetadata();
for (Iterator i = metadata.values().iterator(); i.hasNext();) {
EntityPersister persister = (EntityPersister) i.next();
String entityName = persister.getEntityName();
try {
Query q = session.createQuery("from " + entityName);
q.setMaxResults(1);
q.uniqueResult();
} catch (HibernateException e) {
logger.warn("ERROR probando el mapeo de la entidad " + entityName, e);
allOk = false;
}
}
assertTrue(allOk);
}
» Leer más, comentarios, etc...
PROGRAMANDO EN .NET
Imprimir el contenido de un DataGridView con PrintDocument (en VB.NET)
Diciembre 9th, 2009 - [Enlace local]
Dada la cantidad de comentarios (más de 10 :P) que se produjeron en el post en el que explicaba como imprimir el contenido de un datagrid, me veo en la obligación a hacer el mismo ejemplo en VB.NET, sobre todo porque el código que puse en los comentarios tenía algún error.Recordando el ejemplo, se trata de un formulario que contiene:- un datagrid llamado DataGridView1 - un botón llamado Button1-