Gestione el equipo ágil con XPlanner

Alcance, diseñe, construya, pruebe, entregue, disculpe. Estos son los pasos más transitados de una metodología de ingeniería tradicional cuando se aplica al mundo voluble de los proyectos de software. Como desarrollador de software, probablemente esté familiarizado con ese requisito del sistema "final" que parece agacharse y tejer como un luchador. Quizás haya trabajado duro en un proyecto de desarrollo solo para emerger meses (o años) más tarde y enfrentarse a un cliente que parece profundamente decepcionado porque sus necesidades reales no se han satisfecho. Quizás sus compañeros están en el punto en que un plan de desarrollo meticuloso a largo plazo que se les presenta les infunde una sensación de fatalidad inminente. En pocas palabras, su equipo está listo para comenzar con el desarrollo ágil, pero ¿su herramienta de administración de equipos tradicional se ha programado para la administración de equipos tradicional?

Las metodologías ágiles pueden ser ligeras, pero son muy disciplinadas. Cualquier herramienta que lo ayude a planificar y realizar un seguimiento de las entregas rápidas con la colaboración íntima del cliente puede ser una valiosa adición a su arsenal. La buena noticia es que ahora hay varias herramientas de este tipo disponibles para el equipo ágil. Este artículo detalla una experiencia del mundo real en la gestión de un equipo de desarrollo ágil utilizando una de esta nueva generación de herramientas, el XPlanner de código abierto.

XPlanner es una aplicación Web Java diseñada para soportar la gestión de equipos según la metodología de programación extrema (XP). Sin embargo, hemos descubierto que esta herramienta es lo suficientemente flexible como para proporcionar un apoyo valioso para otros enfoques ágiles convencionales (por ejemplo, Scrum) en el fragor de la entrega del proyecto. Aunque poco sofisticado, XPlanner proporciona una herramienta útil para apoyar a su equipo, ya sea que tenga experiencia o simplemente se esté iniciando en el gratificante mundo del desarrollo ágil de software.

Herramientas de gestión de equipos tradicionales frente a ágiles

Las herramientas tradicionales de administración de equipos (como Microsoft's Project) se basan en estructuras de desglose del trabajo que miran hacia el futuro de un proyecto. La asignación planificada de recursos y una atención cuidadosa a la variación de la línea de base se utilizan para administrar la "ruta crítica" hacia la entrega final. La aplicación de tales herramientas implica importantes esfuerzos de planificación inicial, dependencias rígidas de tareas y una base estable de requisitos. Es probable que los cambios significativos en el alcance o los requisitos requieran revisiones significativas del modelo. Por lo tanto, estas herramientas tradicionales son más apropiadas al planificar un viaje de A a B, asumiendo poca variación en el curso. Por el contrario, los proyectos ágiles están orientados a esperar cambios, sin asumir que B sea ni siquiera el destino final.

Para comprender la cultura del proyecto ágil, es útil considerar los principios del desarrollo ágil propugnados por los autores del Manifiesto Ágil:

  • "Individuos e interacciones sobre procesos y herramientas
  • Software de trabajo sobre documentación completa
  • Colaboración con el cliente sobre la negociación de contratos
  • Responde al cambio sobre el siguiente plan"

    (Kent Beck et al., 2001)

Por lo tanto, los proyectos ágiles abandonan explícitamente la planificación a largo plazo en favor de la participación íntima de las partes interesadas, un enfoque claro en características de alto valor y el lanzamiento de software utilizable temprano y con frecuencia. El objetivo subyacente es ofrecer valor de forma sencilla y eficaz frente al cambio constante. Para que una herramienta de planificación y seguimiento sea valiosa en este contexto, debe ser congruente con estos valores.

Planificación y seguimiento de proyectos con XPlanner

XPlanner es una herramienta de software de gestión de proyectos ágil disponible bajo la GNU Lesser General Public License (lo que la hace "gratuita, como en cerveza", en la jerga de código abierto). El paquete se implementa como una aplicación web, lo que permite que los miembros de su equipo y las partes interesadas del proyecto se unan utilizando sus navegadores web favoritos. Una vez configurado, podrá planificar y realizar un seguimiento de varios aspectos de la entrega de su proyecto ágil a través de una sencilla interfaz web.

Fundamentalmente, desde la perspectiva ágil, los participantes del proyecto pueden colaborar directamente aportando su información al repositorio común del proyecto. Esta colaboración puede involucrar a los clientes que describen los requisitos del proyecto en forma de historias de usuario, que los desarrolladores luego utilizan para detallar y realizar un seguimiento de las tareas necesarias para hacer realidad estas historias.

Además de respaldar este nivel de colaboración con el cliente, XPlanner proporciona otras funciones útiles que respaldan el enfoque ágil. Estos incluyen características tales como un mecanismo simple para definir iteraciones del proyecto; una interfaz intuitiva para las personas que estiman y controlan el esfuerzo; y gráficos para publicar métricas del equipo. XPlanner se analiza aquí ya que se implementó para respaldar la entrega de un sistema de flujo de trabajo y comercio electrónico que consta de varios grupos de partes interesadas y un equipo de siete desarrolladores.

Descarga e instalación

XPlanner es una aplicación Java pura que se puede implementar en cualquier entorno de desarrollo J2SE 1.4 equipado con Apache Ant y un motor de servlet adecuado. Elegimos Apache Tomcat como motor de servlets; sin embargo, cualquier motor compatible con Servlet 2.3 (o una versión más reciente) debería servir. XPlanner se envía como un archivo (zip o tar.gz) que debe descomprimir y compilar antes de implementar y usar la herramienta.

Se trata de un paso de configuración obligatorio, ya que debe configurar su base de datos favorita para utilizarla como depósito de información del proyecto. Como XPlanner usa la capa de persistencia relacional / de objetos de Hibernate para la interacción con la base de datos, tiene la opción de usar cualquier base de datos compatible con Hibernate para el repositorio de su proyecto. La opción incluida es la base de datos Java ligera Hypersonic (ahora llamada HSQLDB); sin embargo, usamos Oracle 9i como nuestra base de datos de repositorio. Para configurar esta base de datos, tuvimos que editar el archivo xplanner.propertiesdescomentando las propiedades de Oracle ya definidas. También necesitábamos modificar el build.xmlarchivo para incorporar el controlador de base de datos delgada de Oracle. Una vez configurado, puede crear su implementación XPlanner. Esto implica ejecutar Ant para producir un archivo web desplegable (WAR) de la siguiente manera:

ant install.db.schema ant build.war 

Implemente el archivo de almacenamiento web resultante ( xplanner.war) en el motor de servlet de su elección y luego busque URL // su-servidor: su-puerto / xplanner / (usando el usuario predeterminado "sysadmin" y la contraseña "admin") para inspeccionar los resultados.

Integrarse con su ecosistema

La mayoría de los entornos de desarrollo ya contienen un sistema de seguimiento de errores, foros de colaboración, sistemas de seguridad, repositorios de estándares, etc. Aunque es útil como herramienta independiente, el valor de XPlanner se puede mejorar mediante sus funciones de integración simples y potentes. XPlanner incluye, por ejemplo, la capacidad de admitir la representación del lenguaje del desarrollador en un campo de descripción, como bug: 1001 como un enlace a //mybugzilla/show_bug.cgi?uid=1001. Esto se puede hacer simplemente agregando twiki.scheme.bug=//mybugzilla/show_bug.cgi?id=al xplanner.propertiesarchivo. Esta misma técnica se puede utilizar para otras herramientas basadas en web como viewcvs (xplanner.propertiesmuestra algunos otros ejemplos). XPlanner también cuenta con un formateador wiki avanzado (que no se usa en nuestro proyecto) que permite la vinculación automática a las entradas wiki. Puede encontrar más información sobre las extensiones XPlanner en Recursos.

En la mayoría de las organizaciones, invariablemente, alguna forma de servidor de directorio compatible con LDAP (protocolo ligero de acceso a directorios) proporciona un depósito centralizado de cuentas de seguridad de usuario. Por ejemplo, dentro de la organización que patrocina nuestro proyecto, un servidor LDAP anticuado pero funcional cumplió este propósito (Active Directory de Microsoft también es compatible en gran medida con el protocolo LDAP). Fue refrescante descubrir que XPlanner es sencillo y XPlannerLoginModulefácil de integrar con LDAP. Esto implicó la actualización de la xplanner.propertiessiguiente manera:

-> Comment out default security #xplanner.security.login.module=com.technoetic.xplanner.security.XPlannerLoginModule

-> Uncomment and edit the LDAP entries from... xplanner.security.login.module=com.technoetic.xplanner.security.jndi.JNDILoginModule

-> ...to: xplanner.security.login.option.roleSearch=(uniqueMember={0})

-> Add user search entries xplanner.security.login.option.userBase=ou=people,o=person

-> And blank out values for xplanner.security.login.option.userPattern= xplanner.security.login.option.userPassword=

Con una reconstrucción e implementación rápidas, la seguridad de autenticación de XPlanner se integró por completo. El único inconveniente era que los nombres de usuario aún debían agregarse explícitamente a XPlanner, pero al menos las contraseñas y los problemas de pertenencia a grupos se convirtieron en un problema del servicio de asistencia corporativa.

Equipo, conoce XPlanner

XPlanner visualiza un proyecto según las iteraciones, las historias de usuario y las tareas. Según lo prescrito por el paradigma Agile, cualquier proyecto gestionado por XPlanner se planifica y se realiza un seguimiento de acuerdo con una serie sucesiva de iteraciones. Cada iteración consta de una fecha de inicio, una fecha de finalización y una colección de historias de usuarios que se diseñarán desde la historia hasta la realidad dentro de ese período de tiempo.

Una historia de usuario es la principal herramienta conceptual utilizada en el desarrollo ágil para comunicar las necesidades del cliente a los desarrolladores de software. Una vez que se asigna una historia de usuario a una iteración actual (como parte de la planificación del lanzamiento a través de XPlanner), el desarrollador busca más detalles para cada historia colaborando con el usuario (con suerte, cara a cara). El resultado de este paso es una serie detallada de tareas de desarrollo, cada una de las cuales el desarrollador registra en XPlanner contra la historia de usuario relevante.

Elegimos nuestro proyecto de flujo de trabajo de comercio electrónico para que se ejecutara con iteraciones mensuales, cada una de las cuales consta de alrededor de 10 historias, con entre 10 y 15 tareas asignadas a cada historia.

Cosechando historias de usuarios

Cada historia de usuario para la iteración de un proyecto debe ser una descripción breve y centrada en los resultados de la experiencia del usuario contada en primera persona (por ejemplo, "luego busco según el color ..."). Esta experiencia está escrita por un usuario que está visualizando el producto futuro ideal en acción, por lo que podría pensar en una historia de usuario como una visualización positiva para el software. El objetivo de cada visualización es proporcionar suficiente información para que un desarrollador de software calcule el esfuerzo necesario para hacer realidad esa historia.

XPlanner cataloga la colección de historias de usuarios de su proyecto, mientras registra un cliente, rastreador, prioridad y estimación de esfuerzo para cada uno. La principal dificultad que encontramos a menudo es la recolección de historias de usuarios de alta calidad de las mentes de los usuarios del sistema. Este fue ciertamente el caso de nuestro proyecto, ya que fue un cambio de paradigma significativo de los rígidos requisitos de sección / subsección a los que los usuarios estaban acostumbrados. Sin embargo, la capacidad de usar XPlanner para administrar historias de manera que las partes interesadas pudieran verlas y actualizarlas fácilmente, y poder intercambiarlas rápidamente dentro y fuera de una iteración determinada, ciertamente ayudó. Una característica agradable, si no funcional, de XPlanner es la sensación auténtica que le da a una historia de usuario, mostrando cada una en la pantalla como una tarjeta de índice similar de 3 por 5, como se muestra en la Figura 1.

Estimar y registrar el esfuerzo

El desarrollo ágil prescribe que los desarrolladores emprendan su propio establecimiento de objetivos, lo que implica analizar una historia de usuario y definir las tareas técnicas necesarias para realizar esa historia. Un desarrollador debe tener la libertad de agregar tareas adicionales o modificar las tareas existentes a medida que estén disponibles más detalles de la historia. XPlanner admite esta flexibilidad al proporcionar a los desarrolladores acceso completo para definir y editar una tarea. A cada tarea se le puede asignar un tipo, como deuda, característica o defecto, para caracterizar el tipo de trabajo que se está realizando (la deuda, por ejemplo, es una tarea para limpiar el "cruft" técnico que quedó en el sistema de una iteración anterior). Las tareas también se especifican con una disposición (planificada o no planificada), el desarrollador aceptante, una descripción del trabajo y una estimación del número de horas ideales necesarias para conquistar esa tarea.

XPlanner hace que sea fácil para un desarrollador registrar cuánto trabajo se ha invertido en una tarea determinada o actualizar la estimación de esfuerzo original (el original aún se almacena). Tenga en cuenta que las estimaciones de esfuerzo, como se mencionó, deben especificarse en horas ideales . Una hora ideal es una hora en la que el desarrollador no experimenta absolutamente ninguna interrupción.

Los desarrolladores también deben registrar la cantidad de horas ideales que invierten en una tarea determinada. Si anima a sus desarrolladores a registrar honestamente las horas ideales (al no exigir saber a dónde va el tiempo), podrá extraer algunas métricas útiles de XPlanner (que se analizan a continuación). Encontramos, por ejemplo, que, en nuestro proyecto, una hora ideal tomó alrededor de 1.4 horas transcurridas para lograr. Esta información se puede utilizar para proporcionar una estimación refinada para iteraciones posteriores, lo que ayuda a mantener las promesas del equipo y las expectativas del cliente en el mismo estadio.

Métricas y planificación para la próxima iteración

Estás en la mitad de una iteración y el jefe quiere saber "cómo nos vemos". Una respuesta bastante gastada a esta pregunta es "Estamos cerca del 80 por ciento del camino". Por supuesto, ese último 20 por ciento siempre parece tardar mucho más de lo que debería; el último 20 por ciento es el equivalente en software de las verduras aburridas en la cena que dejaba para el final.