http://www.dicampus.es
Técnico Web 2.0

Técnicas de
http://www.dicampus.es
desarrollo eficaces en
la Web 2.0

Desarrollo eficaz, eficiente y ágil
http://www.dicampus.es
 Desarrollo eficaz
‣ Consigue los objetivos con los que fue concebido
un proyecto software

Desarrollo eficaz, eficiente y ágil
http://www.dicampus.es
 Desarrollo eficaz
‣ Consigue los objetivos con los que fue concebido
un proyecto software
Satisface a los clientes

Desarrollo eficaz, eficiente y ágil
http://www.dicampus.es
 Desarrollo eficiente
‣ Optimiza el tiempo y los recursos humanos y
materiales necesarios para la consecución del
proyecto

Desarrollo eficaz, eficiente y ágil
http://www.dicampus.es
 Desarrollo eficiente
‣ Optimiza el tiempo y los recursos humanos y
materiales necesarios para la consecución del
proyecto
Incrementa los beneficios

Desarrollo eficaz, eficiente y ágil
 Desarrollo ágil
‣ Reúne un conjunto de buenas prácticas que
http://www.dicampus.es
persiguen:
✓ La entrega de software de alta calidad
✓ La alineación entre los objetivos de la
organización y los de nuestros clientes

Desarrollo eficaz, eficiente y ágil
 Desarrollo ágil
‣ Reúne un conjunto de buenas prácticas que
http://www.dicampus.es
persiguen:
✓ La entrega de software de alta calidad
✓ La alineación entre los objetivos de la
organización y los de nuestros clientes
Contribuye a que el desarrollo sea eficaz y eficiente

En resumen...
Desarrollo ágil
http://www.dicampus.es
Desarrollo
Desarrollo eficaz
eficiente
Incremento de
Satisfacción del
los beneficios
cliente

Buenas prácticas para
http://www.dicampus.es
el desarrollo de
software. Métodos y
técnicas ágiles

¿De qué vamos a hablar?
http://www.dicampus.es
 Desarrollo ágil
 Metodologías ágiles de desarrollo de software.
 Buenas prácticas
 Herramientas
 Gestión ágil de proyectos

Principios básicos del desarrollo ágil
 El Manifiesto Ágil:
http://www.dicampus.es
 Escrito en Febrero de 2001
 Surge como crítica y respuesta a las
metodologías existentes, basadas en procesos,
más formales, y pesadas.
 Recoge los valores en los que se basa el
desarrollo ágil, y los principios que se derivan de
éstos valores.
http://agilemanifesto.org

Principios básicos del desarrollo ágil
 El Manifiesto expone (Valores):
“Estamos poniendo al descubierto mejores métodos para desarrollar
software, haciéndolo y ayudando a otros a que lo hagan. Con este
http://www.dicampus.es
trabajo hemos llegado a valorar:
A los individuos y su interacción, por encima de los procesos
y las herramientas.
El software que funciona, por encima de la documentación
exhaustiva.
La colaboración con el cliente, por encima de la negociación
contractual.
La respuesta al cambio, por encima del seguimiento de un
plan.
Aunque hay valor en los elementos de la derecha, valoramos más los
de la izquierda.”

Principios básicos del desarrollo ágil
 De los valores se derivan doce principios seguidos por
los creadores del manifiesto. Algunos son:
http://www.dicampus.es
o Nuestra principal prioridad es satisfacer al cliente a través de
la entrega temprana y continua de software de valor.
o Son bienvenidos los requisitos cambiantes, incluso si llegan
tarde al desarrollo. Los procesos ágiles se doblegan al
cambio como ventaja competitiva para el cliente.
o Las personas del negocio y los desarrolladores deben
trabajar juntos de forma cotidiana a través del proyecto.
o La forma más eficiente y efectiva de comunicar información de
ida y vuelta dentro de un equipo de desarrollo es mediante la
conversación cara a cara.

Tarea: 3’
 Echemos un vistazo a los principios recogidos en el
http://www.dicampus.es
manifiesto. Comprenderlos nos ayudarán a responder
una serie de preguntas.
o Artículo original en inglés: http://agilemanifesto.org/principles.html
o Traducción al castellano en wikipedia: http://tinyurl.com/
dhkdb8

http://www.dicampus.es
Pregunta

Pregunta
¿Porqué es adecuado el modelo
de desarrollo ágil para la web 2.0?
http://www.dicampus.es

Pregunta
¿Porqué es adecuado el modelo
de desarrollo ágil para la web 2.0?
http://www.dicampus.es
 El negocio en la web es un entorno que se
mueve rápidamente

Pregunta
¿Porqué es adecuado el modelo
de desarrollo ágil para la web 2.0?
http://www.dicampus.es
 El negocio en la web es un entorno que se
mueve rápidamente
 Es necesario acomodar cambios aún
estando en fases adelantadas del desarrollo

Pregunta
¿Porqué es adecuado el modelo
de desarrollo ágil para la web 2.0?
http://www.dicampus.es
 El negocio en la web es un entorno que se
mueve rápidamente
 Es necesario acomodar cambios aún
estando en fases adelantadas del desarrollo
 No hay tiempo que perder, la velocidad en la
entrega es una ventaja competitiva

http://www.dicampus.es
Pregunta

Pregunta
¿Y porqué NO son adecuados los
métodos tradicionales?
http://www.dicampus.es

Pregunta
¿Y porqué NO son adecuados los
métodos tradicionales?
http://www.dicampus.es
 Métodos tradicionales se basan en el
seguimiento de un plan ➔ Dificultad para
acomodar cambios.

Pregunta
¿Y porqué NO son adecuados los
métodos tradicionales?
http://www.dicampus.es
 Métodos tradicionales se basan en el
seguimiento de un plan ➔ Dificultad para
acomodar cambios.
 El seguimiento del plan exige mantener un
nivel de burocracia alto (mucha
documentación) ➔ Lentitud en el desarrollo

Coste del cambio en procesos en cascada
http://www.dicampus.es

Coste del cambio siguiendo métodos ágiles
http://www.dicampus.es

No silver bullet
 El desarrollo ágil no vale para todos los casos
 No es adecuado para cierto tipo de proyectos
http://www.dicampus.es
 Más de 20 desarrolladores
 Equipos distribuidos
 Equipos poco experimentados
 Proyectos críticos, (software de tiempo real, etc.)
F.P. Brooks, “No silver bullet: Essence and accidents of
software engineering,” IEEE computer, vol. 20, 1987, págs.
10-19.

Recapitulando hasta aquí.
 Los métodos ágiles son adecuados para proyectos
que
http://www.dicampus.es
o Cuenten con un equipo de desarrollo que
• Sea experimentado
• Pueda comunicarse de forma fluida
• No sea demasiado numeroso
o Pertenezcan a dominios muy dinámicos (como el negocio
web!)
 Pero no para proyectos que
o Cuenten con un equipo poco experimentado (junior) o con
poca capacidad de comunicación y autogestión
o Tengan requisitos especiales de planificación, gestión, o
control.

Panorámica actual del desarrollo de SW
http://www.dicampus.es

Panorámica actual del desarrollo de SW
http://www.dicampus.es

Metodologías de desarrollo
http://www.dicampus.es
 Conjunto de procedimientos y técnicas para el desarrollo de
productos software.
 Los procedimientos y técnicas no surgen por casualidad
o Han demostrado ser efectivos
o Buenas prácticas

Metodologías ágiles - Similitudes
 Basadas en el desarrollo incremental e iterativo del
producto software
http://www.dicampus.es
 Cada iteración :
o Genera una pequeña release del producto
o Comprende todas las fases del desarrollo
• Análisis
• Diseño
• Codificación
• Prueba
• Implantación
o Suele tener una duración determinada, según la metodología.

Metodologías ágiles - Ciclo de vida
http://www.dicampus.es

Metodologías ágiles - Ciclo de vida
http://www.dicampus.es

Metodologías ágiles - Ciclo de vida
http://www.dicampus.es

Metodologías ágiles - Ciclo de vida
http://www.dicampus.es

Metodologías ágiles - Ciclo de vida
http://www.dicampus.es

Metodologías ágiles - Diferencias
 Cada una enfatiza más una dimensión del desarrollo
o XP - La técnica
http://www.dicampus.es
o Scrum, Lean - La de gestión
 Cada una propone un conjunto de actividades diferentes
 Cada una define sus propios artefactos. Ej: Metodología XXX
Actividad Necesita (Artefactos de entrada) Genera (Artefactos de salida)
Requisitos Documento de visión
(Iteración 1) Modelo de casos de uso
Especificación complementaria
Modelado Modelo de casos de uso Modelo de dominio
(Iteración 1) Modelo de clases
Codificación Modelo de casos de uso Ficheros de código
(Iteración 1) Especificación complementaria Scripts de despliegue
Modelo de clases
... ... ...

Metologías ágiles más conocidas
http://www.dicampus.es
Feature Driven Development
Agile Unified Process
eXtreme Programming
Lean Software Development Crystal
Scrum
Dynamic Systems Development Method
A Practical Guide to Seven Agile Methodologies
http://www.devx.com/architect/Article/32761

Adecuación al tipo de proyecto y equipo
Adecuado XP Scrum Lean FDD AUP Crystal DSDM
para?
Equipos -
✓ ✓ ✓ ✓
✗ ✗
http://www.dicampus.es
pequeños
Requisitos - -
✓ ✓ ✓ ✓ ✗
volátiles
Equipos
✓ ✓ ✓ ✓
✗ ✗ ✗
distribuidos
Cultura - - -
✓ ✓
✗ ✗
burocrática
Sistemas - - - -
✓
✗ ✗
críticos
Varios - - -
✓ ✓
✗ ✗
clientes

Adecuación al tipo de proyecto y equipo
Adecuado XP Scrum Lean FDD AUP Crystal DSDM
http://www.dicampus.es
para?
Equipos -
✓ ✓ ✓ ✓
✗ ✗
pequeños
Requisitos - -
✓ ✓ ✓ ✓ ✗
volátiles
Equipos
✓ ✓ ✓ ✓
✗ ✗ ✗
distribuidos
Varios - - -
✓ ✓
✗ ✗
clientes

Dimensión técnica - XP
 Lleva las prácticas habituales al extremo (de ahí su
nombre)
http://www.dicampus.es
 Requiere de equipos muy hábiles
 Ciclos muy cortos (1-4 semanas)
 Muy poco ceremoniosa, i.e. Pocos artefactos
o Story cards, Código, Pruebas, poco más.
 Muy pocos roles
o Cliente - Descripción de necesidades, validación
o Programador - Desarrollo de la solución
o Coach - Cumplimiento del proceso
o Tracker - Seguimiento de agenda

XP - Técnicas empleadas
 Pair programming
 User Stories
 Colective code ownership
 Planning Game
http://www.dicampus.es
 Continuous Integration
 Small Releases
 Sustainable Pace
 Metaphor
 Whole Team
 Simple design
 Coding Standards
 Testing
 Onsite Customer
 Refactoring
http://www.extremeprogramming.org/rules.html

XP - Técnicas empleadas
 Pair programming
 User Stories
 Colective code ownership
 Planning Game
http://www.dicampus.es
 Continuous Integration
 Small Releases
 Sustainable Pace
 Metaphor
 Whole Team
 Simple design
 Coding Standards
 Testing
 Onsite Customer
 Refactoring
http://www.extremeprogramming.org/rules.html

XP - Historias de Usuario
 Es una herramienta de planificación
 Captura requisitos de muy alto nivel
http://www.dicampus.es
 Escritas por el cliente
 Lenguaje de negocio
 Sirven para estimar esfuerzos y planificar el desarrollo, no
son requisitos finales
http://userstories.com

http://www.dicampus.es
XP - User Stories

XP - Diseño Simple
Consejos
http://www.dicampus.es
 Sigue el principio KISS (Keep it simple, stupid!)
 Nunca diseñes para dar soporte a una funcionalidad no
planificada. (AKA sobrediseño)
 Usa patrones de diseño para que tu diseño sea más
fácil de comprender, más adaptable y más extensible.
Pero sin ser un pattern happy.
http://www.cmcrossroads.com/bradapp/docs/
patterns-intro.html

XP - Testing / TDD / BDD
http://www.dicampus.es
 Creación de tests automatizados que describan los
requisitos del código antes de que ésta sea escrito
 Sirven de documentación (lo que tiene que hacer el
sistema)
 Si el código se modifica, los tests comprueban que
sigue funcionando
Test Driven Development: By Example, Kent Beck,
Addison-Wesley Longman, 2002

XP - Testing / TDD / BDD
 Test-Driven Development (TDD) se centra en
aspectos funcionales del código. Imperativo
http://www.dicampus.es
 “Se obtiene el número de productos en la tienda, se vende uno,
se vuelve a obtener el número de productos en la tienda, el
número de productos final, es el número de productos inicial
menos 1”
 Behaviour Driven Development (BDD) se centra en
aspectos funcionales del dominio. “Declarativo
 Al vender un producto en la tienda, se comprueba que queda un
producto menos en stock”.

XP - Testing / TDD / BDD. Método
1. Crea un test que describa una característica del sistema
2. Ejecútalo y obsérvalo fallar
http://www.dicampus.es
3. Añade funcionalidad de manera que la especificación
descrita por el test se cumpla
4. Ejecuta el test con éxito. Tu código se acaba de crear y
es un código correcto.
5. Refactoriza el código (cambia la implementación
manteniendo las interfaces)
6. Vuelve a ejecutar las pruebas, y comprueba que sigue
funcionando
 Ejemplos: tdd_ruby, bdd_ruby

XP - Testing / TDD / BDD.
 Práctica indispensable, sobre todo en entornos
dinámicos (carentes de sistema estático de tipos)
Ruby, Python, PHP, javascript, etc.
http://www.dicampus.es
palabras=[\"hola\",\"adios\",2]
for (var i=0; i< palabras.length; i++)
document.writeln(palabras[i].toUpperCase());
 Herramientas:
 XUnit: JUnit, NUnit, JSUnit, PyUnit...
 BDD: JBehave, DocTest (Python), RSpec (Ruby),
Cucumber...
 Mock Objects: JMock, NMock, pMock...

XP - Refactoring
 Cambiar la estructura del código sin alterar su
http://www.dicampus.es
funcionalidad
 Para qué?
o Manteniblidad
o Adaptabilidad
o Rendimiento
Refactoring: Improving the Design of Existing Code
By Martin Fowler et al. Addisson - Wesley, 1999

XP - Refactoring
 Los bad smells nos indican la necesidad de aplicar una
refactorización. Por ejemplo.
http://www.dicampus.es
o ¿Tienes muchos if-else anidados?
• Sustituye las comprobaciones por invocaciones
polimórficas (Replace conditionals with polymorphism)
o ¿Tienes un método con muchas líneas de código?
• Extrae parte de su comportamiento a un método privado y
dale un nombre significativo. (Extract method)
o ¿Una clase es poco cohesiva?
• Mueve sus métodos menos cohesivos a otra clase donde
tengan más sentido (Move method)
http://www.refactoring.com/catalog/index.html

XP - Refactoring
 Cada refactoring es una pequeña modificación.
o Algunas muy simples y específicas. (Ej. Encapsulate downcast)
http://www.dicampus.es
Object lastReading() {
return readings.lastElement();
}
Reading lastReading() {
return (Reading)readings.lastElement();
}
o Otras no tanto (Ej Replace Type Code With State /Strategy )
Ejemplo: refactoring películas

XP: Integración continua
 Integración frecuente del código en un entorno similar al
de producción
http://www.dicampus.es
 Aplica diversas técnicas y herramientas
o Self-testing code: El código incluye pruebas que verifican su
funcionamiento. XUnit, Selenium...
o Source code management: El código desarrollado por varios
miembros del equipo se integra en un sistema de control de
versiones. CVS, SVN, Git...
o Task automation: El código incluye mecanismos de
automatización, por ejemplo, para ejecutar las pruebas de forma
automática, o generar informes. Make, Ant,, rake...
Continuous Integration: Improving Software Quality and
Reducing Risk. Martin Fowler. Addison-Wesley, 2007

XP: Integración continua
 Elementos (punto de vista estático)
o Servidor de control de versiones
http://www.dicampus.es
• Mantiene en un repositorio el código desarrollado por los
miembros del equipo
o Servidor de integración continua
• Periódicamente descarga la última versión del código del
repositorio. (svn update)
• Ejecuta tareas de pruebas (ant test)
• Informa a los miembros del equipo del resultado de las
pruebas (web, twitter, mail, sms, etc.)
o Máquinas de desarrollo
• Contienen copias de trabajo del repositorio
• Confirman los cambios al repositorio (svn commit)

XP: Integración continua
 Elementos (punto de vista estático)
http://www.dicampus.es

XP: Integración continua
 Elementos (punto de vista dinámico)
Continuous Integration Server
User @ Workstation Version Control Server
Time
http://www.dicampus.es
update code check if build needed
modify code
has the code changed?
commit changes
[code changed] update code
build code: results
notify (results)

XP: Integración continua
 Herramientas comerciales
o Cruise Control (CC.net, CC.rb...)
http://www.dicampus.es
o BuildBot (para python)
o Hudson
• Open source
• Gratuito
• Multiplataforma
• Extensible

XP: Integración continua
 Beneficios
o No esperamos al final para integrar
http://www.dicampus.es
• ¿Cuánto tiempo nos llevaría integrar?
• ¿Donde fallaría?
o Los fallos se detectan de forma temprana
o Al terminar de codificar, el sistema tiene calidad de producción
o Se obtiene un feedback continuo del estado del proyecto
o Ahorramos tiempo y en consecuencia dinero.

Dimensión de gestión - Scrum
http://www.dicampus.es
 Se centra en el seguimiento y la planificación del
proyecto de forma ágil
 Complementa las técnicas de desarrollo vistas en XP
 Aporta métodos y técnicas para la reducción del riesgo
(planificación)
(PDF) Schwaber, K. Advanced Development Methods.
SCRUM Development Process

Scrum - Reducción del riesgo
 Reducción del riesgo
http://www.dicampus.es

Scrum - Conceptos clave
http://www.dicampus.es
 Release - Subconjunto de la funcionalidad del producto
que tiene valor por sí misma. Cada release se desarrolla
en varios sprints.
 Sprint - Unidad mínima de planificación, en la que se
desarrollan un conjunto de funcionalidades del producto.

Scrum - Conceptos clave (Artefactos)
 Product / Release/ Sprint Backlogs
o Requisitos de alto nivel del producto / Funcionalidad a
http://www.dicampus.es
implementar en la release / Funcionalidad a implementar durante
un sprint
 Burn down chart
o Muestra el progreso diario durante la ejecución de un sprint
o Permite ver si el progreso es adecuado
o Anticipa posibles retrasos permitiendo elaborar planes de
contingencia

Scrum - Conceptos clave (Roles)
 Product Owner
o Mantiene el product backlog, representando los intereses de los
clientes.
http://www.dicampus.es
 Scrum master
o Coordina el trabajo entre los miembros del equipo, su misión es
la de hacer que la planificación se cumpla y que el resto de
miembros tenga los medios para hacer su trabajo.
 Developers
 Testers
 Clients
o Quienes lo van a usar y pagan por el producto

Scrum - Proceso
 Macroproceso: Desarrollo del producto
o Obtención de las funcionalidades deseadas (historias de usuario)
que forman el product backlog.
http://www.dicampus.es
o Desarrollo de cada release
 Microproceso: Desarrollo de la release
o Pregame (Planificación de la release)
• Confección del release backlog.
• Estimación del esfuerzo de ejecución de la release.
o Game (Ejecución de la release)
• Planificación y desarrollo cada sprint
o Postgame (Entrega de la release)
• Completado de la documentación y preparación de la
entrega

Scrum: Desarrollo de cada sprint
 Partimos del sprint backlog
http://www.dicampus.es
 Objetivo: implementar la funcionalidad del sprint backlog,
con calidad de producción, en el tiempo estimado.
 Si no se alcanza la agenda algo hemos hecho mal
o Los Burndown charts nos ayudarán a monitorizar el progreso
 El feedback diario por parte del equipo también nos
ayudará a optimizar el progreso del sprint.
o Scrum meetings

Scrum: Burn down chart
 Indica el trabajo que queda por hacer durante un sprint
 Permite hacer una estimación de cuando se va a
terminar de desarrollar el sprint.
http://www.dicampus.es
http://xprocess.blogspot.com/

Scrum: Scrum meetings
 Daily scrum (A diario)
o Corta duración
http://www.dicampus.es
o De pie (ayuda a cumplir la duración)
o Todo el mundo es bienvenido pero sólo los miembros del equipo
(Pigs) pueden hablar
o En el mismo sitio y a la misma hora (se penalizan los retrasos)
o Cada miembro responde a las siguientes preguntas
• ¿Qué hiciste ayer?
• ¿Qué vas a hacer hoy?
• ¿Has encontrado algún problema que te dificultase el
trabajo? (Responsabilidad del Scrum master solucionarlos)

Scrum: Scrum meetings (II)
 Sprint planning meeting (Al principio)
o Confeccionar el sprint backlog
http://www.dicampus.es
o 8 horas como mucho
 Sprint review meeting (Al final)
o Presentar el trabajo completado a los stakeholders
o 4 horas máximo
 Sprint retrospective (Al final)
o ¿Qué ha ido bien? ¿Qué se puede mejorar? Mejora continua del
proceso
o 3 horas máximo.

Scrum explained: 8’
http://www.dicampus.es
http://www.youtube.com/watch?v=Q5k7a9YEoUI&fmt=22

Fin de la exposición
http://www.dicampus.es
¿Preguntas?

Mejora continua
http://www.dicampus.es
me@miguelfernandez.info

Mejora continua
grazie
obrigado
http://www.dicampus.es
‫ﺷﻜﺮﺍ‬
merci
ॿॿॿॿॿॿॿ
спасибо
Gracias
Danke
thanks
‫תודה‬

Otras referencias
A practical guide to seven agile methods - http://www.devx.com/architect/

Article/32761
Martin Fowler - http://martinfowler.com

http://www.dicampus.es
Recursos sobre AUP, Agile Modelling, etc. - http://www.ambysoft.com/

eXtreme Programming - http://www.extremeprogramming.org/

Sobre historias de usuario - http://userstories.com/

Patrones de diseño - http://www.hillside.net/

Patrones para el diseño de pruebas unitarias - http://xunitpatterns.com/

Artículo de fowler sobre integración continua - http://martinfowler.com/

articles/continuousIntegration.html
Hudson home page - https://hudson.dev.java.net/

Lámparas de lava como indicador del estado del proyecto - http://

mark.michaelis.net/Blog/BuildStatusUsingLavaLampsByKenNichols.aspx
Recursos sobre SCRUM - http://www.scrumalliance.org/resources
