Herramientas Ágiles para Desarrollo

Herramientas Ágiles

2do. Agile Open - 7 de Setiembre de 2012
Alejandro Gallegos | alejandro.gallegos@lemondata.com.ar

Objetivos

Porqué utilizar herramientas ágiles
Cómo se relacionan con la metodología
Consideraciones para implementarlas
Ventajas y desventajas

www.lemondata.com.ar

Prácticas del desarrollo ágil

Revisiones continuas
Refactoring
Diseño simple
Pruebas de integración continuas
Estándares de codificación
Propiedad colectiva
Retroalimentación del cliente
Pequeños releases


Nuestra primera herramienta

¿Cuál es nuestra primera Herramienta?

EL IDE o Entorno de desarrollo


Desarrollo

Nuestro trabajo se centra en el código fuente y por ende
en el entorno de desarrollo.

Elección de un IDE adecuado al proyecto :
Posibilidad de navegación rápida
Generación automática de código
Realizar Refactoring fácilmente
Mantener los estándares de programación
Automatizar tareas: análisis estático de código,
formateo de código, compilación automática, versionado
de código, etc.


Trabajo en equipo Ágil

¿Cómo hago para compartir con el equipo el código
fuente?
¿Cómo mantengo un historial de cambios sobre el código?


Versionado de código

Una versión, revisión o edición de un producto, es el
estado en el que se encuentra dicho producto en un
momento dado de su desarrollo o modificación.

Características:
Mecanismo de almacenamiento
Posibilidad de realizar cambios a lo almacenado
Registro histórico de cambios realizados
Posibilidad de volver a versiones anteriores
Generación de informes con cambios entre versiones


Versionado de código: clasificación
Centralizados:
Repositorio centralizado con todo el código
Único usuario responsable (o conjunto de ellos)
Administración vs Flexibilidad
Ejemplos: CVS y Subversion.

Distribuidos:
Cada usuario tiene su propio repositorio
Los distintos repositorios pueden intercambiar y
mezclar revisiones entre ellos
Es frecuente el uso de un repositorio, que está
normalmente disponible
Ejemplos: Git y Mercurial.

Versionado de código: opciones

CVS SVN GIT MERCURIAL
Cada archivo tiene Todo el repositorio Desarrollo no Desarrollo
su número de tiene un único lineal. Rapidez en completamente
revisión número la gestión de distribuido.
independiente de versión que ramas y mezclado
identifica un de diferentes
estado versiones.
común de todos
los
archivos.


Pruebas
¿Cómo mejoramos el nivel de las pruebas?
¿Cómo evitamos realizar pruebas manuales?
¿Cómo reutilizar las pruebas anteriores?
¿Cómo minimizar o acotar los posibles errores en el
software?


Control de calidad: Pruebas

Necesidad de mantener pruebas unitarias e integradoras
Fomentan el cambio
Simplifican la integración
Documentan el código
Errores acotados y mas fáciles de localizar
La herramienta debería permitir tener pruebas:
Automatizables
Completas
Repetibles
Independientes
Profesionales


JUnit

Es un conjunto de clases (framework) que permite realizar
la ejecución de clases Java de manera controlada, para
poder evaluar si el funcionamiento de cada uno de los
métodos de la clase se comporta como se espera.

Es también un medio de controlar las pruebas de
regresión, necesarias cuando una parte del código ha sido
modificado y se desea ver que el nuevo código cumple con
los requerimientos anteriores.

Este framework se encuentra actualmente en la versión
4.6, con grandes mejoras.

JUnit: como funciona

 En función de algún valor de entrada se evalúa el valor
de retorno esperado.

 Si la clase cumple con la especificación, entonces JUnit
devolverá que el método de la clase pasó exitosamente la
prueba.

 En caso de que el valor esperado sea diferente al que
regresó el método durante la ejecución, JUnit devolverá un
fallo en el método correspondiente.


JUnit: como funciona


Buenas prácticas de codificación
¿Cómo fomento en el equipo las buenas prácticas de
programación?

¿Cómo hago mi código más entendible?

¿Cómo prever posible problemas de rendimiento,
seguridad y complejidad?


Control de calidad: análisis estático

El análisis estático del código es el proceso de evaluar el
software sin ejecutarlo.
La verificación de código estática se basa en un conjunto
de reglas que representan buenas practicas a la hora de
codificar.
La idea es obtener información del código que nos
permita mejorarlo, manteniendo la semántica original.


PMD

Analizador de código estático
Se basa en un conjunto de reglas configurables
Busca errores potenciales:
Posibles errores: sentencias try/catch/finally/switch vacías
Código muerto: variables, parámetros y métodos no usados
Expresiones complejas: if innecesarios, bucles for que pueden
ser while
Código no óptimo
Código duplicado


Entrega de releases

¿Cómo tengo seguridad para hacer cambios?

¿Cómo disminuir el tiempo de integración?

¿Cómo hago versiones estables y entregables fácilmente?


Integración continua

El sistema se compila varias veces por día de forma
automática.
Se obtiene el código fuente desde el repositorio con los
últimos cambios.
Se corren las pruebas unitarias en cada build.
Fomenta :
pruebas de integración continuas
propiedad colectiva del código
pequeños releases con entrega frecuente de valor
Anticipa futuros conflictos.


Integración continua: Hudson


Administración Ágil

¿Cómo puedo administrar el Product Backlog
eficazmente?
¿Cómo automatizar las métricas y visualizar el avance del
proyecto?
¿Qué velocidad en la entrega de valor tiene el equipo?
¿Cómo reduzco los tiempos administrativos del proyecto?


Administración de proyectos ágiles

Factores que ameritan herramientas colaborativas:
Equipos distribuidos geográficamente
Necesidad de mantener históricos de las iteraciones
Mayor control con respecto a tiempos de trabajo
Necesidad de reducir tiempos de administración del proyecto
Métricas automáticas


Kunagi

Herramienta web para administración de proyectos ágiles
Administración y colaboración basada en Scrum
Buenas prácticas ágiles
Información Scrum
Product Backlog, Sprint Backlog, Impediments list.
Datos adicionales del proyecto
Requerimientos no funcionales
Riesgos
Archivos
Issues y bugs
Otras características
Dashboard, Whiteboard y Planning Poker


Kunagi


Sprint y Herramientas
Sprint Planning/ Sprint Review/ Retrospectiva: Kunagi

Diariamente:
Eclipse para el desarrollo
JUnit para realizar las pruebas
PMD para comprobar su código
SVN para compartir su código
Hudson para comprobar la integración de los cambios
Kunagi para tareas, cargar impedimentos, etc.

Al final del Sprint: Kunagi y Hudson: tests fallidos,
warnings PMD, demo al cliente.

Otras herramientas

Java .Net Php Phyton
IDE Eclipse, Visual Studio, Eclipse, Vim, Emacs,
Netbeans, Sharp Develop ZendStudio, Open Gedit, Kate,
Jdeveloper, BlueJ Komodo, PDT, PyDev, Open
Aptana Komodo, Eric
Versionado SVN/CVS/GIT/Mercurial
Pruebas Junit, TestNG NUnit PHPUnit PyUnit
Análisis PMD, FxCop, Code PHP Analyzer, RIPS Emacs flymake,
Estático Checkstyles, Analysis, Pyflakes, PyLint
Findbugs StyleCop
Integración Hudson, Jenkins CruiseControl. Xinc, Jenkins, Hudson.
Continua Net phpUnderControl Jenkins
Gestión Kunagi, Xplanner, DotProject, Jira, GreenHopper, Mantis, Bugzilla,
TargetProcess, WebCollab, Rally, Version One, Agile Zen, Scrumwise


Consideraciones

El equilibrio es fundamental. Las herramientas tienen que
ser un medio para el desarrollo correcto del proyecto.
Cuestiones que van mas allá de las herramientas:
Relación con el cliente
Costos de implementación
Curva de aprendizaje
Restricciones tecnológicas
Re-trabajo para el equipo

“El OBJETIVO de las herramientas es
la entrega de VALOR al cliente al
final del Sprint”


¿Preguntas? ¿Debate?

¿Comentarios?

Herramientas Ágiles para Desarrollo

Más contenido relacionado

La actualidad más candente (17)

Similar a Herramientas Ágiles para Desarrollo (20)

Herramientas Ágiles para Desarrollo