1. Manuales
  2. Scrum - Un método ágil para sus proyectos (2ª edición)

Scrum Un método ágil para sus proyectos (2ª edición)

  • Acceso ilimitado 24/7
  • Todos los libros online de ENI
  • Novedades todos los meses
  • Acceso 100% online
  • Disponible
  • Envío gratis a partir de 25 € de compra
  • Versión online gratis
  • Acceso gratuito a todos nuestros libros online durante 1 hora por toda compra
  • Consulta inmediata
  • Versión HTML online
  • Acceso ilimitado 24/7

Presentación

Este libro está dirigido a todos los que deseen implementar o trabajar con Scrum. Su objetivo es presentar este método ágil, que además es el más utilizado, en sus aspectos teóricos y prácticos para que los lectores tengan el conocimiento necesario para implementarlo en sus futuros proyectos o para realizar de manera efectiva su función, sea cual sea esta, en un proyecto Scrum. Esta nueva edición se actualiza según la versión de la Guía oficial de Scrum de noviembre de 2017.

Después de un breve recordatorio sobre los métodos tradicionales de gestión de proyectos (Cascade y Cycle in V) y los límites que llevaron al nacimiento de enfoques ágiles, el autor presenta métodos relacionados con Scrum, tanto en términos de conceptos como herramientas prácticas (Lean Management, Kanban e incluso eXtreme Programming).

En los siguientes capítulos, después de haber hecho una descripción general del método Scrum que permite al lector tener una visión general rápida, el autor se detiene en los detalles del equipo Scrum con los roles y responsabilidades que contiene. Después explora las prácticas de Scrum en detalle, para formular y ordenar las necesidades, planificar y estimar la duración de las diferentes fases del proyecto para construir planes, administrar el ciclo de vida y hacer el seguimiento del proyecto y finalmente probar lo que se está desarrollando.

Además de este aprendizaje propiamente dicho del método, el autor ha optado por proporcionar al lector elementos que lo ayudarán a abordar este problema, a veces espinoso, del despliegue de Scrum y la gestión del cambio resultante.

Finalmente, dos capítulos nos permiten explorar caminos para ir más allá. Uno aborda las herramientas de software que pueden ser muy útiles en el contexto de la gestión de proyectos de Scrum. El otro aporta respuestas concretas a las preguntas que a menudo se pueden formular en la implementación práctica de Scrum, como por ejemplo cuáles son los métodos para implementarlo en varios equipos, cuáles son las diferencias y aspectos complementarios entre Scrum y Kanban, qué relación existe entre Scrum y DevOps o cómo establecer contratos con Scrum.

Finalmente, este libro termina con un cuestionario que permitirá al lector verificar su nivel de conocimiento e identificar los puntos que pudiera no haber asimilado correctamente. Hay elementos adicionales disponibles para descargar en el sitio web www.ediciones-eni.com.

Índice

  • Introducción
    • 1. Objetivo del libro
    • 2. Nuestro enfoque
    • 3. Estructura del libro
    • 4. Agradecimientos
  • De la gestión de proyectos tradicional a la agilidad
    • 1. Introducción
    • 2. Algunos hechos y cifras
    • 3. El modelo de gestión de proyecto "en cascada"
    • 4. El modelo (o ciclo) en V
      • 4.1 La teoría
      • 4.2 La puesta en práctica del modelo en V
      • 4.3 Los roles
      • 4.4 Noción de efecto túnel
    • 5. La agilidad en el corazón de los proyectos
      • 5.1 Un poco de historia
      • 5.2 Los valores
      • 5.3 Los 12 principios subyacentes
      • 5.4 La agilidad no significa anarquía
    • 6. Scrum, un marco de trabajo ágil
    • 7. Información, formación y certificaciones
    • 8. Para concluir
  • Lean, Kanban y eXtreme Programming
    • 1. Un capítulo necesario
    • 2. Relación de parentesco entre los métodos
    • 3. El Lean Management
      • 3.1 Objetivo de Lean
      • 3.2 Los 14 principios de Lean
    • 4. Kanban
      • 4.1 Principios de Kanban
      • 4.2 Kanban para el desarrollo de software
      • 4.3 Kanban y Scrum
    • 5. El método XP o eXtreme Programming
      • 5.1 Los principios básicos
      • 5.2 Las prácticas de eXtreme Programming
        • 5.2.1 Entregas frecuentes
        • 5.2.2 Ritmo duradero
        • 5.2.3 Presencia del cliente
        • 5.2.4 Diseño sencillo
        • 5.2.5 Implementación de las reglas de codificación
        • 5.2.6 El equipo es responsable del código
        • 5.2.7 Uso de pruebas unitarias
        • 5.2.8 Prueba de aceptación
        • 5.2.9 Implantación de la integración continua
        • 5.2.10 Realizar la refactorización del código
        • 5.2.11 Programación en parejas (Pair Programming)
        • 5.2.12 Estimación con ayuda del Planning Poker
        • 5.2.13 Uso de metáforas y analogías
      • 5.3 Ciclo de eXtreme Programming
    • 6. Scrum, un mix de métodos
  • Descripción de Scrum
    • 1. Nacimiento de Scrum
    • 2. Scrum en pocas palabras
      • 2.1 Los valores Scrum
      • 2.2 El equipo
      • 2.3 Los tres pilares de Scrum
        • 2.3.1 Transparencia
        • 2.3.2 Inspección
        • 2.3.3 Adaptación
      • 2.4 Los eventos (ceremoniales)
        • 2.4.1 El Sprint
        • 2.4.2 La reunión de planificación del Sprint
        • 2.4.3 La melé diaria
        • 2.4.4 La revisión del Sprint
        • 2.4.5 La retrospectiva del Sprint
      • 2.5 Las herramientas
        • 2.5.1 Backlog de Producto
        • 2.5.2 Backlog del Sprint
        • 2.5.3 Seguimiento del progreso
    • 3. Ciclo de vida de Scrum
    • 4. Coste, plazo y perímetro
    • 5. Conclusión
  • El equipo Scrum
    • 1. El equipo, aspecto central de Scrum
      • 1.1 Equipo auto-organizado
      • 1.2 Equipo pluridisciplinar
    • 2. El Scrum Master
      • 2.1 Las responsabilidades del Scrum Master
        • 2.1.1 Aplicación de Scrum
        • 2.1.2 Eliminar los obstáculos
        • 2.1.3 Optimizar las interacciones
        • 2.1.4 Líder del cambio
      • 2.2 La personalidad y las competencias del Scrum Master
        • 2.2.1 Conocer Scrum
        • 2.2.2 Ser un líder
        • 2.2.3 Ser comunicativo
        • 2.2.4 Tener capacidades de mediación
        • 2.2.5 Jugar a la transparencia
    • 3. El Product Owner
      • 3.1 Las responsabilidades del Product Owner
        • 3.1.1 Crear la visión del producto
        • 3.1.2 Gestionar el Product Backlog
        • 3.1.3 Maximizar el valor del producto y del trabajo del equipo
        • 3.1.4 Definir el plan de Release
        • 3.1.5 Implicación en el proceso Scrum
        • 3.1.6 Aceptar o no el resultado de un Sprint
        • 3.1.7 Sus poderes y límites
      • 3.2 La personalidad y las competencias del Product Owner
        • 3.2.1 Tener conocimientos funcionales
        • 3.2.2 Ser organizado
        • 3.2.3 Tener capacidades de toma de decisión
    • 4. El equipo de realización
      • 4.1 Aspectos generales
      • 4.2 Características
        • 4.2.1 Auto-organizado y multi-disciplinar
        • 4.2.2 Tamaño del equipo
    • 5. ¿ Y qué sucede con el resto de roles ?
      • 5.1 La desaparición del jefe de proyecto
      • 5.2 El resto de roles
    • 6. Construir correctamente el equipo: algunas pistas
    • 7. Crear las condiciones del éxito
      • 7.1 Reunir para ganar
      • 7.2 Caso de un equipo fragmentado
    • 8. Conclusión
  • Construir y priorizar el Product Backlog
    • 1. ¿ Por qué invertir en el Product Backlog ?
    • 2. La pieza básica del Product Backlog: la User Story
    • 3. ¿ Cómo redactar las User Stories y Epics ?
      • 3.1 Regla de las 3C
      • 3.2 Redactar una buena User Story: el principio INVEST
      • 3.3 Errores habituales
      • 3.4 La Story técnica: ¿ solución o declaración de fracaso ?
      • 3.5 Identificar las funcionalidades clave con el Product Box
        • 3.5.1 Objetivos
        • 3.5.2 Modo operativo
      • 3.6 Un método eficaz para realizar el Product Backlog: el Story Mapping
        • 3.6.1 ¿ Qué es el Story Mapping ?
        • 3.6.2 Story Mapping ilustrado por un ejemplo
      • 3.7 Principios de priorización del Product Backlog
        • 3.7.1 ¿ Por qué priorizar ?
        • 3.7.2 Enfoque general de la priorización
        • 3.7.3 Los factores que influyen en la priorización
        • 3.7.4 Información general de los métodos de priorización
      • 3.8 Profundizar sobre la priorización por temas
        • 3.8.1 Theme Screening (sondeo de los temas)
        • 3.8.2 Theme Scoring (medida de los temas)
        • 3.8.3 Priorización de los temas usando pesos relativos
      • 3.9 Profundizar sobre la priorización utilizando el modelo de Kano
      • 3.10 Zoom sobre el método MoSCoW
      • 3.11 Zoom sobre el método WSJF
    • 4. Gestionar su Backlog en la práctica
    • 5. Conclusión
  • Planificar y estimar
    • 1. Prácticas que no se deben descuidar
    • 2. Por qué la planificación tradicional falla
    • 3. Horizontes de planificación
    • 4. Herramientas de estimación
      • 4.1 T-Shirt sizing
      • 4.2 Los story points
      • 4.3 Entonces, ¿ story point o d/H ?
      • 4.4 Noción de velocidad
      • 4.5 ¿ Cómo inicializar la velocidad ?
        • 4.5.1 Implantación de un proyecto piloto
        • 4.5.2 Elegir por feeling
        • 4.5.3 Estimación de la velocidad a partir del histórico
      • 4.6 ¿ Quién estima ?
      • 4.7 Un método práctico de estimación: el Planning Poker
        • 4.7.1 El desarrollo del Planning Poker
        • 4.7.2 Beneficios y riesgos
        • 4.7.3 Errores comunes
        • 4.7.4 Descomponer para estimar correctamente: Elephant carpaccio
    • 5. Planificación de Release
      • 5.1 Tener un objetivo claro
      • 5.2 Tener un Product Backlog priorizado
      • 5.3 Estimar el Product Backlog
      • 5.4 Conocer la velocidad del equipo
      • 5.5 Definir el fin
      • 5.6 Definir la duración de los Sprints
      • 5.7 Crear el plan de Release
    • 6. Conclusión
  • La vida de un Sprint
    • 1. Introducción
    • 2. ¿ Cuál es la duración para los Sprints ?
    • 3. ¿ Debe haber un Sprint 0 ?
    • 4. El ritmo del Sprint: vista de conjunto
    • 5. Preparación del Sprint
      • 5.1 Entorno de trabajo
      • 5.2 Equipo
      • 5.3 Definición de "Terminado"
    • 6. Reunión de planificación de Sprint
      • 6.1 ¿ Por qué la presencia del Product Owner es importante ?
      • 6.2 Definition of Ready
      • 6.3 Primera etapa: presentación de las User Stories
      • 6.4 Segunda etapa: ¿ qué trabajo se realizará durante el Sprint ?
      • 6.5 Tercera etapa: ¿ cómo realizar el trabajo previsto ?
        • 6.5.1 Estimación de las tareas
        • 6.5.2 Asignación de las tareas
      • 6.6 La gestión del tiempo
      • 6.7 ¿ Y la corrección de errores ?
      • 6.8 Backlog Grooming
    • 7. Melé diaria (Scrum Meeting/Daily Scrum)
      • 7.1 Un protocolo a respetar
      • 7.2 Una melé eficaz y útil
      • 7.3 El Scrum Master siempre a la escucha
      • 7.4 Seguimiento del avance
      • 7.5 No tengo nada más que hacer
      • 7.6 ¿ Se alcanzará el objetivo del Sprint ?
    • 8. La revisión del Sprint (Sprint Review)
      • 8.1 ¿ Qué, quién, cuánto tiempo ?
      • 8.2 Un objetivo, una motivación
      • 8.3 Demostrar lo que no es demostrable
    • 9. La retrospectiva del Sprint
      • 9.1 Un método que le va a ayudar
      • 9.2 Estado de ánimo
      • 9.3 Entorno de la retrospectiva
      • 9.4 Método número 1: Kick Drop Start
      • 9.5 Método "clásico"
      • 9.6 Presentación "en estrella"
      • 9.7 El SpeedBoat
      • 9.8 Otros métodos
    • 10. Dejar al equipo descansar
    • 11. ¿ Y si comenzamos de nuevo ?
  • Probar en modo Ágil
    • 1. Adoptar Scrum: ¿ cuál es el impacto en la estrategia de pruebas ?
    • 2. Tipologías de pruebas
      • 2.1 Pruebas funcionales de validación
        • 2.1.1 Criterios de validación
        • 2.1.2 Los datos de prueba y escenarios
        • 2.1.3 Las pruebas de validación y las User Stories
      • 2.2 Pruebas de no-regresión
      • 2.3 Pruebas de IHM (interfaz hombre-máquina)
      • 2.4 Pruebas funcionales "de principio a fin"
      • 2.5 Pruebas de componentes
      • 2.6 Pruebas unitarias
      • 2.7 Test Driven Development
      • 2.8 Acceptance Test Driven Development
    • 3. Anti-pattern: el cono del helado
    • 4. La pirámide de pruebas ideal
      • 4.1 Encontrar tiempo para escribir
      • 4.2 ¿ Hay que escribir las pruebas de todas las User Stories ?
      • 4.3 ¿ Cómo escribir las pruebas ?
      • 4.4 Definition of Done y prueba de aceptación
    • 5. Los testers en el equipo Scrum
      • 5.1 La prueba forma parte del equipo
      • 5.2 Tester Ágil: una profesión en cambio
    • 6. En conclusión: escriba las pruebas
  • Consejos para desplegar Scrum
    • 1. ¿ Cómo llevar a cabo el cambio a Scrum ?
    • 2. Situación actual
      • 2.1 Adopción de los métodos ágiles
        • 2.1.1 Scrum ampliamente implementado
        • 2.1.2 Las motivaciones para la adopción de Scrum
        • 2.1.3 ¿ Cómo se practica Scrum ?
        • 2.1.4 Éxitos y desafíos
      • 2.2 Un resultado positivo
    • 3. La motivación
    • 4. ¿ Big-Bang o implementación progresiva ?
    • 5. Scrum y la organización existente
      • 5.1 ¿ Qué hacer con las responsabilidades existentes ?
      • 5.2 La estructura
    • 6. Terminar con las ideas recibidas
      • 6.1 Scrum no es un enfoque estructurado
      • 6.2 No hay noción de planificación
      • 6.3 Scrum destierra la documentación
      • 6.4 Con Scrum, pasamos demasiado tiempo en reuniones
    • 7. El soporte de la dirección
    • 8. Vencer las resistencias a la gestión del cambio
      • 8.1 Resistencia por interés o política
      • 8.2 Resistencia por confort
      • 8.3 Resistencia por incapacidad o afectiva
    • 9. Utilizar los Serious Games para facilitar la implementación
      • 9.1 Para romper el hielo
        • 9.1.1 El secreto del éxito
        • 9.1.2 Clasificarse por edad
        • 9.1.3 La red social en el papel
      • 9.2 El Marshmallow Challenge
    • 10. Hacerse acompañar
    • 11. Nuestros consejos a modo de conclusión
  • Scrum con ayuda de un software
    • 1. ¿ Es necesario obligatoriamente utilizar un software ?
    • 2. Descripción de las herramientas de gestión de proyectos Scrum
      • 2.1 Jira
      • 2.2 Axosoft
      • 2.3 iceScrum
      • 2.4 Tuleap
    • 3. Otras herramientas útiles
      • 3.1 Story Mapping
      • 3.2 Para las retrospectivas de equipos distribuidos: IdeaBoardz
      • 3.3 Herramientas colaborativas
    • 4. Conclusión
  • Para ir más lejos
    • 1. Introducción
    • 2. Escalamiento de Scrum
      • 2.1 LeSS
        • 2.1.1 Los principios básicos
        • 2.1.2 ¿ Qué es diferente de Scrum en LeSS ?
        • 2.1.3 Nuestro consejo sobre LeSS
      • 2.2 SAfe
        • 2.2.1 Introducción
        • 2.2.2 Las fundaciones
        • 2.2.3 El nivel "Equipo"
        • 2.2.4 El nivel "Programa"
        • 2.2.5 El nivel "Gestión de porfolio"
        • 2.2.6 Nuestro consejo sobre SAFe
      • 2.3 El método "Spotify"
        • 2.3.1 Descripción del modelo
        • 2.3.2 El equipo
        • 2.3.3 Las tribus
        • 2.3.4 Las corporaciones y los capítulos
        • 2.3.5 Nuestro consejo sobre el modelo Spotify
    • 3. Scrum y Kanban
      • 3.1 Diferencias entre los dos métodos
      • 3.2 Mezclar o no los enfoques
        • 3.2.1 Algunas consideraciones generales
        • 3.2.2 Un híbrido cada vez más usado: ScrumBan
        • 3.2.3 Hacer la elección
    • 4. Scrum y DevOps
    • 5. Scrum y subcontratación
      • 5.1 Contradicción
      • 5.2 Crear condiciones de confianza
      • 5.3 Responder a una oferta
      • 5.4 Implantación de un plan de garantía de la calidad
      • 5.5 Subcontratación por Sprint
        • 5.5.1 ¿ Cómo calcular el coste de un Sprint ?
        • 5.5.2 ¿ Qué sucede con las User Stories no entregadas ?
        • 5.5.3 Gestión de errores y "no validación" de User Stories
      • 5.6 Diferentes formas de contrato previsto
        • 5.6.1 Costes variables
        • 5.6.2 Costes fijos, perímetro variable
        • 5.6.3 Costes fijos, perímetro fijo
        • 5.6.4 Costes fijos, perímetro fijo pero con ajuste
        • 5.6.5 Presupuesto por iteración
        • 5.6.6 Uso de un margen de beneficio
        • 5.6.7 Implantación de penalizaciones
        • 5.6.8 Trabajo colaborativo
        • 5.6.9 Money For Nothing (pagar por nada) y Change For Free (cambio de oferta)
      • 5.7 Ejemplo de contrato tipo
  • Verifique sus conocimientos
    • 1. ¿ Por qué este cuestionario ?
    • 2. Las preguntas
    • 3. Las respuestas
    • 4. La hora del resultado
    • 5. Es momento de dejarlo
    • índice

Autor

Jean-Paul SUBRAMás información

Jean-Paul SUBRA es ingeniero de la Escuela Supélec (en Francia) y trabaja desde hace más de 20 años en la industria de software. Después de más de 10 años como responsable de equipos de desarrollo en DSI y otros fabricantes de software, desde 2009 ejerce su actividad en entornos ágiles. En 2015, inicío su actividad como consejero, SoftMethods, cuya misión es ayudar a las empresas que producen software a implantar los métodos más eficaces posibles, de los que Scrum forma parte.

Características

  • Nivel Medio a Experto
  • Número de páginas 282 páginas
  • Publicación enero 2020
    • Encuadernación rústica - 17 x 21 cm
    • ISBN: 978-2-409-02398-9
    • EAN: 9782409023989
    • Ref. ENI: DPT3SCRU
  • Nivel Medio a Experto
  • Publicación enero 2020
    • HTML
    • ISBN: 978-2-409-02399-6
    • EAN: 9782409023996
    • Ref. ENI: LNDPT3SCRU

Descargas

Al completar este formulario, acepta recibir información y comunicaciones comerciales sobre nuestros productos y servicios. Puede darse de baja de nuestra newsletter en cualquier momento. Si desea conocer más información acerca de nuestra política de protección de datos, pulse aquí.
  • Descargar los ejemplos del libro (72,5 Ko)