SlideShare ist ein Scribd-Unternehmen logo
1 von 95
Downloaden Sie, um offline zu lesen
Scrum Manager
         Apuntes
            Rev. 1.1
Scrum Manager Proyecto Apuntes
Scrum Manager
   Proyectos
Apuntes de formación
  Rev.1.1 May-2009
Título

Scrum Manager: Proyectos – apuntes de formación.


Autores

Juan Palacio, Claudia Ruata


Imagen de Portada

Philip A.


Edición

Enero – 2009




Más información, y última versión en: http://www.scrummanager.net




Derechos




Derechos registrados en Safe Creative.
Condiciones de uso, copia y distribución en: http://www.safecreative.org/work/0904193094566
Contenido
  Contenido                                                                  5

Prólogo                                                                      9
  Apuntes de formación Scrum Manager                                         11
    Plataforma abierta para consulta y formación profesional Scrum Manager   11
    Servicios profesionales para formación y asesoría Scrum Manager          11

Concepto clásico de gestión de proyectos                                     13
  Introducción: Proyectos y operaciones                                      15
     Definición clásica de proyecto                                          15
  Origen de la gestión de proyectos                                          15
  Organizaciones referentes en la gestión de proyectos                       16
    Modelo válido para cualquier industria                                   16
  Planificación y seguimiento                                                16
  Gestión predictiva o clásica                                               17
  Ámbito de la gestión de proyectos                                          17
  Resumen                                                                    17

El nuevo escenario                                                           19
  Escenario de desarrollo en los 80                                          21
    The New New Product Development Game                                     21
    Características del nuevo escenario                                      22
  Campos de scrum vs. modelo clásico de desarrollo                           23
    Fases de desarrollo solapadas                                            23
  Características del “campo de scrum”                                       24
    Incertidumbre                                                            24
    Auto-organización                                                        24
    Control sutil                                                            24
    Difusión y transferencia del conocimiento                                24
  Resumen                                                                    25

Gestión de proyectos ágil                                                    27
  Introducción                                                               29
  Objetivos de la gestión ágil                                               29
    1.-Valor                                                                 29
    2.-Reducción del tiempo de salida al mercado                             29
    3.-Agilidad                                                              29
    4.-Flexibilidad                                                          29
    5.- Resultados fiables                                                   30
  Las preferencias de la gestión ágil                                        30
  El ciclo de desarrollo ágil                                                30
     1.- Concepto                                                            30
     2.- Especulación                                                        31
     3.- Exploración                                                         31
     4.- Revisión                                                            31
     5.- Cierre                                                              31
  Principales modelos de gestión ágil                                        31

  2005-2009 – ScrumManager - http://www.scrummanager.net
Contenido


    ASD                                                           32
    AUP                                                           32
    CRYSTAL                                                       32
    DSDM                                                          33
    SCRUM                                                         33
    XBreed – Agile Enterprise                                     34
  Resumen                                                         34

Gestión de proyectos: ¿formal o ágil?                             35
  ¿Ágil, clásica, predictiva …?                                   37
  Premisas de la gestión de proyectos predictiva                  37
  Características de la gestión de proyectos predictiva           37
  Hay otras premisas                                              37
  ¿Cuándo y por qué emplear uno u otro estilo de gestión?         38
    Características del proyecto                                  38
    Prioridad de negocio                                          39
    Estabilidad de los requisitos                                 39
    Rigidez del producto                                          39
    Coste de prototipado                                          39
    Criticidad del sistema                                        40
    Tamaño del sistema                                            40
    Condiciones de la organización                                40
    Nivel profesional                                             41
    Cultura organizativa                                          41
    Entorno de desarrollo                                         41
  Resumen                                                         41

Introducción al modelo Scrum para desarrollo de Software          43
  El origen                                                       45
  Introducción al modelo                                          45
  Control de la evolución del proyecto                            46
    Revisión de las Iteraciones                                   46
    Desarrollo incremental                                        46
    Desarrollo evolutivo                                          46
    Auto-organización                                             46
    Colaboración                                                  46
    Visión general del proceso                                    46
  Las reuniones                                                   47
  Los elementos                                                   47
  Los roles                                                       47
  Valores                                                         48
  Resumen                                                         48

Roles y responsabilidades de proyecto                             51
  Introducción                                                    53
  Responsabilidades generales Scrum Management                    53
    De management                                                 53
    De procesos                                                   53
    De producción                                                 53


  2005-2009 – ScrumManager - http://www.scrummanager.net
Contenido


  Responsabilidades y roles “del proyecto”                           53
  El propietario del producto                                        54
     Para ejercer este rol es necesario:                             54
  El equipo                                                          54
  Scrum Manager – Team Leader                                        55
  Resumen                                                            55
    De management                                                    55
    De procesos                                                      55
    De producción                                                    55

Los elementos de Scrum                                               57
  Introducción                                                       59
  Los requisitos en el desarrollo ágil                               59
  Requisitos y visión del producto                                   60
  Pila del producto: los requisitos del cliente                      60
  Formato de la pila del producto                                    61
  Pila del Sprint                                                    61
     Condiciones                                                     61
     Formato y soporte                                               61
     Ejemplos                                                        62
  El Incremento                                                      62
  Resumen                                                            62

Scrum: Las reuniones                                                 63
  Introducción                                                       65
  Planificación del sprint                                           65
     Descripción general                                             65
     Pre-condiciones                                                 65
     Entradas                                                        65
     Resultados                                                      65
     Formato de la reunión                                           66
                                        1
     Funciones del rol de Scrum Manager                              66
     Pizarra de trabajo                                              67
     Un ejemplo de pizarra                                           67
  Seguimiento del sprint                                             68
    Descripción                                                      68
    Entradas                                                         68
    Resultados                                                       68
    Formato de la reunión                                            68
  Revisión del sprint                                                69
    Descripción                                                      69
    Objetivos                                                        69
    Pre-condiciones                                                  69
    Entradas                                                         69
    Resultados                                                       69
    Formato de la reunión                                            69
  Resumen                                                            70

Medición: consideraciones                                            71


  2005-2009 – Navegapolis - http://www.navegapolis.net
Contenido


  Introducción                                                                  73
     ¿Por qué medir?                                                            73
  Flexibilidad y sentido común                                                  73
  Criterios para el diseño y aplicación de métricas                             73
     Cuantas menos, mejor                                                       73
     ¿El indicador es apropiado para el fin que se debe conseguir?              74
     Medición de la eficiencia en la empresa                                    74
     Medición del avance del proyecto                                           74
     Medición de la eficiencia de los trabajos de programación                  74
     ¿Lo que vamos a medir es un indicador válido de lo que queremos conocer?   75
  Resumen                                                                       75

Medición: Las Unidades                                                          77
  Velocidad, trabajo y tiempo                                                   79
    Tiempo                                                                      79
    Trabajo                                                                     79
    Trabajo ya realizado                                                        79
    Trabajo pendiente de realizar                                               79
    Unidades de trabajo                                                         80
  Velocidad                                                                     81
  Resumen                                                                       81

Medición: Usos y herramientas                                                   83
  Gráfico de producto:                                                          85

Ejemplo:                                                                        85
  Gráfico de avance: monitorización del sprint                                  86
  Estimación de póker                                                           87
    Variante: sucesión de Fibonacci                                             88
    Funcionamiento                                                              88
  Resumen                                                                       89

Índice                                                                          91
  Índice                                                                        93




  2005-2009 – ScrumManager - http://www.scrummanager.net
Prólogo
Scrum Manager Proyecto Apuntes
Apuntes de formación Scrum Manager



Apuntes de formación Scrum Manager
Este es el libro de texto para formación del área de “Proyecto” del marco de gestión
                  ®
“Scrum Manager ”.

Es un recurso educativo abierto (OER) y forma parte de la plataforma Scrum Manager
Open Knowledge: http://scrummanager.net/ok/

Se puede emplear de forma gratuita para consulta y auto-formación a título personal.




Plataforma abierta para consulta y formación profesional Scrum
Manager
Scrum Manager Open Knowledge es una plataforma de acceso libre para
consulta y formación, está disponible en http://scrummanager.net/ok/ donde
encontrarás la última versión de este manual, además de otros materiales,
foros, talleres, etc.

Un punto abierto en la Red para consultar y compartir conocimiento, y mantenerte profesionalmente
actualizado.



Servicios profesionales para formación y asesoría Scrum Manager
Puedes localizar profesionales y empresas certificadas para servicios
profesionales de formación y asesoría en la implantación y mejora de Scrum
Management, en el directorio de consultores Scrum Manager:

http://scrummanager.net/ o solicitar información en la dirección formacion@scrummanager.net




Información para formar parte de la red de consultores certificados Scrum Manager en la dirección
formacion@scrummanager.net.




  2008 – 2005-2009 – ScrumManager - http://www.scrummanager.net                               11
Scrum Manager Proyecto Apuntes
Concepto clásico de gestión de proyectos
Scrum Manager Proyecto Apuntes
Origen de la gestión de proyectos




Introducción: Proyectos y                                        Conjunto único de actividades necesarias
                                                                 para producir un resultado definido en un
                                                                 rango de fechas determinado y con una
operaciones                                                      asignación específica de recursos



                                                             Las construcciones de ingeniería civil, como
                                                             puentes o edificios, son ejemplos clásicos de
                                                             obras realizadas como proyectos, y en general lo
                                                             es el desarrollo de cualquier sistema singular.

                                                             Un proyecto tiene objetivos y características
                                                             únicas.
El desarrollo de productos, la prestación de                 Algunos necesitan el trabajo de una sola persona,
servicios, o incluso la organización de la propia            y otros el de cientos de ellas; pueden durar unos
empresa son trabajos que pueden tomar la forma               días o varios años.
de proyectos o de operaciones.
                                                             Algunos ejemplos de proyectos:
Ambos compantes tres características:
                                                                 Diseño de un nuevo ordenador portátil.
    Los realizan personas.                                      Construcción de un edificio.
    Se emplean recursos limitados.                              Desarrollo de un sistema de software.
    Se llevan a cabo siguiendo una estrategia de                Implantación de una nueva línea de producto
     actuación.                                                   en una empresa.
                                                                 Diseño de una campaña de marketing.
Aunque comparten estas tres características, la
diferencia clave entre operaciones y proyectos es
que:
                                                             Origen de la gestión de
    Las operaciones se ejecutan de forma
    repetitiva para obtener resultados de
                                                             proyectos
    similares características
    Los proyectos producen resultados                        Los proyectos han existido siempre.
    únicos                                                   Cualquier trabajo para desarrollar algo único es
                                                             un proyecto, pero la gestión de proyectos es una
                                                             disciplina relativamente reciente que comenzó a
Se considera proyecto a la ejecución de un                   forjarse en los años sesenta.
trabajo que además de requerir personas, recur-
sos y ejecución controlada:                                  La necesidad de su profesionalización surgió en
                                                             el ámbito militar.
Es un desarrollo único                                       En los 50, el desarrollo de complejos sistemas
                                                             militares, requería coordinar el trabajo conjunto de
La teoría clásica de gestión de proyectos, añade             equipos y disciplinas diferentes, en la cons-
a la característica anterior otra, que desde la              trucción de sistemas únicos.
perspectiva de gestión predictiva tiene sentido,             Bernard Schriever, arquitecto del desarrollo de
pero no tanto, como se verá, desde la perspectiva            misiles balísticos Polaris, es considerado el padre
de gestión de proyectos ágil.                                de la gestión de proyectos, por la introducción del
                                                             concepto de “concurrencia”, para integrar todos
Se desarrolla en un marco temporal pre-                      los elementos del plan del proyecto en un solo
establecido.                                                 programa y presupuesto.

                                                             El objetivo de la concurrencia era ejecutar las
                                                             diferentes actividades de forma simultánea, y no
                                                             secuencialmente, y al aplicarla en los proyectos
                                                             Thor, Atlas y Minuteman se redujeron conside-
Definición clásica de proyecto                               rablemente los tiempos de ejecución.




    2005-2009 – ScrumManager - http://www.scrummanager.net                                                    15
Origen de la gestión de proyectos


La industria del automóvil siguió los pasos de la                de una gestión de proyectos, para ofrecer garan-
militar, aplicando técnicas de gestión de                        tías de previsibilidad y calidad de los resultados.
proyectos para la coordinación del trabajo entre
áreas y equipos diferentes.
                                                                 Este conocimiento se ha configurando como el
Comenzaron a surgir técnicas específicas,                        currículo de una nueva profesión: La gestión de
histogramas, cronogramas, los conceptos de ciclo                 proyectos predictiva.
de vida del proyecto o descomposición en tareas
(WBS Work Breakdown Structure).                                  Las organizaciones más relevantes en esta línea
                                                                 son:
En 1960, Meter Norden, del laboratorio de
investigación de IBM, en su seminario de Inge-                      International Project Management Association
niería de Presupuesto y Control presentado ante                      (IPMA), fundada en 1965
American Management Association, indicó:                            Project     Management      Institute (PMI)
                                                                     constituído en 1965
                                                                    Más tarde surgió Prince2, que comenzó a
       Es posible relacionar los nuevos                              trabajar en 1989.
       proyectos con otros pasados y
       terminados para estimar sus costes                        IPMA y PMI surgieron como organizaciones
       Se producen regularidades en todos                        profesionales para desarrollar metodologías y
       los proyectos                                             procesos para la gestión de proyectos.
       Es       absolutamente     necesario                      Prince2 ha tenido la evolución inversa. Comenzó
       descomponer los proyectos en partes                       siendo una metodología, alrededor de la que se
       de menor dimensión para realizar                          ha terminado creando una organización.
       planificaciones.

                                                                 Modelo válido para cualquier
                                                                 industria
Organizaciones referentes                                        También en este sentido la evolución ha sido
                                                                 diferente para Prince2:
en la gestión de proyectos                                       PMI e IPMA tuvieron desde el principio como
                                                                 finalidad el desarrollo de un conocimiento de
                                                                 gestión válido para cualquier proyecto.
La construcción de sistemas complejos que                        Sin embargo, Prince2 comenzó siendo un modelo
requerían el trabajo sincronizado de varias                      de referencia para proyectos específicos de
disciplinas hizo evidente en los 60 la necesidad                 Tecnologías de la Información, desarrollado por la
de nuevos métodos de organización para evitar                    Central Computer and Telecommunications
problemas recurrentes:                                           Agency (CCTA) del Gobierno Británico; y a partir
                                                                 de una revisión llevada a cabo en 1996 se decidió
    Desbordamiento de agendas.                                  ampliar su ámbito de validez, para cualquier tipo
    Desbordamiento de costes.                                   de proyecto.
    Calidad o utilidad del resultado obtenido.


                                                                 Planificación y seguimiento




Para dar respuesta a esta necesidad, desde los
años 60 han surgido organizaciones que contri-
buyen al desarrollo del cuerpo de conocimiento


16      2005-2009 – ScrumManager - http://www.scrummanager.net
Origen de la gestión de proyectos


La gestión de proyectos desarrollada en las                      Grupos de procesos de la gestión de proyectos
últimas décadas del siglo pasado se basa en la                                  PMBOK 2004
planificación del trabajo, y en el posterior
seguimiento y control de la ejecución.

La planificación se realiza sobre un análisis
detallado del trabajo que se quiere realizar y su            Ámbito de la gestión de
                                                             proyectos
descomposición en tareas.
Parte por tanto de un proyecto de obra, o de unos
requisitos detallados de lo que se quiere hacer.
Sobre esa información se desarrolla un plan
adecuado a los recursos y tiempos disponibles; y
                                                             La solvencia demostrada por la gestión de
durante la construcción se sigue de cerca la
                                                             proyectos en la industria militar, y en la
ejecución para detectar posibles desviaciones y
                                                             automovilística para solucionar los problemas
tomar medidas para mantener el plan, o
                                                             habituales de calidad, tiempos y costes, coincide
determinar qué cambios va a experimentar.
                                                             en el tiempo con la presión que todas las
Se trata por tanto de una gestión “predictiva”, que
                                                             industrias experimentan en mayor o menor
vaticina a través del plan inicial cuáles van a ser
                                                             medida para reducir la agenda de salida al
la secuencia de operaciones de todo el proyecto,
                                                             mercado y los costes de producción. Como
su coste y tiempos.
                                                             resultado, en todos los sectores: farmacéutico,
                                                             químico, servicios, tecnologías de la información,
Su principal objetivo es conseguir que el producto
                                                             etc. se adoptan técnicas de gestión de proyectos,
final se obtenga según lo “previsto”; y basa el
                                                             dándoles de facto validez para todos los ámbitos.
éxito del proyecto en los tres puntos apuntados:
agendas, costes y calidad.



Gestión predictiva o clásica
La gestión de proyectos predictiva o clásica es
una disciplina formal de gestión, basada en la
planificación, ejecución y seguimiento a través de
procesos sistemáticos y repetibles.

    Establece como criterios de éxito: obtener el
     producto definido, en el tiempo previsto y con
     el coste estimado.
    Asume que el proyecto se desarrolla en un


     entorno estable y predecible.
     El objetivo de su esfuerzo es mantener el               Resumen
     cronograma, el presupuesto y los recursos.
    Divide el desarrollo en fases a las que                    Definición clásica de proyecto: construcción
     considera “ciclo de vida”, con una secuencia                de un resultado único, en unas fechas
     de tipo: concepto, requisitos, diseño,                      previstas y con unos recursos previstos de
     planificación, desarrollo, cierre.                          antemano.
                                                                La profesionalización de la gestión de
                                                                 proyectos surgió en los 50 para dar respuesta
                                                                 a las necesidades de la industria militar, y en
                                                                 los años posteriores el resto de industrias han
                                                                 adoptado sus principios.
                                                                Las organizaciones más conocidas por la
                                                                 investigación, y creación de comunidades
                                                                 profesionales para la gestión de proyectos
                                                                 son: PMI (Project Management Institute),
                                                                 Internacional      Project        Management
                                                                 Association (IPMA) y Prince2.
                                                                Características de la gestión de proyectos
                                                                 desarrollada en la segunda mitad del siglo
                                                                 pasado:


    2005-2009 – ScrumManager - http://www.scrummanager.net                                                       17
Origen de la gestión de proyectos


      Gestión      basada    en   la   aplicación
       sistemática de procesos repetibles y
       escalables.
      Los criterios de éxito de un proyecto son:
       calidad, costes y fechas.
      Carácter predictivo: ejecución según el
       plan inicial previsto.
      Desarrollo sobre un entorno estable.
      El objetivo de la gestión es: desarrollar un
       plan, y mantener el cronograma y los
       recursos planificados.
      Ciclo de vida compuesto por fases
       secuenciales.




18      2005-2009 – ScrumManager - http://www.scrummanager.net
El nuevo escenario
Scrum Manager Proyecto Apuntes
El nuevo escenario


                                                             División del trabajo, especialización y producción
                                                             basada en procesos, fueron premisas que, como

Escenario de desarrollo en                                   axiomáticas, asumió la gestión de proyectos, y
                                                             por esta razón, los puntos clave de la gestión

los 80
                                                             predictiva o clásica son:

                                                                Estimar cuál va a ser el trabajo necesario, y a
                                                                 continuación gestionar la ejecución para que
En los 80, el ciclo de vida de los proyectos era el              se cumplan la estimación inicial.
denominado en cascada: el proyecto se divide en                 El trabajo se desarrolla en fases.
fases, y éstas se ejecutan de forma secuencial:                 División del trabajo en equipos de
definición del producto, diseño, construcción de                 especialistas.
elementos, integración, pruebas…                                Desarrollo basado en procesos.

Dos características de la construcción de nuevos
productos en esta década son:

    Ciclo de vida secuencial.
    División y especialización del trabajo.




                                                             The New New                            Product
                                                             Development Game
                                                             Es el título del artículo publicado en 1986 por
                                                             Hirotaka Takeuchi e Ikujijo Nonaka; que a su vez
Cada fase la realiza un departamento, personas o             daba continuación a otro anterior de los mismos
equipos diferentes, profesionalmente especiali-              autores junto con Kenichi Imai: “Managing the
zados en los conocimientos necesarios.                       New Product Development Process: How
                                                             Japanese Companies Learn and Unlearn”.
La gestión de proyectos desarrolla modelos de
estructuras organizativas de tipo matricial, con             La publicación de “The New New Product
diferentes variaciones, para facilitar la comunica-          Development Game” ha marcado el punto de
ción y coordinación entre equipos diferentes.                inicio de una nueva forma de gestionar proyectos
                                                             en entornos rápidos e inestables.
En las mismas fechas, a la par de la consolida-
ción del conocimiento de gestión de proyectos, se            Cuando la teoría de gestión de proyectos estaba
estaban desarrollando las teorías de producción              alcanzando una cierta madurez, los autores ob-
basada en procesos, promovidas por Michel                    servaron que algunas empresas, en mercados
Hammer, como mejor medio para garantizar la                  muy competitivos, relacionados con productos de
calidad, eficiencia y repetitividad.                         vanguardia tecnológica, trabajaban ignorando esa
                                                             teoría.

                                                             “Muchas compañías han descubierto que para
                                                             mantenerse en el actual mercado competitivo
                                                             necesitan algo más que los conceptos básicos de
                                                             calidad elevada, costes reducidos y diferen-
                                                             ciación. Además de esto, también es necesario
                                                             velocidad y flexibilidad.”
                                                             “En 1981 las encuestas realizadas a 700
                                                             empresas americanas revelan que el 30% de sus
                                                             beneficios se debe a nuevos productos”.




    2005-2009 – ScrumManager - http://www.scrummanager.net                                                   21
El nuevo escenario


Hasta entonces, el desarrollo de nuevos produc-                   La cámara Canon AE-1 (1976)
tos se realizaba como una carrera de relevos, en                  Cámara Canon Auto Boy (1979).
la que un grupo de especialistas funcionales
pasaban el relevo al siguiente.                                En estas empresas el trabajo no recorría fases a
El proyecto avanzaba secuencialmente de fase                   través de diferentes equipos especializados.
en fase: creación del concepto, pruebas de viabi-
lidad, diseño del producto, diseño del proceso,                “El producto emerge de la interacción constante
desarrollo de prototipo y producción final.                    de un equipo de élite, multidisciplinario que
                                                               trabaja conjuntamente desde el principio hasta el
Es un modelo de trabajo segmentado por                         final”
especialización de funciones.
La gente de marketing explora y estudia las                    Nonaka y Takeuchi compararon la forma de
necesidades de los clientes, para crear el con-                trabajar de estos equipos únicos y multi-
cepto del producto. Los ingenieros de investi-                 disciplinarios, con los equipos de rugby, y el
gación y desarrollo elaboran un diseño adecuado,               ambiente y entorno de trabajo que les
los ingenieros de producción llevan a cabo la                  proporcionaba la empresa lo llamaron “campo de
                                                                       1
solución técnica…                                              scrum ”.


                                                               Características                 del          nuevo
La figura siguiente representa el ciclo de vida al
construir un producto con un patrón de gestión
secuencial, y cuál es la diferencia con la nueva
forma, observada por Nonaka y Takeuchi en
empresas que ignoraban los principios de la
                                                               escenario
gestión clásica de proyectos.




                                                               En los 40, 50 y 60 los productos tardaban años en
                                                               quedar obsoletos, y las empresas los producían
Los desarrollos secuenciales puros suelen ser                  con variaciones mínimas a lo largo del tiempo.
más teóricos que prácticos, y en realidad quienes
los adoptan, generalmente producen ciclos                      Apple ha desarrollado 6 versiones de su popular
“secuenciales con solapamiento”, donde una fase                iPod, en sólo 6 años.
no suele necesitar para empezar que esté
completamente terminada la anterior.                           Hoy determinados productos permanecen en un
                                                               continuo estado “beta”. El entorno tecnológico es
Nonaka y Takeuchi observaron que empresas                      tan inestable, que las novedades se lanzan tras el
americanas y japonesas tecnológicas, de primera                menor tiempo de desarrollo posible, dejando que
línea, que aventajaban a sus competidores en                   vayan evolucionando a través de versiones, en el
innovación y rapidez, compartían pautas de                     propio mercado. Que sea éste quien diga de
trabajo comunes, ajenas al clásico patrón secuen-              forma continua cómo deben modificarse los
cial.                                                          “requisitos”.

Analizaron la forma de trabajo de: Fuji-Xerox,                 En estas circunstancias, las diferencias de lide-
Canon, Honda, Nec, Epson, Brother, 3M, Xerox y                 razgo entre unas empresas y otras no radica
Hewlett-Packard y en concreto la forma en la que               tanto en la eficiencia y previsibilidad con la que se
abordaban el desarrollo de 6 productos:                        gestionan el lanzamiento de nuevos productos,
                                                               sino en la capacidad de agilidad y cambio durante
    La fotocopiadora Fuji-Xerox FX-3500. (1978)               su construcción; y el principal valor para ocupar
    La copiadora personal Canon PC-10 (1982)                  puestos de cabeza es la innovación.
    El coche urbano de 1200cc de Honda (1981)                 1
    El ordenador personal NEC PC 8000 (1979)                   Scrum es un término empleado en rugby para definir una
                                                               determinada formación del equipo.

22      2005-2009 – Navegapolis - http://www.navegapolis.net
El nuevo escenario



Campos de scrum vs.
                                                              regularmente incrementos de funcionalidad que
                                                              incrementan el valor al producto.


modelo clásico de                                             Fases de desarrollo solapadas
desarrollo                                                    El concepto de “fase” que implica un trabajo
                                                              secuencial, se cambia ahora por el de “actividad”.
                                                              Requisitos, análisis, diseño, desarrollo no son
Estos son los principales contrastes               que        fases ejecutadas en un orden determinado. Son
diferencian el desarrollo tradicional del ágil:               actividades que se pueden realizar en cualquier
                                                              momento, de forma simultánea; “a demanda”
                                                              cuando las necesita el equipo.

                                                              En el ciclo de vida secuencial de software se
                                                              habla de “modificación de requisitos”.
                                                              Este término lleva implícito el concepto de que
                                                              estamos “cambiando” algo que quedó cerrado en
                                                              la fase de requisitos.
                                                              En el desarrollo ágil, los requisitos evolucionan,
                                                              se desarrollan y enriquecen durante todo el ciclo
                                                              de vida, igual que el diseño y el código.

                                                              Takeuchi y Nonaka observaron dos tipos de
                                                                                                               2
                                                              solapamiento: uno que denominaron “sashimi ”
No lo realizan equipos diferentes especializados.             estableciendo analogía con el plato típico japonés
Es un equipo único, formado por personas muy                  porque se produce un solapamiento bastante
competentes, con perfiles y conocimientos que                 amplio, de tal forma, que en cualquier punto del
cubren las disciplinas necesarias para llevar a               ciclo de vida, se encuentran de forma simultánea
                                                                                                              3
cabo el trabajo.                                              varias fases; y otro que denominaron “rugby ”,
                                                              que deja perdido por completo el concepto de
No hay fases. En realidad las fases pasan a ser               fases, y en el que el equipo trabaja
tareas que se ejecutan cuando se necesitan.                   concurrentemente en todas las actividades desde
No se hace primero el diseño del concepto o los               el primer día.
requisitos, más tarde el análisis, luego el
desarrollo, etc.                                              En el solapamiento “sashimi” aún se mantiene el
Lo que aplicado al software serían las fases de:              concepto de fase, aunque con un solapamiento
requisitos del sistema, requisitos del software,              muy amplio.
análisis, diseño, construcción, pruebas e inte-
gración; y se ejecutarían de forma secuencial,
pasan a tareas que se llevan a cabo en el mo-
mento que hacen falta. Normalmente a lo largo de
pequeñas iteraciones durante todo el desarrollo.              En el solapamiento “rugby” no son ya fases, sino
                                                              definitivamente tareas.
No se espera a disponer de requisitos detallados
para comenzar el análisis, ni a tener éste para               En el desarrollo tradicional:
pasar a la codificación. Muchas veces los requi-               Las transiciones entre fases, acaban
sitos no se pueden conocer si no avanza el                        funcionando como fronteras. Cada equipo se
desarrollo y se va viendo y “tocando” el resultado.               siente responsable de su parte de trabajo, de
Otras veces el mercado es tan rápido que a mitad                  lo que debe entregar a la siguiente fase, pero
de trabajo las tendencias o la competencia                        no del resultado final.
obligarán a modificar el producto.                             Los documentos de diseño, los requisitos o
Además, la participación de todo el equipo en el                  los prototipos pueden acabar siendo
diseño aporta gran cantidad de talento innovador;                 barricadas en la frontera de cada fase, que
un valor clave en el mercado de productos y                       lejos favorecer la comunicación directa
servicios TIC.                                                    fomentan la fragmentación.

Los equipos ágiles empiezan a trabajar sin                    2
                                                                Nombre que dieron al tipo de solapamiento uqe empleaba el
conocer con detalle cómo será el producto final.              equipo de desarrollo de la FX-3500 en Fuji-Xerox.
Parten de la visión general, y sobre ella, producen           3
                                                                Con este nombre denominaron a la combinación simultánea
                                                              de todas las fases desde el primer día, empleada por los
                                                              equipo de Honda.

  2005-2009 – ScrumManager - http://www.scrummanager.net                                                             23
El nuevo escenario


    Los retrasos de cada fase son cuellos de                     Auto-superación. El equipo va desarrollando
     botella del proyecto. El solapamiento diluye el               soluciones, que evalúa, analiza y mejora.
     ruido y los problemas entre fases.                           Auto-enriquecimiento. La multi-disciplinaridad
                                                                   del equipo favorece el enriquecimiento mutuo
                                                                   y la aportación de soluciones valiosas

Características del “campo                                         complementarias.


de scrum”                                                      Control sutil
                                                               El equipo dispone de autonomía, pero no debe
Las características “ambientales” en las empresas              derivar en caos.
que desarrollan los nuevos productos con                       La gestión establece puntos de control suficientes
modelos de gestión ágil son:                                   para evitar que el escenario de ambigüedad,
                                                               inestabilidad y tensión del “campo de scrum”
    Incertidumbre consustancial al entorno y la               evolucione hacia el descontrol.
     cultura de la organización.
    Equipos auto-organizados.                                 Pero debe gestionarse sin un control rígido que
    Control sutil.                                            impediría la creatividad y la espontaneidad.
    Difusión y transferencia del conocimiento.                El término “control sutil” se refiere a la creación de
                                                               un ecosistema que potencia y desarrolla el “auto-

Incertidumbre
                                                               control entre iguales”, como consecuencia de la
                                                               responsabilidad y del gusto por el trabajo
                                                               realizado.
Se trabaja en entornos de incertidumbre consus-
tancial.                                                       Algunas acciones para generar este ecosistema
En estas empresas, la dirección apunta cuál es la              son:
meta genérica a la que se pretende arribar, o la
dirección estratégica que hay que seguir. No se                   Selección de las personas adecuadas para el
proporciona el plan detallado del producto.                        proyecto.
Al mismo tiempo se dá al equipo un margen de                      Análisis de los cambios en la dinámica del
amplia libertad.                                                   grupo para incorporar o retirar a miembros si
Los ingredientes que sirven de acicate para la                     resulta necesario.
creatividad y el compromiso son:                                  Creación de un espacio de trabajo abierto.
                                                                  Animar a los ingenieros a “mezclarse” con el
    La “tensión” que crea la visión difusa y el reto              mundo real de las necesidades de los
     que supone el grado de dificultad que                         clientes.
     encierra.                                                    Sistemas de evaluación y reconocimiento
    El margen de autonomía, libertad y                            basados en el rendimiento del equipo.
     responsabilidad.                                             Gestión de las diferencias de ritmo a través
                                                                   del proceso de desarrollo.

Auto-organización                                                 Tolerancia y previsión con los errores;
                                                                   considerando que son un medio de
                                                                   aprendizaje, y que el miedo al error merma la
Son equipos auto-organizados, sin roles de
                                                                   creatividad y la espontaneidad.
gestión ni pautas de asignación de tareas.
                                                                  Implicar a los proveedores en el proyecto y
No se trata de equipos auto-dirigidos, sino auto-
                                                                   animarles a su propia auto-organización.
organizados. La gestión es la que marca la
dirección, pero no la organización.

Parten de cero. Deben empezar por crear su pro-
                                                               Difusión y transferencia del
pia organización y buscar el conocimiento que
necesitan.                                                     conocimiento
Son similares a una “Start-up” que comienza.                   Tanto a nivel de proyecto como de organización.
Para lograr la auto-organización los equipos                   Los equipos son multidisciplinarios, y todos los
deben reunir tres características:                             miembros aportan y aprenden:
    Autonomía. Son libres para elegir la                         del resto del equipo,
     estrategia de la solución. En este sentido la
     dirección de la empresa actúa como un
     capitalista de capital-riesgo.

24      2005-2009 – Navegapolis - http://www.navegapolis.net
El nuevo escenario


    de las investigaciones para mejorar el valor y             Características ambientales en estos entor-
     el componente innovador que espera el                       nos llamados “campos de scrum”
     cliente,                                                     Incertidumbre
    de la experiencia del desarrollo.                            Auto-organización
                                                                  Control sutil
Las personas que participan en un proyecto, con                   Difusión del conocimiento
el tiempo pasan a otros equipos y proyectos de la                 Fases de desarrollo solapadas
empresa, de manera que comparten y comunican
el conocimiento a lo largo de toda la organización.

Los equipos y las empresas mantienen libre
acceso a la información, herramientas y políticas
de gestión del conocimiento




Resumen
    Hasta los 80, para el desarrollo de nuevos
     productos se empleaban:
      Ciclos de vida secuencial.
      División y especialización del trabajo.
    En los 80 se desarrolla la teoría de
     producción basada en procesos para propor-
     cionar eficiencia calidad y repetibilidad.
    En esos años, algunas empresas de tecno-
     logía (Caon, Fuji-Xerox, Honda, Epson, HP,
     etc.) logran más valor y mejores resultados en
     el desarrollo de nuevos productos, desafiando
     al desarrollo secuencial y a la división del
     trabajo.
    Nonaka y Takeuchi son los primeros en
     identificar estos nuevos entornos de produc-
     ción a los que denominan “campos de scrum”
     en el artículo The New New Product Develop-
     ment Game”.
    Las principales diferencias con el desarrollo
     tradicional de producto son:
      No trabajan departamentos especializa-
         dos, sino un único equipo multi-
         disciplinario.
      Solapamiento de las fases del desarrollo.
      No se parte de unos requisitos detallados
         sino de la visión del resultado.
      No se sigue un plan pre-elaborado.



    2005-2009 – ScrumManager - http://www.scrummanager.net                                               25
Scrum Manager Proyecto Apuntes
Gestión de proyectos ágil
                  Conceptos
Scrum Manager Proyecto Apuntes
Gestión de proyectos ágil: conceptos


                                                           Su objetivo es dar el mayor valor posible al
                                                           producto, cuando éste se basa en:

Introducción                                                  Innovación
                                                              Flexibilidad
Muchas empresas trabajan en escenarios que se
parecen ya muy poco a los que impulsaron la                La permanencia de estas empresas depende de
gestión de proyectos predictiva       y necesitan          su capacidad de innovación continua. Del
estrategias    diferentes   para    gestionar     el       lanzamiento continuo de novedades, que com-
lanzamiento de sus productos: estrategias orien-           piten con los productos de otras empresas que
tadas a la entrega temprana de resultados tan-             también están en continua innovación.
gibles, y con la suficiente agilidad y flexibilidad
para trabajar en entornos inestables y rápidos.            Flexibilidad.
                                                           El producto no sólo es valioso por su valor en el
Ahora necesitan construir el producto al mismo             momento de su lanzamiento, sino también por su
tiempo que cambian y aparecen nuevos requisi-              capacidad de adaptación y evolución a través de
tos; y como las circunstancias de los mercados y           actualizaciones y ampliaciones.
de las empresas no se pueden cambiar, son las
formas en las que gestionan sus proyectos las
que tienen que cambiar para dar respuesta a las
nuevas necesidades.                                        2.-Reducción del tiempo de
El cliente conoce la visión de su producto pero            salida al mercado
por la novedad, el valor de innovación que
necesita y la velocidad a la que se va a mover el          En la década de los 90, el tiempo medio de salida
escenario tecnológico y de negocio, durante el             al mercado de los nuevos productos en EE.UU.
                                                                                         4
desarrollo, no puede detallar cómo será el                 se redujo de 35,5 a 11 meses
producto final.
                                                           Este tiempo es un factor competitivo clave en
¡Ah!. Pero, ¿existe el producto final?.                    determinados sectores.

Quizá ya no hay “productos finales”, sino                  Las estrategias de la gestión ágil para producir
productos en evolución, mejora o incremento                resultados en menos tiempo que la gestión
continuo, desde la primera versión beta.                   tradicional son:

                                                              Solapamiento de las fases de desarrollo.
                                                              Entrega temprana de las primeras partes del
   El resultado es la gestión ágil de                          producto, que corresponden con las de mayor
   proyectos, que no se formula sobre el                       urgencia para el cliente, de forma que puede
   concepto de anticipación (requisitos,                       lanzar la primera versión en el menor tiempo
   diseño, planificación y seguimiento) sino                   posible.
   sobre    el    de   adaptación    (visión,
   exploración y adaptación)
                                                           3.-Agilidad
                                                           Capacidad para producir partes completas del
                                                           producto en periodos breves de tiempo

Objetivos de la gestión ágil                               4.-Flexibilidad
La gestión ágil de proyectos tiene como objetivo           Capacidad para adaptar la forma y el curso del
dar garantías a las demandas principales de la             desarrollo a las características del proyecto, y a la
industria actual: valor, reducción del tiempo de
                                                           evolución de los requisitos.
desarrollo, agilidad, flexibilidad y fiabilidad.


1.-Valor
La gestión ágil se necesita en los mercados
rápidos.                                                   4
                                                             Wujec, Tom, and Sandra Muscat. Return on Imagination:
                                                           Realizing the Power of Ideas, London: Financial Times
                                                           Prentice Hall, 2002

  2005-2009 – ScrumManager - http://www.scrummanager.net                                                      29
Gestión de proyectos ágil: conceptos



5.- Resultados fiables                                          El ciclo de desarrollo ágil
El objetivo de la gestión predictiva es ejecutar el
trabajo planificado (y conocido de antemano) en
el plazo planificado y por el coste previsto.

La gestión ágil no tiene un carácter predictivo o
de anticipación. No conoce de antemano el de-
talle del producto que va a desarrollar, y por eso
su objetivo no es fiabilidad en el cumplimiento de
los planes, sino en el valor del resultado.

Los procesos de la gestión tradicional son buenos
cuando consiguen desarrollar de forma repetible
los productos especificados en el tiempo y con los
costes previstos.

Los procesos de la gestión ágil son buenos,                     El desarrollo ágil parte de la visión, del concepto
cuando consiguen entregar de forma temprana y                   general del producto, y sobre ella el equipo
continua un valor innovador.                                    produce de forma continua incrementos en la
                                                                dirección apuntada por la visión; y en el orden de
                                                                prioridad que necesita el negocio del cliente.

Las preferencias de la                                          Los ciclos breves de desarrollo, se denominan
                                                                iteraciones y se realizan hasta que se decide no
gestión ágil                                                    evolucionar más el producto.

                                                                Este esquema está formado por cinco fases:
La gestión ágil, a diferencia de la tradicional,
muestra las preferencias resumidas en el                        1.- Concepto
manifiesto ágil:                                                2.- Especulación
                                                                3.- Exploración
1.- La capacidad de respuesta al cambio,                        4.- Revisión
sobre el seguimiento de un plan.                                5.- Cierre


                                                                1.- Concepto
2.- Los productos que funcionan frente a
especificaciones y documentaciones inne-
cesarias.
                                                                En esta fase se crea la visión del producto y se
3.- La colaboración con el cliente frente a la                  determina el equipo que lo llevará a cabo.
negociación contractual.
                                                                Partir sin una visión genera esfuerzo baldío.
4.- A las personas y su interacción por encima                  La visión es un factor crítico para el éxito del
de los procesos y las herramientas.                             proyecto.
                                                                Se necesita tener el concepto de lo que se quiere,
                                                                y conocer el alcance del proyecto. Es además
                                                                una información que deben compartir todos los
                                                                miembros del equipo




30     2005-2009 – ScrumManager - http://www.scrummanager.net
Gestión de proyectos ágil: conceptos



2.- Especulación                                             4.- Revisión
Una vez que se sabe qué hay que construir, el                Equipo y usuarios revisan lo construido hasta ese
equipo especula y formula hipótesis basadas en               momento.
la información de la visión, que per se es muy               Trabajan y operan con el producto real
general e insuficiente para determinar las                   contrastando su alineación con el objetivo.
implicaciones de un desarrollo (requisitos, diseño,
costes…).

En esta fase se determinan las limitaciones
impuestas por el entorno de negocio: costes y
agendas principalmente, y se cierra la primera
aproximación de lo que se puede producir.

La gestión ágil investiga y construye a partir de la
visión del producto. Durante el desarrollo
confronta las partes terminadas: su valor, posi-
bilidades, y la situación del entorno en cada
momento.


                                                             5.- Cierre
La fase de especulación se repite en cada
iteración, y teniendo como referencia la visión y el
alcance del proyecto consiste en:
                                                             Al llegar a la fecha de entrega de una versión de
    Desarrollo y revisión de los requisitos                 producto (fijada en la fase de concepto y revisada
     generales.                                              en las diferentes fases de especulación), se
    Mantenimiento de una lista con las                      obtiene el producto esperado.
     funcionalidades esperadas.
    Mantenimiento de un plan de entrega: fechas             Posiblemente éste seguirá en el mercado, y por
     en las que se necesitan las versiones, hitos e          emplear gestión ágil, es presumible que se trata
     iteraciones del desarrollo. Este plan refleja ya        de un producto que necesita versiones y mejoras
     el esfuerzo que consumirá el proyecto                   frecuentes para no quedar obsoleto. El cierre no
     durante el tiempo.                                      implica el fin del proyecto.
    En función de las características del modelo
     de gestión y del proyecto puede incluir                 Lo que se denomina “mantenimiento” supondrá la
     también una estrategia o planes para la                 continuidad del proyecto en ciclos incrementales
     gestión de riesgos.                                     hacia la siguiente versión para ir acercándose a la
                                                             visión del producto.
Si las exigencias formales de la organización lo
requieren, también se produce información admi-
nistrativa y financiera.
                                                             Principales modelos de
                                                             gestión ágil
                                                             Si hubiera que determinar cuál es el origen de la
                                                             gestión ágil de proyectos, a falta de mejor infor-
                                                             mación, habría que situarlo en las prácticas adop-
                                                             tadas en los 80 por empresas como Honda, 3M,
                                                             Canon, Fuji, Nec, Xerox, hp o Epson para el
                                                                                            5
                                                             desarrollo de nuevos productos .



3.- Exploración
                                                             La industria del software ha sido la primera en
                                                             seguir su adopción, y muchos de sus
                                                             profesionales han documentado y propagado las
Se desarrolla un incremento del producto, que                formas particulares en las que han implementado
incluye las funcionalidades determinadas en la
fase anterior.                                               5
                                                              Hirotaka Takeuchi e Ikujiro Nonaka, 1986 “The New New
                                                             Development Game”

    2005-2009 – ScrumManager - http://www.scrummanager.net                                                     31
Gestión de proyectos ágil: conceptos


los principios de la agilidad en sus equipos de                  ESPECULACIÓN, compuesta por 5 pasos:
trabajo.                                                         1.- Inicio para determinar la misión del proyecto.
De esta forma han aparecido en las últimas                       2.- Fijación del marco temporal del proyecto.
décadas los nombres:                                             3.- Determinación del nº de iteraciones y la
                                                                 duración de cada una.
    AD - Agile Database Techniques                              4.- Definición del objetivo de cada iteración.
    AM - Agile Modeling                                         5.- Asignación de funcionalidad a cada iteración.
    ASD - Adaptive Software Development
    AUP - Agile Unified Process                                 COLABORACIÓN
    Crystal                                                     Desarrollo concurrente del trabajo de cons-
    FDD - Feature Driven Development                            trucción y gestión del producto.
    DSDM - Dynamic Systems Development
     Method                                                      APRENDIZAJE
    Lean Software Development                                   En cada iteración se revisa:
    Scrum                                                        Calidad, con criterios de cliente.
    TDD - Test-Driven Design                                     Calidad, con criterios técnicos.
    XBreed                                                       Funcionalidad desarrollada.
    XP - eXtreme Programming                                     Estado del proyecto.

Éstos son los modelos que se encuentran                          Las características básicas de ASD son:
inscritos en la organización Agile Alliance                       Trabajo orientado y guiado por la misión del
(www.agilealliance.org) para promocionar y                           proyecto.
difundir su conocimiento.                                         Basado en la funcionalidad.
                                                                  Desarrollo iterativo.
Cada una de ellos expone formas concretas de                      Desarrollo acotado temporalmente.
aplicación de principios ágiles en el desarrollo de               Guiado por los riesgos.
software.                                                         Trabajo tolerante al cambio.
Algunos determinan cómo realizar las pruebas, o

                                                                 AUP
la duración que emplean para desarrollar cada
iteración, o el protocolo para realizar las
reuniones de trabajo.
                                                                 Agile Unified Process es una versión simplificada
Unos métodos cubren áreas concretas de la                        de Rational Unified Process, desarrollada por
ingeniería del software (diseño, desarrollo                      Scott Amber.
pruebas), como es caso de AD, AM o XP, y otros
se centran en la gestión del proyecto.                           Divide el ciclo de desarrollo en 4 fases:

Éstos últimos son:                                               INICIO: identificación del alcance y dimensión del
                                                                 proyecto, propuesta de la arquitectura y del
    ASD - Adaptive Software Development                         presupuesto del cliente.
    AUP - Agile Unified Process                                 ELABORACIÓN: Confirmación de la idoneidad de
    Crystal                                                     la arquitectura.
    DSDM - Dynamic Systems Development                          CONSTRUCCIÓN: Desarrollo incremental del
     Method                                                      sistema, siguiendo las prioridades funcionales de
    Scrum                                                       los implicados.
    XBreed                                                      TRANSICIÓN: Validación e implantación del
                                                                 sistema.
Por ejemplo, el principio de desarrollo ágil
iterativo e incremental, tiene reflejo en ciclos de
30 días empleados por scrum, o de entre 1 y 4                    CRYSTAL
meses empleado por los modelos Cristal.
                                                                 Concebido por Alistair Cockburn, este modelo no
                                                                 describe una metodología cerrada, sino un
ASD                                                              conjunto de ellas, junto con los criterios para
                                                                 seleccionar y adecuar la más apropiada al
Adaptive Software Development es el modelo de                    proyecto. Los parámetros para determinarla son
implementación de patrones ágiles para de-                       la criticidad y el tamaño del sistema que se va a
sarrollo de software, diseñado por Jim Highsmith,                construir.
que materializa las fases de la gestión ágil de la
siguiente forma:



32      2005-2009 – ScrumManager - http://www.scrummanager.net
Gestión de proyectos ágil: conceptos



                                                             Es un modelo que estuvo representado en la
                                                             firma del Manifiesto Ágil: Arie van Bennekum,
                                                             firmante del manifiesto, era miembro del
                                                             consorcio en Benelux, consultor y formador de
                                                             DSDM.

                                                             En 2001, año del Manifiesto Ágil, DSDM publicó
                                                             la versión 4.1 de su modelo, y se consideró una
                                                             metodología ágil; y aunque mantuvo las siglas,
                                                             cambió la denominación original (Dynamis
                                                             Systems Development Method) por Framework
                                                             for Business Centred Development.

                                                             Procesos del ciclo de desarrollo DSDM

                                                             El ciclo de desarrollo de DSDM está compuesto
Los criterios empleados para la medición de estos            de 5 fases, precedidas de un pre-proyecto y un
parámetros son:                                              post-proyecto.

Criticidad (dimensión de las pérdidas que                        1.   Pre-proyecto
ocasionaría un malfuncionamiento del sistema)                    2.   Estudio de viabilidad
                                                                 3.   Estudio de negocio
1 (c): Pérdida de confort o usabilidad.                          4.   Iteración de modelado funcional
2 (d): Pérdidas económicas moderadas.                            5.   Iteración de diseño y desarrollo
3 (e): Pérdidas económicas graves.                               6.   Implementación
4 (l): Pérdida de vidas humanas.                                 7.   Post-desarrollo

Estos criterios corresponden a los niveles de
integridad de un sistema definidos por el estándar
IEEE 1012-1998.


Dimensión.
Crystal determina el tamaño del sistema por el nº
de personas empleadas en su desarrollo. (6 - 20 -
40 - 80)

Fundamentos de Crystal:

    Desarrollo iterativo e incremental.
    Duración máxima de una iteración: 4 meses.
     Recomienda duraciones entre 1 y 3 meses.
    Especial énfasis en la importancia de las


     personas sobre los procesos.
     Especial énfasis en la comunicación directa.
                                                             SCRUM
    Modelo abierto a la adaptación e introducción           Jeff Sutherland en 1993 trabajaba en Easel
     de prácticas de otros modelos ágiles                    Corporation (compañía que en los macrojuegos
     (eXtreme Programming, Scrum...)                         de compras y fusiones se integraría en VMARK, y
                                                             luego en Informix y finalmente en Ascential

DSDM
                                                             Software Corporation). Tras conocer el trabajo de
                                                             Nonaka y Takeuchi, Jeff identificó paralelismos
                                                             con la industria del software, y aplicó un modelo
DSDM es el acrónimo que dá nombre a un                       de desarrollo ágil, iterativo e incremental para
modelo de procesos para desarrollo de sistemas               desarrollar y mantener sistemas de software.
de software, concebido por el DSDM Consortium,
que se fundó en Inglaterra en 1994, y que                    En 1996 lo presentó junto con Ken Schwaber
actualmente tiene presencia en Inglaterra,                   como proceso formal para gestión del desarrollo
EE.UU., Benelux, Dinamarca, Francia y Suiza; y               de software en OOPSLA 96, con el nombre que
con    interés   y   contactos      para   futuras           Nonaka y Takeuchi habían dado a estos equipos
representaciones en Australia, India y China [...]


    2005-2009 – ScrumManager - http://www.scrummanager.net                                                 33
Gestión de proyectos ágil: conceptos


de trabajo: "Scrum", por la comparación que                         La gestión ágil se basa en los principios del
                                  6
hicieron con los equipos de Rugby                                    manifiesto ágil y centra el valor:
                                                                      Más en las personas y su interacción que
                                                                        en los procesos y las herramientas
                                                                      Más en los resultados que funcionan que
                                                                        en la documentación exhaustiva
                                                                      Más en la colaboración con el cliente que
                                                                        en la negociación contractual
                                                                      Más en la capacidad de respuesta al
                                                                        cambio que en el seguimiento de un plan

                                                                    El desarrollo ágil comprende cinco fases:
                                                                     concepto, especulación, exploración, revisión
                                                                     y cierre.

                                                                    El desarrollo ágil surgió en empresas de
Se basa en el principio ágil de desarrollo iterativo
                                                                     productos tecnológicos, fue identificado por
e incremental.
                                                                     Nonaka y Takeuchi en los años 80 y a partir
Al período de trabajo para desarrollar un
                                                                     de los 90 diferentes profesionales del
incremento de producto se lo denomina “sprint”, y
                                                                     desarrollo del software incorporaron sus
se recomienda una duración de 30 días, si bien
                                                                     principios en sus entornos de trabajo.
pueden contemplarse casos de hasta 60 días
                                                                     De esas implementaciones ágiles, las que
(según Ken Schwaber, o 45 según Jeff
                                                                     abordan la gestión del proyecto son: ASD,
Shuterland).
                                                                     AUP, Crystal, DSDM, Scrum.
Establece una reunión al inicio de cada sprint
para determinar el trabajo que se va a realizar,
otra al final para evaluar el resultado, y revisiones
diarias que realiza el equipo en su auto-gestión.


XBreed – Agile Enterprise
Propuesto por Mike Breedle, que colaboró con
Ken Schwaber en la definición de Scrum, es una
combinación de Scrum para la gestión del
proyecto, y Extreme Programming como prácticas
de desarrollo.

Esta es una combinación comúnmente empleada
independientemente de su definición como
Xbreed que hasta la fecha no ha tenido especial
relevancia.   También     denominado     “Agile
Enterprise”.



Resumen
    La gestión ágil de proyectos no es una
     gestión de anticipación (requisitos, diseño,
     planificación y seguimiento) sino de adap-
     tación (visión, exploración y adaptación).

    La gestión ágil tiene como objetivos: valor,
     reducción del tiempo de desarrollo, agilidad,
     flexibilidad y fiabilidad.



6
  Scrum es el nombre que se dá en Rugby a una determinada
formación del equipo.

34      2005-2009 – ScrumManager - http://www.scrummanager.net
Gestión de proyectos: ¿formal o ágil?
Scrum Manager Proyecto Apuntes
Gestión de proyectos: ¿formal o ágil?




¿Ágil, clásica, predictiva …?
Al surgir en los 80 una nueva forma de gestionar
proyectos, se hizo necesario añadir un “apellido”
al término “gestión de proyectos” para matizar si
se refiere a la nueva o a la de siempre.

La nueva, al autodenominarse ágil, obligó a dar
un apellido al modelo de gestión de proyectos que
hasta entonces, por único, no lo había nece-
sitado.
                                                           Características de la gestión
Las denominaciones empleadas para cada tipo
son:
                                                           de proyectos predictiva
                                                           Estas premisas han dado dos características a la
                               Clásica                     gestión de proyectos predictiva:
                               Tradicional
  Gestión de proyectos         Predictiva                  1.- Universalidad
                               Formal                      Los proyectos, pese a su diversidad, comparten
                               Pesada                      patrones comunes de ejecución.
                                                           Las prácticas de gestión se basan en estos
                                                           patrones comunes y resultan válidas para
                                                           cualquier tipo de proyecto.
                               Ágil
  Gestión de proyectos         Adaptable
                               Adaptativa

En algunos ámbitos, hay cierta rivalidad acadé-
mica o profesional entre defensores de uno y otro
modelo. Preferimos por tanto no emplear el
término “pesado” que puede aportar connota-
ciones peyorativas.

También preferimos no emplear “adaptativa” y
usar en su lugar “adaptable”, para evitar un
anglicismo innecesario.                                    2.- Carácter predictivo
                                                           La gestión clásica define con detalle cuál es el
                                                           “producto previsto” y elabora un plan de
Premisas de la gestión de                                  desarrollo, a partir del cual calcula costes y
                                                           fechas.

proyectos predictiva
                                                           Durante la ejecución realiza actividades de
                                                           seguimiento y vigilancia para evitar desviaciones
                                                           sobre lo planificado.
Premisas sobre las que se desarrolló la gestión

                                                           Hay otras premisas
de proyectos tradicional:

1.- Todos los proyectos mantienen caracterís-
ticas y comportamientos regulares (Meter
Norden 1960)                                               Las dos premisas que cimentan el desarrollo de la
                                                           gestión de proyectos:
2.- El objetivo de la ejecución de un proyecto              Todos los proyectos comparten idénticos
es lograr el producto previsto en el tiempo                    patrones de ejecución.
planificado    sin    desbordar   los   costes              El objetivo es conseguir el producto definido
estimados.                                                     en costes y fechas.
                                                            son cuestionables:




  2005-2009 – ScrumManager - http://www.scrummanager.net                                                 37
Gestión de proyectos: ¿formal o ágil?


     1.- No hay una forma única y válida para                   Se pedía un proyecto, pero no se quería
     gestionar cualquier tipo de proyecto                       garantizar la ejecución de un plan, sino obtener el
                                                                máximo valor en las líneas marcadas.

Es cierto que muchas características que dife-                  Hay proyectos en los que importa más el valor y
rencian unos proyectos de otros son superficiales               la innovación que el cumplimiento del plan.
y resultan indiferentes para el modelo de gestión;
pero hay otras que permiten adoptar estrategias
de gestión muy diferentes en cada caso.
                                                                    La gestión predictiva pide al equipo el
Características diferenciales:                                      cumplimiento del plan.
                                                                    La gestión adaptable pide al equipo el
     Componente innovador que se espera del                        mayor valor posible para una visión de
      resultado.                                                    producto
     Grado de estabilidad de los requisitos durante
      el desarrollo.
     Coste de prototipado.
     Maleabilidad del producto para modificar su
      funcionalidad una vez desarrollado.

La gestión de proyectos predictiva, al auto-
considerarse válida para cualquier proyecto no
contempla que según las características del
proyecto, puedan resultar más apropiados otros
criterios de gestión.

     Conseguir el mayor valor innovador del
      producto no es uno de sus objetivos, y por
      tanto no aplica prácticas diferentes según el
      grado innovador que se desee.

     Considera que       los   requisitos  deben
      permanecer estables durante la ejecución. Si
      no ocurre esto presupone que se debe a
      deficiencias en el proceso de la fase de
                                                                ¿Cuándo y por qué emplear
      requisitos; porque no contempla posibles
      evoluciones rápidas o inestabilidades del                 uno u otro estilo de gestión?
      entorno tecnológico o de negocio.
                                                                Para obtener los mayores beneficios que cada
     El objetivo es la eficiencia, el cumplimiento             estilo de gestión puede ofrecer, éste tiene que ser
      del plan, y no el valor del producto. Desde               compatible no sólo con las características del
      este punto de vista, el re-trabajo siempre es             proyecto, sino también con las de la organización
      caro. No se considera la relación entre el                que las va a aplicar.
      coste del re-trabajo y el valor proporcionado.


     2.- Hay proyectos en los que no se quiere
                                                                Características del proyecto
     “hacer el producto descrito en las fechas                  Las características relevantes para decidir el
     y con los costes estimados”                                estilo de gestión más adecuado son:

                                                                    Principal prioridad de negocio.
                                                                    Estabilidad de los requisitos.
Cuando en 1978 la dirección de Honda encargó el                     Rigidez del producto.
diseño de un nuevo automóvil, sólo dió dos                          Coste de prototipado.
instrucciones al equipo de ingenieros:                              Criticidad del sistema.
“Primero: necesitamos un concepto de automóvil                      Tamaño del sistema.
completamente diferente a lo que cualquier otra
compañía haya hecho nunca; y segundo: debe                      El orden expuesto se corresponde con nuestro
ser un coche económico, pero no barato”.                        criterio de relevancia, siendo por tanto la prioridad
                                                                de negocio la principal razón de compatibilidad o
El resultado fue el Honda Civic.

38       2005-2009 – Navegapolis - http://www.navegapolis.net
Gestión de proyectos: ¿formal o ágil?


incompatibilidad, y el tamaño del sistema la                 Por supuesto los dos objetivos son deseables,
menos relevante.                                             pero hay que elegir, porque simplemente son
                                                             excluyentes. No se pueden planificar diagramas
Por la relativa novedad de la gestión ágil, estos            de Gantt o rutas críticas sobre una visión general.
criterios no están aún consensuados. Así por
ejemplo mientras algunos textos opinan que el                Cuanto mayor valor se desea en uno u otro
tamaño o la criticidad del sistema son aspectos              extremo (valor o predicción), más contraprodu-
muy relevantes, hay opiniones autorizadas en                 cente resulta emplear el estilo de gestión
sentido contrario:                                           inadecuado.


                                                             Estabilidad de los requisitos
     En la "International Conference on Complex
     Systems 2006", Jeff Sutherland presentó el
     informe "Adaptive Engineering of Large
     Software    Projects   with   Distributed   /           ¿Se puede obtener una descripción de requisitos
     Outsourced Teams " que demostraba los                   detallada al inicio del proyecto, y ésta se man-
     buenos resultados obtenidos con prácticas de            tendrá estable durante el desarrollo?
     gestión ágiles en un desarrollo de grandes
     dimensiones: un millón de líneas de código              O lo que es lo mismo, ¿Se puede saber con cer-
     Java, y un equipo de 50 personas distribuidos           teza y detalle qué es lo que se quiere construir,
     en dos empresas ubicadas en países                      siendo improbable que cambien los criterios o las
     distintos.                                              necesidades?

    El modelo específico de Scrum desarrollado
     por Ken Schwaber para Software contempla                Rigidez del producto
     el desarrollo de sistemas críticos, incluyendo
                                                             ¿Cuán fácil resulta modificar el producto?
     los requerimientos de conformidad también
     como resultados entregables de las
                                                             Esta es una razón importante, porque no es lo
     iteraciones junto con las funcionalidades a las
                                                             mismo modificar software, circuitos electrónicos,
     que afectan.
                                                             construcciones civiles…

                                                             Modificar la estructura de una base de datos para
                                                             añadir algunas tablas no es lo mismo que
                                                             modificar la estructura de un edificio para
                                                             rectificar el número de plantas.


                                                             Coste de prototipado
                                                             Otra cuestión relevante para el modelo de gestión
                                                             ágil es la relación: coste de prototipar / valor
                                                             conseguido para el producto. Este factor suele
                                                             estar relacionado con la rigidez del producto.


Prioridad de negocio                                         Ver, tocar, e interactuar con las partes ya desa-
                                                             rrolladas (o con simulaciones o prototipos) genera
                                                             ideas y posibilidades que sobre el concepto inicial
¿Cuál es la principal prioridad para los intereses
                                                             y el papel no llegan a concebirse.
de negocio del cliente?
¿Qué tiene más importancia: el cumplimiento de
                                                             El prototipado y el feed-back que proporciona son
agendas y fechas o el valor innovador del
                                                             extremadamente importantes, sobre todo en el
producto?
                                                             desarrollo de nuevos productos, o de sistemas
                                                             innovadores.
Este es el primer aspecto que se debe considerar.
La gestión predictiva es un modelo construido y
                                                             A medida que el equipo lo va “tocando” y
especializado en garantizar el cumplimiento de
                                                             “probando” surgen funcionalidades y posibilidades
los planes.
                                                             nuevas que aportan mayor valor al concepto
                                                             inicial.
La gestión adaptable es un modelo construido y
especializado en dar el mayor valor posible al
                                                             En este sentido, el argumento: “la forma más
producto.
                                                             eficiente de desarrollar un trabajo es hacerlo bien
                                                             a la primera”, que se emplea con frecuencia para

    2005-2009 – ScrumManager - http://www.scrummanager.net                                                   39
Gestión de proyectos: ¿formal o ágil?


defender la validez de la gestión predictiva en                   Producirá pérdidas económicas graves.
cualquier proyecto, resulta tendencioso. La                       Producirá pérdidas económicas.
afirmación “per se” es obviamente cierta; pero                    Fallará la finalidad principal del sistema.
también son ciertas dos circunstancias rela-                      Fallarán funcionalidades auxiliares del
cionadas:                                                          sistema.
                                                                  Se producirán fallos ergonómicos o de
    se puede hacer “bien a la primera” cuando es                  comodidad para los usuarios.
     posible conocer con detalle el resultado sin

                                                               Tamaño del sistema
     necesidad de hacer pruebas antes.

    Las posibilidades al hacer un trabajo no son
     sólo “bien” o “mal”. Bien es un término amplio.           Una de las principales bases del desarrollo ágil es
     Puede ser aceptable o suficientemente bien,               la preferencia de la comunicación e interacción
     o lo mejor posible.                                       directa de los implicados en el proyecto.

Estos factores, junto con la relación entre coste              Los grandes proyectos implican equipos nume-
de prototipado y valor que aporta deben tenerse                rosos y en ocasiones físicamente distantes,
también en cuenta para elegir el modelo de                     circunstancias que dificultan la comunicación
gestión más adecuado para el proyecto.                         directa.
                                                               No obstante hay desarrollos incipientes de
                                                               prácticas ágiles que implantan esquemas de
                                                               agrupamiento y comunicación directa en
                                                               estructuras celulares de equipos de hasta 6
                                                               personas.


                                                               Condiciones de la organización
                                                               Los elementos empleados por las organizaciones
                                                               para ejecutar proyectos son: personas, procesos
                                                               y tecnología.

                                                               Los resultados de la gestión ágil dependen más
                                                               del valor de las personas que de los procesos de
                                                               la organización.
Criticidad del sistema                                         Las personas tienen características propias:
¿Cuál es el grado de criticidad del sistema que va
a desarrollar?                                                    Sus resultados son “sensibles” al entorno. La
                                                                   falta de motivación y los ambientes laborales
Considerando por análisis de criticidad:                           hostiles reducen significativamente el valor
                                                                   intelectual del trabajo.
La evaluación estructurada de las características                 Cuando el trabajo depende del talento, la
del producto (p. ej.: seguridad, complejidad,                      diferencia de valor entre los mediocres y los
rendimiento) para determinar la severidad del                      mejores es muy grande.
impacto de un fallo del sistema, de su
degradación o de su no cumplimiento con los                    Adoptar modelos de desarrollo ágil no consiste
requisitos o los objetivos del sistema.                        sólo en realizar las prácticas formales: equipo
                                                               único, reuniones periódicas, desarrollo evolutivo
O lo que es lo mismo:                                          de los requisitos, etc.
                                                               Si la organización mantiene un modelo de
Si el sistema falla, se degrada o no consigue                  desarrollo basado en procesos y no en personas,
realizar las funciones de los requisitos, ¿qué                 y no tiene alineadas con los principios ágiles: la
impacto tiene en la seguridad o en el ren-                     cultura y estructura organizativa, no obtiene los
dimiento?                                                      resultados propios del desarrollo ágil.

Un ejemplo de criterios de criticidad, ordenados
de mayor a menor, puede ser:

    Causará daño a las personas.
    Causará daño al medio ambiente.


40      2005-2009 – Navegapolis - http://www.navegapolis.net
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes
Scrum Manager Proyecto Apuntes

Weitere ähnliche Inhalte

Was ist angesagt?

Scrum manager
Scrum manager Scrum manager
Scrum manager .. ..
 
Administración 2
Administración 2Administración 2
Administración 2pierre R.
 
Adaptar pmbok y prince2 en una sola estructura
Adaptar pmbok y prince2 en una sola estructuraAdaptar pmbok y prince2 en una sola estructura
Adaptar pmbok y prince2 en una sola estructuraEdwin Garcia
 
Metodologia sial
Metodologia sialMetodologia sial
Metodologia siallyaromero
 

Was ist angesagt? (6)

ESTRATEGIAS COMPETITIVAS
ESTRATEGIAS COMPETITIVASESTRATEGIAS COMPETITIVAS
ESTRATEGIAS COMPETITIVAS
 
Scrum manager
Scrum manager Scrum manager
Scrum manager
 
2016 scrum-guide-spanish
2016 scrum-guide-spanish2016 scrum-guide-spanish
2016 scrum-guide-spanish
 
Administración 2
Administración 2Administración 2
Administración 2
 
Adaptar pmbok y prince2 en una sola estructura
Adaptar pmbok y prince2 en una sola estructuraAdaptar pmbok y prince2 en una sola estructura
Adaptar pmbok y prince2 en una sola estructura
 
Metodologia sial
Metodologia sialMetodologia sial
Metodologia sial
 

Andere mochten auch

The Scrum Master Role
The Scrum Master RoleThe Scrum Master Role
The Scrum Master RoleNigel Thurlow
 
Agilizando PMBOK (con Agile Project Management)
Agilizando PMBOK (con Agile Project Management)Agilizando PMBOK (con Agile Project Management)
Agilizando PMBOK (con Agile Project Management)Rafael Igual
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Managementmarcups
 
Webinario: Despliegue agil de gestion de proyectos (PPM)
Webinario: Despliegue agil de gestion de proyectos (PPM)Webinario: Despliegue agil de gestion de proyectos (PPM)
Webinario: Despliegue agil de gestion de proyectos (PPM)ITM Platform
 
Scrum retos y desafíos desde las trincheras - Infosoft 2012
Scrum retos y desafíos desde las trincheras - Infosoft 2012Scrum retos y desafíos desde las trincheras - Infosoft 2012
Scrum retos y desafíos desde las trincheras - Infosoft 2012Hiroshi Hiromoto
 
Historias de usuario
Historias de usuarioHistorias de usuario
Historias de usuarioFabian Garzon
 
Entendiendo el Triángulo de Hierro en Agile
Entendiendo el Triángulo de Hierro en AgileEntendiendo el Triángulo de Hierro en Agile
Entendiendo el Triángulo de Hierro en AgileJohnny Ordóñez
 
Scrum role introduction – The Product Owner
Scrum role introduction – The Product OwnerScrum role introduction – The Product Owner
Scrum role introduction – The Product OwnerLê Trọng-Hiệp
 
Gestion proyectos, metodología ágiles y SCRUM
Gestion proyectos, metodología ágiles y SCRUMGestion proyectos, metodología ágiles y SCRUM
Gestion proyectos, metodología ágiles y SCRUMAlejandro Marin
 
Movimiento circular de los satelites
Movimiento circular de los satelitesMovimiento circular de los satelites
Movimiento circular de los satelitesCristhianHelmy
 

Andere mochten auch (20)

Scrum: la guía básica
Scrum: la guía básicaScrum: la guía básica
Scrum: la guía básica
 
The Scrum Master Role
The Scrum Master RoleThe Scrum Master Role
The Scrum Master Role
 
Metodología scrum
Metodología scrumMetodología scrum
Metodología scrum
 
Gestión de Proyectos Agile - Scrum
Gestión de Proyectos Agile - ScrumGestión de Proyectos Agile - Scrum
Gestión de Proyectos Agile - Scrum
 
Agilizando PMBOK (con Agile Project Management)
Agilizando PMBOK (con Agile Project Management)Agilizando PMBOK (con Agile Project Management)
Agilizando PMBOK (con Agile Project Management)
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Webinario: Despliegue agil de gestion de proyectos (PPM)
Webinario: Despliegue agil de gestion de proyectos (PPM)Webinario: Despliegue agil de gestion de proyectos (PPM)
Webinario: Despliegue agil de gestion de proyectos (PPM)
 
Roles scrum
Roles scrumRoles scrum
Roles scrum
 
Scrum detrás de Scrum en Ágiles 2013
Scrum detrás de Scrum en Ágiles 2013Scrum detrás de Scrum en Ágiles 2013
Scrum detrás de Scrum en Ágiles 2013
 
Agile project&product management
Agile project&product managementAgile project&product management
Agile project&product management
 
Introducción a SCRUM
Introducción a SCRUMIntroducción a SCRUM
Introducción a SCRUM
 
Scrum retos y desafíos desde las trincheras - Infosoft 2012
Scrum retos y desafíos desde las trincheras - Infosoft 2012Scrum retos y desafíos desde las trincheras - Infosoft 2012
Scrum retos y desafíos desde las trincheras - Infosoft 2012
 
Historias de usuario
Historias de usuarioHistorias de usuario
Historias de usuario
 
Entendiendo el Triángulo de Hierro en Agile
Entendiendo el Triángulo de Hierro en AgileEntendiendo el Triángulo de Hierro en Agile
Entendiendo el Triángulo de Hierro en Agile
 
Metodología scrum
Metodología scrumMetodología scrum
Metodología scrum
 
Scrum role introduction – The Product Owner
Scrum role introduction – The Product OwnerScrum role introduction – The Product Owner
Scrum role introduction – The Product Owner
 
Gestion proyectos, metodología ágiles y SCRUM
Gestion proyectos, metodología ágiles y SCRUMGestion proyectos, metodología ágiles y SCRUM
Gestion proyectos, metodología ágiles y SCRUM
 
full-stack agile: Common Agile Myths
full-stack agile: Common Agile Mythsfull-stack agile: Common Agile Myths
full-stack agile: Common Agile Myths
 
Movimiento circular de los satelites
Movimiento circular de los satelitesMovimiento circular de los satelites
Movimiento circular de los satelites
 
Clean code
Clean codeClean code
Clean code
 

Ähnlich wie Scrum Manager Proyecto Apuntes

Flexibilidad con scrum
Flexibilidad con scrumFlexibilidad con scrum
Flexibilidad con scrumSergi Duró
 
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresa
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresaLibro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresa
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresaIndiana Jones
 
Flexibilidad con scrum
Flexibilidad con scrumFlexibilidad con scrum
Flexibilidad con scrumsergioj25
 
Spanish technical report cmmi v 1 3
Spanish technical report cmmi v 1 3Spanish technical report cmmi v 1 3
Spanish technical report cmmi v 1 3rjsernaque
 
Implementando una PMO con Scrum
Implementando una PMO con ScrumImplementando una PMO con Scrum
Implementando una PMO con ScrumRicardo Toledo
 
Modelo para desarrollar proyectos de mejora basado en pmbok
Modelo para desarrollar proyectos de mejora basado en pmbokModelo para desarrollar proyectos de mejora basado en pmbok
Modelo para desarrollar proyectos de mejora basado en pmbokTBL The Bottom Line
 
CMMI y PMI en la Gestión de Requerimientos
CMMI y PMI en la Gestión de RequerimientosCMMI y PMI en la Gestión de Requerimientos
CMMI y PMI en la Gestión de RequerimientosVictor Caravantes
 
Agile Tools - Caja herramientas ágiles @RoseRestrepoV
Agile Tools - Caja herramientas ágiles @RoseRestrepoVAgile Tools - Caja herramientas ágiles @RoseRestrepoV
Agile Tools - Caja herramientas ágiles @RoseRestrepoVRose Restrepo
 
Gestion de los interesados (Stakeholders) en entornos agiles de proyecto
Gestion de los interesados (Stakeholders) en entornos agiles de proyectoGestion de los interesados (Stakeholders) en entornos agiles de proyecto
Gestion de los interesados (Stakeholders) en entornos agiles de proyectoAlejandro Gabay
 
gestion de proyecto scrum manager_98 HO.pdf
gestion de proyecto scrum manager_98 HO.pdfgestion de proyecto scrum manager_98 HO.pdf
gestion de proyecto scrum manager_98 HO.pdfRodolfoSaulCohen
 
Gestión ágil de proyectos
Gestión ágil de proyectosGestión ágil de proyectos
Gestión ágil de proyectosMax Kraszewski
 
Administracion de proyectos
Administracion de proyectosAdministracion de proyectos
Administracion de proyectosTensor
 

Ähnlich wie Scrum Manager Proyecto Apuntes (20)

Flexibilidad con scrum
Flexibilidad con scrumFlexibilidad con scrum
Flexibilidad con scrum
 
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresa
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresaLibro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresa
Libro - Palacios - Flexibilidad con scrum - Adaptando los procesos a la empresa
 
Flexibilidad con scrum
Flexibilidad con scrumFlexibilidad con scrum
Flexibilidad con scrum
 
Spanish technical report cmmi v 1 3
Spanish technical report cmmi v 1 3Spanish technical report cmmi v 1 3
Spanish technical report cmmi v 1 3
 
Implementando una PMO con Scrum
Implementando una PMO con ScrumImplementando una PMO con Scrum
Implementando una PMO con Scrum
 
Libro scrum
Libro scrumLibro scrum
Libro scrum
 
Presentación gestión ágil de proyectos v 1.0
Presentación gestión ágil de proyectos v 1.0Presentación gestión ágil de proyectos v 1.0
Presentación gestión ágil de proyectos v 1.0
 
Modelo para desarrollar proyectos de mejora basado en pmbok
Modelo para desarrollar proyectos de mejora basado en pmbokModelo para desarrollar proyectos de mejora basado en pmbok
Modelo para desarrollar proyectos de mejora basado en pmbok
 
Rup
RupRup
Rup
 
Rup
RupRup
Rup
 
CMMI y PMI en la Gestión de Requerimientos
CMMI y PMI en la Gestión de RequerimientosCMMI y PMI en la Gestión de Requerimientos
CMMI y PMI en la Gestión de Requerimientos
 
Presentacion plm
Presentacion plmPresentacion plm
Presentacion plm
 
Agile Tools - Caja herramientas ágiles @RoseRestrepoV
Agile Tools - Caja herramientas ágiles @RoseRestrepoVAgile Tools - Caja herramientas ágiles @RoseRestrepoV
Agile Tools - Caja herramientas ágiles @RoseRestrepoV
 
Gestion de los interesados (Stakeholders) en entornos agiles de proyecto
Gestion de los interesados (Stakeholders) en entornos agiles de proyectoGestion de los interesados (Stakeholders) en entornos agiles de proyecto
Gestion de los interesados (Stakeholders) en entornos agiles de proyecto
 
Scrum
ScrumScrum
Scrum
 
gestion de proyecto scrum manager_98 HO.pdf
gestion de proyecto scrum manager_98 HO.pdfgestion de proyecto scrum manager_98 HO.pdf
gestion de proyecto scrum manager_98 HO.pdf
 
Diapositivas AUDITORIA
Diapositivas AUDITORIADiapositivas AUDITORIA
Diapositivas AUDITORIA
 
Gestión ágil de proyectos
Gestión ágil de proyectosGestión ágil de proyectos
Gestión ágil de proyectos
 
Administracion de proyectos
Administracion de proyectosAdministracion de proyectos
Administracion de proyectos
 
Metodologia Scrum
Metodologia ScrumMetodologia Scrum
Metodologia Scrum
 

Kürzlich hochgeladen

La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2montoyagabriela340
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfOBr.global
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfangelinebocanegra1
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosLCristinaForchue
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidaddanik1023m
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfJoseAlejandroPerezBa
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....Aaron Betancourt
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETGermán Küber
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxPaolaCarolinaCarvaja
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSLincangoKevin
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfalejandrogomezescoto
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...OLGAMILENAMONTAEZNIO
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfcastrodanna185
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...RaymondCode
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.marianarodriguezc797
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx Emialexsolar
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfymiranda2
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfodalistar77
 

Kürzlich hochgeladen (20)

La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdf
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidad
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
 
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier FolchBEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
 
Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docx
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
 
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura SilvaBEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdf
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx E
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdf
 

Scrum Manager Proyecto Apuntes

  • 1. Scrum Manager Apuntes Rev. 1.1
  • 3. Scrum Manager Proyectos Apuntes de formación Rev.1.1 May-2009
  • 4. Título Scrum Manager: Proyectos – apuntes de formación. Autores Juan Palacio, Claudia Ruata Imagen de Portada Philip A. Edición Enero – 2009 Más información, y última versión en: http://www.scrummanager.net Derechos Derechos registrados en Safe Creative. Condiciones de uso, copia y distribución en: http://www.safecreative.org/work/0904193094566
  • 5. Contenido Contenido 5 Prólogo 9 Apuntes de formación Scrum Manager 11 Plataforma abierta para consulta y formación profesional Scrum Manager 11 Servicios profesionales para formación y asesoría Scrum Manager 11 Concepto clásico de gestión de proyectos 13 Introducción: Proyectos y operaciones 15 Definición clásica de proyecto 15 Origen de la gestión de proyectos 15 Organizaciones referentes en la gestión de proyectos 16 Modelo válido para cualquier industria 16 Planificación y seguimiento 16 Gestión predictiva o clásica 17 Ámbito de la gestión de proyectos 17 Resumen 17 El nuevo escenario 19 Escenario de desarrollo en los 80 21 The New New Product Development Game 21 Características del nuevo escenario 22 Campos de scrum vs. modelo clásico de desarrollo 23 Fases de desarrollo solapadas 23 Características del “campo de scrum” 24 Incertidumbre 24 Auto-organización 24 Control sutil 24 Difusión y transferencia del conocimiento 24 Resumen 25 Gestión de proyectos ágil 27 Introducción 29 Objetivos de la gestión ágil 29 1.-Valor 29 2.-Reducción del tiempo de salida al mercado 29 3.-Agilidad 29 4.-Flexibilidad 29 5.- Resultados fiables 30 Las preferencias de la gestión ágil 30 El ciclo de desarrollo ágil 30 1.- Concepto 30 2.- Especulación 31 3.- Exploración 31 4.- Revisión 31 5.- Cierre 31 Principales modelos de gestión ágil 31 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 6. Contenido ASD 32 AUP 32 CRYSTAL 32 DSDM 33 SCRUM 33 XBreed – Agile Enterprise 34 Resumen 34 Gestión de proyectos: ¿formal o ágil? 35 ¿Ágil, clásica, predictiva …? 37 Premisas de la gestión de proyectos predictiva 37 Características de la gestión de proyectos predictiva 37 Hay otras premisas 37 ¿Cuándo y por qué emplear uno u otro estilo de gestión? 38 Características del proyecto 38 Prioridad de negocio 39 Estabilidad de los requisitos 39 Rigidez del producto 39 Coste de prototipado 39 Criticidad del sistema 40 Tamaño del sistema 40 Condiciones de la organización 40 Nivel profesional 41 Cultura organizativa 41 Entorno de desarrollo 41 Resumen 41 Introducción al modelo Scrum para desarrollo de Software 43 El origen 45 Introducción al modelo 45 Control de la evolución del proyecto 46 Revisión de las Iteraciones 46 Desarrollo incremental 46 Desarrollo evolutivo 46 Auto-organización 46 Colaboración 46 Visión general del proceso 46 Las reuniones 47 Los elementos 47 Los roles 47 Valores 48 Resumen 48 Roles y responsabilidades de proyecto 51 Introducción 53 Responsabilidades generales Scrum Management 53 De management 53 De procesos 53 De producción 53 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 7. Contenido Responsabilidades y roles “del proyecto” 53 El propietario del producto 54 Para ejercer este rol es necesario: 54 El equipo 54 Scrum Manager – Team Leader 55 Resumen 55 De management 55 De procesos 55 De producción 55 Los elementos de Scrum 57 Introducción 59 Los requisitos en el desarrollo ágil 59 Requisitos y visión del producto 60 Pila del producto: los requisitos del cliente 60 Formato de la pila del producto 61 Pila del Sprint 61 Condiciones 61 Formato y soporte 61 Ejemplos 62 El Incremento 62 Resumen 62 Scrum: Las reuniones 63 Introducción 65 Planificación del sprint 65 Descripción general 65 Pre-condiciones 65 Entradas 65 Resultados 65 Formato de la reunión 66 1 Funciones del rol de Scrum Manager 66 Pizarra de trabajo 67 Un ejemplo de pizarra 67 Seguimiento del sprint 68 Descripción 68 Entradas 68 Resultados 68 Formato de la reunión 68 Revisión del sprint 69 Descripción 69 Objetivos 69 Pre-condiciones 69 Entradas 69 Resultados 69 Formato de la reunión 69 Resumen 70 Medición: consideraciones 71 2005-2009 – Navegapolis - http://www.navegapolis.net
  • 8. Contenido Introducción 73 ¿Por qué medir? 73 Flexibilidad y sentido común 73 Criterios para el diseño y aplicación de métricas 73 Cuantas menos, mejor 73 ¿El indicador es apropiado para el fin que se debe conseguir? 74 Medición de la eficiencia en la empresa 74 Medición del avance del proyecto 74 Medición de la eficiencia de los trabajos de programación 74 ¿Lo que vamos a medir es un indicador válido de lo que queremos conocer? 75 Resumen 75 Medición: Las Unidades 77 Velocidad, trabajo y tiempo 79 Tiempo 79 Trabajo 79 Trabajo ya realizado 79 Trabajo pendiente de realizar 79 Unidades de trabajo 80 Velocidad 81 Resumen 81 Medición: Usos y herramientas 83 Gráfico de producto: 85 Ejemplo: 85 Gráfico de avance: monitorización del sprint 86 Estimación de póker 87 Variante: sucesión de Fibonacci 88 Funcionamiento 88 Resumen 89 Índice 91 Índice 93 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 11. Apuntes de formación Scrum Manager Apuntes de formación Scrum Manager Este es el libro de texto para formación del área de “Proyecto” del marco de gestión ® “Scrum Manager ”. Es un recurso educativo abierto (OER) y forma parte de la plataforma Scrum Manager Open Knowledge: http://scrummanager.net/ok/ Se puede emplear de forma gratuita para consulta y auto-formación a título personal. Plataforma abierta para consulta y formación profesional Scrum Manager Scrum Manager Open Knowledge es una plataforma de acceso libre para consulta y formación, está disponible en http://scrummanager.net/ok/ donde encontrarás la última versión de este manual, además de otros materiales, foros, talleres, etc. Un punto abierto en la Red para consultar y compartir conocimiento, y mantenerte profesionalmente actualizado. Servicios profesionales para formación y asesoría Scrum Manager Puedes localizar profesionales y empresas certificadas para servicios profesionales de formación y asesoría en la implantación y mejora de Scrum Management, en el directorio de consultores Scrum Manager: http://scrummanager.net/ o solicitar información en la dirección formacion@scrummanager.net Información para formar parte de la red de consultores certificados Scrum Manager en la dirección formacion@scrummanager.net. 2008 – 2005-2009 – ScrumManager - http://www.scrummanager.net 11
  • 13. Concepto clásico de gestión de proyectos
  • 15. Origen de la gestión de proyectos Introducción: Proyectos y Conjunto único de actividades necesarias para producir un resultado definido en un rango de fechas determinado y con una operaciones asignación específica de recursos Las construcciones de ingeniería civil, como puentes o edificios, son ejemplos clásicos de obras realizadas como proyectos, y en general lo es el desarrollo de cualquier sistema singular. Un proyecto tiene objetivos y características únicas. El desarrollo de productos, la prestación de Algunos necesitan el trabajo de una sola persona, servicios, o incluso la organización de la propia y otros el de cientos de ellas; pueden durar unos empresa son trabajos que pueden tomar la forma días o varios años. de proyectos o de operaciones. Algunos ejemplos de proyectos: Ambos compantes tres características:  Diseño de un nuevo ordenador portátil.  Los realizan personas.  Construcción de un edificio.  Se emplean recursos limitados.  Desarrollo de un sistema de software.  Se llevan a cabo siguiendo una estrategia de  Implantación de una nueva línea de producto actuación. en una empresa.  Diseño de una campaña de marketing. Aunque comparten estas tres características, la diferencia clave entre operaciones y proyectos es que: Origen de la gestión de Las operaciones se ejecutan de forma repetitiva para obtener resultados de proyectos similares características Los proyectos producen resultados Los proyectos han existido siempre. únicos Cualquier trabajo para desarrollar algo único es un proyecto, pero la gestión de proyectos es una disciplina relativamente reciente que comenzó a Se considera proyecto a la ejecución de un forjarse en los años sesenta. trabajo que además de requerir personas, recur- sos y ejecución controlada: La necesidad de su profesionalización surgió en el ámbito militar. Es un desarrollo único En los 50, el desarrollo de complejos sistemas militares, requería coordinar el trabajo conjunto de La teoría clásica de gestión de proyectos, añade equipos y disciplinas diferentes, en la cons- a la característica anterior otra, que desde la trucción de sistemas únicos. perspectiva de gestión predictiva tiene sentido, Bernard Schriever, arquitecto del desarrollo de pero no tanto, como se verá, desde la perspectiva misiles balísticos Polaris, es considerado el padre de gestión de proyectos ágil. de la gestión de proyectos, por la introducción del concepto de “concurrencia”, para integrar todos Se desarrolla en un marco temporal pre- los elementos del plan del proyecto en un solo establecido. programa y presupuesto. El objetivo de la concurrencia era ejecutar las diferentes actividades de forma simultánea, y no secuencialmente, y al aplicarla en los proyectos Thor, Atlas y Minuteman se redujeron conside- Definición clásica de proyecto rablemente los tiempos de ejecución. 2005-2009 – ScrumManager - http://www.scrummanager.net 15
  • 16. Origen de la gestión de proyectos La industria del automóvil siguió los pasos de la de una gestión de proyectos, para ofrecer garan- militar, aplicando técnicas de gestión de tías de previsibilidad y calidad de los resultados. proyectos para la coordinación del trabajo entre áreas y equipos diferentes. Este conocimiento se ha configurando como el Comenzaron a surgir técnicas específicas, currículo de una nueva profesión: La gestión de histogramas, cronogramas, los conceptos de ciclo proyectos predictiva. de vida del proyecto o descomposición en tareas (WBS Work Breakdown Structure). Las organizaciones más relevantes en esta línea son: En 1960, Meter Norden, del laboratorio de investigación de IBM, en su seminario de Inge-  International Project Management Association niería de Presupuesto y Control presentado ante (IPMA), fundada en 1965 American Management Association, indicó:  Project Management Institute (PMI) constituído en 1965  Más tarde surgió Prince2, que comenzó a Es posible relacionar los nuevos trabajar en 1989. proyectos con otros pasados y terminados para estimar sus costes IPMA y PMI surgieron como organizaciones Se producen regularidades en todos profesionales para desarrollar metodologías y los proyectos procesos para la gestión de proyectos. Es absolutamente necesario Prince2 ha tenido la evolución inversa. Comenzó descomponer los proyectos en partes siendo una metodología, alrededor de la que se de menor dimensión para realizar ha terminado creando una organización. planificaciones. Modelo válido para cualquier industria Organizaciones referentes También en este sentido la evolución ha sido diferente para Prince2: en la gestión de proyectos PMI e IPMA tuvieron desde el principio como finalidad el desarrollo de un conocimiento de gestión válido para cualquier proyecto. La construcción de sistemas complejos que Sin embargo, Prince2 comenzó siendo un modelo requerían el trabajo sincronizado de varias de referencia para proyectos específicos de disciplinas hizo evidente en los 60 la necesidad Tecnologías de la Información, desarrollado por la de nuevos métodos de organización para evitar Central Computer and Telecommunications problemas recurrentes: Agency (CCTA) del Gobierno Británico; y a partir de una revisión llevada a cabo en 1996 se decidió  Desbordamiento de agendas. ampliar su ámbito de validez, para cualquier tipo  Desbordamiento de costes. de proyecto.  Calidad o utilidad del resultado obtenido. Planificación y seguimiento Para dar respuesta a esta necesidad, desde los años 60 han surgido organizaciones que contri- buyen al desarrollo del cuerpo de conocimiento 16 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 17. Origen de la gestión de proyectos La gestión de proyectos desarrollada en las Grupos de procesos de la gestión de proyectos últimas décadas del siglo pasado se basa en la PMBOK 2004 planificación del trabajo, y en el posterior seguimiento y control de la ejecución. La planificación se realiza sobre un análisis detallado del trabajo que se quiere realizar y su Ámbito de la gestión de proyectos descomposición en tareas. Parte por tanto de un proyecto de obra, o de unos requisitos detallados de lo que se quiere hacer. Sobre esa información se desarrolla un plan adecuado a los recursos y tiempos disponibles; y La solvencia demostrada por la gestión de durante la construcción se sigue de cerca la proyectos en la industria militar, y en la ejecución para detectar posibles desviaciones y automovilística para solucionar los problemas tomar medidas para mantener el plan, o habituales de calidad, tiempos y costes, coincide determinar qué cambios va a experimentar. en el tiempo con la presión que todas las Se trata por tanto de una gestión “predictiva”, que industrias experimentan en mayor o menor vaticina a través del plan inicial cuáles van a ser medida para reducir la agenda de salida al la secuencia de operaciones de todo el proyecto, mercado y los costes de producción. Como su coste y tiempos. resultado, en todos los sectores: farmacéutico, químico, servicios, tecnologías de la información, Su principal objetivo es conseguir que el producto etc. se adoptan técnicas de gestión de proyectos, final se obtenga según lo “previsto”; y basa el dándoles de facto validez para todos los ámbitos. éxito del proyecto en los tres puntos apuntados: agendas, costes y calidad. Gestión predictiva o clásica La gestión de proyectos predictiva o clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.  Establece como criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado.  Asume que el proyecto se desarrolla en un  entorno estable y predecible. El objetivo de su esfuerzo es mantener el Resumen cronograma, el presupuesto y los recursos.  Divide el desarrollo en fases a las que  Definición clásica de proyecto: construcción considera “ciclo de vida”, con una secuencia de un resultado único, en unas fechas de tipo: concepto, requisitos, diseño, previstas y con unos recursos previstos de planificación, desarrollo, cierre. antemano.  La profesionalización de la gestión de proyectos surgió en los 50 para dar respuesta a las necesidades de la industria militar, y en los años posteriores el resto de industrias han adoptado sus principios.  Las organizaciones más conocidas por la investigación, y creación de comunidades profesionales para la gestión de proyectos son: PMI (Project Management Institute), Internacional Project Management Association (IPMA) y Prince2.  Características de la gestión de proyectos desarrollada en la segunda mitad del siglo pasado: 2005-2009 – ScrumManager - http://www.scrummanager.net 17
  • 18. Origen de la gestión de proyectos  Gestión basada en la aplicación sistemática de procesos repetibles y escalables.  Los criterios de éxito de un proyecto son: calidad, costes y fechas.  Carácter predictivo: ejecución según el plan inicial previsto.  Desarrollo sobre un entorno estable.  El objetivo de la gestión es: desarrollar un plan, y mantener el cronograma y los recursos planificados.  Ciclo de vida compuesto por fases secuenciales. 18 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 21. El nuevo escenario División del trabajo, especialización y producción basada en procesos, fueron premisas que, como Escenario de desarrollo en axiomáticas, asumió la gestión de proyectos, y por esta razón, los puntos clave de la gestión los 80 predictiva o clásica son:  Estimar cuál va a ser el trabajo necesario, y a continuación gestionar la ejecución para que En los 80, el ciclo de vida de los proyectos era el se cumplan la estimación inicial. denominado en cascada: el proyecto se divide en  El trabajo se desarrolla en fases. fases, y éstas se ejecutan de forma secuencial:  División del trabajo en equipos de definición del producto, diseño, construcción de especialistas. elementos, integración, pruebas…  Desarrollo basado en procesos. Dos características de la construcción de nuevos productos en esta década son:  Ciclo de vida secuencial.  División y especialización del trabajo. The New New Product Development Game Es el título del artículo publicado en 1986 por Hirotaka Takeuchi e Ikujijo Nonaka; que a su vez Cada fase la realiza un departamento, personas o daba continuación a otro anterior de los mismos equipos diferentes, profesionalmente especiali- autores junto con Kenichi Imai: “Managing the zados en los conocimientos necesarios. New Product Development Process: How Japanese Companies Learn and Unlearn”. La gestión de proyectos desarrolla modelos de estructuras organizativas de tipo matricial, con La publicación de “The New New Product diferentes variaciones, para facilitar la comunica- Development Game” ha marcado el punto de ción y coordinación entre equipos diferentes. inicio de una nueva forma de gestionar proyectos en entornos rápidos e inestables. En las mismas fechas, a la par de la consolida- ción del conocimiento de gestión de proyectos, se Cuando la teoría de gestión de proyectos estaba estaban desarrollando las teorías de producción alcanzando una cierta madurez, los autores ob- basada en procesos, promovidas por Michel servaron que algunas empresas, en mercados Hammer, como mejor medio para garantizar la muy competitivos, relacionados con productos de calidad, eficiencia y repetitividad. vanguardia tecnológica, trabajaban ignorando esa teoría. “Muchas compañías han descubierto que para mantenerse en el actual mercado competitivo necesitan algo más que los conceptos básicos de calidad elevada, costes reducidos y diferen- ciación. Además de esto, también es necesario velocidad y flexibilidad.” “En 1981 las encuestas realizadas a 700 empresas americanas revelan que el 30% de sus beneficios se debe a nuevos productos”. 2005-2009 – ScrumManager - http://www.scrummanager.net 21
  • 22. El nuevo escenario Hasta entonces, el desarrollo de nuevos produc-  La cámara Canon AE-1 (1976) tos se realizaba como una carrera de relevos, en  Cámara Canon Auto Boy (1979). la que un grupo de especialistas funcionales pasaban el relevo al siguiente. En estas empresas el trabajo no recorría fases a El proyecto avanzaba secuencialmente de fase través de diferentes equipos especializados. en fase: creación del concepto, pruebas de viabi- lidad, diseño del producto, diseño del proceso, “El producto emerge de la interacción constante desarrollo de prototipo y producción final. de un equipo de élite, multidisciplinario que trabaja conjuntamente desde el principio hasta el Es un modelo de trabajo segmentado por final” especialización de funciones. La gente de marketing explora y estudia las Nonaka y Takeuchi compararon la forma de necesidades de los clientes, para crear el con- trabajar de estos equipos únicos y multi- cepto del producto. Los ingenieros de investi- disciplinarios, con los equipos de rugby, y el gación y desarrollo elaboran un diseño adecuado, ambiente y entorno de trabajo que les los ingenieros de producción llevan a cabo la proporcionaba la empresa lo llamaron “campo de 1 solución técnica… scrum ”. Características del nuevo La figura siguiente representa el ciclo de vida al construir un producto con un patrón de gestión secuencial, y cuál es la diferencia con la nueva forma, observada por Nonaka y Takeuchi en empresas que ignoraban los principios de la escenario gestión clásica de proyectos. En los 40, 50 y 60 los productos tardaban años en quedar obsoletos, y las empresas los producían Los desarrollos secuenciales puros suelen ser con variaciones mínimas a lo largo del tiempo. más teóricos que prácticos, y en realidad quienes los adoptan, generalmente producen ciclos Apple ha desarrollado 6 versiones de su popular “secuenciales con solapamiento”, donde una fase iPod, en sólo 6 años. no suele necesitar para empezar que esté completamente terminada la anterior. Hoy determinados productos permanecen en un continuo estado “beta”. El entorno tecnológico es Nonaka y Takeuchi observaron que empresas tan inestable, que las novedades se lanzan tras el americanas y japonesas tecnológicas, de primera menor tiempo de desarrollo posible, dejando que línea, que aventajaban a sus competidores en vayan evolucionando a través de versiones, en el innovación y rapidez, compartían pautas de propio mercado. Que sea éste quien diga de trabajo comunes, ajenas al clásico patrón secuen- forma continua cómo deben modificarse los cial. “requisitos”. Analizaron la forma de trabajo de: Fuji-Xerox, En estas circunstancias, las diferencias de lide- Canon, Honda, Nec, Epson, Brother, 3M, Xerox y razgo entre unas empresas y otras no radica Hewlett-Packard y en concreto la forma en la que tanto en la eficiencia y previsibilidad con la que se abordaban el desarrollo de 6 productos: gestionan el lanzamiento de nuevos productos, sino en la capacidad de agilidad y cambio durante  La fotocopiadora Fuji-Xerox FX-3500. (1978) su construcción; y el principal valor para ocupar  La copiadora personal Canon PC-10 (1982) puestos de cabeza es la innovación.  El coche urbano de 1200cc de Honda (1981) 1  El ordenador personal NEC PC 8000 (1979) Scrum es un término empleado en rugby para definir una determinada formación del equipo. 22 2005-2009 – Navegapolis - http://www.navegapolis.net
  • 23. El nuevo escenario Campos de scrum vs. regularmente incrementos de funcionalidad que incrementan el valor al producto. modelo clásico de Fases de desarrollo solapadas desarrollo El concepto de “fase” que implica un trabajo secuencial, se cambia ahora por el de “actividad”. Requisitos, análisis, diseño, desarrollo no son Estos son los principales contrastes que fases ejecutadas en un orden determinado. Son diferencian el desarrollo tradicional del ágil: actividades que se pueden realizar en cualquier momento, de forma simultánea; “a demanda” cuando las necesita el equipo. En el ciclo de vida secuencial de software se habla de “modificación de requisitos”. Este término lleva implícito el concepto de que estamos “cambiando” algo que quedó cerrado en la fase de requisitos. En el desarrollo ágil, los requisitos evolucionan, se desarrollan y enriquecen durante todo el ciclo de vida, igual que el diseño y el código. Takeuchi y Nonaka observaron dos tipos de 2 solapamiento: uno que denominaron “sashimi ” No lo realizan equipos diferentes especializados. estableciendo analogía con el plato típico japonés Es un equipo único, formado por personas muy porque se produce un solapamiento bastante competentes, con perfiles y conocimientos que amplio, de tal forma, que en cualquier punto del cubren las disciplinas necesarias para llevar a ciclo de vida, se encuentran de forma simultánea 3 cabo el trabajo. varias fases; y otro que denominaron “rugby ”, que deja perdido por completo el concepto de No hay fases. En realidad las fases pasan a ser fases, y en el que el equipo trabaja tareas que se ejecutan cuando se necesitan. concurrentemente en todas las actividades desde No se hace primero el diseño del concepto o los el primer día. requisitos, más tarde el análisis, luego el desarrollo, etc. En el solapamiento “sashimi” aún se mantiene el Lo que aplicado al software serían las fases de: concepto de fase, aunque con un solapamiento requisitos del sistema, requisitos del software, muy amplio. análisis, diseño, construcción, pruebas e inte- gración; y se ejecutarían de forma secuencial, pasan a tareas que se llevan a cabo en el mo- mento que hacen falta. Normalmente a lo largo de pequeñas iteraciones durante todo el desarrollo. En el solapamiento “rugby” no son ya fases, sino definitivamente tareas. No se espera a disponer de requisitos detallados para comenzar el análisis, ni a tener éste para En el desarrollo tradicional: pasar a la codificación. Muchas veces los requi-  Las transiciones entre fases, acaban sitos no se pueden conocer si no avanza el funcionando como fronteras. Cada equipo se desarrollo y se va viendo y “tocando” el resultado. siente responsable de su parte de trabajo, de Otras veces el mercado es tan rápido que a mitad lo que debe entregar a la siguiente fase, pero de trabajo las tendencias o la competencia no del resultado final. obligarán a modificar el producto.  Los documentos de diseño, los requisitos o Además, la participación de todo el equipo en el los prototipos pueden acabar siendo diseño aporta gran cantidad de talento innovador; barricadas en la frontera de cada fase, que un valor clave en el mercado de productos y lejos favorecer la comunicación directa servicios TIC. fomentan la fragmentación. Los equipos ágiles empiezan a trabajar sin 2 Nombre que dieron al tipo de solapamiento uqe empleaba el conocer con detalle cómo será el producto final. equipo de desarrollo de la FX-3500 en Fuji-Xerox. Parten de la visión general, y sobre ella, producen 3 Con este nombre denominaron a la combinación simultánea de todas las fases desde el primer día, empleada por los equipo de Honda. 2005-2009 – ScrumManager - http://www.scrummanager.net 23
  • 24. El nuevo escenario  Los retrasos de cada fase son cuellos de  Auto-superación. El equipo va desarrollando botella del proyecto. El solapamiento diluye el soluciones, que evalúa, analiza y mejora. ruido y los problemas entre fases.  Auto-enriquecimiento. La multi-disciplinaridad del equipo favorece el enriquecimiento mutuo y la aportación de soluciones valiosas Características del “campo complementarias. de scrum” Control sutil El equipo dispone de autonomía, pero no debe Las características “ambientales” en las empresas derivar en caos. que desarrollan los nuevos productos con La gestión establece puntos de control suficientes modelos de gestión ágil son: para evitar que el escenario de ambigüedad, inestabilidad y tensión del “campo de scrum”  Incertidumbre consustancial al entorno y la evolucione hacia el descontrol. cultura de la organización.  Equipos auto-organizados. Pero debe gestionarse sin un control rígido que  Control sutil. impediría la creatividad y la espontaneidad.  Difusión y transferencia del conocimiento. El término “control sutil” se refiere a la creación de un ecosistema que potencia y desarrolla el “auto- Incertidumbre control entre iguales”, como consecuencia de la responsabilidad y del gusto por el trabajo realizado. Se trabaja en entornos de incertidumbre consus- tancial. Algunas acciones para generar este ecosistema En estas empresas, la dirección apunta cuál es la son: meta genérica a la que se pretende arribar, o la dirección estratégica que hay que seguir. No se  Selección de las personas adecuadas para el proporciona el plan detallado del producto. proyecto. Al mismo tiempo se dá al equipo un margen de  Análisis de los cambios en la dinámica del amplia libertad. grupo para incorporar o retirar a miembros si Los ingredientes que sirven de acicate para la resulta necesario. creatividad y el compromiso son:  Creación de un espacio de trabajo abierto.  Animar a los ingenieros a “mezclarse” con el  La “tensión” que crea la visión difusa y el reto mundo real de las necesidades de los que supone el grado de dificultad que clientes. encierra.  Sistemas de evaluación y reconocimiento  El margen de autonomía, libertad y basados en el rendimiento del equipo. responsabilidad.  Gestión de las diferencias de ritmo a través del proceso de desarrollo. Auto-organización  Tolerancia y previsión con los errores; considerando que son un medio de aprendizaje, y que el miedo al error merma la Son equipos auto-organizados, sin roles de creatividad y la espontaneidad. gestión ni pautas de asignación de tareas.  Implicar a los proveedores en el proyecto y No se trata de equipos auto-dirigidos, sino auto- animarles a su propia auto-organización. organizados. La gestión es la que marca la dirección, pero no la organización. Parten de cero. Deben empezar por crear su pro- Difusión y transferencia del pia organización y buscar el conocimiento que necesitan. conocimiento Son similares a una “Start-up” que comienza. Tanto a nivel de proyecto como de organización. Para lograr la auto-organización los equipos Los equipos son multidisciplinarios, y todos los deben reunir tres características: miembros aportan y aprenden:  Autonomía. Son libres para elegir la  del resto del equipo, estrategia de la solución. En este sentido la dirección de la empresa actúa como un capitalista de capital-riesgo. 24 2005-2009 – Navegapolis - http://www.navegapolis.net
  • 25. El nuevo escenario  de las investigaciones para mejorar el valor y  Características ambientales en estos entor- el componente innovador que espera el nos llamados “campos de scrum” cliente,  Incertidumbre  de la experiencia del desarrollo.  Auto-organización  Control sutil Las personas que participan en un proyecto, con  Difusión del conocimiento el tiempo pasan a otros equipos y proyectos de la  Fases de desarrollo solapadas empresa, de manera que comparten y comunican el conocimiento a lo largo de toda la organización. Los equipos y las empresas mantienen libre acceso a la información, herramientas y políticas de gestión del conocimiento Resumen  Hasta los 80, para el desarrollo de nuevos productos se empleaban:  Ciclos de vida secuencial.  División y especialización del trabajo.  En los 80 se desarrolla la teoría de producción basada en procesos para propor- cionar eficiencia calidad y repetibilidad.  En esos años, algunas empresas de tecno- logía (Caon, Fuji-Xerox, Honda, Epson, HP, etc.) logran más valor y mejores resultados en el desarrollo de nuevos productos, desafiando al desarrollo secuencial y a la división del trabajo.  Nonaka y Takeuchi son los primeros en identificar estos nuevos entornos de produc- ción a los que denominan “campos de scrum” en el artículo The New New Product Develop- ment Game”.  Las principales diferencias con el desarrollo tradicional de producto son:  No trabajan departamentos especializa- dos, sino un único equipo multi- disciplinario.  Solapamiento de las fases del desarrollo.  No se parte de unos requisitos detallados sino de la visión del resultado.  No se sigue un plan pre-elaborado. 2005-2009 – ScrumManager - http://www.scrummanager.net 25
  • 27. Gestión de proyectos ágil Conceptos
  • 29. Gestión de proyectos ágil: conceptos Su objetivo es dar el mayor valor posible al producto, cuando éste se basa en: Introducción  Innovación  Flexibilidad Muchas empresas trabajan en escenarios que se parecen ya muy poco a los que impulsaron la La permanencia de estas empresas depende de gestión de proyectos predictiva y necesitan su capacidad de innovación continua. Del estrategias diferentes para gestionar el lanzamiento continuo de novedades, que com- lanzamiento de sus productos: estrategias orien- piten con los productos de otras empresas que tadas a la entrega temprana de resultados tan- también están en continua innovación. gibles, y con la suficiente agilidad y flexibilidad para trabajar en entornos inestables y rápidos. Flexibilidad. El producto no sólo es valioso por su valor en el Ahora necesitan construir el producto al mismo momento de su lanzamiento, sino también por su tiempo que cambian y aparecen nuevos requisi- capacidad de adaptación y evolución a través de tos; y como las circunstancias de los mercados y actualizaciones y ampliaciones. de las empresas no se pueden cambiar, son las formas en las que gestionan sus proyectos las que tienen que cambiar para dar respuesta a las nuevas necesidades. 2.-Reducción del tiempo de El cliente conoce la visión de su producto pero salida al mercado por la novedad, el valor de innovación que necesita y la velocidad a la que se va a mover el En la década de los 90, el tiempo medio de salida escenario tecnológico y de negocio, durante el al mercado de los nuevos productos en EE.UU. 4 desarrollo, no puede detallar cómo será el se redujo de 35,5 a 11 meses producto final. Este tiempo es un factor competitivo clave en ¡Ah!. Pero, ¿existe el producto final?. determinados sectores. Quizá ya no hay “productos finales”, sino Las estrategias de la gestión ágil para producir productos en evolución, mejora o incremento resultados en menos tiempo que la gestión continuo, desde la primera versión beta. tradicional son:  Solapamiento de las fases de desarrollo.  Entrega temprana de las primeras partes del El resultado es la gestión ágil de producto, que corresponden con las de mayor proyectos, que no se formula sobre el urgencia para el cliente, de forma que puede concepto de anticipación (requisitos, lanzar la primera versión en el menor tiempo diseño, planificación y seguimiento) sino posible. sobre el de adaptación (visión, exploración y adaptación) 3.-Agilidad Capacidad para producir partes completas del producto en periodos breves de tiempo Objetivos de la gestión ágil 4.-Flexibilidad La gestión ágil de proyectos tiene como objetivo Capacidad para adaptar la forma y el curso del dar garantías a las demandas principales de la desarrollo a las características del proyecto, y a la industria actual: valor, reducción del tiempo de evolución de los requisitos. desarrollo, agilidad, flexibilidad y fiabilidad. 1.-Valor La gestión ágil se necesita en los mercados rápidos. 4 Wujec, Tom, and Sandra Muscat. Return on Imagination: Realizing the Power of Ideas, London: Financial Times Prentice Hall, 2002 2005-2009 – ScrumManager - http://www.scrummanager.net 29
  • 30. Gestión de proyectos ágil: conceptos 5.- Resultados fiables El ciclo de desarrollo ágil El objetivo de la gestión predictiva es ejecutar el trabajo planificado (y conocido de antemano) en el plazo planificado y por el coste previsto. La gestión ágil no tiene un carácter predictivo o de anticipación. No conoce de antemano el de- talle del producto que va a desarrollar, y por eso su objetivo no es fiabilidad en el cumplimiento de los planes, sino en el valor del resultado. Los procesos de la gestión tradicional son buenos cuando consiguen desarrollar de forma repetible los productos especificados en el tiempo y con los costes previstos. Los procesos de la gestión ágil son buenos, El desarrollo ágil parte de la visión, del concepto cuando consiguen entregar de forma temprana y general del producto, y sobre ella el equipo continua un valor innovador. produce de forma continua incrementos en la dirección apuntada por la visión; y en el orden de prioridad que necesita el negocio del cliente. Las preferencias de la Los ciclos breves de desarrollo, se denominan iteraciones y se realizan hasta que se decide no gestión ágil evolucionar más el producto. Este esquema está formado por cinco fases: La gestión ágil, a diferencia de la tradicional, muestra las preferencias resumidas en el 1.- Concepto manifiesto ágil: 2.- Especulación 3.- Exploración 1.- La capacidad de respuesta al cambio, 4.- Revisión sobre el seguimiento de un plan. 5.- Cierre 1.- Concepto 2.- Los productos que funcionan frente a especificaciones y documentaciones inne- cesarias. En esta fase se crea la visión del producto y se 3.- La colaboración con el cliente frente a la determina el equipo que lo llevará a cabo. negociación contractual. Partir sin una visión genera esfuerzo baldío. 4.- A las personas y su interacción por encima La visión es un factor crítico para el éxito del de los procesos y las herramientas. proyecto. Se necesita tener el concepto de lo que se quiere, y conocer el alcance del proyecto. Es además una información que deben compartir todos los miembros del equipo 30 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 31. Gestión de proyectos ágil: conceptos 2.- Especulación 4.- Revisión Una vez que se sabe qué hay que construir, el Equipo y usuarios revisan lo construido hasta ese equipo especula y formula hipótesis basadas en momento. la información de la visión, que per se es muy Trabajan y operan con el producto real general e insuficiente para determinar las contrastando su alineación con el objetivo. implicaciones de un desarrollo (requisitos, diseño, costes…). En esta fase se determinan las limitaciones impuestas por el entorno de negocio: costes y agendas principalmente, y se cierra la primera aproximación de lo que se puede producir. La gestión ágil investiga y construye a partir de la visión del producto. Durante el desarrollo confronta las partes terminadas: su valor, posi- bilidades, y la situación del entorno en cada momento. 5.- Cierre La fase de especulación se repite en cada iteración, y teniendo como referencia la visión y el alcance del proyecto consiste en: Al llegar a la fecha de entrega de una versión de  Desarrollo y revisión de los requisitos producto (fijada en la fase de concepto y revisada generales. en las diferentes fases de especulación), se  Mantenimiento de una lista con las obtiene el producto esperado. funcionalidades esperadas.  Mantenimiento de un plan de entrega: fechas Posiblemente éste seguirá en el mercado, y por en las que se necesitan las versiones, hitos e emplear gestión ágil, es presumible que se trata iteraciones del desarrollo. Este plan refleja ya de un producto que necesita versiones y mejoras el esfuerzo que consumirá el proyecto frecuentes para no quedar obsoleto. El cierre no durante el tiempo. implica el fin del proyecto.  En función de las características del modelo de gestión y del proyecto puede incluir Lo que se denomina “mantenimiento” supondrá la también una estrategia o planes para la continuidad del proyecto en ciclos incrementales gestión de riesgos. hacia la siguiente versión para ir acercándose a la visión del producto. Si las exigencias formales de la organización lo requieren, también se produce información admi- nistrativa y financiera. Principales modelos de gestión ágil Si hubiera que determinar cuál es el origen de la gestión ágil de proyectos, a falta de mejor infor- mación, habría que situarlo en las prácticas adop- tadas en los 80 por empresas como Honda, 3M, Canon, Fuji, Nec, Xerox, hp o Epson para el 5 desarrollo de nuevos productos . 3.- Exploración La industria del software ha sido la primera en seguir su adopción, y muchos de sus profesionales han documentado y propagado las Se desarrolla un incremento del producto, que formas particulares en las que han implementado incluye las funcionalidades determinadas en la fase anterior. 5 Hirotaka Takeuchi e Ikujiro Nonaka, 1986 “The New New Development Game” 2005-2009 – ScrumManager - http://www.scrummanager.net 31
  • 32. Gestión de proyectos ágil: conceptos los principios de la agilidad en sus equipos de ESPECULACIÓN, compuesta por 5 pasos: trabajo. 1.- Inicio para determinar la misión del proyecto. De esta forma han aparecido en las últimas 2.- Fijación del marco temporal del proyecto. décadas los nombres: 3.- Determinación del nº de iteraciones y la duración de cada una.  AD - Agile Database Techniques 4.- Definición del objetivo de cada iteración.  AM - Agile Modeling 5.- Asignación de funcionalidad a cada iteración.  ASD - Adaptive Software Development  AUP - Agile Unified Process COLABORACIÓN  Crystal Desarrollo concurrente del trabajo de cons-  FDD - Feature Driven Development trucción y gestión del producto.  DSDM - Dynamic Systems Development Method APRENDIZAJE  Lean Software Development En cada iteración se revisa:  Scrum  Calidad, con criterios de cliente.  TDD - Test-Driven Design  Calidad, con criterios técnicos.  XBreed  Funcionalidad desarrollada.  XP - eXtreme Programming  Estado del proyecto. Éstos son los modelos que se encuentran Las características básicas de ASD son: inscritos en la organización Agile Alliance  Trabajo orientado y guiado por la misión del (www.agilealliance.org) para promocionar y proyecto. difundir su conocimiento.  Basado en la funcionalidad.  Desarrollo iterativo. Cada una de ellos expone formas concretas de  Desarrollo acotado temporalmente. aplicación de principios ágiles en el desarrollo de  Guiado por los riesgos. software.  Trabajo tolerante al cambio. Algunos determinan cómo realizar las pruebas, o AUP la duración que emplean para desarrollar cada iteración, o el protocolo para realizar las reuniones de trabajo. Agile Unified Process es una versión simplificada Unos métodos cubren áreas concretas de la de Rational Unified Process, desarrollada por ingeniería del software (diseño, desarrollo Scott Amber. pruebas), como es caso de AD, AM o XP, y otros se centran en la gestión del proyecto. Divide el ciclo de desarrollo en 4 fases: Éstos últimos son: INICIO: identificación del alcance y dimensión del proyecto, propuesta de la arquitectura y del  ASD - Adaptive Software Development presupuesto del cliente.  AUP - Agile Unified Process ELABORACIÓN: Confirmación de la idoneidad de  Crystal la arquitectura.  DSDM - Dynamic Systems Development CONSTRUCCIÓN: Desarrollo incremental del Method sistema, siguiendo las prioridades funcionales de  Scrum los implicados.  XBreed TRANSICIÓN: Validación e implantación del sistema. Por ejemplo, el principio de desarrollo ágil iterativo e incremental, tiene reflejo en ciclos de 30 días empleados por scrum, o de entre 1 y 4 CRYSTAL meses empleado por los modelos Cristal. Concebido por Alistair Cockburn, este modelo no describe una metodología cerrada, sino un ASD conjunto de ellas, junto con los criterios para seleccionar y adecuar la más apropiada al Adaptive Software Development es el modelo de proyecto. Los parámetros para determinarla son implementación de patrones ágiles para de- la criticidad y el tamaño del sistema que se va a sarrollo de software, diseñado por Jim Highsmith, construir. que materializa las fases de la gestión ágil de la siguiente forma: 32 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 33. Gestión de proyectos ágil: conceptos Es un modelo que estuvo representado en la firma del Manifiesto Ágil: Arie van Bennekum, firmante del manifiesto, era miembro del consorcio en Benelux, consultor y formador de DSDM. En 2001, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y se consideró una metodología ágil; y aunque mantuvo las siglas, cambió la denominación original (Dynamis Systems Development Method) por Framework for Business Centred Development. Procesos del ciclo de desarrollo DSDM El ciclo de desarrollo de DSDM está compuesto Los criterios empleados para la medición de estos de 5 fases, precedidas de un pre-proyecto y un parámetros son: post-proyecto. Criticidad (dimensión de las pérdidas que 1. Pre-proyecto ocasionaría un malfuncionamiento del sistema) 2. Estudio de viabilidad 3. Estudio de negocio 1 (c): Pérdida de confort o usabilidad. 4. Iteración de modelado funcional 2 (d): Pérdidas económicas moderadas. 5. Iteración de diseño y desarrollo 3 (e): Pérdidas económicas graves. 6. Implementación 4 (l): Pérdida de vidas humanas. 7. Post-desarrollo Estos criterios corresponden a los niveles de integridad de un sistema definidos por el estándar IEEE 1012-1998. Dimensión. Crystal determina el tamaño del sistema por el nº de personas empleadas en su desarrollo. (6 - 20 - 40 - 80) Fundamentos de Crystal:  Desarrollo iterativo e incremental.  Duración máxima de una iteración: 4 meses. Recomienda duraciones entre 1 y 3 meses.  Especial énfasis en la importancia de las  personas sobre los procesos. Especial énfasis en la comunicación directa. SCRUM  Modelo abierto a la adaptación e introducción Jeff Sutherland en 1993 trabajaba en Easel de prácticas de otros modelos ágiles Corporation (compañía que en los macrojuegos (eXtreme Programming, Scrum...) de compras y fusiones se integraría en VMARK, y luego en Informix y finalmente en Ascential DSDM Software Corporation). Tras conocer el trabajo de Nonaka y Takeuchi, Jeff identificó paralelismos con la industria del software, y aplicó un modelo DSDM es el acrónimo que dá nombre a un de desarrollo ágil, iterativo e incremental para modelo de procesos para desarrollo de sistemas desarrollar y mantener sistemas de software. de software, concebido por el DSDM Consortium, que se fundó en Inglaterra en 1994, y que En 1996 lo presentó junto con Ken Schwaber actualmente tiene presencia en Inglaterra, como proceso formal para gestión del desarrollo EE.UU., Benelux, Dinamarca, Francia y Suiza; y de software en OOPSLA 96, con el nombre que con interés y contactos para futuras Nonaka y Takeuchi habían dado a estos equipos representaciones en Australia, India y China [...] 2005-2009 – ScrumManager - http://www.scrummanager.net 33
  • 34. Gestión de proyectos ágil: conceptos de trabajo: "Scrum", por la comparación que  La gestión ágil se basa en los principios del 6 hicieron con los equipos de Rugby manifiesto ágil y centra el valor:  Más en las personas y su interacción que en los procesos y las herramientas  Más en los resultados que funcionan que en la documentación exhaustiva  Más en la colaboración con el cliente que en la negociación contractual  Más en la capacidad de respuesta al cambio que en el seguimiento de un plan  El desarrollo ágil comprende cinco fases: concepto, especulación, exploración, revisión y cierre.  El desarrollo ágil surgió en empresas de Se basa en el principio ágil de desarrollo iterativo productos tecnológicos, fue identificado por e incremental. Nonaka y Takeuchi en los años 80 y a partir Al período de trabajo para desarrollar un de los 90 diferentes profesionales del incremento de producto se lo denomina “sprint”, y desarrollo del software incorporaron sus se recomienda una duración de 30 días, si bien principios en sus entornos de trabajo. pueden contemplarse casos de hasta 60 días De esas implementaciones ágiles, las que (según Ken Schwaber, o 45 según Jeff abordan la gestión del proyecto son: ASD, Shuterland). AUP, Crystal, DSDM, Scrum. Establece una reunión al inicio de cada sprint para determinar el trabajo que se va a realizar, otra al final para evaluar el resultado, y revisiones diarias que realiza el equipo en su auto-gestión. XBreed – Agile Enterprise Propuesto por Mike Breedle, que colaboró con Ken Schwaber en la definición de Scrum, es una combinación de Scrum para la gestión del proyecto, y Extreme Programming como prácticas de desarrollo. Esta es una combinación comúnmente empleada independientemente de su definición como Xbreed que hasta la fecha no ha tenido especial relevancia. También denominado “Agile Enterprise”. Resumen  La gestión ágil de proyectos no es una gestión de anticipación (requisitos, diseño, planificación y seguimiento) sino de adap- tación (visión, exploración y adaptación).  La gestión ágil tiene como objetivos: valor, reducción del tiempo de desarrollo, agilidad, flexibilidad y fiabilidad. 6 Scrum es el nombre que se dá en Rugby a una determinada formación del equipo. 34 2005-2009 – ScrumManager - http://www.scrummanager.net
  • 35. Gestión de proyectos: ¿formal o ágil?
  • 37. Gestión de proyectos: ¿formal o ágil? ¿Ágil, clásica, predictiva …? Al surgir en los 80 una nueva forma de gestionar proyectos, se hizo necesario añadir un “apellido” al término “gestión de proyectos” para matizar si se refiere a la nueva o a la de siempre. La nueva, al autodenominarse ágil, obligó a dar un apellido al modelo de gestión de proyectos que hasta entonces, por único, no lo había nece- sitado. Características de la gestión Las denominaciones empleadas para cada tipo son: de proyectos predictiva Estas premisas han dado dos características a la Clásica gestión de proyectos predictiva: Tradicional Gestión de proyectos Predictiva 1.- Universalidad Formal Los proyectos, pese a su diversidad, comparten Pesada patrones comunes de ejecución. Las prácticas de gestión se basan en estos patrones comunes y resultan válidas para cualquier tipo de proyecto. Ágil Gestión de proyectos Adaptable Adaptativa En algunos ámbitos, hay cierta rivalidad acadé- mica o profesional entre defensores de uno y otro modelo. Preferimos por tanto no emplear el término “pesado” que puede aportar connota- ciones peyorativas. También preferimos no emplear “adaptativa” y usar en su lugar “adaptable”, para evitar un anglicismo innecesario. 2.- Carácter predictivo La gestión clásica define con detalle cuál es el “producto previsto” y elabora un plan de Premisas de la gestión de desarrollo, a partir del cual calcula costes y fechas. proyectos predictiva Durante la ejecución realiza actividades de seguimiento y vigilancia para evitar desviaciones sobre lo planificado. Premisas sobre las que se desarrolló la gestión Hay otras premisas de proyectos tradicional: 1.- Todos los proyectos mantienen caracterís- ticas y comportamientos regulares (Meter Norden 1960) Las dos premisas que cimentan el desarrollo de la gestión de proyectos: 2.- El objetivo de la ejecución de un proyecto  Todos los proyectos comparten idénticos es lograr el producto previsto en el tiempo patrones de ejecución. planificado sin desbordar los costes  El objetivo es conseguir el producto definido estimados. en costes y fechas. son cuestionables: 2005-2009 – ScrumManager - http://www.scrummanager.net 37
  • 38. Gestión de proyectos: ¿formal o ágil? 1.- No hay una forma única y válida para Se pedía un proyecto, pero no se quería gestionar cualquier tipo de proyecto garantizar la ejecución de un plan, sino obtener el máximo valor en las líneas marcadas. Es cierto que muchas características que dife- Hay proyectos en los que importa más el valor y rencian unos proyectos de otros son superficiales la innovación que el cumplimiento del plan. y resultan indiferentes para el modelo de gestión; pero hay otras que permiten adoptar estrategias de gestión muy diferentes en cada caso. La gestión predictiva pide al equipo el Características diferenciales: cumplimiento del plan. La gestión adaptable pide al equipo el  Componente innovador que se espera del mayor valor posible para una visión de resultado. producto  Grado de estabilidad de los requisitos durante el desarrollo.  Coste de prototipado.  Maleabilidad del producto para modificar su funcionalidad una vez desarrollado. La gestión de proyectos predictiva, al auto- considerarse válida para cualquier proyecto no contempla que según las características del proyecto, puedan resultar más apropiados otros criterios de gestión.  Conseguir el mayor valor innovador del producto no es uno de sus objetivos, y por tanto no aplica prácticas diferentes según el grado innovador que se desee.  Considera que los requisitos deben permanecer estables durante la ejecución. Si no ocurre esto presupone que se debe a deficiencias en el proceso de la fase de ¿Cuándo y por qué emplear requisitos; porque no contempla posibles evoluciones rápidas o inestabilidades del uno u otro estilo de gestión? entorno tecnológico o de negocio. Para obtener los mayores beneficios que cada  El objetivo es la eficiencia, el cumplimiento estilo de gestión puede ofrecer, éste tiene que ser del plan, y no el valor del producto. Desde compatible no sólo con las características del este punto de vista, el re-trabajo siempre es proyecto, sino también con las de la organización caro. No se considera la relación entre el que las va a aplicar. coste del re-trabajo y el valor proporcionado. 2.- Hay proyectos en los que no se quiere Características del proyecto “hacer el producto descrito en las fechas Las características relevantes para decidir el y con los costes estimados” estilo de gestión más adecuado son:  Principal prioridad de negocio.  Estabilidad de los requisitos. Cuando en 1978 la dirección de Honda encargó el  Rigidez del producto. diseño de un nuevo automóvil, sólo dió dos  Coste de prototipado. instrucciones al equipo de ingenieros:  Criticidad del sistema. “Primero: necesitamos un concepto de automóvil  Tamaño del sistema. completamente diferente a lo que cualquier otra compañía haya hecho nunca; y segundo: debe El orden expuesto se corresponde con nuestro ser un coche económico, pero no barato”. criterio de relevancia, siendo por tanto la prioridad de negocio la principal razón de compatibilidad o El resultado fue el Honda Civic. 38 2005-2009 – Navegapolis - http://www.navegapolis.net
  • 39. Gestión de proyectos: ¿formal o ágil? incompatibilidad, y el tamaño del sistema la Por supuesto los dos objetivos son deseables, menos relevante. pero hay que elegir, porque simplemente son excluyentes. No se pueden planificar diagramas Por la relativa novedad de la gestión ágil, estos de Gantt o rutas críticas sobre una visión general. criterios no están aún consensuados. Así por ejemplo mientras algunos textos opinan que el Cuanto mayor valor se desea en uno u otro tamaño o la criticidad del sistema son aspectos extremo (valor o predicción), más contraprodu- muy relevantes, hay opiniones autorizadas en cente resulta emplear el estilo de gestión sentido contrario: inadecuado.  Estabilidad de los requisitos En la "International Conference on Complex Systems 2006", Jeff Sutherland presentó el informe "Adaptive Engineering of Large Software Projects with Distributed / ¿Se puede obtener una descripción de requisitos Outsourced Teams " que demostraba los detallada al inicio del proyecto, y ésta se man- buenos resultados obtenidos con prácticas de tendrá estable durante el desarrollo? gestión ágiles en un desarrollo de grandes dimensiones: un millón de líneas de código O lo que es lo mismo, ¿Se puede saber con cer- Java, y un equipo de 50 personas distribuidos teza y detalle qué es lo que se quiere construir, en dos empresas ubicadas en países siendo improbable que cambien los criterios o las distintos. necesidades?  El modelo específico de Scrum desarrollado por Ken Schwaber para Software contempla Rigidez del producto el desarrollo de sistemas críticos, incluyendo ¿Cuán fácil resulta modificar el producto? los requerimientos de conformidad también como resultados entregables de las Esta es una razón importante, porque no es lo iteraciones junto con las funcionalidades a las mismo modificar software, circuitos electrónicos, que afectan. construcciones civiles… Modificar la estructura de una base de datos para añadir algunas tablas no es lo mismo que modificar la estructura de un edificio para rectificar el número de plantas. Coste de prototipado Otra cuestión relevante para el modelo de gestión ágil es la relación: coste de prototipar / valor conseguido para el producto. Este factor suele estar relacionado con la rigidez del producto. Prioridad de negocio Ver, tocar, e interactuar con las partes ya desa- rrolladas (o con simulaciones o prototipos) genera ideas y posibilidades que sobre el concepto inicial ¿Cuál es la principal prioridad para los intereses y el papel no llegan a concebirse. de negocio del cliente? ¿Qué tiene más importancia: el cumplimiento de El prototipado y el feed-back que proporciona son agendas y fechas o el valor innovador del extremadamente importantes, sobre todo en el producto? desarrollo de nuevos productos, o de sistemas innovadores. Este es el primer aspecto que se debe considerar. La gestión predictiva es un modelo construido y A medida que el equipo lo va “tocando” y especializado en garantizar el cumplimiento de “probando” surgen funcionalidades y posibilidades los planes. nuevas que aportan mayor valor al concepto inicial. La gestión adaptable es un modelo construido y especializado en dar el mayor valor posible al En este sentido, el argumento: “la forma más producto. eficiente de desarrollar un trabajo es hacerlo bien a la primera”, que se emplea con frecuencia para 2005-2009 – ScrumManager - http://www.scrummanager.net 39
  • 40. Gestión de proyectos: ¿formal o ágil? defender la validez de la gestión predictiva en  Producirá pérdidas económicas graves. cualquier proyecto, resulta tendencioso. La  Producirá pérdidas económicas. afirmación “per se” es obviamente cierta; pero  Fallará la finalidad principal del sistema. también son ciertas dos circunstancias rela-  Fallarán funcionalidades auxiliares del cionadas: sistema.  Se producirán fallos ergonómicos o de  se puede hacer “bien a la primera” cuando es comodidad para los usuarios. posible conocer con detalle el resultado sin Tamaño del sistema necesidad de hacer pruebas antes.  Las posibilidades al hacer un trabajo no son sólo “bien” o “mal”. Bien es un término amplio. Una de las principales bases del desarrollo ágil es Puede ser aceptable o suficientemente bien, la preferencia de la comunicación e interacción o lo mejor posible. directa de los implicados en el proyecto. Estos factores, junto con la relación entre coste Los grandes proyectos implican equipos nume- de prototipado y valor que aporta deben tenerse rosos y en ocasiones físicamente distantes, también en cuenta para elegir el modelo de circunstancias que dificultan la comunicación gestión más adecuado para el proyecto. directa. No obstante hay desarrollos incipientes de prácticas ágiles que implantan esquemas de agrupamiento y comunicación directa en estructuras celulares de equipos de hasta 6 personas. Condiciones de la organización Los elementos empleados por las organizaciones para ejecutar proyectos son: personas, procesos y tecnología. Los resultados de la gestión ágil dependen más del valor de las personas que de los procesos de la organización. Criticidad del sistema Las personas tienen características propias: ¿Cuál es el grado de criticidad del sistema que va a desarrollar?  Sus resultados son “sensibles” al entorno. La falta de motivación y los ambientes laborales Considerando por análisis de criticidad: hostiles reducen significativamente el valor intelectual del trabajo. La evaluación estructurada de las características  Cuando el trabajo depende del talento, la del producto (p. ej.: seguridad, complejidad, diferencia de valor entre los mediocres y los rendimiento) para determinar la severidad del mejores es muy grande. impacto de un fallo del sistema, de su degradación o de su no cumplimiento con los Adoptar modelos de desarrollo ágil no consiste requisitos o los objetivos del sistema. sólo en realizar las prácticas formales: equipo único, reuniones periódicas, desarrollo evolutivo O lo que es lo mismo: de los requisitos, etc. Si la organización mantiene un modelo de Si el sistema falla, se degrada o no consigue desarrollo basado en procesos y no en personas, realizar las funciones de los requisitos, ¿qué y no tiene alineadas con los principios ágiles: la impacto tiene en la seguridad o en el ren- cultura y estructura organizativa, no obtiene los dimiento? resultados propios del desarrollo ágil. Un ejemplo de criterios de criticidad, ordenados de mayor a menor, puede ser:  Causará daño a las personas.  Causará daño al medio ambiente. 40 2005-2009 – Navegapolis - http://www.navegapolis.net