sábado, 16 de febrero de 2013

Conociendo Struts 2 - Armando mi primer Proyecto

En el anterior articulo aprendimos sobre el funcionamiento de struts  2, sus ventajas y desventajas, en esta ocasión buscaremos abordar en la practica como armar un proyectos en eclipse.

Si bien dentro de la carpeta lib de struts encontramos muchas librerías.



En esta ocasión utilizaremos las siguientes dado que por el momento estamos iniciando las practicas a manera que avancemos incorporaremos otras a nuestros ejemplos.


La información del objetivo de cada uno de estos jar de seguro se pueden encontrar en la red pero creo que es necesario brindar una pequeña reseña.

commons-fileupload: FileUpload analiza peticiones HTTP que se ajusten a la RFC 1867, "basada en formularios de carga de archivos en HTML". Es decir, si una petición HTTP se envía mediante el método POST, y con un tipo de contenido "multipart / form-data", entonces FileUpload puede analizar esa petición, y poner los resultados a disposición de forma fácilmente utilizado por la persona que llama.


commons-io: Commons IO es una biblioteca de utilidades para ayudar en el desarrollo de la funcionalidad de IO. Proporciona soporta para las operaciones de entrada y salida en general como escritura y lectura de archivos, gestión de filtros, comparación de archivos entre otras virtudes que por lo general todo proyecto struts 2 lo requiere.


commons-lang3: Lang ofrece una serie de servicios públicos de ayuda para la API de java.lang, en particular los métodos de manipulación de cadenas, métodos numéricos básicos, objeto de reflexión, la simultaneidad, la creación y la serialización y propiedades del sistema. 


commons-lang: lang3 es una version mas nueva de esta que utiliza otras clases, esta no es necesaria incluirla.


commons-logging: Apache Commons Logging (JCL) nos proporciona una Interfase cuyo propósito es ser una "abstracción" independiente de otros frameworks o toolkits de Logeo.

Por lo general se utiliza esta interfase en el código y después conectar una implementación en especifico (Log4J,Avalon LogKit , JDK 1.4 Logging API) a través de configuración sin necesidad de modificar el código. 

  1. import org.apache.commons.logging.Log;  
  2. import org.apache.commons.logging.LogFactory;  
  3. public class BasicLogging  {  
  4.    private static final Log LOGGER = LogFactory.getLog(BasicLogging.class);  


la cual puede ser utilizada de la siguiente forma en cualquier parte del código: 

LOGGER.info("Test de logging"); 

freemarker: FreeMarker es un "motor de plantillas", una herramienta genérica para generar la salida de texto (nada de HTML a código fuente generado automáticamente), basado en plantillas, está diseñado para ser práctico para la generación de páginas Web HTML, sobre todo por las aplicaciones basadas en servlets que utilizan el patron MVC (Model View Controller).


javassist: es una biblioteca de Java que proporciona un medio para manipular el código de bytes de Java de una aplicación.  En este sentido Javassist proporciona el soporte para  reflexión, es decir, la capacidad de cambiar la implementación de una clase en tiempo de ejecución.


ognl: significa Lenguaje Objeto-Graph Navigation, es un lenguaje de expresión para obtener y establecer las propiedades de los objetos de Java, además de otros extras como la proyección y la lista de selección y expresiones lambda. Se utiliza la misma expresión, tanto para obtener y establecer el valor de una propiedad.


struts2-core: ni hablar es el corazón de struts 2.


xwork-core: ni hablar el otro corazon de struts 2.


Nota: repasando en si esta son las dependencias que requiere struts para hacernos la vida fácil en el modelo de MVC que propone.


Primero creamos un proyecto dinámico en Eclipse: File à  New à Dynamic web Project




Nota: Le daremos el nombre en mi caso struts2_Ejemplo1 y por supuesto que lo enlazaremos a tomcat 7 que para esta etapa ya debería estar preparado y configurado, en caso contrario en el blog pueden encontrar una guia.

Ahora las carpetas que conforman mi proyecto y las que nos interesan en esta ocasión serán.



struts2_Ejemplo1\src : Directorio donde colocaremos las clases HolaMundo.java y en este caso el descriptor struts.xml.


Nota: como todo en java este framework struts utiliza un archivo de configuración llamado struts.xml y que por lo general deberemos colocarlo en la carpeta proyecto\src  en futuras entregas podremos notar que esto puede cambiar.


struts2_Ejemplo1\WebContent: Directorio donde colocaremos los JSP que para esta ocasión utilizaremos solo dos index.jsp y bienvenida.jsp.


struts2_Ejemplo1\WebContent\WEB-INF\  Directorio donde debería encontrar el descriptor de despliegue web.xml.


struts2_Ejemplo1\WebContent\WEB-INF\lib Directorio donde colocamos las librerías que usaremos de struts esta vez.

.
el resultado final debería ser algo como esto.




Mas claro imposible tenemos armada la estructura básica de mi primer proyecto struts, ahora vamos a trabajar en que esto pueda caminar.




























En primera instancia lo que debemos hacer es es indicar a Apache Tomcat que toda petición debe ser interceptada y gestionada por el filtro “FilterDispatcher”, el cual es el controlador de nuestra aplicación, para esto deberemos modificar el descriptor de despliegue web.xml.


<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">

  <display-name>struts2_Ejemplo1</display-name>

  <filter>

   <filter-name>struts2</filter-name>

   <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>

  </filter>

  <filter-mapping>

   <filter-name>struts2</filter-name>

   <url-pattern>/*</url-pattern>

  </filter-mapping>

  <welcome-file-list>

    <welcome-file>index.html</welcome-file>    

  </welcome-file-list>

</web-app>

Esta configuración es la más básica y por defecto para usar struts 2, podemos apreciar que se hace referencia al controlador (FilterDispatcher), el mapeo de las urls: /*, el cual indica al controlador que revise todas las peticiones (request) que envíe el cliente, y por último la página de inicio por defecto: index.html.

El siguiente paso es modificar el archivo de configuración de src\ struts.xml en donde estan las acciones a ejecutar por Struts 2.



<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE struts PUBLIC

    "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN"

    "http://struts.apache.org/dtds/struts-2.0.dtd">



<struts>

    <package name="default" extends="struts-default">



            <action name="holaMundo" class="actions.HolaMundo">

                  <result name="SUCCESS">/bienvenida.jsp</result>

            </action>

     

    </package>

</struts>

Dentro del paquete van las acciones, , la cual tiene los atributos básicos:name, el cual es el nombre de la acción a realizar, en este caso, cuando en la url termine en: holaMundo.action (notar que en el archivo struts.xml no viene ese nombre, no es necesario ya que struts es lo suficiente inteligente para mapearla), luego en este caso hay una clase en el atributo class que ejecutará la acción (Modelo, la clase Action), la cual tiene la Uri donde se encuentra:actions.HolaMundo. luego tenemos el resultado que se mostrará con el result al cliente en caso que sea exitosa la acción: <resultname="ok">/bienvenida.jsp</result>, esto nos dice que en caso de devolver la cadena (String) ok la acción (HolaMundo.java), nos envíe a la página: bienvenida.jsp



Las acciones son las encargadas de definir cual será la clase que se encargará de procesar la petición solicitada y cual será la respuesta dependiendo del resultado. Estas acciones se registran dentro de struts.xml.
La estructura básica de una acción es la siguiente:

   /pagina_error.jsp
   /pagina_exito.jsp
Nombre_Accion: identificador por el cual se llama a la accion desde la “Vista” (archivos JSP).
Paquete.Nombre_Clase: Controlador encargado de realizar la logica de la accion. Es una clase java, ubicada en algun paquete.
pagina_exito.jsp/pagina_error.jps: Son jsp’s que dependiendo si la respuesta del controlador serán visualizados.
Entonces, la logica desde el punto de vista de las acciones es la siguiente:
  • Se llama una acción (desde algún jps a struts.xml)
  • Se realiza la lógica (en alguna Clase)
  • La clase entrega un resultado (desde la Clase a struts.xml)
  • En función del resultado, se visualiza el jsp. ( desde struts.xml a jsp)
Ahora es el momento de hablar de los action, Struts 2  no te obliga a implementar ninguna interfaz o extiende de alguna clase, sólo es necesario para poner en práctica un método execute () que devuelve una cadena para indicar que la página de resultados debe devolver.
un ejemplo de esto seria 
package actions;

public class HolaMundo {

 public String execute() {
  return "success";
 }
 
}

pero struts 2 nos proporciona de manera opcional la posibilidad de implementar una interface que ayuda mucho a nivel código en cuanto a lógica de funcionamiento como.

package com.opensymphony.xwork2;
 
public interface Action {
 
    public static final String SUCCESS = "success";
 
    public static final String NONE = "none";
 
    public static final String ERROR = "error";
 
    public static final String INPUT = "input";
 
    public static final String LOGIN = "login";
 
    public String execute() throws Exception;
 
}
ahora si nuestra clase implementara esta interfaz.


el resultado por supuesto no es ni mas ni menos el que nosotros cremos en el codigo anterior respetando los requerimiento de struts 2 antes mencionados.


por lo que implementar la interface que nos proporciona el framework es de ayuda a que implementemos el método como nos indica o como lo necesita. 
Ahora tranquilos por que como pueden ver esto lo podemos hacer sin necesidad de implementar nada por lo que es algo que los programadores no tienden a usar mucho.

lo mas común es extender de ActionSupport que proporciona soporte para mensajes, acceso a propiedades, gestion de error y validación en si acceso a las acciones mas comunes a realizar en un action.



execute () - Este método ejecuta automáticamente cuando la acción se llama. Esta es la opción predeterminada  demostrando su lógica de negocio.

validate () - Este método es aplicado por defecto subclases método debe override este método para proporcionar validación.


ClearErrors () - Este método se puede utilizar cuando se quiere continuar con la ejecución, y quiere borrar el estado de la acción.


pausa () - Este método detiene / pausa la ejecución del método y devuelve inmediatamente la acción al resultado específico como Action.ERORR, Action.SUCCSESS, Action.INPUT. Cuando la próxima vez que esta acción es llamada se reanuda inmediatamente.


clearErrorsAndMessages () - Borra todos los mensajes de error y.


ClearErrors () - Borra todos los errores ().


clearMessages () - Borra todos los mensajes ().


ActionSupport clase también proporciona algunas LOG campos, textProvider,



NOTA FINAL: te quedo claro se usa para trabajar con action. 


por dios me la pase hablando de todo y nos fuimos de nuestro ejemplo de trabajo, por ello nosotros cuando creamos nuestra clase HolaMundo de seguro quedo algo asi.




bueno ahora vamos a agregar 1 propiedad de tipo string llamada Saludo


package actions;

public class HolaMundo {
  public String Saludo;   
}



llego la hora de generar nuestro pojo por lo que generamos los get y set para estas propiedades




El resultado final es 


ahora llega la parte interesante por que vamos a extender de la clase ActionSupport primero importamos la libreria necesaria y luego extendemos de la clase.



Nos presentara un conflicto por que no generamos un identificador serialversion


Desde el eclipse podremos generarlo sin problema.


Solucionado el problema aquí es donde nos encontramos



ahora no debemos olvidar la implementacion del método execute donde claramente llamaremos a un método e indicaremos el retorno donde struts.xml devuelve el resultado.



ahora tenemos que trabajar sobre las vistas donde en primera instancia vamos generar el contenido del archivo index.html.


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<META HTTP-EQUIV="Refresh" CONTENT="0;URL=holaMundo.action">

<title>Insert title here</title>

</head>

<body>

  <h3>Cargando...</h3>

</body>

</html>
 

Nota: como podemos observar el código html hace referencia a la llamada del action holaMundo que ejecutara la logica para proporcionar la salida en este caso un simple mensaje de saludo a la pagina resultante jsp.

y ahora vamos a editar el archivo bienvenida.jsp que debería quedar algo asi 


<%@ page language="java" contentType="text/html; charset=ISO-8859-1"

    pageEncoding="ISO-8859-1"%>

<%@taglib uri="/struts-tags" prefix="s"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

<title>Insert title here</title>

</head>

<body>

      <h1><s:property value="Saludo" /></h1>

</body>

</html>
 

por ultimo deberíamos ejecutar sobre tomcat y el resultado seria 





y el resultado obtenido debería ser 



nuestro primer ejemplo de ejecución con struts2, perdón por hacer tan largo esta guía pero creí necesario tocar temas que en otro sitio se pasan por algo generando una dependencia solo mecánica sin entender el por que de las cosas.

En futuras entregas vamos a incrementar la complejidad del ejemplo que ayude a entender las virtudes de struts 2.

De por si me gustaría escuchar comentarios de parte de los lectores dado que es lo que ayuda a la transmisión del conocimiento el entender la otra parte, la que consume, aguardo comentarios.




viernes, 15 de febrero de 2013

Conociendo Struts 2 - introducción y preparación de herramientas de trabajo

Si bien tuve la oportunidad de trabajar en modalidad MVC en tecnologia NET y JAVA, Struts 2 es un framework el cual no tuve la oportunidad de manipular por ello es que voy a trabajar un poco con el para entender sus posibilidades.

Por un lado esta de mas decir que struts 2 no es un continuación de struts 1 sino una unificación de dos framework como lo son webwork y struts. Por un lado struts es un MVC usado en un porcentaje alto de proyectos que hoy se encuentran implementados y funcionales por su fácil implantación  y una curva de aprendizaje aceptable para todo desarrollo. 


El desarrollo de Struts 2 está pensado para mejorar Struts aportando flexiblidad, sencillez y robustez a los elementos que se emplean en el desarrollo, facilitar el desarrollo de nuevas aplicaciones y el mantenimiento de aquellas que se desarrollen.

Por ello se hace una nueva arquitectura, una nueva API, nuevos Tags, etc., a partir de un framework existente WebWork, pero manteniendo todo lo bueno que tenía Struts.

El resultado lo vamos a analizar en una serie de por lo menos 10 artículos que nos posibiliten conocer este  framework sencillo y fiable.

Características de struts 2


1. Diseño Simplificado:  en la versión 2 en la cual se hace uso de Interfaces  provee una
mayor facilidad para la extensión y la adaptación, ya que los interfaces son más fáciles de adaptar que las clases abstractas utilizadas por struts. 
Los actions se convierten en POJOs, elementos que además estarán poco acoplados. Los POJOs son clases que cuentan con getter y setter para poder recibir valores desde páginas, y cuentan con algunos métodos en los cuáles pondremos la lógica de negocio.

2. Simplificación de los actions: Como hemos dicho los actions son POJOs , cualquier clase java con un método execute puede actuar como un Action. Así no se hace necesario implementar ningún interfaz. 

3. Desaparecen los ActionForms: se ven reemplazados por simples JavaBeans que son usados para leer las propiedades directamente. Lo usual es que el propio Action actúe de JavaBean, con lo que se facilita el
desarrollo. Además de ha mejorado la lectura de parámetros con el objetivo de no tener únicamente propiedades de tipo String.

4. Test simplificados: como los actions engloban la lógica de negocio y los JavaBeans, es más sencillo hacer test unitarios.

5. Fácil selección de opciones por defecto: casi todos los elementos de configuración tienen definidos un valor por defecto que se puede parametrizar, lo que facilita la elección de acciones por defecto.

6. Results mejorados: a diferencia de los Action Forwards, los results de Struts 2 son más flexibles a la hora de poder definir múltiples elementos de la vista. Además desaparece la complejidad de utilizar ActionForwards, ya que se sustituye por la devolución de Strings.

7. Mejoras en Tags: struts 2 permite añadir capacidades utilizando tags que permite hacer páginas consistentes sin añadir código. Los tags presentan más opciones, están orientados a los results y pueden ser
cambiados de forma sencilla. Además se añaden tags de marcado (markup) los cuáles son editables usando templates FreeMarker. Esto significa que podemos hacer que un mismo tag se comporte de forma
diferente sin tener que hacer ninguna tarea de programación.

8. Se introducen anotaciones: las aplicaciones en struts 2 puede usar anotaciones como alternativa a XML y configuraciones basadas en properties.

9. Arranque rápido: muchos cambios se pueden hacer sin necesidad de reiniciar el contenedor web.

10. Parametrización del controlador: Struts 1 permitía parametrizar el  procesador de peticiones a nivel de módulo. Struts 2 lo permite a nivel de action.

11. Fácil integración con Spring.

12. Soporte de Ajax: se incluye un theme AJAX que nos permite hacer

Como funciona Struts 2



Un usario envía una petición: Un usuario realiza la petición de un recurso dentro del servidor.

El elemento FilterDispatcher determina la acción que deberá responder: El framework dispone de los elementos requeridos para que el dispatcher sea capaz de determinar qué action es el responsable de recibir la petición y procesarla. Para ello se apoya en el framework para  la publicación del recurso, y para su ejecución.

Se aplican los interceptores definidos: Existen diferentes interceptores que se pueden configurar para que ejecuten diferentes funcionalidades como workflows, validaciones, upload de ficheros, etc.

Se ejecuta el Action: Tras la ejecución de los diferentes interceptores el método específico del Action es ejecutado, realizándose aquellas operaciones y acciones que se hayan definido. El action termina devolviendo un resultado el cúal se utiliza para determiar la página a devolver.

Se renderiza la salida: Tras la ejecución del action se determina cuál es la página que se devuelve y se ejecutan el forward a dicha página.

Se devuelve la petición.: Para realizar la devolución se ejecutan los interceptores que correspondan y se procede a devolver la petición al cliente. De esta forma es posible añadir lógica externa a los servidores
también en la devolución

Se muestra el resultado al cliente final: Finalmente el control es devuelto al cliente quien podrá visualizar el resultado en su navegador.



Responsabilidades del Controlador

Es el responsable de recibir las peticiones de los clientes y es el responsable de:

1. Procesar las peticiones, determinando qué clase es la que tiene que responder.
2. Modificar el modelo en función de los parámetros que recibe ejecutando la lógica de negocio que el desarrollador haya definido. 
3. Redirigir a la vista en función de la lógica de negocio. Como no podía se de otro forma, el controlador permite el uso de tecnologías estándares tales como Java Filters, Java Beans, ResourceBundles, XML, etc.

Responsabilidades del Modelo

Es la parte responsable de la gestión de la información. En este punto se suelen incluir aquellas clases, herramientas, librerías, etc., que permiten el acceso a los datos, así como el modelado de los mismos. Algunas de las tecnologías que se suelen emplear son JDBC, EJB, Hibernate o JPA, entre otros.

Responsabilidades de la Vista

Es la responsable de la percepción que tienen los usuarios finales de la aplicación. Se incluyen las páginas Html, JS, etc, y en general todos los elementos de visualización de la aplicación. Se nutre de la información que el controlador ha captado del modelo para pintar las páginas finales. Algunas de las tecnologías que se emplean son Html, JSP, XSLT, PDF,
templates,etc.


En un nivel mas profundo 

Para aclarar ideas y mostras cómo es la arquitectura de Struts 2 se añade un diagrama en el cual se puede ver de forma gráfica qué elementos son los que intervienen dentro del procesamiento de una peticón HTTP, distinguiéndose cuáles son elementos de estándares de J2EE, cuáles son elementos propios de
Struts 2 y cuáles son creados por el usuario.



1. Una petición llega a un servlet (HttpServletRequest) el cual es la parte del controlador que va a recibir la petición.

2. El servlet delega en el ActionMapper para determinar cúal es la acción que se va a ejecutar.

3. A continuación se ejecuta la “cadena de filtros”, entre los que destacamos:
  • Action Context Clean Up Filter. Éste filtro se emplea cuando hay  que realizar una integración con   otras tecnologías (compartición de cookies,etc.)
  • FilterDispatch. Éste es encargado de determinar si la resolución de la petición requiere la ejecución o no de un action. Hemos de tener en cuenta que existen redirecciones u otros que no necesitan de un action que las implemente. En el caso de que haya que usar un action, se delega en el Action Proxy.

4. Action Proxy: se ejecuta cuando la petición requiere la ejecución de un action. Lo que hace es utilizar el Gestor de Configuraciones para crear  ActionInvocation. Éste es una clase que implementa el patrón
Command, el cuál se ejecuta.

5. Action Invocation: se lanza tras leer el fichero de configuración, y por tanto es conocedor de qué clase se debe ejecutar, así como de los interceptores que intervienen. Por ello es responsable de ejecutar cada
uno de los interceptores, y luego ejecutará el Action correspondiente. Éste Action contendrá la lógica de negocio que se debe ejecutar. Como resultado de la ejecución del Action se obtendrá un Result, el
cual se emplea para determinar cuál de los elementos de la vista se deben llamar.

6. Se ejecuta el elemento que debe configurar la vista y el resultado se devuelve deshaciendo el camino hasta el cliente.

Ahora que ya contamos con una introducción de struts 2  podemos preparar nuestro entorno de trabajo.

como para comenzar deberíamos tener instalador Tomcat 7 y enlazado a eclipse Helio, si no sabes como hacerlo Aquí hay una guia a disposicion

Deberíamos tener instalado Web Tools Platform SDK (WTP SDK) en nuestro Helio para facilitar el desarrollo web, por ello procederemos a realizar la instalación del mismo.

Primero que nada deberemos instalar WPT en nuestro caso realizaremos la instalación en eclipse de la versión 3.2.5 y a continuacion mostraremos el proceso de instalación.

The Eclipse Web Tools Platform (WTP) software repository - 






El proceso de instalación nos solicitara reiniciar eclipse para que los cambios tengan efecto.


Podremos verificar la instalación desde eclipse.



podríamos decir que ahora tenemos el entorno de trabajo preparado para trabajar en desarrollo web, por un lado contamos con el tomcat 7 instalado, configurado y eclipse con lo necesario para trabajar de manera cómoda.

Ahora el siguiente paso es descargar struts 2 desde 


En mi caso opte por la versión full que contiene todo el material del framework


Al descomprimir el archivo podremos ver el contenido del mismo.

En esta primera entrega:
  •  conocimos struts 2, sus virtudes y funcionamiento
  •  Instalamos el servidor de aplicaciones para trabajar 
  • Preparamos Eclipse para trabajar 
  • Descargamos struts 2


jueves, 14 de febrero de 2013

Gestión de Proyecto con RedMine


Redmine, gestor de proyectos de código libre para nuestras empresas
Organizar la información que guardamos en la empresa es uno de los caballos de batalla de la empresa moderna ya que a poco que nos empeñemos podemos sufrir el síndrome de Diógenes digital y acabar por ir añadiendo discos duros y discos duros aumentando la capacidad de almacenamiento de forma indefinida. Al final debemos buscar soluciones y una de las que podemos implantar para organizar mejor tanto la información como el trabajo es Redmine, gestor de proyectos de código libre para nuestras empresas.
Redmine hace uso de Ruby on Rails. Como base de datos soporta tanto MySQL como PosgreSQL o SQLite. La principal ventaja que nos aporta como gestor de proyectos es poder tener toda la información asociada a un proyecto acotada dentro del mismo. Además nos permitirá el control de la ejecución del mismo, todo ello a través de una interfaz web que hace sencilla la gestión de los mismos.

Principales características de Redmine


Creación de un Proyecto con Redmine
Redmine soporta distintos tipos de proyectos. Los usuarios que acceden tienen distintas funciones según el rol asignado, ya sea como usuario, jefe de proyecto, administrador, etc. todo ello en función de un sistema de permisos. Cada proyecto puede llevar asociado si así lo deseamos documentos, archivos o noticias. Además se establece un sistema de notificaciones para los usuarios mediante correo electrónico ya sea porque le han asignado una tarea o porque una parte del proyecto ha cambiado o se ha actualizado.
A cada proyecto le podemos asociar un Wiki que nos permite generar contenidos rápidamente, y editarlos y gestionarlos de forma colaborativa. También tenemos la posibilidad de tener un foro por proyecto, lo que sin duda contribuye en gran medida a reducir el nivel de correos que nos cruzamos entre los participantes en el mismo, lo que sin duda contribuye a mejorar la productividad de cada uno de los miembros del proyecto.
Diagramas Gant
Por último otra característica importante es el control de errores y cambios de versiones. Además tenemos la posibilidad de reflejar el desarrollo del proyecto a través de diagramas de gant, una herramienta muy visual que nos ayudará a controlar los progresos del mismo. Una herramienta ya clásica en todo gestor de proyectos que se precie.

Iniciando el trabajo con Redmine

Lo primero que debemos hacer cuando tenemos instalado Redmine es iniciar el trabajo de backoffice ydar de alta los usuarios, con sus distintos roles y permisos, jefes de proyecto, desarrolladores, etc. aunque también pueden darse de alta ellos mismos a través de la interfaz web, para que después el administrador les apruebe el acceso.
Perfiles en Redmine
El siguiente paso es dar de alta un proyecto y asignarle un jefe. Una vez completada esta fase podemos comenzar a establecer los hitos o etapas del mismo. Si vamos añadiendo las previsiones de tiempo de cada una de las tareas podemos obtener el gráfico de gant de para cada hito. Cada tarea se asignará a un miembro del equipo, que cuando se conecten a la página del proyecto podrán visualizar las que tienen asignadas. A medida que van marcando tareas como terminadas, en el gráfico del hito del proyecto se van rellenando de color verde, de manera que podemos controlar de esta manera de un golpe de vista como va el progreso.
Todo proyecto tiene una fase de ajustes, donde se descubren pequeños fallos que pueden corregirse, de manera que una vez aislados podemos asignarlos a un miembro del proyecto para que ejecute la tarea pertinente. Esta es una cuestión habitual en el mundo del desarrollo de software pero que no está exenta el resto de empresas que es habitual encontrar flecos por cerrar, aun después de haber cobrado y cerrado el proyecto.

Conclusiones

Redmine nos puede ayudar en gran medida a gestionar de manera ágil todos los proyectos de nuestra empresa, la documentación asociada, los archivos que anexamos y todo ello controlando en cada momento la ejecución del mismo. Su administración es sencilla y permite definir flujos de trabajo que evitarán que la gestión nos inunde la bandeja de entrada con un correo por cada pequeño detalle a discutir en el mismo.
Para probarlo tenemos la opción de descargarlo e instalarlo a través de Bitnami, que nos permitirá probarlo de forma fiable en local para después si lo consideramos adecuado llevarlo al servidor de manera que lo ponemos disponible para todos los usuarios de la empresa. Sin duda merece la pena hacer la prueba.

En las próximas semanas voy a generar un tour sobre la herramienta para hablar de los beneficios de su utilización en el blog si bien no es la única herramienta de gestión de proyectos, si es una muy utilizada por desarrolladores.

Explicando Scrum a mi abuela por Jorge Cerrano


Sin duda Jorge Cerrano el creador de esta historia tiene una gran capacidad de transmisión de conocimiento.  por que sinceramente es fantástico esta introducción a scrum. Creo que es una historia para compartir con los amigos que tengo en mi entorno dado que pude leer este articulo hace mucho tiempo y posibilito un entendimiento rápido a la metodología agil.

Explicando Scrum a mi abuela

Introducción 
El otro día me encontraba hablando con un compañero de trabajo a través del teléfono móvil, cuando mi abuela me escuchó nombrar palabras raras en la conversación.
Una de esas palabras era Scrum, y por la forma en la que hablaba fue lo que más atención la llamó, así que cuando colgué, lo primero que me preguntó fue con quién hablaba, de qué hablaba, y que era eso de Scrum.
Imaginaros la cara que se me quedó, porque... ¿cómo explicar Scrum a mi abuela?.
Aunque mi abuela es muy avanzada para la mayoría de la gente de su edad, la verdad es que no es fácil explicarla muchos de los aspectos tecnológicos emergentes, pero bueno, es mi abuela y tenía que intentar explicárselo de forma convincente.
Aquí, os transcribo aquella inverosímil conversación.
La conversación y sus explicaciones
¿De que hablabas?, parecía interesante eso que decías de Scrum. ¿Qué es exactamente?¡Ah sí! Scrum es una metodología.
¿Y para que se utiliza?Se utiliza en mi profesión, en el desarrollo del Software concretamente, aunque hay gente por ahí que la usa o la quiere usar en otras profesiones y áreas.
¿Y para eso del desarrollo del Software tenéis que usar ese tal Scrum?En realidad no. No es estrictamente necesario.
Scrum por sus características no es válido para cualquier proyecto ni para cualquier persona o equipo de personas. Es más, Scrum según muchos especialistas de esta metodología, es óptima para equipos de trabajo de hasta 8 personas, aunque hay empresas que han utilizado Scrum con éxito con equipos más grandes.
Yo diría que para el 90% de los proyectos y empresas, es una metodología válida, pero no es una metodología válida al 100%. Es más, no hay metodología mejor que otra ni válida al 100% para todas las personas y empresas.
Scrum es por lo tanto, una metodología más de las muchas que hay, y ésta en concreto, se basa en la filosofía del desarrollo ágil que fue expuesto por dos japoneses alrededor del año 1986.
Siempre estos japoneses... has dicho desarrollo ágil varias veces... ¿que es eso exactamente?, a mí eso sí que me suena a japonés o a chinoEl desarrollo ágil pone de manifiesto básicamente lo siguiente:
  • El mercado actual es altamente competitivo y la tecnología es muy cambiante. En el desarrollo del Software se pide básicamente rapidez, calidad y reducción de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad.
  • Los ciclos de desarrollo por otro lado, acostumbran a ser largos, y lo que se exige por otra parte, es que esos ciclos sean lo más cortos posibles.
El desarrollo ágil aboga por estas premisas principalmente.
Hay más detalles, pero no los voy a abordar ahora para no marearte con información que nos desvíe la atención de la propia explicación de Scrum.
Empiezo a entender algo más esto...pero... ¿en qué consiste exactamente eso de Scrum?Scrum es como decía antes, una metodología ágil.
Obedece a las necesidades anteriormente citadas, y no responde a ninguna moda, sino a una necesidad realmente demandada en el desarrollo del Software.
Scrum no es ni la mejor metodología ni la única, antes te decía que hay muchas, pero sí, es una metodología que está empujando muy fuerte por la facilidad de implantación y por su agilidad en cuanto a cambios y lo que propiamente aporta en comparación con otras metodologías.
Por un lado, Scrum evita la burocracia y la generación documental. No es que con Scrum no se deba o no se pueda documentar, si no que con Scrum no se exige documentar nada para iniciar un proyecto, algo que en otras metodologías es impensable.
Con Scrum por otro lado, la idea principal es la de ponerse a trabajar prácticamente desde el primer momento y empezar a sacar frutos de ese trabajo para que el cliente vaya viendo los avances y se quede satisfecho con lo que se está haciendo y cómo se está haciendo.
Sí sí, vale... pero ¿cómo muestras al cliente esos progresos en el trabajo?.Bien bien, no te he contado aún mucho sobre Scrum, sólo el cascarón que lo envuelve, pero ya que preguntas y te veo realmente interesada, te voy a contar todo lo que hay con más detalle.
De forma resumida y global, en Scrum vamos a diferenciar dos aspectos importantes, los actores y las acciones.
Vaya, esto se pone interesante, sigue sigue que me está empezando a gustar esto del Scrum.¡Ja!, pues espera a que te cuente, que esto no ha hecho nada más que comenzar.
Te decía que hay dos aspectos fundamentales a diferenciar, los actores y las acciones.
Los actores son los que ejecutarán obviamente las acciones.
Estos de forma general, serán:
  • Product Owner
  • Scrum Master
  • Scrum Team
  • Usuarios o Clientes
Algo que no te he dicho aún, es que para que un proyecto Software tenga éxito, el Usuario o Cliente, debe involucrarse sí o .
Esto vale para todos TODOS los proyectos, aunque no todos los Usuarios y Clientes lo entienden así, pero nuestra misión es también hacérselo ver.
Prosigo.
El Product Owner conoce y marca las prioridades del proyecto o producto.
El Scrum Master es la persona que asegura el seguimiento de la metodología guiando las reuniones y ayudando al equipo ante cualquier problema que pueda aparecer. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas.
El Scrum Team son las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner.
Los Usuarios o Cliente, son los beneficiarios finales del producto, y son quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades.
¿Y lo de las acciones?Te veo con hambre de conocimiento, eso está bien.
Las acciones tienen relación directa con los actores. Sin ellas, todo sería un caos.
En Scrum se indican claramente las acciones a acometer y como acometerlas. Nuestra responsabilidad es hacerlo siempre de una forma adecuada y algo rígida para impedir que se aplique erróneamente esta metodología.
Las acciones de Scrum forman parte de un ciclo iterativo repetitivo, por lo que el mecanismo y forma de trabajar que a continuación se indica, tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en el desarrollo.
Las acciones fundamentales de Scrum son:
  • Product Backlog
  • Sprint Backlog
  • Daily Scrum Meeting
El Product Backlog corresponde con todas las tareas, funcionalidades o requerimientos a realizar. Antes decía que el Product Owner es la persona que se encarga de marcar las prioridades, y es al fin y al cabo, la persona que mantiene y actualiza dado el caso, la lista de tareas.
El Sprint Backlog corresponde con una o más tareas que provienen del Product Backlog. Es decir, del Product Backlog se saca una o más tareas que van a formar parte del Sprint Backlog. Las tareas del Sprint Backlog se deben acometer (recomendado) en unas 2 semanas ó 4 semanas. Hay Sprint Backlogs de 2 semanas y hay Sprint Backlogs de 4 semanas. Eso debe de ser marcado antes de iniciar el Sprint Backlog, de hecho, delProduct Backlog se sacará la tarea o tareas realistas para acometer el Sprint Backlog. Una norma fundamental es que mientras un Sprint Backlogse inicia, éste NO puede ser alterado o modificado. Hay que esperar a que concluya el Sprint Backlog para realizar la correspondiente modificación o alteración cuya tarea, formaría parte de otro Sprint Backlog.
El Daily Scrum Meeting es una tarea iterativa que se realiza todos los días que dure el Sprint Backlog con el equipo de desarrollo o de trabajo. Se trata de una reunión operativa, informal y ágil, de un máximo de 30 minutos, en la que se le hace 3 preguntas a cada integrante del equipo.
  • Qué tareas ha realizado desde la última reunión (que he hecho).
  • Sobre qué va a trabajar en el día actual (que voy a hacer hoy).
  • Identificación de obstáculos o riesgos que impiden o pueden impedir el normal avance (que ayuda necesito). El Scrum Master, debe eliminar aquí cualquier obstáculo que encuentre.
Una pregunta más... has dicho que del Product Backlog se sacan tareas que van al Sprint Backlog, pero entiendo que no todas las tareas del Product Backlog van a la vez al Sprint Backlog, así que... ¿que se hace cuando una tarea del Sprint Backlog se finaliza?
Bien, esta es una pregunta típica.
Quizás no me he explicado bien, pero el Sprint Backlog, una vez que se inicia, ni se toca.
Es decir, que una tarea se acaba, y punto.
Se continúa con otra tarea del Sprint Backlog y así hasta que se acaben.
Lo que debemos tener claro, es que al finalizar un Sprint Backlog (ya sea de 2 semanas ó de 4 semanas), debemos haber acabado las tareas delSprint Backlog.
Reitero que las tareas del Sprint Backlog deben de ser realistas.
Así que cuando se ha finalizado un Sprint Backlog, deberíamos tener algo, un entregable o algo que se pueda mostrar y que enseñe los avances acometidos en el Sprint.
En el Product Backlog tendremos más tareas, y es posible incluso que hayan salido nuevas tareas o que otras hayan desaparecido, por lo que es cuando se acaba el Sprint Backlog, cuando debemos hacer varias cosas importantes y que te indico a continuación.
Esto me está gustando muchísimo...Me alegro, a mí me parece interesantísimo, y es más, Scrum es de sentido común, tanto, que yo sin saberlo ya lo utilizaba hace algunos años sin saber que era realmente Scrum.
Bueno, prosigo con esta explicación.
Como te decía, adicionalmente a las acciones anteriormente comentadas encontramos otras acciones más.
Antes para no saturarte, no te dije que entre el Product Backlog y el Sprint Backlog, hay algo, una reunión concretamente, que se denominaSprint Planning Meeting.
  • El Sprint Planning Meeting es una reunión que tiene por objetivo, planificar el Sprint a partir del Product Backlog. El objetivo de esta reunión es la de mover las tareas del Product Backlog al Sprint Backlog. En esta reunión, suelen participar el Product Owner que es como te dije antes quien prioriza las tareas, el Scrum Master y el Scrum Team.
  • Del Sprint Planning Meeting, sale también el Sprint Goal, que es un pequeño documento o una breve descripción que indica lo que elSprint intetará alcanzar.
  • En el Sprint Review se revisa en unas 2 horas como máximo el Sprint finalizado. Al llegar a este punto, debemos tener "algo" que elCliente o el Usuario pueda ver y tocar. En esta reunión, suelen asistir el Product Owner, el Scrum Master, el Scrum Team y personas que podrían estar involucradas en el proyecto. El Scrum Team es quién muestra los avances realizados en el Sprint.
  • Al finalizar un Sprint Backlog y el Sprint Review, se inicia el Sprint Retrospective. El Product Owner revisará con el equipo los objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarán los cambios y ajustes si son necesarios, y se marcarán los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint.
Mira, te pintaré un diagrama que espero te ayude a entender todas las acciones de Scrum.
¿Y porque es eso de las 2 ó 4 semanas?. ¿No sería más fácil que cada equipo pusiera su franja de tiempo?Sí claro, cada equipo, cada empresa, cada proyecto, puede poner la franja horaria y frecuencia temporal que considere oportuno así como cambiar aspectos de Scrum, pero te voy a poner un sencillo ejemplo con el cuál entenderás que es mejor hacer esto así que de otra forma.
Supongamos el caso de la construcción de un rascacielos o de un edificio.
Si con el fin de controlar el proyecto y que no se te escape nada ni metamos la pata en algo, me preguntas cada día en varias ocasiones como estoy haciendo las cosas, como lo llevo y cuales son mis avances, te aseguro que no terminaremos la construcción del edificio en el tiempo planificado ni de broma. Además, seguro que querrás cambiar o modificar algo cada día o incluso varias veces en el mismo día.
Si me preguntas cada 6 meses por ejemplo, avanzaré mucho sin interrupciones, pero a buen seguro que el riesgo de desviaciones es mucho mayor y seguramente si ocurren, reajustar esas desviaciones al proyecto tendrá costes elevados asociados.
Un término medio es el ajuste temporal de 2 ó 4 semanas que está basado en la experiencia de muchas personas en muchos proyectos. No es lo mismo reconducir el proyecto perdiendo 2 ó 4 semanas, que reconducirlo perdiendo 6 meses por ejemplo.
La idea de la metodología ágil es fundamentalmente que adopte los cambios, que se pueda reconducir el proyecto en un momento dado, y que afecte lo menos posible a los costes, los tiempos y al equipo de trabajo.
No es la metodología ideal. Yo siempre digo que si hubiera algo ideal, todo el mundo lo usaría, pero sí te digo, que Scrum se acerca bastante a esa idea general de la gestión ideal de proyectos.
A mí personalmente es la que más me gusta y la que por experiencia, mayor satisfacción suele dar, tanto al cliente o al usuario final como al equipo de trabajo.

Y no te creas que hay mucho más que saber de Scrum, esta es la filosofía o idea general que espero te haya quedado clara y te haya servido para entender lo que hablaba con mi compañero de trabajo.
Sin duda que me ha parecido muy interesante. Muchas gracias.
Nota: queda prohibida la reproducción parcial o total de este artículo sin la correspondiente autorización.