¡Una empresa entera ágil!
- Detalles
- Publicado: Miércoles, 23 Diciembre 2009 15:50
- Escrito por Diego Gomez
Hablando el mes pasado con mi amigo Siraj nos preguntamos ¿por qué la "filosofía" ágil no resulta tan bien en los negocios como un todo?. Lo que quiero decir es que resulta bastante fácil de encontrar hoy en día un departamento de desarrollo de productos/software de una empresa que use métodos ágiles, pero ¿qué es lo que falta para que recursos humanos, marketing, financiero, administrativo, comercial y todos los demás departamentos también entren en esto?
Nosotros, los agilistas y los ingenieros de software, estudiamos mucho acerca de cómo organizar y gestionar un proyecto, desarrollar el software, probarlo, implementarlo, etc. Nos enfocamos bastante en la forma de maximizar el retorno y el valor de los requisitos y funcionalidades generados en un proyecto de software. Pero, ¿será que estamos preguntando si el proyecto en sí crea valor para la organización? Y más que eso: ¿será que ese proyecto en particular genera más valor que otro proyecto, que podría estar teniendo problemas debido a la falta de recursos? 
Imaginen si existieran perillas para manejar la capacidad (o velocidad), el tiempo de ciclo, la calidad y la predictibilidad de los proyectos, y que pudieramos configurar nuestro proceso moviendo estas perillas. "Quiero alta capacidad, tiempos de ciclo bajos, alta calidad y alta predictibilidad. Así que voy a girar estas perillas a 10, 1, 10, 10 respectivamente".
Antes de Java EE 6, podíamos crear objetos DataSource usando mecanismos propietarios de cada proveedor (como comandos), y así usábamos el DataSource en la aplicación. Sin embargo, Java EE 6 hace que la definición de DataSource sea más flexible. Java EE 6 presenta un nuevo mecanismo para definir objetos DataSource, que podemos declarar de forma portable en cualquier servidor de aplicaciones compatible con Java EE 6. Ahora podemos declarar las definiciones de los DataSource usando anotaciones o en los descriptores de despliegue.
"ScrumMaster" es un nombre que sugiere ser el guardián del proceso de Scrum. Él es un agente de cambio que apoya a su equipo, que enseña y promueve Scrum en toda la organización. Garantiza el buen funcionamiento de las actividades del equipo erradicando los impedimentos y manteniendo al equipo protegido de las distracciones externas. Sin embargo, en ciertos escenarios, los equipos ágiles sienten que el ScrumMaster en sí es el mayor impedimento. 
El coaching consiste en generar conversaciones de calidad en las cuales el coach ayuda al coachee a ver nuevas perspectivas y posibilidades, de manera que pueda tomar el siguiente paso en su crecimiento personal y profesional. En el contexto de los equipos ágiles, el coaching asume dos posturas: de coaching y de mentoring. Si, se hace coaching para ayudar a alguien a alcanzar su próxima meta en su vida. También se comparten conocimientos de experiencias ágiles e ideas, se los guía para usar métodos ágiles. El coaching y el mentoring se cruzan para desarrollar talentos ágiles, de manera que puedan alcanzarse más y mejores resultados para el negocio.
Hace unos días 
Después de varios meses de trabajo ya está disponible 
Cuando desarrollamos aplicación con spring, quartz y la configuración de los jobs queda empaquetada en la aplicación, resulta bastante molesto tener que cambiar la configuración, recompilar y desplegar nuevamente la aplicación, en algunos casos hasta se tiene que volver a la configuración inicial luego de una sola ejecución. Para no tener que caer en esto, nos podemos valer de JMX y exponer el bean que contiene el método que es ejecutado por quartz.