El sitio web www.vuestroslibros.com utiliza cookies propias y de terceros para recopilar información que ayuda a optimizar su visita a sus páginas web.
No se utilizarán las cookies para recoger información de carácter personal. Usted puede permitir su uso o rechazarlo; también puede cambiar su configuración siempre que lo desee.
Encontrará mas información en nuestra política de Cookies.

ACEPTAR

 
Scrum.  Un método ágil para sus proyectos | 9782409012921 | Portada

SCRUM. UN MéTODO áGIL PARA SUS PROYECTOS

Jean-Paul SUBRA - Aurélien VANNIEUWENHUYZE

Precio: 45.00€

Oferta: 42.75€ (-5%)

Añadir a la cesta

Datos técnicos

  • ISBN 9782409012921
  • Año Edición 2018
  • Páginas 246
  • Encuadernación Rústica
  • Idioma Español
 

Sinopsis

Este libro se dirige a cualquier persona que desee aplicar o trabajar con Scrum. Su objetivo es presentar esta metodología ágil, que es la más utilizada, con sus aspectos teóricos y prácticos, para que los lectores dispongan de los conocimientos necesarios para aplicarla en sus futuros proyectos o para desempeñar eficazmente su rol en un proyecto Scrum, sea el que sea.

Después de un breve recordatorio sobre los métodos de gestión de proyectos tradicionales (Cascada y Ciclo en V) y sus límites, que han llevado al nacimiento de los enfoques ágiles, el autor presenta los métodos relacionados con Scrum, tanto desde un punto de vista de terminología como de las herramientas prácticas (Lean Management, Kanban incluso eXtreme Programming).

En los siguientes capítulos, después de haber visto una descripción del método Scrum que permite al lector tener rápidamente una visión global, el autor se detiene en los aspectos concretos relacionados con el equipo Scrum, es decir, los roles y las responsabilidades que derivan de ellos. A continuación explora en detalle las prácticas Scrum: formular y ordenar las necesidades, planificar y estimar la duración de las diferentes fases del proyecto, con el fin de construir los planes, gestionar el ciclo de vida y el seguimiento del proyecto y para terminar, probar lo que se ha desarrollado.

Además de aprender el método propiamente dicho, el autor ha querido dar al lector los elementos que le ayuden a abordar la problemática, algunas veces espinosa, del despliegue de Scrum y de la gestión del cambio que tiene como resultado.

Para terminar hay dos capítulos que permiten explorar las pistas para ir aún más lejos. Uno de ellos aborda las herramientas de software que pueden ser muy útiles en el marco de la gestión de los proyectos Scrum. El otro aporta respuestas concretas a las preguntas que habitualmente podemos hacernos durante la puesta en práctica de Scrum: ¿cuáles son los métodos para desplegarlo en varios equipos?, ¿cuáles son las diferencias y coincidencias entre Scrum y Kanban?, ¿cómo contractualizar con Scrum?

Este libro termina con un cuestionario que permitirá al lector comprobar sus conocimientos e identificar los puntos que pudiera no haber asimilado correctamente.

Í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 método á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 XP
6. Scrum, un mix de métodos
Descripción de Scrum
1. Nacimiento de Scrum
2. Scrum en pocas palabras
2.1 El equipo
2.2 Los tres pilares de Scrum
2.2.1 Transparencia
2.2.2 Inspección
2.2.3 Adaptación
2.3 Los eventos (ceremoniales)
2.3.1 Sprint
2.3.2 Reunión de planificación del Sprint
2.3.3 La Melé diaria
2.3.4 La revisión del Sprint
2.3.5 La retrospectiva del Sprint
2.4 Las herramientas
2.4.1 Backlog de Producto
2.4.2 Backlog del Sprint
2.4.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 Sus responsabilidades
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 Su personalidad y sus competencias
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 Sus responsabilidades
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 Su personalidad y sus competencias
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 Características
4.1.1 Auto-organizado y multi-disciplinar
4.1.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 historia técnica: ¿solución o declaración de fracaso?
3.5 Un método eficaz para realizar el Product Backlog: el Story Mapping
3.5.1 ¿Qué es el Story Mapping?
3.5.2 Story Mapping ilustrado por un ejemplo
3.6 Principios de priorización del Product Backlog
3.6.1 ¿Por qué priorizar?
3.6.2 Enfoque general de la priorización
3.6.3 Los factores que influyen en la priorización
3.6.4 Información general de los métodos de priorización
3.7 Profundizar sobre la priorización por temas
3.7.1 Theme Screening (Sondeo de los temas)
3.7.2 Theme Scoring (Medida de los temas)
3.7.3 Priorización de los temas usando pesos relativos
3.8 Profundizar sobre la priorización utilizando el modelo de Kano
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 de la Release
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 Primera etapa: presentación de las User Stories
6.3 Segunda etapa: ¿Qué trabajo se realizará durante el Sprint?
6.4 Tercera etapa: ¿Cómo realizar el trabajo previsto?
6.4.1 Estimación de las tareas
6.4.2 Asignación de las tareas
6.5 La gestión del tiempo
6.6 ¿Y la corrección de errores?
6.7 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 1: Kick Drop Start
9.5 Método "clásico"
9.6 Presentación "en estrella"
9.7 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?
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 verdadero método
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. Vencer las resistencias a la gestión del cambio
7.1 Resistencia por interés o política
7.2 Resistencia por confort
7.3 Resistencia por incapacidad o afectiva
8. Utilizar los Serious Games para facilitarla implementación
8.1 Para romper el hielo: red social "en papel"
8.2 El Marshmallow Challenge
9. 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
3. Otras herramientas útiles
3.1 Story mapping
3.2 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 Los principios
2.2.2 El nivel "Equipo"
2.2.3 El nivel "Programa"
2.2.4 El nivel "Gestión de porfolio"
2.2.5 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
4. Scrum y subcontratación
4.1 Contradicción n°1: El manifiesto ágil
4.2 Contradicción n°2: El método en sí mismo
4.3 Contradicción n°3: Las penalizaciones
4.4 Crear condiciones de confianza
4.5 Responder a una oferta
4.6 Implantación de un Plan de garantía de la calidad
4.7 Subcontratación por Sprint
4.7.1 ¿Cómo calcular el coste de un Sprint?
4.7.2 ¿Qué sucede con las User Stories no entregadas?
4.7.3 Gestión de errores y "no validación" de User Stories
4.8 Diferentes formas de contrato previsto
4.8.1 Costes variables
4.8.2 Costes fijos, perímetro variable
4.8.3 Costes fijos, perímetro fijo
4.8.4 Costes fijos, perímetro fijo pero con ajuste
4.8.5 Presupuesto por iteración
4.8.6 Uso de un margen de beneficio
4.8.7 Implantación de penalizaciones
4.8.8 Trabajo colaborativo
4.8.9 Money For Nothing (pagar por nada) y Change For Free (cambio de oferta)
4.9 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

 

2018 © Vuestros Libros Siglo XXI | Desarrollo Web Factor Ideas

Producto añadido al carrito.

Si desea ver la cesta de la compra haga click aquí.