Trabajo Práctico #8

Para este trabajo práctico les vamos a pedir que tomen los Casos de Uso que definieron para el ejercicio del Call Center y los traduzcan en User Stories, utilizando este template.

• pueden ampliar la base teórica de la siguiente forma:
  • “User Stories” en AgileModeling.com
  • “Scrum and XP from the Trenches” Henrik Kniberg (ingles)(español)

**La fecha límite de entrega es el próximo miércoles 11/11, 18hs.

**la entrega es en formato digital a través de nuestro mail.

Clase Práctica #9

Vamos a ver con un poco más de detalle algunos de los conceptos de la clase pasada.

Integración Continua: es una práctica de desarrollo de software en la que cada miembro del equipo integra su trabajo de manera frecuente (en general por lo menos una vez al día). Esta práctica responde a la necesidad de lograr entregas periódicas e incrementales, permitiendo trabajar de forma más fluida y reduciendo los problemas a la hora de integrar las funcionalidades nuevas con las ya existentes.
Al integrar de forma continua cada cambio que hacemos, reducimos los problemas a la hora de unir nuestra versión del código con la de los demás y logramos detectar los problemas de compatibilidad de manera más rápida. Para esto vamos a necesitar primero contar con un sistema de control de versiones (ver: subversión, git, BitKeeper, perforce, SourceSafe, CVS, etc). También será recomendable lograr automatizar los pasos del ‘Build’, la compilación del código, la ejecución de las pruebas y los pasajes de ambientes (ver: Ant, CruiseControl, Hudson, etc).

Refactoring: Esta es una práctica que plantea reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Solemos convivir con sistemas complejos, difíciles de mantener y modificar. Muchas veces nos preguntamos, como llegamos a tener este sistema? En el video de Ken, posteado en el TP #7, se explica bastante bien esta situación.
Seguimos reutilizando estos sistemas inmantenibles porque de alguna forma funcionan y en general nadie quiere modificar un sistema que está funcionando. Lo importante a tener en claro es que el planteo de refactoring no es meramente una cambio cosmético con fines de seguir un estándar de desarrollo, el planteo pretende lograr mantener la simplicidad a lo largo de la vida del sistema, cuando eliminamos la redundancia, eliminamos funcionalidades no utilizadas y mejoramos los diseños obsoletos; simplificamos la integración de nuevas funcionalidades, ahorramos tiempos y aumenta la calidad del sistema, logramos mantener el diseño simple evitando el desorden y la complejidad innecesaria, la coordinación del equipo y la transferencia de conocimiento mejora.
La principal barrera de refactoring es lograr asegurarse de no introducir errores al aplicar una modificación o mejora, para esto debemos tener un equipo de testing muy grande o un conjunto de pruebas automatizadas asociadas al código que estamos modificando (ver siguiente punto TDD y Unit Test). Si no contamos con formas eficientes de probar la aplicación es probable que no hagamos refactoring, hasta llegar al punto en el que es más fácil reescribir todo el sistema que modificarlo.

TDD y Unit Test: Este es un enfoque evolutivo en el que diseñamos las pruebas y vamos modificando el desarrollo en función de estas. Las pruebas unitarias son uno de los conceptos centrales de XP, lo que se plantea principal mente es que cada porción del código tenga un conjunto de pruebas asociadas y que estas puedan ser ejecutadas de forma automatizada (ver xUnit, jUnit, nUnit).
Esto nos permitirá cierta libertad a la hora de tener que modificar el código, incluso teniendo que modificar una funcionalidad desarrollada por otra persona o equipo (permitiendo la Propiedad del código compartida)
En general cuando nos presionan con los tiempos de entrega, solemos reducir la calidad. Una de las principales áreas impactadas es esta, al tener código con menor porcentaje de testeo, podría implicar software con mayor porcentaje de errores y por ende esto implicará más trabajo en el futuro reparando esos errores.

Scrum: Ken Schwaber plantea que scrum es un framework que define algunas pocas reglas y roles y compara esto con el juego de ajedrez; las reglas de este juego son pocas y bastante simples, sin embargo las estrategias existentes para jugarlo son muy numerosas. Además destaca que las prácticas de XP son compatibles con SCRUM.

Burndown Chart: es una representación gráfica del trabajo por hacer en un proyecto en el tiempo. Usualmente el trabajo remanente (o backlog) se muestra en el eje vertical y el tiempo en el eje horizonal. Es decir, el diagrama representa una serie temporal del trabajo pendiente. Este diagrama es útil para predecir cuándo se completará todo el trabajo. Aquí podremos apreciar la velocidad del equipo y tener una visión clara del status del proyecto y de la estimación de fin.

User Story: Las User Stories describen funcionalidades de un sistema de software que aportan valor al usuario/cliente. Debería incluir los objetivos y motivaciones, a fin de entender porque es necesaria esta funcionalidad. Se diferencia de un caso de uso ya que este es normalmente más grande que una user story. Por ejemplo, cada camino dentro de un caso de uso podría ser una user story. En general las user stories van a estar compuestas de una descripción/nombre, la importancia (definida por el usuario -PO-), la estimación (definida por el equipo de desarrollo), el detalle de las pruebas de aceptación y las notas (que son aclaraciones, por ejemplo: se necesita un diagrama de actividad).

Planning Poker: La idea de esta técnica de estimación es lograr que todos los miembros del equipo den su opinión sin influenciar a los demás. Para esto cada uno cuenta con un grupo de cartas, se presentan los requerimientos a estimar uno por uno haciendo una descripción de los mismos, se procede a discutir aquellos detalles más relevantes o que no hayan quedado claros. Tras este periodo de discusión cada uno de las personas implicadas en el proceso de estimación elije de su mazo de cartas la carta que representa su estimación del trabajo que implica implementar el requisito que se está discutiendo. Las estimaciones son privadas hasta que todo el mundo cuenta con una estimación. En ese momento, todas las estimaciones se hacen públicas. Si la dispersión entre las estimaciones es grande, se vuelve a discutir y cada uno da su opinión sobre porque piensa que esa historia debería durar mas o menos, esto sirve para aclarar las historias. Luego se realiza una segunda ronda esperando que la dispersión sea menor.

Fuente / Articulos relacionados:

“Continuous Integration” Martin Fowler
“Evolutionary Database Design” Martin Fowler
“SCRUM Guide” Ken Schwaber (Mayo 2009)
“Release Burndown Analysis” (video)
“Source code control the way it was meant to be” Linus Torvalds at Google Tech Talks
“A Visual Guide to Version Control”
“What Is a Good Test Case?” Cem Kaner
“Scrum and XP from the Trenches” Henrik Kniberg (version ingles)(version español)
“Kanban vs Scrum” Henrik Kniberg

Trabajo Práctico #7

Para este trabajo práctico vamos a tener una actividad individual, les dejo dos videos interesantes sobre algunos de los temas de la clase pasada. El primero está disponible en el canal de YouTube de la Universidad de New South Wales y el segundo ya lo habíamos mencionado dentro de la bibliografía, es una charla de Ken Schwaber en google. La tarea es bastante simple, tienen que ver los videos y después darnos su feedback, pueden aportar otros artículos/links/videos/bibliografía/experiencias laborales/etc que consideren interesantes.

Curso: Higher Computing – Richard Buckland – Lecture 24: eXtreme Programming

Google Tech Talks September 5, 2006 Ken Schwaber co-developed the Agile process, Scrum.

Clase Práctica #8

La idea de esta clase es hablar sobre metodologías ágiles, ya mencionamos varias veces algunos conceptos pero nunca con demasiada profundidad. Comenzaremos en la página agilemanifesto.org, aquí vamos a encontrar la historia del surgimiento del concepto “ágil” dentro del desarrollo del software.
En 2001 bajo el manifiesto ágil se definieron una serie de valores y principios que deberían cumplir todas las metodologías ágiles aplicadas en el Software. Estos principalmente surgen de la idea de aligerar a los proyectos de software de burocracia, dando más importancia y responsabilidad a las piezas claves de un proyecto, que son el cliente y los programadores. Intentando evitar que ocurran problemas muy comunes con las metodologías pesadas, donde al acabar un proyecto tenemos más documentación que lineas de código.

Valores:

El individuo y sus interacciones frente los procesos y las herramientas
Software que funciona frente a buena documentación
Colaboración con el cliente frente la negociación de los contratos
Respuesta a los cambios frente al seguimiento de los planes

Principios:

1. Realizar entregas cortas en el tiempo y continuas.
2. Dar la bienvenida a los cambios.
3. Entregas periódicas y frecuentes que funcionen.
4. Los clientes forman parte del equipo de desarrollo.
5. Equipo con individuos motivados. Darles para ello el ambiente, apoyo y confianza.
6. La comunicación directa es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Intenta evitar el teléfono, correos electrónicos, fax, etc.
7. la medida principal de progreso es el software que funciona.
8. Desarrollo sostenible. Es indispensable que exista paz y armonia en el equipo para que el proyecto tenga éxito.
9. Buen diseño y calidad técnica.
10. La simplicidad es algo básico.
11. Equipos autorganizados.
12. El equipo debe realizar reflexiones periodicamente para planterase cómo llegar a ser más efectivo.

Entonces aquellas metodologías consideradas ágiles adhieren o se basan en estos valores y principios. Si investigamos un poco, vamos a encontrar que la lista de metodologías ágiles es bastante extensa, nos vamos centrar en eXtreme Programming y SCRUM, que son quizás las dos más populares o adoptadas hoy en día.

• eXtreme Programming

La programación extrema o eXtreme Programming (XP) es un enfoque de ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es una de los más destacados procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural e inevitable. Ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Principios:

Simplicidad, Comunicación (diaria y cara a cara), Feedback, Respeto, Coraje (para decir la verdad sobre el estado de avance del proyecto).

Prácticas:

Test Driven Development: Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.

Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.

Refactorización del código: reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ninguna falla.

Diseño simple: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.

Integración Continua: integración de los cambios varias veces por día.

Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.

Integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.

• SCRUM

Scrum es un Framework para la gestión de proyectos, expuesta por Hirotaka Takeuchi e Ikujiro Nonaka, en el artículo The New New Product Development Game[Harvard Business Review Ene-Feb 1986] en el que ponen de manifiesto que:
El mercado competitivo de los productos tecnológicos, además de los conceptos básicos de calidad, coste y diferenciación, exige también rapidez y flexibilidad.
Los nuevos productos representan cada vez un porcentaje más importante en el volumen de negocio de las empresas.
El mercado exige ciclos de desarrollo más cortos.

El artículo compara al desarrollo tradicional de ciclo de vida formado por fases separadas y equipos especializados con las carreras de relevos, donde un equipo pasa el testigo al siguiente hasta finalizar el desarrollo del producto. Siguiendo el símil deportivo, se compara al nuevo modelo de desarrollo, basado en el solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del juego del rugby; y de él se toma el término scrum.
Nonaka y Takeuchi extraen las bases de scrum de las prácticas que observan en las empresas con buenos resultados de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson, Brother, 3M o Hewlett-Packard; y son:

Inestabilidad consustancial al entorno de desarrollo.
Equipos auto-organizados.
Solapamiento de las fases del desarrollo.
Multi-aprendizaje.
Control sutil.
Transferencia de aprendizaje a nivel organizacional.

Scrum aplicado al desarrollo de software
Aunque surgió como modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil.

Roles: Product Owner, Scrum Master, Equipo.
Componentes del proceso: Product Backlog, Sprint Backlog, Producto Incremental.
Reuniones: Planificación del sprint, Revisión diaria, Revisión del sprint.

“The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as «hackers» are ignorant of both the methodologies and the original definition of the term hacker.” Jim Highsmith, for the Agile Alliance