¿Por que fallan los proyectos?
¿Por qué fallan los suyos?
La cruda realidad
Causa de Fracasos en los
Proyectos
 Cronogramas poco realistas
 Personal inadecuado
 Cambios en los requerimientos
 Trabajo de pobre calidad
 Creer en magia
 Winning with Software: An Executive
Strategy. Watts S. Humphrey
¿VIAJARÍA USTED EN UN
AVIÓN AL QUE USTED LE
ESCRIBIÓ EL SOFTWARE
DE NAVEGACIÓN?
Manifiesto Ágil
Estamos descubriendo formas mejores de desarrollar software
tanto por nuestra propia experiencia como ayudando a terceros. A
través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
http://agilemanifesto.org/iso/es/
Los 12 Principios
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas
y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos
juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay
que darles el entorno y el apoyo que necesitan, y confiarles la ejecución
del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo
de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
http://agilemanifesto.org/iso/es/
Los 12 Principios
8. Los procesos Ágiles promueven el desarrollo sostenible. Los
promotores, desarrolladores y usuarios debemos ser capaces de
mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño
mejora la Agilidad.
10.La simplicidad, o 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.
12.A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo para a continuación ajustar y perfeccionar su comportamiento
en consecuencia.
http://agilemanifesto.org/iso/es/
Valores
 Compromiso
 Enfoque y Foco
 Apertura y transparencia
 Respeto
 Coraje
Objetivo: Pasar a la otra orilla a pie sin
mojarse (sin usar un puente, etc, etc.)
Crecimiento orgánico
(iterativo e incremental)
Una
mujer con
una
pradera
atrás
Diferencias entre enfoque iterativo y
enfoque orgánico (iterativo e
incremental)
SCRUM
“El Arte de Amar los Lunes”.
Alan Cyment
 Scrum es una framework metodológico 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.
Scrum ha sido utilizado por:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce
Scrum ha sido utilizado para:
 Software comercial
 Desarrollos internos
 Desarrollos bajo Contrato
 Proyectos Fixed-price
 Aplicaciones Financieras
 Aplicaciones certificadas ISO
9001
 Sistemas Embebidos
 Sistemas con requisitos 7x24
y 99.999% de disponibilidad
 Joint Strike Fighter
• Desarrollo de video juegos
• Sistemas críticos de soporte
vital, aprobados por laFDA
• Software de control satelital
• Sitios Web
• Software para Handheld
• Teléfonos portátiles
• Aplicaciones de Network
switching
• Aplicaciones de ISV
• Algunas de las más grandes
aplicaciones en uso
Características
 Equipos auto-organizados
 El producto avanza en una serie de “Sprints"
de dos semanas a un mes de duración
 Los requisitos son capturados como
elementos de una lista de “Product Backlog"
 No hay prácticas de ingeniería prescritas
 Utiliza normas generativas para crear un
entorno ágil para la entrega de proyectos
 Uno de los “procesos ágiles”
Sprints
 En Scrum los proyectos avanzan en
una serie de “Sprints”
 Análogo a las iteraciones en XP
 La duración típica es 2–4 semanas o a
lo sumo un mes calendario
 La duración constante conduce a un
mejor ritmo
 El product es diseñado, codificado y
testeado durante el Sprint
Scrum Framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
•Product owner
•ScrumMaster
•Team
Roles
Product Owner
 Define las funcionalidades del producto
 Decide sobre las fechas y contenidos de los releases
 Es responsable por la rentabilidad del producto (ROI)
 Prioriza funcionalidades de acuerdo al valor del mercado/negocio
 Ajusta funcionalidades y prioridades en cada iteración si es
necesario
 Acepta o rechaza los resultados del trabajo del equipo
Product Owner
El espiritu de Scrum.
Alan Cyment
El ScrumMaster
 Representa a la gestión del proyecto
 Responsable de promover los valores y prácticas de
Scrum
 Remueve impedimentos
 Se asegura de que el equipo es completamente
funcional y productivo
 Permite la estrecha cooperación en todos los roles y
funciones
 Escudo del equipo de interferencias externas
El Team
 Típicamente de 5 a 9 personas
 Multi-funcional:
◦ Programadores, testers, analistas, diseñadores, etc.
 Los miembros deben ser full-time
◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)
 Los equipos son auto-organizativos
◦ Idealmente, no existen títulos pero a veces se utilizan de
acuerdo a la organización
 Solo puede haber cambio de miembros entre los sprints
Interacción entre los roles
Fuente: El espiritu de Scrum.
Alan Cyment
•Product owner
•ScrumMaster
•Team
Roles
Scrum Framework
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
Sprint Planning meeting
Priorización
• Analizar y evaluar el Product
Backlog
• Seleccionar el objetivo del Sprint
Planificación
• Decidir como alcanzar el
objetivo del Sprint (diseño)
• Crear el Sprint Backlog (tareas)
en base a los temas del Product
Backlog (user stories / features)
• Estimar Sprint Backlog en horas
Objetivo
del Sprint
Sprint
Backlog
Condicione
s del
Negocio
Capacidad
del Equipo
Product
Backlog
Tecnología
Producto
Actual
Planificación del Sprint
 El equipo selecciona los temas a partir del Product
Backlog que pueden comprometerse a completar
 Se crea el Sprint Backlog
 Se identifican tareas y cada una es estimada (1-16 horas)
 Realizado colaborativamente, no solo por el ScrumMaster
 El diseño de Alto Nivel es considerado
YO COMO planificador
de vacaciones, QUIERO
ver fotos de los
hoteles. PARA poder
mostrar diferentes
sitios a mis clientes
Codificar la capa intermedia (8 hs)
Codificar la interfaz de usuario (4)
Escribir los test fixtures (4)
Codificar la clase foo (6)
Actualizar test de performance (4)
Daily Scrum
 Parámetros
 Diaria
 Dura 15 minutos
 Parados
 No para la solución de problemas
 Todo el mundo está invitado
 Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden
hablar
 Ayuda a evitar otras reuniones innecesarias
Todos responden 3
preguntas
 No es dar un status report al Scrum Master
 Se trata de compromisos delante de pares
¿Qué hiciste ayer?
1
¿Qué vas a hacer hoy?
2
¿Hay obstáculos en tu camino?
3
Sprint review
 El equipo presenta lo realizado durante el
sprint
 Normalmente adopta la forma de una
demo de las nuevas características o la
arquitectura subyacente
 Informal
◦ Regla de 2 hs preparación
◦ No usar diapositivas
 Todo el equipo participa
 Se invita a todo el mundo
Sprint retrospective
 Periódicamente, se echa un vistazo a lo que
funciona y lo que no
 Normalmente 1 hora
 Se realiza luego de cada sprint
 Todo el equipo participa
 ScrumMaster
 Product owner
 Equipo
 Posiblemente clientes y otros
Retrospective
 Por lo general se evalua
Felicidad
Productividad
Calidad
Esto es sólo una
de las muchas
maneras de
hacer una
retrospectiva.
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Reuniones
•Product backlog
•Sprint backlog
•Burndown charts
Artefactos
Ejemplo de Product
Backlog
Ejemplo de Sprint
Backlog
Tareas
Codificar UI
Codificar negocio
Testear negocio
Escribir ayuda online
Escribir la clase foo
L
8
16
8
12
8
M
4
12
16
8
M J
4
11
8
4
V
8
8
Agregar error logging
8
10
16
8
8
Scrum estar acompañado
de buenas prácticas de
ingeniería.
Scrum = reglas + espíritu + buenas
prácticas

Scrum

  • 2.
    ¿Por que fallanlos proyectos? ¿Por qué fallan los suyos?
  • 3.
  • 4.
    Causa de Fracasosen los Proyectos  Cronogramas poco realistas  Personal inadecuado  Cambios en los requerimientos  Trabajo de pobre calidad  Creer en magia  Winning with Software: An Executive Strategy. Watts S. Humphrey
  • 5.
    ¿VIAJARÍA USTED ENUN AVIÓN AL QUE USTED LE ESCRIBIÓ EL SOFTWARE DE NAVEGACIÓN?
  • 6.
    Manifiesto Ágil Estamos descubriendoformas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda. http://agilemanifesto.org/iso/es/
  • 7.
    Los 12 Principios 1.Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. 7. El software funcionando es la medida principal de progreso. http://agilemanifesto.org/iso/es/
  • 8.
    Los 12 Principios 8.Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. 10.La simplicidad, o 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. 12.A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. http://agilemanifesto.org/iso/es/
  • 9.
    Valores  Compromiso  Enfoquey Foco  Apertura y transparencia  Respeto  Coraje
  • 10.
    Objetivo: Pasar ala otra orilla a pie sin mojarse (sin usar un puente, etc, etc.)
  • 11.
    Crecimiento orgánico (iterativo eincremental) Una mujer con una pradera atrás
  • 12.
    Diferencias entre enfoqueiterativo y enfoque orgánico (iterativo e incremental)
  • 13.
    SCRUM “El Arte deAmar los Lunes”. Alan Cyment
  • 14.
     Scrum esuna framework metodológico 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.
  • 15.
    Scrum ha sidoutilizado por: •Microsoft •Yahoo •Google •Electronic Arts •High Moon Studios •Lockheed Martin •Philips •Siemens •Nokia •Capital One •BBC •Intuit •Intuit •Nielsen Media •First American Real Estate •BMC Software •Ipswitch •John Deere •Lexis Nexis •Sabre •Salesforce.com •Time Warner •Turner Broadcasting •Oce
  • 16.
    Scrum ha sidoutilizado para:  Software comercial  Desarrollos internos  Desarrollos bajo Contrato  Proyectos Fixed-price  Aplicaciones Financieras  Aplicaciones certificadas ISO 9001  Sistemas Embebidos  Sistemas con requisitos 7x24 y 99.999% de disponibilidad  Joint Strike Fighter • Desarrollo de video juegos • Sistemas críticos de soporte vital, aprobados por laFDA • Software de control satelital • Sitios Web • Software para Handheld • Teléfonos portátiles • Aplicaciones de Network switching • Aplicaciones de ISV • Algunas de las más grandes aplicaciones en uso
  • 17.
    Características  Equipos auto-organizados El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración  Los requisitos son capturados como elementos de una lista de “Product Backlog"  No hay prácticas de ingeniería prescritas  Utiliza normas generativas para crear un entorno ágil para la entrega de proyectos  Uno de los “procesos ágiles”
  • 18.
    Sprints  En Scrumlos proyectos avanzan en una serie de “Sprints”  Análogo a las iteraciones en XP  La duración típica es 2–4 semanas o a lo sumo un mes calendario  La duración constante conduce a un mejor ritmo  El product es diseñado, codificado y testeado durante el Sprint
  • 19.
    Scrum Framework •Product owner •ScrumMaster •Team Roles •Sprintplanning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  • 20.
    Scrum framework •Sprint planning •Sprintreview •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos •Product owner •ScrumMaster •Team Roles
  • 23.
    Product Owner  Definelas funcionalidades del producto  Decide sobre las fechas y contenidos de los releases  Es responsable por la rentabilidad del producto (ROI)  Prioriza funcionalidades de acuerdo al valor del mercado/negocio  Ajusta funcionalidades y prioridades en cada iteración si es necesario  Acepta o rechaza los resultados del trabajo del equipo
  • 24.
    Product Owner El espiritude Scrum. Alan Cyment
  • 25.
    El ScrumMaster  Representaa la gestión del proyecto  Responsable de promover los valores y prácticas de Scrum  Remueve impedimentos  Se asegura de que el equipo es completamente funcional y productivo  Permite la estrecha cooperación en todos los roles y funciones  Escudo del equipo de interferencias externas
  • 26.
    El Team  Típicamentede 5 a 9 personas  Multi-funcional: ◦ Programadores, testers, analistas, diseñadores, etc.  Los miembros deben ser full-time ◦ Puede haber excepciones (Ej.: Infraestructura, SCM, etc.)  Los equipos son auto-organizativos ◦ Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización  Solo puede haber cambio de miembros entre los sprints
  • 27.
    Interacción entre losroles Fuente: El espiritu de Scrum. Alan Cyment
  • 28.
    •Product owner •ScrumMaster •Team Roles Scrum Framework •Productbacklog •Sprint backlog •Burndown charts Artefactos •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones
  • 29.
    Sprint Planning meeting Priorización •Analizar y evaluar el Product Backlog • Seleccionar el objetivo del Sprint Planificación • Decidir como alcanzar el objetivo del Sprint (diseño) • Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features) • Estimar Sprint Backlog en horas Objetivo del Sprint Sprint Backlog Condicione s del Negocio Capacidad del Equipo Product Backlog Tecnología Producto Actual
  • 30.
    Planificación del Sprint El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar  Se crea el Sprint Backlog  Se identifican tareas y cada una es estimada (1-16 horas)  Realizado colaborativamente, no solo por el ScrumMaster  El diseño de Alto Nivel es considerado YO COMO planificador de vacaciones, QUIERO ver fotos de los hoteles. PARA poder mostrar diferentes sitios a mis clientes Codificar la capa intermedia (8 hs) Codificar la interfaz de usuario (4) Escribir los test fixtures (4) Codificar la clase foo (6) Actualizar test de performance (4)
  • 31.
    Daily Scrum  Parámetros Diaria  Dura 15 minutos  Parados  No para la solución de problemas  Todo el mundo está invitado  Sólo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar  Ayuda a evitar otras reuniones innecesarias
  • 32.
    Todos responden 3 preguntas No es dar un status report al Scrum Master  Se trata de compromisos delante de pares ¿Qué hiciste ayer? 1 ¿Qué vas a hacer hoy? 2 ¿Hay obstáculos en tu camino? 3
  • 33.
    Sprint review  Elequipo presenta lo realizado durante el sprint  Normalmente adopta la forma de una demo de las nuevas características o la arquitectura subyacente  Informal ◦ Regla de 2 hs preparación ◦ No usar diapositivas  Todo el equipo participa  Se invita a todo el mundo
  • 34.
    Sprint retrospective  Periódicamente,se echa un vistazo a lo que funciona y lo que no  Normalmente 1 hora  Se realiza luego de cada sprint  Todo el equipo participa  ScrumMaster  Product owner  Equipo  Posiblemente clientes y otros
  • 35.
    Retrospective  Por logeneral se evalua Felicidad Productividad Calidad Esto es sólo una de las muchas maneras de hacer una retrospectiva.
  • 36.
    •Product owner •ScrumMaster •Team Roles Scrum framework •Sprintplanning •Sprint review •Sprint retrospective •Daily scrum meeting Reuniones •Product backlog •Sprint backlog •Burndown charts Artefactos
  • 37.
  • 38.
    Ejemplo de Sprint Backlog Tareas CodificarUI Codificar negocio Testear negocio Escribir ayuda online Escribir la clase foo L 8 16 8 12 8 M 4 12 16 8 M J 4 11 8 4 V 8 8 Agregar error logging 8 10 16 8 8
  • 39.
    Scrum estar acompañado debuenas prácticas de ingeniería. Scrum = reglas + espíritu + buenas prácticas