Scrum Master - Developer Capitulo 1

www.jbenterprisegroup.com
MSC,MBA, PMP
PEDRO CASTAÑEDA VARGAS
Curso Taller
SCRUM
Metodología Ágil de Gestión de
Proyectos de SoftwareM7.1
Reflexiones!
―Una sola metodología no puede funcionar para todo el
espectro de proyectos, en vez de eso el administrador de
cada proyecto debería identificar la naturaleza especifica
de cada proyecto y seleccionar la mejor metodología de
desarrollo aplicable.‖
Hawrysh & Ruprecht 2000
―Hay una necesidad de ambos métodos [ágiles y
orientados a procesos] ya que no hay un modelo
de desarrollo que se ajuste a todos los propósitos
imaginables.‖
McCauley 2001

 Generalidades de Proyectos
 Manifiesto Ágil
 Principios Ágiles
 Declaración de Interdependencia
 Estadísticas de Metodologías Ágiles
INTRODUCCIÓN METODOLOGÍAS ÁGILES
Es un conjunto de actividades interrelacionadas y no repetitivas, que
están orientadas al logro de metas específicas y que poseen un inicio y un
fin claramente establecidos.
Definiendo un proyecto…
Alcance
Satisfacción del
Cliente
Alcance
Mirada Clásica Mirada Actual

Los proyectos de SW en la realidad…
CHAOS 2012
SURVEY RESULTS
Fuente: The Standish Group, The Chaos Report 2012
Otras estadísticas…
Fuente:
McKinsey (2012). Delivering large-scale IT projects on time, on Budget, and on value
Gartner (2012). Survey Shows Why Projects Fail. In L. Mieritz (Ed.): Gartner
 McKinsey (2012)
• Average cost overrun: 66%
• Average time overrun: 33%
• Limited functionality: 17%
 Gartner (2012)
• Project failure: 20-28%
• Heavily reliant on Project size

POBRE
GESTIÓN
Corrupción
del Alcance
Ignorar los
Riesgos del
Proyecto
No hay un
Sistema de
Control de
Cambios
No se
gestionan las
Expectativas
Requisitos
inadecuados o
ambiguos
Falta de
implicación
del Usuario
Entregas
Tardías
Pobre
Comunicación
Sobrecoste
Ausencia de
una
planificación
formal
Objetivos
poco claros,
no definidos o
poco realistas
Falta de
Compromiso
No hay una
definición de
Roles y
Responsabilid
ades
Ausencia de
Pruebas
Objetivos
cambiantes
Ausencia de
Plantillas de
Ayuda y
Documentació
n
Decisiones
Incorrectas
Estimaciones
Erróneas Pobre gestión
de conflictos
Ausencia de
Compromiso
de la
Dirección
Poco o nulo
soporte de la
Dirección
Desconocimie
nto técnico
del equipo
(Capacidades
no
adecuadas)
Falta de
Recursos
Pobre o nula
priorización
Causas más comunes de fracaso en proyectos…
Un requerimiento desde diferentes perspectivas…

Intangibilidad del Software
―¿de qué color es un objeto que no podemos ver?‖PROBLEMA
SOLUCIÓN
Método Ágil
Búsqueda de un acuerdo
inmutable, previamente
negociado
Acuerdo iterativo
adaptable a los cambios
Método Tradicional
Analizando la realidad…
1950 1960 1970 1980 1990 1990 2000
FDD CRYSTAL
DSDM
XP SCRUM
AGILIDAD
PROCESOS
Qué nos ofrece la industria de software?
ASD

Características Ágiles y Tradicionales
Metodología Ágil Metodología Tradicional
Orientada a proyectos pequeños. Corta duración (o
entregas frecuentes), equipos pequeños (< 10
integrantes) y trabajando en el mismo sitio.
Posibles problemas de escalabilidad en proyectos
“grandes”
Aplicables a proyectos de cualquier tamaño, pero suelen
ser especialmente efectivas/usadas en proyectos grandes
y con equipos posiblemente dispersos. Posibles
problemas de adaptabilidad a proyectos “pequeños”
Pocos Artefactos. El modelado es prescindible,
modelos desechables.
Más Artefactos. El modelado es esencial, mantenimiento
de modelos
Pocos Roles, más genéricos Más Roles, más específicos
No existe un contrato tradicional, debe ser
bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de desarrollo (además
in-situ)
El cliente interactúa con el equipo de desarrollo mediante
reuniones
La arquitectura se va definiendo y mejorando a lo
largo del proyecto
Se promueve que la arquitectura se defina
tempranamente en el proyecto
Énfasis en los aspectos humanos: el individuo y el
trabajo en equipo
Énfasis en la definición del proceso: roles, actividades y
artefactos
Se esperan cambios durante el proyecto Se espera que no ocurran cambios de gran impacto
durante el proyecto
Los beneficios que propone el desarrollo ágil…

Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike Beedle.
Cuándo es útil una metodología ágil?
Desarrollo de
nuevos productos
Investigación
Científica
Líneas de
Producción
Documento creado en febrero del 2001 firmado por 17 gurús de la
informática, desarrolladores de software y administradores. Fue escrito
por Martin Fowler y Highsmith.
El propósito del Manifiesto Ágil fue distribuido de la siguiente manera:
“Estamos descubriendo mejores formas de desarrollar
software haciéndolo y ayudando a que otros lo hagan.
A través de este trabajo hemos llegado a valorar:”
Manifiesto Ágil
Los individuos y
las Interacciones
Software de
Trabajo
Cliente
Colaboración
Respuestas al
cambio
Procesos y
Herramientas
Documentación
completa
Negociación de
contratos
Tras un Plan

Agilismo
Predictibilidad
Vs
Individuos e
iteraciones
Procesos y
herramientas
Argumento: deben servir de
ayuda pero no pueden ser el
objetivo
Prioridad:
→ Calidad profesional del equipo
→ Entrega temprana y continua
1

Software
Funcionando
Wiiiiiiii!
Prioridad:
→ Satisfacción del cliente
→ Aportar valor al negocio
Documentación
extensiva
Argumento: debe servir de
complemento pero no significar
un impedimento
2
Colaboración
con el cliente
Prioridad:
→ Participación del cliente
→ Comunicación directa y continua
Negociación
contractual
Argumento: sólo el cliente
conoce lo que otorga verdadero
valor al negocio
3

Respuesta
ante el cambio
Prioridad:
→ Aceptar cambios de requerimientos
→ Ventaja competitiva para el negocio
Seguir un plan
Argumento: el cliente no está
realmente seguro hasta que no
prueba el software
4
Los 12 principios del Agile Manifesto (Manifiesto Ágil) por Fowler
y Highsmith (2001) son los siguientes:
Principios Ágiles
En lugar de trabajar así
Preferimos así

1. Nuestra máxima prioridad es
satisfacer al Cliente a través de la
entrega temprana y continua de un
software de gran utilidad.
Principios Ágiles
2. Darle la bienvenida a requisitos
cambiantes incluso tarde en el desarrollo. Los
procesos ágiles aprovechan el cambio y lo
transforman en una ventaja competitiva para
el Cliente.
3. Entregar software de buen
funcionamiento con frecuencia, a
partir de un par de semanas a un par
de meses, con una preferencia por el
tiempo más corto.
Principios Ágiles
4. La gente de negocios y los
desarrolladores deben trabajar
juntos todos los días durante todo el
Proyecto.

5. Construir proyectos alrededor de
individuos motivados, darles el entorno y
el apoyo que necesitan y confiar en ellos
para hacer el trabajo.
Principios Ágiles
6. El método más eficiente y eficaz
de comunicación con y dentro de un
equipo de desarrollo es cara a cara.
7. Un software funcional es la
medida de progreso principal.
Principios Ágiles
8. Los procesos ágiles promueven el
desarrollo sostenible. Los
patrocinadores, desarrolladores y
usuarios deben ser capaces de
mantener un ritmo constante de forma
indefinida.

9. La atención continua a la
excelencia técnica y el buen diseño
mejora la agilidad.
Principios Ágiles
10. Simplicidad — el arte
de maximizar la cantidad de
trabajo no realizado — es
esencial.
11. Las mejores
arquitecturas, requisitos y
diseños emergen de equipos
auto-organizados.
Principios Ágiles
12. En intervalos regulares, el
equipo reflexiona sobre cómo ser
más eficaz, y en base a eso ajusta
su comportamiento.

Fue escrita a principios del 2005 por un grupo de 15 líderes de Proyectos
como un suplemento a El Manifiesto Ágil. Enumera seis valores de gestión
necesarios para reforzar una mentalidad de desarrollo ágil,
particularmente en la gestión de Proyectos complejos e inciertos.
La declaración destaca que los equipos de proyectos, Clientes y otros
stakeholders son interdependientes y están conectados, algo que deben
reconocer para tener éxito. Los valores también son interdependientes.
Declaración de Interdependencia
1. Aumentamos el ROI, al
enfocarnos en el flujo continuo
de valor.
2. Ofrecemos resultados fiables
mediante la participación de
Clientes en las interacciones
frecuentes, donde también son
responsables por el trabajo.

3. Asumimos que habrán
incertidumbre y las superamos
a través de iteraciones,
anticipación y adaptación.
4. Damos rienda suelta a la
creatividad y la innovación al
reconocer que las Personajes o
Personas son la fuente máxima
de valor y creamos un entorno en
el que puedan tener un impacto
positivo.
5. Aumentamos el
rendimiento a través de la
rendición de cuentas por parte
del grupo en cuestión de
resultados y eficacia del
equipo, responsabilidades que
todos comparten.
6. Mejoramos la eficacia y la
fiabilidad a través de estrategias
situacionalmente específicas,
procesos y prácticas.

Fuente: The CHAOS Manifesto, The Standish Group, 2012.
Los métodos ágiles reportan mejores resultados…
Algunas estadísticas de metodologías ágiles…

Algunas estadísticas de metodologías ágiles…
Average results based on survey of 5,183 participants over 7 surveys from 2003 – 2008.
Source: Business Value of Agile Methods by Dr. David Rico (2009)
Métrica Resultados
Productividad 67% mejora
Calidad 65% mejora
Costo 49% reducción
Tradicional Vs Ágil

Results measured from 2005 – 2008 for 150 teams at Yahoo adopting Scrum using survey question.
Source: Rolling out Agile in a Large Enterprise by Gabrielle Benefield (2008)
(*) Source: Agile Development in the Enterprise by Dr. Jeff Sutherland (2009)
Métrica Resultados
Productividad 34% mejora con equipos no
entrenados
Productividad 100% - 200% mejora (*) con equipos
entrenados
Costo $1.5m ahorros anuales por Scrum
Coach
Popularidad 81% de equipos desea usar Scrum
otra vez
Tradicional Vs Ágil
Systematic CMMI-5 Results
―Self Organization is the key to Hyper Productivity – 400% to 800% improvement in
Velocity and Quality‖
Dr. Jeff Sutherland, co-creator of Scrum
• Mejora de la productividad en
un 100% en los primeros 6
meses
• Duplicidad de la velocidad con
DONE*
Source: Agile Development in the Enterprise by Dr. Jeff Sutherland (2009)
*Source: Going from Good to Great by Carsten Jakobsen and Dr. Jeff Sutherland (Agile 2009)
Hiper productividad en SCRUM

10%
20%
30%
50%
40%
60%
CMMI 1 CMMI 5
70%
80%
90%
100%
CMMI 5
SCRUM
Project effort
Rework
Work
Process focus
CMMI
Adding
SCRUM
50 %
50 %
50 %
10 %
9 %
6 %
25 %
4 %
100 %
69 %
35 %
Source: Systematic A/S
Análisis de Desempeño SCRUM y CMMI
Waterfall
[1]
Waterfall
[2]
Scrum
[1]
SirsiDynix
[3]
Xebia
[4]
Personas (Mes) 540 2,000 54 827 125
Líneas of Java 58,000 500,000 51,000 671,688 100,000
Puntos de
Función
900 10,000 959 12,673 1887
Puntos de
Función por
Desarrollador
(Mes)
1.7 5 17.8 15.3 15.1
Resultados repetibles
1. User Stories Applied for Agile Development by Mike Cohn (2004)
2. Software Assessments, Benchmarks and Best Practices by Capers Jones (2000)
3. Distributed Scrum: Agile Project Management by Outsourced Teams by J. Sutherland, A. Viktorov, J. Blount, N.
Puntikov (2007)
4. Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams by J.
Sutherland, G. Schoonheim, E. Rustenburg, M. Rijk (2008)
Hiper productividad en SCRUM

Trabajo en equipo?…
Lo que debemos evitar…
Equipo Montaña Rusa
Equipo como
máquina bien
engrasada
Equipo que hunde al
barco

Manifiesto Ágil (en español):
www.agilemanifesto.org/iso/es/
Roles, artefactos y ceremonias en Scrum:
http://www.desarrolloweb.com/manuales/metodologias-agil-desarrollo-software.html
Desarrollo Ágil con Kanban:
http://www.desarrolloweb.com/articulos/desarrollo-agil-kanban.html
Diseño Ágil con TDD (Carlos Blé Jurado):
http://www.dirigidoportests.com/el-libro ó www.carlosble.com
Otros recursos:
TDD en PHP (inglés): www.enhance-php.com
TDD en PHP (español): http://eugeniabahit.blogspot.com/2011/09/enhance-php-acerca-de-los-test.html
Código Estándar en Python: www.python.org/dev/peps/pep-0008/ (guía de estilos para Python)
Tutorial TDD en Python: http://magmax9.blogspot.com/search/label/tests
Algunas referencias bibliográficas:
Hyper Productive Agile, Practices for achieving break-through results with Agile, Ryan Shriver –
Managing Consultant – www.dominiondigital.com, rshriver@dominiondigital.com - theagileengineer.com – twitter:
ryanshriver
Una introducción a SCRUM, ErnestoGrafeuille, Noviembre 2008
Material de Ayuda
Preguntas?

Scrum Master - Developer Capitulo 1

Más contenido relacionado

La actualidad más candente

Similar a Scrum Master - Developer Capitulo 1

Último

Scrum Master - Developer Capitulo 1