La Iteración menos uno
- Detalles
- Publicado: Jueves, 14 Agosto 2008 00:00
- Escrito por Carlos Alvarez
Si tan sólo fuera tan simple.
Si tan sólo fuera tan simple.
El problema de la rotación de personal no es un tema menor para aquellos que poseen empleados. Si bien en algunas actividades de baja calificación "casi cualquiera" puede realizar las tareas, por lo general el personal con cierta antiguedad representa toda una inversión por parte de la empresa.
Se ha integrado al equipo, ha asimilado la cultura de la empresa, conoce los modos de trabajo... todo esto se pierde cuando un empleado se marcha.
Es un tema interesante... los dejo con la nota de la Lic. Gonzalez.
La gestión del riesgo se refiere a reducir la probabilidad e impacto de los eventos adversos en un proyecto. El desarrollo Ágil de software, debido a su carácter iterativo, implícitamente hace que la gestión del riesgo forme parte del ciclo de vida del proyecto. Los miembros de la comunidad Ágil discutieron si es necesaria la gestión del riesgo explícita, la capacidad de Scrum para gestionar todos los tipos de riesgo y que debería hacer la gestión de riesgos.
Michele Sliger sugiere que en el desarrollo de software Ágil el riesgo se gestiona todo el tiempo: en parte en el Scrum diario, en las reuniones de planificación de cada iteración, en las reuniones de planificación de release, y también en las reuniones de revisión y retrospectiva. Sin embargo, ella sugiere un enfoque estructurado para la gestión de riesgo. Los pasos incluyen:
Johnny Chung Lee es un muchacho muy creativo que se encargó de encontrarle aplicaciones completamente novedosas para el Wii Remote, el control remoto de Wii, la consola de juegos de Nintendo. Y cuando digo "novedosas" quiero decir "absolutamente alucinantes".
El Wii Remote es en realidad una cámara sensible a la luz infraroja (la emitida, por ejemplo, por los controles remoto). Se ubican unos emisores infrarojos cerca del televisor; el Wii Remote se utiliza con las manos, y al moverlo la Wii puede detectar el movimiento y posición, traduciendo esto en acciones en el juego.
Johnny pensó algo completamente distinto para el Wii Remote, y con algo de ingenio nos muestra en video aplicaciones sorprendentes.
En los últimos 8 años, la plataforma Java EE fue creciendo y madurando en forma constante, y actualmente cubre un amplio rango de necesidades para aplicaciones web y corporativas. Además, la plataforma Java EE cuenta con una enorme y activa comunidad y mercado que crean tecnologías adicionales, frameworks y aplicaciones que funcionan sobre la plataforma. Algunas de estas soluciones brindan facilidades que no se encuentran en la plataforma. Otras proveen alternativas a las facilidades de la propia plataforma.
Java Enterprise Edition 6, definida en JCR 316 y planificada para este año, tiene como objetivo central el incorporar y soportar a estas tecnologías adicionales como parte natural del escenario Java EE, y a la vez continuar simplificando la plataforma para poder llegar a más desarrolladores.
Para lograr esto se proponen dos temas centrales para Java EE 6: extensibilidad y perfiles.
Intel está preparándose para lanzar la nueva arquitectura Larrabee en el 2009-2010. El nombre todavía no es el definitivo (sinceramente, Larrabee no pasó por el departamento de marketing), pero la tecnología es más que interesante, y podría provocar uno de los cambios más grandes de los últimos años para la industria del hardware: Larrabee promete volver obsoletas a las actuales placas aceleradoras de video para los juegos. ATI y nVidia, por ahora, miran cautelosos.
En High Scalability publican un truco interesante, este consiste en utilizar el servicio de Google de hosting de librerías JavaScript que es gratis. Del proyecto que se trata es AJAX Libraries API y por ahora están alojando jQuery, jQuery UI, prototype, script.aculo.us, MooTools, y dojo.
Este servicio se puede usar desde cualquier página web y es tan sencillo como referenciar a los archivos JavaScript que queremos utilizar.
Donde trabajo, comenzamos hace poco a formalizar las revisiones de código. Esperábamos que fuera algo bastante polémico dentro del grupo de desarrolladores, aunque no resultó así. Antes de comenzar a trabajar en el sistema de revisiones de código, leímos bastante sobre el tema y tomamos los recaudos que nos parecían necesarios.
El tema de las revisiones en nuestro grupo ha surgido como un complemento a la implementación de TDD.
El trabajo en Sistemas no siempre es placentero. Después de todo, no es posible que estemos siempre usando las últimas y más simpáticas tecnologías: alguien tiene que encargarse del trabajo sucio. A veces, literalmente.
Desafortunadamente, este trabajo sucio es a menudo necesario para que la empresa funcione. ¿La buena noticia? Convertirse en experto en al menos alguna de estas técnicas nos asegurará trabajo de por vida. Claro, no necesariamente nos va a gustar...