GWT (Google Web Toolkit) se ha convertido en uno de los frameworks más populares para el desarrollo de aplicaciones web que siguen el paradigma AJAX.
En el artículo Creación de soluciones modulares con GWT y Maven exploramos la creación de aplicaciones web modulares utilizando Apache Maven para la construcción de la solución y la gestión de sus dependencias.
"¿Cuántos recursos necesitamos para este proyecto?". O incluso: "¿En cuánto debemos aumentar nuestra plantilla?" Si estás trabajando o has estado trabajando en algún tipo de entorno corporativo, es muy probable que hayas escuchado estas frases (o algunas similares... o peores). Si sos un Líder de Proyectos, tal vez estés usando estas frases en tu día a día. Este tipo de frases se volvieron comunes en la industria del software y las personas la usan sin prestar atención a lo que la frase realmente representa. "Recursos Humanos" es comúnmente el nombre del departamento que gestiona personas.
Si usás frases como estas, por favor, pará. ¡Ahora!. No porque es ofensivo para quienes llamás "recursos" (aunque si lo es). La razón para no utilizar este tipo de frases es que refiriéndote a tu gente como "recursos" haces daño a tus proyectos.
Es común que algunos equipos, durante la retrospectiva, tengan problemas en seguir y recordar los impedimentos que tuvieron y el contexto dentro del cual ocurrieron. Una forma de salvar esta situación es crear eventos clave e impedimentos diarios en el mismo gráfico de burndown. Este gráfico ya tiene una escala de tiempo, así que ¿por qué no aprovecharla?.
En este artículo veremos dos variantes para que el gráfico de Burndown nos muestre más información útil.
A veces veo algunos equipos obsesionados con la planificación del sprint, especialemente con la estimación de las tareas. Quiero decir, realmente obsesionados. ¿Dos días de planificación para un sprint de dos semanas? Aunque no lo crean, ocurre. Incluso aunque se quejan de pasar mucho tiempo en las reuniones de Scrum, insisten y discuten los detalles de la estimación de cada tarea. Por suerte, para aquellos equipos que quieran aprovechar su experiencia en Scrum y en las planificaciones, eliminar la estimación de tareas es una opción.
El tutorial Primeros pasos con el ESB Apache ServiceMix 4 presenta una primera toma de contacto con la próxima versión del ESB de software libre.
La nueva versión de ServiceMix incorporará el estándar OSGi para seguir liderando la implantación de soluciones SOA de software libre. De esta forma, ServiceMix 4 se alinea con la corriente predominante en los nuevos desarrollos de servidores de aplicaciones Java como Sun Glassfish, Bea Weblogic o el SpringSource dm server.
Creo que pasó la hora que los desarrolladores maduren un poco en cuanto a la necesidad de probar TODA y CUALQUIER aplicación que sea escrita, independientemente de su tamaño. Creo que ya pasó hace mucho la fase en la cual la arrogancia era suficiente para creer que su aplicación funcionaría sin tests (después de todo, ¡usted es el mejor programador del mundo!).
Este es un asunto un poco controvertido en la comunidad, tenemos defensores de los 2 abordajes, los libros de Ken Schawber y Mike Cohn, vemos la recomendación de estimar las tareas en horas, pero ya hace algún tiempo la idea de abrir mas las estimaciones de tareas está creciendo y ganando fans y yo soy uno de ellos en particular. Lo que suele ocurrir es que la planificación del sprint puede ser largo y cansador cuando el equipo tiene que estimar cada una de las tareas que considera son necesarias para desarrollar los temas del backlog, que normalmente se ve son interminables discusiones de si una tarea va a llevar 4 o 6 horas, cuando esta información no es realmente importante a la hora de entregar un elemento rápido.
La grandeza se concibe en la intención de lograr algo en una escala apropiada; nace de la aplicación de la integridad; florece en la navegación de los conflictos; y madura con la vitalidad de la pasión.
El Ciclo de la Grandeza es un ciclo de comportamiento de equipos muy importante. Es facil de entender, pero dificil de practicar. Comprender y lograr este ciclo es la forma de vencer la mediocridad personal y grupal.
El Ciclo cuenta con las siguientes fases:
Las personas que son "inteligentes" suelen ser más que las personas que tienen los otros atributos esenciales para crear gran software. Sin embargo, siempre es preferible, o más inteligente, que los equipos tengan la mezcla correcta de cualidades. Más aún, cualquier equipo que consista sólo de personas realmente inteligentes no va a estar enfocado exclusivamente en su "inteligencia" cómo única virtud para el éxito del equipo. La inteligencia, por definición, va a darse cuenta de esto; si no lo hace, no es inteligencia, sino una pseudo-inteligencia.
Pero, ¿qué signifca ser inteligente para un equipo?
En diciembre de 2008, se realizó un evento en Chicago del que resultó el Manifiesto para el Arte del Software. Este manifiesto busca establecer valores para la creación de software y elevar las expectativas que existen sobre el software profesional.
Quienes estén de acuerdo pueden firmar el manifiesto para ser agregados a la lista. Antes, los invito a repasar a continuación el Manifiesto para el Arte del Software.
¿Viste esos momentos en los que estamos profundamente inmersos en la resolución de un problema técnico en un proyecto?
Muchos de estos momentos son importantes ya que comunmente nos ofrecen grandes desafíos intelectuales, y una vez resueltos nos brindan momentos de gran satisfacción para nuestro sistema mental de recompensas. Siendo que muchas veces, especialmente cuando se trata de un proyecto solo, realmente no hay otra forma, tenemos que tener esta actitud heroica para ser "asesinos de problemas" en el proyecto, lleve el tiempo que fuese necesario (en minutos, horas o días), y a cualquier costo, al final sino las cosas no caminan.